Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
Bergmann89 hat geschrieben:
Sicher das endl immer das gleiche ist wie #13#10? Ich dachte immer auf Linux Systemen macht das ein #13 und auf Windows Systemen ein #13#10. Halt jenachdem was fur das System ein gültiger Zeilenumbruch ist...
Ne Horazont hat schon recht es ist nur '\n' und nicht '\r\n'. Kann man sich im ostream header anschauen. Für Dateien ist es also eher weniger brauchbar.
Die Konvertierung die '\n' auf Windows in "\n\r" umwandelt steckt in der Schreibmethode des Betriebssystems, wenn Dateien(Streams) als "Text" geladen oder gespeichert werden. Deshalb ist es auch wichtig dort nicht versehentlich zu vergessen, anzugeben, dass es sich um eine Binärdaten handelt. Normalerweise könnte das dem Dateiladefunktionen ja egal sein wenn solche Konvertierungen nicht wären.
Wen ich mir C++ angucke, ist dies eine Mischung aus Pascal Classen und Objecten. Gleicht aber eher Pascal-Objecten, welche man statisch und dynamisch machen kann.
Unter dem Strich ist die Objektorientierte-Programmierung unter C++ viel flexibler. Auch das ganze mit den Standart Constructer und Destructer ist interessant.
Nach meiner Meinung ist Pascal viel einfacher, dafür ist aber C++ viel flexibler.
So nebenbei gibt es mit Lazarus eine sehr flexible Entwicklungumgebung für Pascal/Delphi, welche sogar Platformübergreifend ist. Für C++ habe ich nicht mal annähernd etwas in dieser Richtung gefunden, ausser vieleicht das teure RAD Studio XE6. Komischerweise wird mehr C++ entwicklet, obwohl die Entwicklung viel komplizierter ist.
Von Java will ich gar nicht sprechen, dies ist schlimmer als Basic.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
mathias hat geschrieben:
So nebenbei gibt es mit Lazarus eine sehr flexible Entwicklungumgebung für Pascal/Delphi, welche sogar Platformübergreifend ist. Für C++ habe ich nicht mal annähernd etwas in dieser Richtung gefunden, ausser vieleicht das teure RAD Studio XE6. Komischerweise wird mehr C++ entwicklet, obwohl die Entwicklung viel komplizierter ist.
C++ gibt es fast überall. Siehe GNUCC oder CLANG. IDEs gibts wie Sand am Meer, und mit Eclipse und Co. ist man dann auf ganz vielen Plattformen unterwegs. Und wieso ist die Entwicklung mit C++ komplizierter als mit Pascal? Kann ich nicht nachvollziehen.
mathias hat geschrieben:
Von Java will ich gar nicht sprechen, dies ist schlimmer als Basic.
Hast du Java mal evaluiert? Ich entwickel aktuell sehr viel mit Java (8) und wär froh ich könnte mein Delphi auf der Arbeit gegen Java eintauschen...
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Struct und Class sind in C++ über die Zeit mehr verschmolzen. Wenn ich mich recht entsinne, dann gibt es heute nur noch einen Unterschied ist und das ist die Sichtbarkeit. Struct hat eine public sichtbarkeit und class private. VTables, Constructor und so weiter werden heute bei beiden nicht mehr default generiert, sondern nur, wenn es notwendig ist. Allerdings hab ich schon gesehen, dass der gcc beim struct kein constructor erzeugt hatte, obwohl eine Klasse als member enthalten war(VC++ hatte ein Konstruktor erzeugt).
Die frage ist, ob wirklich mehr C++ entwickelt wird, da viel code bereits existiert und wieder verwendet wird, würde ich das nicht mal Unterschreiben. Die Spiele und Filmbranche sind die Zweige, die den Größten Umsatzt durch Software generieren und in beiden sind C++ Dominant aber sicherlich nicht die einzigen Lösungen die man findet. Das ist durchwachsen mit C#, Java, Python und einigen mehr. Viel Software, die eingesetzt wird braucht kurze Latenzen zwischen Eingabe und Ausgabe bzw. müssen auch extrem viel Arbeit verrichten. Das sind die Stärken von C++ aber es gibt auch Fälle wo einfach nur Aufgaben automatisiert oder vereinfacht werden sollen und da verwendet man auch mal andere Sprachen. Java ist recht beliebt, wenn es um verteilung von Arbeit auf ganze Computer netze geht. Dabei ist der Zeitintensive Teil oft in C++ geschrieben und dann kommen Frameworks wie Quartz oder Hypernate oben drüber. Natürlich könnte man auch versuchen es mit Erlang zu machen aber finde mal Erlang programmierer und in beiden Branchen bezahlt man lieber 10 Studenten als 1 Senior Programmierer. C++ war früher die Sprache und dadurch sind heutige Profies dominierend C++ Programmierer und davon gibt es viele und je mehr es gibt, des so weniger muss man den zahlen. Ein Senior Java Entwickler kostet mehr als ein C++ler und der kann auch einiger maßen Java schreiben, wenn auch nicht so schnell und gut aber diese Feinheiten interessiert in der Spielebranche auch kein Manager.
Ich glaube, dass es zu einem Teil ein Generations bezogenes Phänomen ist. Zu einer Programmiersprache braucht man auch eine starke Entwicklungsumgebung und die sind ja bei C#, D, Erlang und noch einigen mehr doch eher jung bis wenig ausgereift. Zum anderen Teil glaube ich, dass es auch das Ökosystem schuld ist. Sony, Microsoft und Nintendo stellen ihre Konsolen nur mit C/C++ SDK bereit. Microsoft hat ja mal ein Pseudo SDK für C# angeboten aber das war nicht annähernd so ausgereift und umfangreich und letztlich auch eingestellt worden. Für Mobile Geräte und PC ist es einfacher, da gibt es wesentlich mehr Auswahl aber letztlich hat niemand vor sein Produkt in mehreren Sprachen zu schreiben und damit bleibt man dann eher bei C++. Viele kleine Tools in der Spielebranche werden mit C# geschrieben aber nachdem QT den besitzter und auch die Philosophie geändert hat, sehe ich wieder mehr Tools in QT geschrieben. Was mich zum letzten Punkt bringt, die Bibliotheken die man verwenden will sind immer C oder C++. AMD, Intel, Nvidia, Creative, IBM und wie sie alle heissen stellen ihre SDK's für Hardware und Software nicht in C# oder ähnlichen her. Das ist C/C++ und dann gibt es Firmen und Hobbyisten, die den Kram versuchen auf anderen Sprachen zu portierne und zu betreiben.
Es gibt schon viele Industriebereichen wo C++ mitlerweile eher eine Rarität ist.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
C++ gibt es fast überall. Siehe GNUCC oder CLANG. IDEs gibts wie Sand am Meer, und mit Eclipse und Co. ist man dann auf ganz vielen Plattformen unterwegs.
Stimmt IDEs gibt es wie Sand am Meer, aber keine ist so gut wie Lazarus. Oder kennt ihr etwas, mit dem man auch so schnell Formular-Anwendungen kreieren kann wie mit Lazarus ?
Zitat:
Struct und Class sind in C++ über die Zeit mehr verschmolzen.
Ich dacht Struct sie so was ähnliches wie bei Pascal der Record, und dieser kennt keine Methoden.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
mathias hat geschrieben:
Zitat:
C++ gibt es fast überall. Siehe GNUCC oder CLANG. IDEs gibts wie Sand am Meer, und mit Eclipse und Co. ist man dann auf ganz vielen Plattformen unterwegs.
Stimmt IDEs gibt es wie Sand am Meer, aber keine ist so gut wie Lazarus. Oder kennt ihr etwas, mit dem man auch so schnell Formular-Anwendungen kreieren kann wie mit Lazarus ?
Klar, da gibt es Sachen gegen die Delphi und Lazarus einfach nur primitiv wirken. QT-Creator, Visual Studio oder XCode haben so etwas out-of-box. Du wirst aber mit sicherheit auch diverse GTK-Plugins finden die dir helfen. Für Old-School WinAPI gibt's auch eine Menge Zeugs, aber so etwas braucht wohl niemand mehr.
mathias hat geschrieben:
Zitat:
Struct und Class sind in C++ über die Zeit mehr verschmolzen.
Ich dacht Struct sie so was ähnliches wie bei Pascal der Record, und dieser kennt keine Methoden.
Ist auch tatsächlich per Konvention so. Also gar nicht erst damit Anfangen dort Funktionen oder sonstige OOP-Features reinzubauen. Hintergrund ist halt die PODS-Problematik wenn man mit externen Komponenten kommuniziert. Kuck einfach mal in die Doku von std::is_pod.
Für Old-School WinAPI gibt's auch eine Menge Zeugs, aber so etwas braucht wohl niemand mehr.
Dies habe ich auch schon probiert, unter C und Pascal, der riesen Aufwand, bis man nur ein einfaches Fenster hat.
Zitat:
Ist auch tatsächlich per Konvention so. Also gar nicht erst damit Anfangen dort Funktionen oder sonstige OOP-Features reinzubauen.
Unter FreePascal kann man auch bei Records Methoden reinbauen, nur Vererben, wie bei Objecten geht nicht. Gebraucht habe ich dies nie, werde es auch nie brauchen.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
yunharla hat geschrieben:
mathias hat geschrieben:
Ich dacht Struct sie so was ähnliches wie bei Pascal der Record, und dieser kennt keine Methoden.
Ist auch tatsächlich per Konvention so. Also gar nicht erst damit Anfangen dort Funktionen oder sonstige OOP-Features reinzubauen. Hintergrund ist halt die PODS-Problematik wenn man mit externen Komponenten kommuniziert. Kuck einfach mal in die Doku von std::is_pod.
Ein struct ist in C++ eine class die ihre Standard Sichtbarkeit als public definiert. Es hat alle Eigenschaften einer class, wie methoden, vtable, POD fähigkeit, kann in union verwendet werden, default Constructor/Destructor und Copy-Constructor wird erstellt, wenn nicht POD und noch einiges mehr.
Zwar nicht der aktuelle Standard aber der vorletzte.
Zitat:
A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. A POD class is a class that is either a POD-struct or a POD-union.
Im aktuellen ist es noch mehr restriktiert worden, wegen Exceptions und Movement Constructor. Aber hey, der C++14 steht vor der Tür und für C++17 gibt es schon die ersten Drafts also gibt es doch rege Änderungen.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
TAK2004 hat geschrieben:
yunharla hat geschrieben:
mathias hat geschrieben:
Ich dacht Struct sie so was ähnliches wie bei Pascal der Record, und dieser kennt keine Methoden.
Ist auch tatsächlich per Konvention so. Also gar nicht erst damit Anfangen dort Funktionen oder sonstige OOP-Features reinzubauen. Hintergrund ist halt die PODS-Problematik wenn man mit externen Komponenten kommuniziert. Kuck einfach mal in die Doku von std::is_pod.
Ein struct ist in C++ eine class die ihre Standard Sichtbarkeit als public definiert. Es hat alle Eigenschaften einer class, wie methoden, vtable, POD fähigkeit, kann in union verwendet werden, default Constructor/Destructor und Copy-Constructor wird erstellt, wenn nicht POD und noch einiges mehr.
Zwar nicht der aktuelle Standard aber der vorletzte.
Zitat:
A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. A POD class is a class that is either a POD-struct or a POD-union.
Im aktuellen ist es noch mehr restriktiert worden, wegen Exceptions und Movement Constructor. Aber hey, der C++14 steht vor der Tür und für C++17 gibt es schon die ersten Drafts also gibt es doch rege Änderungen.
Jup, das ändert ja aber nichts an der Tatsache das C++ noch nicht kompatibel zu C ist. Und solange das nicht passiert sollte man auch ruhig weiterhin entweder struct = POD definieren oder halt Kommentare machen.
Unter dem Strich ist die Objektorientierte-Programmierung unter C++ viel flexibler.
Flexiblität ist meiner Meinung nach die Stärke von C++. Exemplarische Zitate von StackOverflow die die Sache meiner Meinung nach gut auf den Punkt bringen. Java: "I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++." C++: "Many C++ design decisions have their roots in my dislike for forcing people to do things in some particular way [...] Often, I was tempted to outlaw a feature I personally disliked, I refrained from doing so because I did not think I had the right to force my views on others."
C++ wird damit komplexer und schwerer zu überschauen, aber C++ schränkt dich dafür weniger ein.
mathias hat geschrieben:
So nebenbei gibt es mit Lazarus eine sehr flexible Entwicklungumgebung für Pascal/Delphi, welche sogar Platformübergreifend ist. Für C++ habe ich nicht mal annähernd etwas in dieser Richtung gefunden
Entwicklungsumgebung, unter Windows Visual Studio? Außerdem gibt es wohl kaum eine Sprache die ernsthaft auf mehr Platformen als C++ zum Laufen zu bekommen ist, außer vielleicht C. Mit C(und meistens auch ++) kannst du den Mikrocontroller deines Kühlschrankes oder des Toasters programmieren, wenn du willst. Ich behaupte es gibt keine Sprache die auf mehr Platformen läuft. Mit Emscripten bekommt man C++ sogar in den Webbrowser.
TAK2004 hat geschrieben:
eine starke Entwicklungsumgebung und die sind ja bei C#, D, Erlang und noch einigen mehr doch eher jung bis wenig ausgereift.
Ist das ein Verwechselung bei C#? C# jung und nicht ausgereifte IDE? Für die Sprache gibt es extrem ausgereifte und umfangreiche IDEs wie Visual Studio und andere Open Source Varianten wie MonoDevelop usw. die ich persönlich kaum kenne. C# mag auch Schwächen haben, aber die IDE ist es ganz ganz bestimmt nicht. Das ist noch eher der Grund zum Wechsel zu C#.
mathias hat geschrieben:
Oder kennt ihr etwas, mit dem man auch so schnell Formular-Anwendungen kreieren kann wie mit Lazarus ?
Sicher. C# ist hier ganz besonders prädestiniert. Obwohl ich in diese Richtung noch nie gearbeitet habe, würde es mich wundern wenn zum Beispiel gänige Java IDEs da nicht auch etwas bieten würden. Für C++ gibt es auch gute Frameworks für GUI, die allerdings, wie die gesamte Sprache, nicht so einfach sein sollten.
mathias hat geschrieben:
Ich dacht Struct sie so was ähnliches wie bei Pascal der Record, und dieser kennt keine Methoden.
Struct und Class ist von der Funktionalität zu 100% Äquivalent. Es ist eigentlich absolut egal ob man "struct" oder "class" darüber schreibt. Der einzige marginale Unterschied ist, dass "class" Member ohne Angabe erstmal privat sind und in "struct" ohne Angabe öffentlich("public"). Ich habe mich einmal dazu entschieden, kein "struct" mehr zu verwenden sondern nur noch "class". Das macht Forward Declarations der Konsistenz halber einfacher und durch meine "explizit vor implizit" Einstellung sind ein paar zusätzliche Zugriffsmodifikatoren auch nicht verkehrt.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
OpenglerF hat geschrieben:
TAK2004 hat geschrieben:
eine starke Entwicklungsumgebung und die sind ja bei C#, D, Erlang und noch einigen mehr doch eher jung bis wenig ausgereift.
Ist das ein Verwechselung bei C#? C# jung und nicht ausgereifte IDE? Für die Sprache gibt es extrem ausgereifte und umfangreiche IDEs wie Visual Studio und andere Open Source Varianten wie MonoDevelop usw. die ich persönlich kaum kenne. C# mag auch Schwächen haben, aber die IDE ist es ganz ganz bestimmt nicht. Das ist noch eher der Grund zum Wechsel zu C#.
MonoDevelop ist ziemlich schlecht und Unity3D hat nicht ohne Grund sich davon verarbschiedet und es gibt auch eine wesentlich bessere Kommerziellen branch. VC# ist für Windows sehr toll und hat auch schon ein paar nützliche Tools und Refactoring features aber ist total inkompatibel mit anderen C# compilern und IDE. .net, was eigentlich Leute mit C# assoziieren gibt es nur rudimentär, langsam und mit Bugs gespickt von OpenSource Quellen. Also Ja VC# ist toll für Windows und die IDE ist stark aber C# std library ist genau so sparsam mit Klassen wie stl von c++ und .Net .
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Mitglieder in diesem Forum: 0 Mitglieder und 27 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.