PureBoard

Kurzer hat geschrieben:- Heißt das, dass PB Exen unter Windows in jedem Fall auf irgendwelche Windows DLLs angewiesen sind (auch wenn keien API Aufrufe im Code stecken)?

Ganz genau. Die ganzen Funktionen zum Erstellen von Fenstern und Gadgets basieren meistens auf APIs des Betriebssystems. Hier hast du eine kleine Übersicht: http://www.purebasic.fr/blog/?p=336

Wenn ich mit PB ein Hello World für die Konsole schreibe, dann werden folgende Libraries unter Linux hinzugelinkt: Das ist der Code: Unter Windows hat der selbe Code als Executable 5632 Bytes und es werden die Bibliotheken MSVCRT.DLL und KERNEL32.DLL geladen.

Ich würde Dir empfehlen einmal einen Blick auf BlitzMax aus der BlitzBasic-Familie zu werfen.

BlitzMax ist eine objektorientierte Weiterentwicklung des prozeduralen BlitzBasic, das genauso wie PureBasic plattform-unabhängig auf Windows, Linux und MacOS läuft. Außerdem ist BlitzMax vor 2 Monaten von seinem Schöpfer Mark Sibly als Open Source freigegeben worden. Wenn Du Dich kostenlos bei BlitzBasic registrierst, kannst Du Dir die Orginalversion von BlitzMax (oder auch BlitzPlus und Blitz3D) herunterladen. Eine Übersicht mit Linksammlung für Anfänger (inklusive wie man sich BlitzMax herunterlädt) gibt es hier.

Den Umstieg von PureBasic auf BlitzMax halte ich für einen Hobbyprogrammierer für wesentlich einfacher als den Umstieg auf C++. In BlitzMax wird man nicht gezwungen, objektorientiert zu programmieren. Man kann erst einmal wie gewohnt prozedural programmieren und sich mit der Programmiersprache vertraut machen, um sich dann langsam auf objektorientiertes Terrain vorzutasten...

Das ist auch ein guter Vorschlag. An BlitzMax hab ich gar nicht mehr gedacht, obwohl ich mir selbst damals schon BlitzBasic gekauft hatte, bevor ich zu Purebasic kam.

In C++ wird man übrigens auch nicht gezwungen objektorientiert zu programmieren.

Shardik hat geschrieben:Den Umstieg von PureBasic auf BlitzMax halte ich für einen Hobbyprogrammierer für wesentlich einfacher als den Umstieg auf C++. In BlitzMax wird man nicht gezwungen, objektorientiert zu programmieren. Man kann erst einmal wie gewohnt prozedural programmieren und sich mit der Programmiersprache vertraut machen, um sich dann langsam auf objektorientiertes Terrain vorzutasten...

NicTheQuick hat geschrieben:In C++ wird man übrigens auch nicht gezwungen objektorientiert zu programmieren.

Stimmt, das liest sich bei mir so als ob ich meine, dass der Umstieg auf C++ weniger einfach ist, weil man in C++ objektorientiert programmieren muß. Eigentlich hätte ein Absatz zwischen die beiden Sätze gehört, weil ich diese Implikation nicht beabsichtigte. Denn C++ wird von Verfechtern der objektorientierten Programmierung immer vorgeworfen, für Umsteiger aus der prozeduralen Programmierung schlecht geeignet zu sein, weil man eben auch weiterhin prozedural arbeiten kann und nicht gezwungen ist, objektorientiert zu arbeiten und angeblich nur eine komplette Umstellung der Denkweise zu guten objektorientierten Programmen führt...

Ich halte C++ für Hobbyprogrammierer für zu schwierig, weil C++ sehr komplex ist und nur ein täglicher Umgang damit zu einem effizienten Einsatz führen wird.

Das schlimmste an C++ sind ja die Compiler-Fehlermeldungen, die nicht immer auf die Zeile verweisen, in der der Fehler tatsächlich steckt. Aber das lernt man dann irgendwann auch, dass man einfach nur ein Semikolon in einer Header-Datei vergessen hat.

NicTheQuick hat geschrieben:Das schlimmste an C++ sind ja die Compiler-Fehlermeldungen, die nicht immer auf die Zeile verweisen, in der der Fehler tatsächlich steckt. Aber das lernt man dann irgendwann auch, dass man einfach nur ein Semikolon in einer Header-Datei vergessen hat.

Wenn der Compiler nicht in der lage ist die richtige Fehlerzeile zu ermitteln dann ist das ein sehr schlecht programmierter Compiler. Sehr unprofessionell wenn nicht mal die Zeile ermittelt werden kann.

Das sind seltene Fälle. Die Fehlermeldungen der Compiler sind meistens voll mit Informationen, die man erstmal lernen muss zu verstehen. Sie sind eben aussagekräftiger als die von Purebasic.
Das Problem mit dem Semikolon rührt daher, dass bei C/C++ ein Befehl mit einem Semikolon abgeschlossen wird. Hat man das Semikolon z.B. in der letzten Zeile in einer Headerdatei "a.h" vergessen und inkludiert diese in "a.cpp", dann entsteht der Fehler eben auch in "a.cpp", wenn dort ein neuer Befehl steht, der den letzten in "a.h" nicht sinnvoll ergänzen kann.

Wenn du diese Arbeitsweise als sehr schlecht programmierten Compiler empfindest, dann mach's besser. Bin gespannt.

NeoChris hat geschrieben:Wenn der Compiler nicht in der lage ist die richtige Fehlerzeile zu ermitteln dann ist das ein sehr schlecht programmierter Compiler. Sehr unprofessionell wenn nicht mal die Zeile ermittelt werden kann.

Der Compiler sieht keine Zeilen, weil es in c++ keine Zeilen im herkömmlichen Sinne gibt.

Ich habe meine Freizeit u.a. mit dem erfolglosen Versuch verbracht, dem DevCpp einen anderen Compiler unterzujubeln, der direkt gegen die Microsoft DLLs linkt (statt gegen eine 1 MiB große eigene Runtime DLL). Dummerweise kann ich mich in sowas immer ganz gut "verbeißen" - hat nur hier nicht viel gebracht, außer dass ich jetzt Visual Studio 8 Express auf ner virtuellen Maschine habe.

Eure weiteren Kommentare zu C++ find ich ziemlich hilfreich und der link zu BlitzMax war auch gut. Danke.