Ist es sinnvoll heute noch C++ anzufangen?

[Scheppertreiber]

Die Zeit wird kommen, dann ist GW-BASIC wieder in. goto wird heiliggesprochen
und OOP wird vom Papst verboten. Mal abwarten

[u_ser-l]

+fricky schrieb:

au ja, noch etwas basic, pascal, logo und prolog dazu, eine portion HTML und das ganze abgerundet mit einer prise Verilog. wohl bekomms!

mach dich nicht lustig!

das mit dem dynamischen Typsystem in C++ ist nicht nur ein Scherz. Es würde die Anwendungsmöglichkeiten von C++ enorm in Richtung rapid-prototyping und sogar scripting erweitern.

[JustAnotherNoob]

ich vergewissere dir, dass das zu 99.99% nicht passieren wird und zwar nicht, weil sie es "vergessen" haben.

[u_ser-l]

ich denke auch.

Einige Sprachen wie das neue Cobra von cobra-language.com erlauben ja wahlweise statische und dynamische Typisierung.

[Freddy Closer]

Keine neuen Beiträge Ist es sinnvoll heute noch C++ anzufangen?

Nein.

Fred closed.

[Paddy33]

Hi,

Ich finde auch, dass C++ schon so seine Tücken hat. Leider auch einige, in die selbst erfahrenere Programmierer oftmals tappen. Die Sprache hat zu viele mächtige Features, die den Leuten zu viel Freiheit an die Hand geben. So entstehen einfach zu viele Fehler und das wird mit dem kommenden C++0x Standard nicht besser, sondern eher noch im Gegenteil. Damit werden sie es endgültig erreichen, daß Niemand mehr durch diese Sprache durchblickt.

Ein weiterer, in diesem Thread noch nicht genannter, netter Fallstrick in C++ ist IMHO auch noch dieser Klassiker:

class MyClass {
	int *array;
	int len;
public:
	MyClass(int l) : len(l), array(new int[len]) {}
};

int main(int argc, char* argv[]) {
	MyClass test(10);
	return 0;
}

Aufgrund des hohen Verbreitungsgrads wird C++ noch nicht morgen verschwunden sein, bei vielen älteren, aber noch gepflegten, Projekten lohnt eine Neuprogrammierung wohl kaum aber neue Projekte werden heutzutage und zukünftig kaum noch in C++ realisiert meiner Erfahrung nach. Ausnahmen bestätigen auch hier natürlich die Regel.

[ibs]

aber neue Projekte werden heutzutage und zukünftig kaum noch in C++ realisiert meiner Erfahrung nach.

Nach deiner Erfahrung aus einer Firma?

C++ hat eben seine Bereiche gefunden und da ist es sehr erfolgreich (siehe Stellenausschreibungen, Freelancer, Firmen die Support und Tools anbieten usw.). Im Gegensatz zu früher wird C++ eben nicht mehr unbedingt überall eingesetzt. Aber das ist ein Prozess durch den viele Sprachen gehen.

Wenn man Desktopanwendungen entwickelt, die unter OS X und Windows laufen sollen, dann führt ja kaum ein Weg an C++ vorbei. C# ist vielleicht gut unter Windows, aber eben nicht unter OS X und das gleiche für Objective C nur andersrum (Java ist keine wirkliche Alternative, da es keine native GUI anbietet und einfach schmerzhaft bei der Verbreitung ist). In der Spieleprogrammierung ist C++ unangetastet. Im Embeddedbereich ist C++ auch sehr erfolgreich und im Scientificcomputing ist C++ die Topsprache.

Ich denke in 50 Jahren wird hier noch diskutiert werden, wann C++ denn nun ausstirbt.

(Übrigens wird es wohl eher immer lukrativer C++ Kenntnisse zu haben, wenn immer weniger Leute C++ kennen. Selbst wenn man von jetzt auf gleich alle neuen C++ Projekte einstellen würde, braucht man ja zur Wartung noch viele C++ Programmierer. Nicht umsonst führen COBOL Programmierer oft die Gehaltsstatistiken an!)

[general bacardi]

Paddy33 schrieb:

So entstehen einfach zu viele Fehler und das wird mit dem kommenden C++0x Standard nicht besser, sondern eher noch im Gegenteil.

Das befürchte ich leider auch. Wie dick werden C++ Lehrbücher wohl sein wenn der neue Standard draussen ist?
Disclaimer: Ich mag C++ und werde auch weiterhin in C++ programmieren.

[Dravere]

general bacardi schrieb:

Das befürchte ich leider auch. Wie dick werden C++ Lehrbücher wohl sein wenn der neue Standard draussen ist?

Gleich dick ...

... nur wirst du zwei davon haben

Grüssli

[+fricky]

u_ser-l schrieb:

das mit dem dynamischen Typsystem in C++ ist nicht nur ein Scherz. Es würde die Anwendungsmöglichkeiten von C++ enorm in Richtung rapid-prototyping und sogar scripting erweitern.

naja, ich wette das kann man in C++ schon heute, mit 'nem wilden gebräu aus template metaprogramming, preprocessor-tricks und RTTI, hinbekommen (wär 'ne idee für eine neue boost-library, wenn die nicht schon gibt). mit C++0x gibt's auch noch 'ne dynamic-typing-light version durch das mutierte 'auto' keyword.

[u_ser-l]

sicher, wenn man jede Funktion und jede Library-Fkt. mit einem wrapper von/nach void* versieht und alle Variablen void* deklariert und ständig hin- und hercastet, geht das schon heute. Ist aber nicht elegant und bläht den Programmcode auf, obwohl er durch Weglassen von Typangaben doch reduziert werden soll.

[ablach]

Herrlich, hab gerade den ganzen Thread gelesen und Tränen in den Augen
danke!

Artchi schrieb:

Es ist ja nicht so, das die C++-Fanboys sich jede Woche in Java-Foren rumtummeln und gegen Java stänkern. Denk mal darüber nach, wer hier von beiden Seiten Minderwertigkeitskomplexe hat?

Komisch, da es in dem Thread hier 19 Seiten lang um c vs c++ ging und die Ausgangsfrage "Ist es sinnvoll heute noch C++ anzufangen?" lautete

ibs schrieb:

Wenn man Desktopanwendungen entwickelt, die unter OS X und Windows laufen sollen, dann führt ja kaum ein Weg an C++ vorbei. C# ist vielleicht gut unter Windows, aber eben nicht unter OS X und das gleiche für Objective C nur andersrum (Java ist keine wirkliche Alternative, da es keine native GUI anbietet und einfach schmerzhaft bei der Verbreitung ist)

Da der Post noch aktuell ist: Das ist faktisch falsch:
Das einzig annehmbare Cross-platform GUI toolkit für c++ ist unbestreitbar QT (was du übrigens auch mit Java verwenden kannst), leider bietet QT weder auf Windows noch auf OS X eine gutaussehende native GUI.
Im Gegensatz zu Java, da Java Swing sowohl unter Windows als auch unter OS X (und auch unter GTK, leider nicht mit KDE) auf den nativen gui toolkits basiert. Die Java Unterstützung auf OS X ist perfekt (es gibt einen Grund, dass NeoOffice Java Swing als GUI benutzt für das OpenOffice backend), da sie ja auch von Apple entwickelt wurde. Ebenso kannst du damit rechnen, dass Java auf 100% aller OS X rechner vorhanden ist, da es mit dem Betriebssystem ausgeliefert und upgedated wird.
Und wenn man von C(++) kommt kann man ja immernoch SWT nehmen, dann hat man noch paar Abartigkeiten aus der alten Heimant

[ibs]

ablach schrieb:

ibs schrieb:

Wenn man Desktopanwendungen entwickelt, die unter OS X und Windows laufen sollen, dann führt ja kaum ein Weg an C++ vorbei. C# ist vielleicht gut unter Windows, aber eben nicht unter OS X und das gleiche für Objective C nur andersrum (Java ist keine wirkliche Alternative, da es keine native GUI anbietet und einfach schmerzhaft bei der Verbreitung ist)

Da der Post noch aktuell ist: Das ist faktisch falsch:
Das einzig annehmbare Cross-platform GUI toolkit für c++ ist unbestreitbar QT (was du übrigens auch mit Java verwenden kannst), leider bietet QT weder auf Windows noch auf OS X eine gutaussehende native GUI.

Wer redet von Cross-platform GUI toolkits? Man kommt eben oft leider doch nicht darum herum, die GUI für beide Systeme in den Systemtoolkits zu schreiben. OS X und Windows unterscheiden sich eben zu sehr in vielen Details, als dass man das in einem Rutsch erledigen könnte. Vor allem wenn man sich an die Guidelines der Paltformen halten will (was man muss, wenn man einen Sticker des Herstellers bekommen will). Das geht nicht mit einer einzigen GUI Library.

Wobei ich Qt dennoch recht gut finde. wxWidgets bietet aber ebenfalls native GUI. Aber wie gesagt, man kann nicht sinnvoll eine GUI für zwei so unterschiedliche Systeme basteln.

Die Java Unterstützung auf OS X ist perfekt (es gibt einen Grund, dass NeoOffice Java Swing als GUI benutzt für das OpenOffice backend), da sie ja auch von Apple entwickelt wurde. Ebenso kannst du damit rechnen, dass Java auf 100% aller OS X rechner vorhanden ist, da es mit dem Betriebssystem ausgeliefert und upgedated wird.

Windows ist hier problematisch und unter OS X weiß man auch nicht, wer welche Version hat. (Gibt leider genug Leute/Firmen, die keine automatischen Updates ausliefern). Da kann man bei C++ mit eigenen DLLs oder dem OS X .app System sehr einfach Anwendungen deployen.

(Man sieht, dass du hier offensichtlich mehr theoretische Erfahrung hast. Nach deinen Aussagen glaube ich kaum, dass du jemals kommerzielle Desktop Anwendungen entwickelt hast)

[Dravere]

ablach schrieb:

Das einzig annehmbare Cross-platform GUI toolkit für c++ ist unbestreitbar QT (was du übrigens auch mit Java verwenden kannst), leider bietet QT weder auf Windows noch auf OS X eine gutaussehende native GUI.

1. Was bitte ist annehmbar?
2. Weisst du eigentlich WIEVIELE Cross-Platform GUI Frameworks es in C++ gibt?

ablach schrieb:

Im Gegensatz zu Java, da Java Swing sowohl unter Windows als auch unter OS X (und auch unter GTK, leider nicht mit KDE) auf den nativen gui toolkits basiert.

ROFL, da hat jemand keine Ahnung. Auf den nativen GUI Toolkit. Klar, Java Swing gleicht auch so wahnsinnig dem Aussehen von der Windows GUI. Und wenn man auf das Windows Theme umstellt, wird oft vieles nicht unterstützt oder läuft einfach schief.

ablach schrieb:

Die Java Unterstützung auf OS X ist perfekt

Nochmals ROFL. Ja, in der Theorie, in der Praxis meistens nicht. Vor allem folgt die Auslieferung von neuen Versionen meistens extrem verspätet. Ich habe schon erlebt, dass MacOS X über ein Jahr hinten nach war mit der Java Version Auslieferung. Und dann hast du ein ziemliches Problem, da du nicht einfach irgendwo Java runterladen kannst.

Auch ist Java nicht so platformunabhängig wie viele es gerne möchten. Es stimmt zwar, dass man es nur einmal kompilieren muss und dann auf allen Platformen starten kann, aber wenn es zum Beispiel auf Windows funktioniert, heisst es noch lange nicht, dass es auch auf MacOS X oder Linux funktionieren wird.

Dein Name ist wirklich gut gewählt

Grüssli

[ablach]

ibs schrieb:

Wer redet von Cross-platform GUI toolkits? Man kommt eben oft leider doch nicht darum herum, die GUI für beide Systeme in den Systemtoolkits zu schreiben.

Wenn du die GUI eh für beide Systeme einzeln schreiben willst, warum willst du dich dann auf eine Sprache (C++) festlegen? Hindert dich doch niemand die Mac GUI in Obj-C und die Win GUI in C# zu implementieren?

Windows ist hier problematisch und unter OS X weiß man auch nicht, wer welche Version hat. [..]
(Man sieht, dass du hier offensichtlich mehr theoretische Erfahrung hast. Nach deinen Aussagen glaube ich kaum, dass du jemals kommerzielle Desktop Anwendungen entwickelt hast)

Ich habe schon einige Java (Swing) Anwendungen entwickelt und auf Windows und OS X Systemen deployt und hatte nie probleme mit der Verbreitung von Java. Java 1.5 ist auf allen Systemen ab 10.4 verfügbar und installiert, 10.3 wird eh nicht mehr supported von den meisten Anwendungen. Unter Windows sieht es ähnlich aus, ansonsten wird Java 1.5 eben als Systemanforderung angegeben (in meinem Fall geht der Windows-Installer und das Programm selbst auch sicher, dass Java installiert ist). Mit C# hab ich das gleiche "Problem".

Dravere schrieb:

1. Was bitte ist annehmbar?
2. Weisst du eigentlich WIEVIELE Cross-Platform GUI Frameworks es in C++ gibt?

Nein, ich hab sie nie gezählt Ich kenne aber die wichtigsten, und QT ist sehr gut, was anderes würde ich für crossplattformentwicklung in C++ nicht empfehlen, du?

ROFL, da hat jemand keine Ahnung. Auf den nativen GUI Toolkit. Klar, Java Swing gleicht auch so wahnsinnig dem Aussehen von der Windows GUI. Und wenn man auf das Windows Theme umstellt, wird oft vieles nicht unterstützt oder läuft einfach schief.

Ich weiß nicht wovon du redest, Swing benutzt die UXTheme API (oder wie die heißt) von Windows XP und verwendet die nativen XP Themes. Eher scheint es so als hättest du keine Erfahrung mit Java auf dem Desktop?

Nochmals ROFL. Ja, in der Theorie, in der Praxis meistens nicht. Vor allem folgt die Auslieferung von neuen Versionen meistens extrem verspätet. Ich habe schon erlebt, dass MacOS X über ein Jahr hinten nach war mit der Java Version Auslieferung. Und dann hast du ein ziemliches Problem, da du nicht einfach irgendwo Java runterladen kannst.

Die Verfügbarkeit neuerer Versionen lässt natürlich zu wünschen übrig, ist aber erstmal zweitrangig. Das Perfekt bezog sich offensichtlich auf die Implementierung und nicht auf die Verfügbarkeit, hast du das absichtlich so absurd reinterpretiert?

Auch ist Java nicht so platformunabhängig wie viele es gerne möchten. Es stimmt zwar, dass man es nur einmal kompilieren muss und dann auf allen Platformen starten kann, aber wenn es zum Beispiel auf Windows funktioniert, heisst es noch lange nicht, dass es auch auf MacOS X oder Linux funktionieren wird.

Dein Name ist wirklich gut gewählt

Grüssli

Komischer Argumentationsgang, bist du -fricky?

[ablach]

edit: link vergessen

Dravere schrieb:

Und dann hast du ein ziemliches Problem, da du nicht einfach irgendwo Java runterladen kannst.

http://developer.apple.com/java/download/

[+fricky]

Dravere schrieb:

general bacardi schrieb:

Das befürchte ich leider auch. Wie dick werden C++ Lehrbücher wohl sein wenn der neue Standard draussen ist?

Gleich dick ...
... nur wirst du zwei davon haben

zwei? braucht man nicht jetzt schon zwei oder drei? ich glaube eher, struppis baby wird bald eine neue wissenschaft begründen.

[Dravere]

ablach schrieb:

Nein, ich hab sie nie gezählt Ich kenne aber die wichtigsten ...

Und das ist bei dir eine Bibliothek, nämlich Qt?

ablach schrieb:

..., und QT ist sehr gut, was anderes würde ich für crossplattformentwicklung in C++ nicht empfehlen, du?

Definitiv würde ich etwas anderes empfehlen. Es kommt allerdings auch ganz auf die Anforderunen an, welche der Entwickler stellt.
Also einfach nur pauschal Qt empfehlen, würde ich ganz sicher nicht.

ablach schrieb:

Ich weiß nicht wovon du redest, Swing benutzt die UXTheme API (oder wie die heißt) von Windows XP und verwendet die nativen XP Themes. Eher scheint es so als hättest du keine Erfahrung mit Java auf dem Desktop?

Nein, Java Swing benutzt überhaupt nichts natives. Alle Java Swing Komponenten werden direkt gerendert und zwar von Java und gehen nicht über irgendwelche nativen Komponenten. Kannst es gerne nachlesen gehen, wo du willst, auf Wikipedia oder auf der Sun Seite.

Deshalb ist das Look and Feel von Java Swing auch so frei konfigurierbar. Du kannst jederzeit eine eigene XML Datei erstellen, welche ein neues Look and Feel beschreibt, was dann gerendert wird.

ablach schrieb:

Die Verfügbarkeit neuerer Versionen lässt natürlich zu wünschen übrig, ist aber erstmal zweitrangig. Das Perfekt bezog sich offensichtlich auf die Implementierung und nicht auf die Verfügbarkeit, hast du das absichtlich so absurd reinterpretiert?

Nein, ich habe dich einfach beim Wort genommen. Du hast gesagt die Unterstützung sei perfekt auf Mac0S X und dabei nichts genaueres spezifiziert. Auch würde ich davon absehen zu sagen, dass es eine perfekte Implementation habe. Etwas perfektes gibt es schlicht und einfach nicht. Wenn jemand etwas als perfekt bezeichnet, bedeutet dies meistens, dass er über die Sache zu wenig weiss oder sich blind und taub stellt

Denn Perfektion ist meistens eine sehr subjektive und relative Empfindung.

Auch, wenn es perfekt wäre, wofür entwickelt man es dann noch weiter?

ablach schrieb:

Komischer Argumentationsgang

Was ist komisch? Werd mal etwas genauer.

ablach schrieb:

edit: link vergessen

Dravere schrieb:

Und dann hast du ein ziemliches Problem, da du nicht einfach irgendwo Java runterladen kannst.

http://developer.apple.com/java/download/

rofl, klar, wenn es über die automatischen Updates nicht kommt, dann wird es sicher dort vorhanden sein. Nein, wahrscheinlich wird es dann nirgends vorhanden sein!
Übrigens, bei diesen Downloads ... wo ist eigentlich Update 14? Die sind wohl schon wieder hinten nach.

Grüssli

[ablach]

Dravere schrieb:

Nein, Java Swing benutzt überhaupt nichts natives. Alle Java Swing Komponenten werden direkt gerendert und zwar von Java und gehen nicht über irgendwelche nativen Komponenten. Kannst es gerne nachlesen gehen, wo du willst, auf Wikipedia oder auf der Sun Seite.
Deshalb ist das Look and Feel von Java Swing auch so frei konfigurierbar. Du kannst jederzeit eine eigene XML Datei erstellen, welche ein neues Look and Feel beschreibt, was dann gerendert wird.

Autsch, peinliches Halbwissen. Swing ist pures Java, das stimmt, die Look and Feels (für bestimmte GUIs) greifen aber allesamt auf native Resourcen zu. Zu diesen L&Fs gehören das Windows XP L&F, das GTK L&F, das Aqua L&F und das KDE L&F (ist 3rd party, beruht aber auf dem gleichen prinzip).
(Oder glaubst du die Entwickler haben für jedes GTK Theme ein eigenes passendes Java L&F entwickelt?)
Deine XML Dateien gibt es übrigens nur im Synth L&F, was extra entwickelt wurde um einfach "skinnable" zu sein, für andere L&Fs musst du Java benutzen, nicht XML.

Nein, ich habe dich einfach beim Wort genommen. Du hast gesagt die Unterstützung sei perfekt auf Mac0S X und dabei nichts genaueres spezifiziert.

Sorry, der ganze Post ging um die GUI Unterstützung, sowohl vor dem Satz als auch danach.

Dravere schrieb:

rofl, klar, wenn es über die automatischen Updates nicht kommt, dann wird es sicher dort vorhanden sein. Nein, wahrscheinlich wird es dann nirgends vorhanden sein!
Übrigens, bei diesen Downloads ... wo ist eigentlich Update 14? Die sind wohl schon wieder hinten nach.

Doppel-Autsch, Java für OS X ist eine ganz andere Implementierung als die von Sun, warum sollten die beiden die gleichen >update< versionsnummern haben? Die eine Implementierung hat doch ganz andere Bugs als die andere und umgekehrt, warum sollten die also gleichzeitig upgedated werden.
Den ersten Satz versteh ich nicht, überprüf mal deine Grammatik. Jedenfalls: Java ist auf allen OS X systemen vorinstalliert und wird automatisch upgedated. Wenn nicht, kann man sich die Versionen dort manuell runterladen.

Was C++ Toolkits angeht: Ich hab GTK, wx und QT ausprobiert, und QT "hat mir am besten gefallen", habe bisher alles realisieren können was ich wollte und ja, ich würde es auch pauschal weiterempfehlen, allein schon aufgrund der umfangreichen Bibliothek

links:
http://weblogs.java.net/blog/bino_george/archive/2004/11/hifi_swing_or_i_1.html
http://java.sun.com/developer/technicalArticles/javase/6_desktop_features/#NativeLookFeel

[Dravere]

ablach schrieb:

Autsch, peinliches Halbwissen. Swing ist pures Java, das stimmt, die Look and Feels (für bestimmte GUIs) greifen aber allesamt auf native Resourcen zu.

Ich frage mich langsam, als was du native Resourcen bezeichnest. Vor allem wieso plötzlich native Resourcen? Wir haben doch über native GUIs geredet? Tatsache ist aber, und das geht auch sehr schön aus den Artikeln hervor, welche du verlinkt hast, dass Java seine Komponenten selber zeichnet. LOGISCH muss es dabei irgendwelche APIs von der entsprechenden Platform verwenden. Aber das ist kein native GUI. Da kannst du wettern und tun wie du willst, es ändert nichts an der Tatsache.

ablach schrieb:

Doppel-Autsch, Java für OS X ist eine ganz andere Implementierung als die von Sun, warum sollten die beiden die gleichen >update< versionsnummern haben?

Schon mal die Beschreibung angeschaut?

Java for Mac OS X 10.5 Update 4 schrieb:

This release updates Java SE 6 to version 1.6.0_13, J2SE 5.0 to version 1.5.0_19, and J2SE 1.4.2 to 1.4.2_21.

http://support.apple.com/downloads/Java_for_Mac_OS_X_10_5_Update_4

Im Hintergrund braucht es die gleichen Versionen, sonst hättest du ziemlich Mühe, da der Bytecode unterschiedlich wäre. Denn im Bytecode wird die Java Version gespeichert.

ablach schrieb:

Die eine Implementierung hat doch ganz andere Bugs als die andere und umgekehrt, warum sollten die also gleichzeitig upgedated werden.

Weil es auch Bugs in den Java Spezifikationen haben könnte und diese auch auf MacOSX vorhanden sind?

ablach schrieb:

..., allein schon aufgrund der umfangreichen Bibliothek

Was Qt auch zu einem Framework macht und nicht nur einem GUI Toolkit. Aber sowas braucht man eigentlich nicht, das meiste ist meiner Meinung nach in deutlich schönerem C++ in Boost vorhanden.

Aber naja, ich ziehe mich aus diesem Thread wieder mal zurück. Hat sowieso keinen Zweck ...

Grüssli