Gast
#7205303
using namespace std; oder std::cout << "Hello World!"; Was ist der Vor/Nachteil? Was nutzt ihr und wieso?
Was sagt denn dein Lehrer? Oliver
Wenn man **nur** die Standardbibliothek benutzt, kann man 'using' benutzen. Könnten weitere Namensräume hinzukommen, immer davor schreiben, damit man weiß woher der Ausdruck kommt.
Gast
#7205436
using kann man in C++ Dateien verwenden, um den Code lesbarer zu machen und wenn es keine Namensraumkollisionen gibt. Man sollte using aber nie (!) in Headerfiles verwenden.
Gast
#7205447
hm ist das wichtig bei solchen Standard Namespaces? Volker Z. schrieb: > Könnten weitere Namensräume hinzukommen, immer davor schreiben, damit > man weiß woher der Ausdruck kommt.
Gast
#7205454
Was für schwere Probleme haben hier eigentlich manche. Nerven euch solch dummen Kommentare selber gar nicht??!! Nein, ich bin weder Schüler noch Stunden, ich gehe stramm auf die 50 zu. Selbst WENN ich Schüler wäre, ginge es Forenteilnehmer einen Scheiß an, ob es für den unterricht oder rein privat wäre. ERNSTHAFT! Was für Probleme haben Menschen wie Du? Neid? Weil sie selber voll abgekackt haben und nicht wollen das es andere einfacher haben als Du? Frust? Ich meine diese Frage wirklich ernst. Bitte sage mir, wieso tangiert es offenbar einige die hier fragen stellen, wenn diese zum Unterricht erfolgen würden?! Wenn ich so etwas lese und ich nicht antworten wollen würde, schließe ich den Tab wieder oder klicke auf ein anderes Thema. Aber was bringt dies dazu deinen Erguss zum Besten zu geben der völlig sinnlos und dazu noch eine falsche Vermutung ist?! Oliver S. schrieb: > Was sagt denn dein Lehrer? > > Oliver
Peter K. schrieb: > using namespace std Sollte man grundsätzlich nicht nutzen: https://stackoverflow.com/q/1452721/4730685 Volker Z. schrieb: > Wenn man nur die Standardbibliothek benutzt, Macht man so trotzdem alle Interna der Bibliothek sichtbar, was nicht so schön ist. MikeH schrieb: > und wenn es keine Namensraumkollisionen gibt. Es können aber in zukünftigen Versionen der Bibliothek welche hinzukommen. Wenn schon kann man einzelne Bezeichner "holen":
1 | |
2 | |
Wobei mit etwas Gewöhnung das Tippen von "std::string" o.ä. auch kein Problem mehr ist.
Gast
#7205459
Immer std:: davor schreiben. Es nimmt nicht viel platz weg, und der ganze Kram in dem Namespace kommt einem dann nicht anderswo in dir Quere. Weder Heute, noch Morgen.
Peter K. schrieb: > Ich meine diese Frage wirklich ernst. Ach... Die Frage ist so alt wie der namespace std. Und entsprechend gibt es dazu seit ewigen Zeiten unzählige ernsthafte Überlegungen und Kommentare im Netz. Wer solch eine Frage ernst meint, sollte sich ernsthaft darum kümmern, und nicht nur einen Zweizeiler ins nächste Forum rotzen. Ansonsten hat die Frage die Qualität von : welche Farbe ist schöner: rot oder blau? Oliver
Peter K. schrieb: > using namespace std; > oder > std::cout << "Hello World!"; > > Was ist der Vor/Nachteil? > Was nutzt ihr und wieso? Es sollte Dir klar sein bzw. Du kannst es nachlesen, warum man einen kompletten namespace (std oder was anderes) nicht in einer include-Datei per using namespace einbringen sollte. Man kann in einer Implementierungsdatei durchaus using namespace X verwenden, wobei einem klar sein muss, dass es - wenn es auf File-Scope eingesetzt wird - bis zum Ende der TU gilt. Daher ist es (meistens) besser nur einzelne Symbole in den umgebenden Namensraum zu bringen mit etwa using std::cout. Oder man verwenden using namespace X im Block-Scope.
Gast
#7205538
Danke, ich wende mir das bei Sack Overflow gleich mal durchlesen. Und auch den Anderen natürlich Dank:-) @Oliver Wenn DIR diese Frage so erscheint mag das sein, jemand er sich aber erst mit einer neuen Sache beschäftigt, sieht das naturgemäß etwas anders. Du solltest mal etwas weniger ICH bezogen denken und über den Tellerrand. Und die Frage kann auch noch 1000x von anderen gestellt werden, nennt sich Kommunikation, Wenn du in deinem Kemmerlein alleine vor dich hin brödelst kannst du das gerne tun, andere pflegen lieber den sozialen Kontakt.. Oliver S. schrieb: > Ansonsten hat die Frage die Qualität von : welche Farbe ist schöner: rot > oder blau?
Gast
#7205546
" Don't forget you can do: "using std::cout;" which means you don't have to type std::cout, but don't bring in the entire std namespace at the same time Ahhh, ok:-) Auch noch eine interessante Option
Peter K. schrieb: > " > Don't forget you can do: "using std::cout;" which means you don't have > to type std::cout, but don't bring in the entire std namespace at the > same time > > > Ahhh, ok:-) Auch noch eine interessante Option Du scheinst die Beiträge hier gar nicht zu lesen, oder?
Gast
#7205560
Wobei es interessant ist, das witzigerweise bei diesem Onliecompiler genau das gemacht wird, das ist natürlich dann für einen Anfänger noch verwirrender, da man sich natürlich daran orientiert was man häufig sieht https://www.onlinegdb.com/online_c++_compiler
Gast
#7205569
Peter K. schrieb: > Was nutzt ihr und wieso? Vorzugsweise using mybib::myf (oder eben ohne using) um mich daran zu erinnern, das das auch geht. Normalerweise macht das aber keiner, gefühlt 99,55 % nutzen using namespace und gucken höchstens komisch bei using mybib::myf. Hinsichtlich der Tippfehlerwahrscheinlichkeit hat using namespace mybib schon seine Vorteile Wenn man seinem Code einen professionellen Anstrich geben möchte, dann mit using namespace bib. Gerade aber weil using namespace std so verbreitet ist fragt man sich schon, warum man es überhaupt schreiben muss. Man könnte sich doch auch sowas denken: disable std falls man nichts davon braucht. Disable ist aber der falsche Begriff, das ist nicht transparent - und gerade das soll ja gegeben sein. Vielleicht passt in diesem Fall "exclude namespace std" besser? So ganz grob liegt man irgendwie auch eher beim Compiler-Schalter. So ein Compilerschalter ist aber auch alles andere als transparent. Müsste man aber öfter schon dazuschreiben: "Wir compilieren vorzugsweise mit den Schaltern x, y und z". Da aber Dokumentation(nehmen wir mal an) so vom Grund auf eher schlecht ist - und man immer wieder darum kämpfen muss: Eventuell hilft es, wenn man dabei noch das Buch: Don Quijote von Miguel de Servantnes Saavedra (Wenn schon nicht im Original, dann wenigstens mit einer guten Übersetzung) im Hinterkopf hat.
Wilhelm M. schrieb: > Man kann in einer Implementierungsdatei durchaus using namespace X > verwenden Aber auch das ist tückisch, wie in der 2. Antwort erläutert: https://stackoverflow.com/a/1453605 Wird eine Library aktualisiert und bekommt eine gleichnamige Funktion, kann plötzlich die aufgerufen werden. rbx schrieb: > Wenn man seinem Code einen professionellen Anstrich geben möchte, dann > mit using namespace bib. Aus Schreibfaulheit "using namespace" zu nutzen ist für mich nicht besonders professionell. Im Gegenteil, wenn im Code "std::optional" steht weiß ich genau dass es sich um das Standard-Optional handelt, bei "optional" könnte es auch eine Eigen-Implementation sein, von der es viele gibt. rbx schrieb: > Gerade aber weil using namespace std so verbreitet ist fragt man sich > schon, warum man es überhaupt schreiben muss. Weil man sonst sehr viel Abwärtskompatibilität verlieren würde. Sehr viel Code enthält Bezeichner, die identisch zu Standard-Bibliotheks-Namen sind, und das würde kollidieren. In der Standard-Bibliothek kommt ja auch ständig was hinzu. In anderen Sprachen ist es auch so, da sind nur kleine Mengen an Standard-Datentypen/Klassen immer sichtbar, alles andere steckt in Namespaces/Packages. z.B. in Java ist es das java.lang Package. rbx schrieb: > Vielleicht passt in diesem Fall "exclude namespace std" besser? So ganz > grob liegt man irgendwie auch eher beim Compiler-Schalter. Große Sprachfeatures per Compiler-Schalter abschalten gibt ein Chaos, das wird i.A. so weit wie möglich vermieden. Besonders wenn includes hinzukommen - was wenn die eine inkludierte Library die Standardbibliothek braucht und die andere nicht?
Gast
#7205622
Ich habe gerade mal das Beispiel auspobiert mit using davor Wieso ist das using hier falsch verwendet? Ohne Using geht es natürlich problemlos
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Peter K. schrieb: > Wenn du in deinem Kemmerlein alleine vor dich hin brödelst kannst du das > gerne tun, andere pflegen lieber den sozialen Kontakt.. Wenn du das Thema ernst meinst, hättest du dir ja vorab eine eigene Meinung bilden, und diese dann hier zur Diskussion stellen können. Das wäre aber mit Eigeninitiative verbunden gewesen. Aber egal. Ich schreibe im Falle von std::cout und allen anderen dirket im namespace standard angesiedelten Namen das std:: immer hin. Die paar Zeichen tun nicht weh. Das allerdings ist ja nur ein Teil der Fragestellung, den Namespaces gibt ja nun viele weitere neben std. Wenn dann sowas wie foolib::defaultNamespace::blaModule::experimental::featureritis::wasauch immer vorkommt, dann geht nicht ohne using. Das dann aber im kleinstmöglichen Scope Oliver
Peter K. schrieb: > Wieso ist das using hier falsch verwendet? Das ist halt keine C++ -Syntax. Was soll das "using" da bewirken?!
Peter K. schrieb: > Ich habe gerade mal das Beispiel auspobiert mit using davor > Wieso ist das using hier falsch verwendet? > Ohne Using geht es natürlich problemlos Ich hatte es ja schon mal gesagt: Du scheinst die Posts von anderen Leuten in diesem Thread, die Dir helfen wollen, gar nicht zu lesen. Noch scheinst Du etwa cppreference o.ä. zu benutzen. Troll?
Peter K. schrieb: > use namespace oder std? Ich persönlich bin da ziemlich hin- und hergerissen. Hauptnachteil von "using namespace std;": Gefahr von Name-Clashes beim Update der Standardbibliothek. Hauptnachteil der "std::"-Präfixe: Bei gehäuftem Auftreten extrem störend beim Lesen von Code. Die Verwendung "using namespace std;" gilt als schlechter Stil. Schwer lesbarer Code ist aber erst recht schlechter Stil. Der Nachteil von "using namespace std;" (Name-Clashes) tritt äußerst selten in Erscheinung und lässt sich ggf. durch Umbenennung von Symbolen beseitigen. Der Nachteil von "std::" hingegen ist omnipräsent und lässt sich nicht beseitigen. Deswegen bin ich geneigt, die (leichten) Nachteile von "using namespace std;" zu Gunsten der besseren Lesbarkeit in Kauf zu nehmen. Ein guter Kompromiss wäre das selektive Einbinden von Symbolen aus dem std-Namespace, was mit "using std::symbol;" prinzipiell auch möglich ist. Allerdings stellt für mich die Syntax eine hohe Hemmschwelle dar, weswegen ich using-Deklarationen nur sehr selten verwende. Vor C++17 war es extrem umständlich, damit eine größere Zahl von Symbolen einzubinden, weil jedes davon eine eigene using-Deklaration erforderte. Mit der Einführung von mehrfachen using-Deklaration in C++17 wurde dieses Problem etwas entschärft. Allerdings wäre es sehr praktisch, wenn man bspw. in
1 | |
2 | |
die nervigen Wiederholungen von "std::" weglassen könnte, bspw. so:
1 | |
In anderen Programmiersprachen (bspw. Python und Haskell) gibt es so etwas in vergleichbarer Form schon immer, weswegen ich nicht verstehe, warum sich die C++-Entwickler damit so schwer tun. MikeH schrieb: > Man sollte using aber nie (!) in Headerfiles verwenden. Das ist klar, praktisch wäre es aber in vielen Fällen dennoch. Schön wäre es deswegen, wenn man "using namespace std;" auch auf File-Scope lokal begrenzen könnte, bspw. so:
1 | |
2 | |
3 | |
4 | |
5 | |
Leider geht auch das nicht. Fazit: Die Namespaces in C++ sind an sich eine gute Sache, aber deren Usability ist aus (für mich) unerfindlichen Gründen trotz einiger Nachbesserungen nach wie vor ziemlich bescheiden.
Gast
#7205905
```cpp
#include <iostream>
using std::cout;
int main()
{
cout << "Hello World";
return 0;
}
```
Gast
#7205956
??? Was genau willst Du damit sagen? Du verwendest es so? Aber die Frage, warum, ist damit ja nicht beantwortet;-)
war vielleicht nur nochmal ein Verwendungsbeispiel sein, was aber mittlerweile klar sein sollte. Die drei Backticks funktionieren übrigens nur als Formattierung in der Mobile Website, als Desktopdarstellung sind nur die Backticks zu sehen. Mobile wird anscheinend mit Markdown Language formatiert.
Gast
#7205987
Ich finde
1 | |
grauenvoll. Ist eine Frage der Gewöhnung aber
1 | |
vor jede benutzte Funktion zu schreiben bringt mich nicht um. Wo ich eher Zweifel habe, ob
1 | |
nun gut ist oder nicht. Die KiCAD-Entwickler entfernen es ja wieder nach und nach aus ihrem Code.
loeti2 schrieb: > Ich finde
1 | |
grauenvoll.
Was soll das sein?
> Ist eine Frage der Gewöhnung aber1 | |
vor jede benutzte > Funktion zu schreiben bringt mich nicht um. Jede wohl kaum? > Wo ich eher Zweifel habe, ob
1 | |
nun gut ist oder nicht. > Die KiCAD-Entwickler entfernen es ja wieder nach und nach aus ihrem > Code. Das wird nicht überall gehen ;-)
Gast
#7206107
In einem anderen vor mir leigendem Lehrbuch steht das Beipsiel.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Das funktioniert nicht mal....
Peter K. schrieb: > #include <iostream.h> Das .h ist auch zu viel heutzutage. Es gibt leider sehr viele schlechte und fehlerhafte Bücher über C und C++...
Gast
#7206115
wenn es nur das .h wäre:-( Auch der Rest geht natürlich nicht da std::bzw uses fehlt Ich finde auh beim Überfleigen egrade nicht, wie das umgangen werden soll, kann ja sein das ich was überlesen habe (C++ Das Grundalgen Buch)1230Seiten dick... Wenn ich da alte Pascal/Delphi Bücher nehme, funktionieren die Beispiele dort auch heute sofort unverändert...nun gut...
Peter K. schrieb: > Ich finde auh beim Überfleigen egrade nicht, wie das umgangen werden > soll Also so wie es da steht ist es definitiv falsch. Manche Autoren schreiben irgendwo am Anfang "Es ist immer using namespace std;" implizit angenommen. Peter K. schrieb: > Wenn ich da alte Pascal/Delphi Bücher nehme, funktionieren die Beispiele > dort auch heute sofort unverändert. Naja, dein Beispiel da hat nie funktioniert.
Gast
#7206151
ganz weit hinten im Buch(Seite 954) Werden Namespaces auf 2!! Seiten angesprochen aber nur an fiktiven Beispielen. Aber diesen Beispielen folgend wäre es dann so
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Gast
#7206204
Naja, aber offenbar ist dieser "Fehler" nicht so ungewöhnlich. Ganz offenbar war es mal richtig.. http://www.willemer.de/informatik/cpp/cincout.htm Boa, what war das schön Pascal und Delphi zu lernen. Dort gab/gibt es solch ein Durcheinander nicht
Peter K. schrieb: > Ganz offenbar war es mal richtig.. Ne, nie ohne "using namespace std;" oder std:: . Peter K. schrieb: > Dort gab/gibt es solch ein Durcheinander nicht Keine fehlerhafte Bücher?
Gast
#7206246
Nein, ich habe hier 4 oder 5 Bücher über C und C++ und stoße ständig auf soclhe Unterschiede oder Probleme.. Ich habe hier aber mindestens 12 Bücher zu Turbo Pascal und Delphi oder die Pascal Quellcode enthalten(Schnittstellen am PC benutzen etc)und bin dort, zumindest bislang , auf keinen gravierenden Fehler gestoßen Auch nicht im NEtz.. BEi C++ habe ich diese fehlerhaften Beispiele ja eben erst spontan sofort gefunden Niklas G. schrieb: > Peter K. schrieb: >> Dort gab/gibt es solch ein Durcheinander nicht > > Keine fehlerhafte Bücher?
Peter K. schrieb: > Nein, ich habe hier 4 oder 5 Bücher über C und C++ und stoße ständig auf > soclhe Unterschiede oder Probleme.. Wie gesagt, es gibt viele schlechte Bilder. Allerdings war die Standardbibliothek anfangs nicht konsistent von allen Anbietern umgesetzt. Wobei das fehlende std:: wohl so nie funktioniert haben dürfte. Peter K. schrieb: > Ich habe hier aber mindestens 12 Bücher zu Turbo Pascal und Delphi oder > die Pascal Quellcode enthalten(Schnittstellen am PC benutzen etc)und > bin dort, zumindest bislang , auf keinen gravierenden Fehler gestoßen Und das ist konsistent über alle verschiedenen Compiler, Plattformen und Library-Anbieter? Der Code von damals funktioniert auch heute noch auf allen Compilern/Plattformen? Wie viele gab/gibt es davon überhaupt?
Niklas G. schrieb: > Peter K. schrieb: >> #include <iostream.h> > > Das .h ist auch zu viel heutzutage. Es gibt leider sehr viele schlechte > und fehlerhafte Bücher über C und C++... Und main() hat den Typ int und nicht void. Was ist denn das für ein Buch überhaupt? Am besten gleich in den Müll!
Gast
#7206294
@ Niklas G. "Und das ist konsistent über alle verschiedenen Compiler," Ja, klar. Es gibt bei Pascal ja einen inoffiziellen Standard und der ist von Borland. Danach richten sich alle, und das setzt sich auch bei delphi fort. Daher ist Freepascal auch sehr kompatibel bis Delphi 6 oder so, da bin ich nicht mehr auf den aktuellen Stand Aber alle Bücher bis Delphi 6 oder so, kannst du problemlos auch für Freepascal nutzen. Die Zeiten wo PAscal als Lehrspracheverrufen war , war die vor Borland. Danach konnte man damit ja auch sehr professionell programmieren, nicht umsonst war es die beliebteste Programmierprache, bis sie es bei Windows vermasselt hatten und viel zu lange gebraucht hatten den Fehler auszubügeln. Auch ich war damals bei Objekt Pascal ausgestiegen, da das einfach kacke war. Mit Delphi bzw Lazarus /Freepascal war dann alles wieder ein Traum und der Erfolg hätte sich fortsetzen können. Da war es aber schon zu spät und C hat sich durchgesetzt. Das Betriebssystem von Apples Computer, Lisa war in Pascal geschrieben https://de.wiki5.ru/wiki/Apple_Lisa @Wilhelm steht oben Es ist sonst ziemlich gut scheinbar und erst recht sein C Buch. Alles sehr ausführlich bis ins kleinste mit Begründungen erklärt. C++ (C++ Das Grundalgen Buch)1230Seiten dick... Professionell Programmieren von Anfang an
Gast
#7206297
Peter K. schrieb: > Nein, ich habe hier 4 oder 5 Bücher über C und C++ und stoße ständig auf > soclhe Unterschiede oder Probleme.. https://www.stroustrup.com/4th.html https://www.stroustrup.com/C++.html https://www.oreilly.com/library/view/effective-modern-c/9781491908419/ Nimm halt die "richtigen" Bücher. Die sollten keine derartigen Inkonsistenzen aufweisen. PS: "The C++-Programming Language, 4th edition" "scott meyers effective modern c++" einfach bei Google eintippen, direkt auf der ersten Seite finden sich github/moodle Links. Die Papierbücher haben leider keine Suchfunktion...
Peter K. schrieb: > Danach richten sich alle, und das setzt sich auch bei delphi fort. Welche waren das alle, und hatten die alle eine identische Standardbibliothek? Pascal ist halt auch einfach älter. C++ ist erst seit 1998 standardisiert inkl. Bibliothek, d.h. erst seit dem konnte man wirklich verlässlich kompatiblen Code mit Standardbibliothek schreiben. Alle Codebeispiele/Bücher nach 1998 sollten heute noch funktionieren, mindestens mit -std=c++98 o.ä. Für C gilt das seit 1990.
Gast
#7206304
Peter K. schrieb: > In einem anderen vor mir leigendem Lehrbuch steht das > Beipsiel.#include <iostream.h> > void main() > { > cout << "Hello World"; > } > > Das funktioniert nicht mal.... Die haben es echt geschafft "Hello World" aus dem Standardwerk FALSCH abzuschreiben?! >Typically, a program produces some output. Here is a program that writes > Hello, World!: > #include <iostream> > int main() > { > std::cout << "Hello, World!\n"; > } Sogar das Newline haben sie vergessen.
Gast
#7206308
@Niklas ja, die Standard Libs sind immer dabei und gleich "Alle" so viele gibt es ja nicht. FreePascal /Lazarus PAscal decken aber zum Glück nahezu alle wichtigen CPU und uC ab https://de.wikipedia.org/wiki/Object_Pascal @peter nein, das \n haben sie nicht vergessen..das kommt später.
Peter K. schrieb: > so viele gibt es ja nicht. Bei C und C++ schon, die alle konsistent unter einen Hut zu bekommen ist nicht so einfach. Dazu noch der historisch gewachsene Charakter und die Abwärtskompatibilität von C++ zu C...
Gast
#7206311
Na die Abwärtsompatibilität behält Pascal ja auch bei erfreulicherweise. Das heutige Freepascal das mit C++ vergleichbar ist(siehe Wiki Artikel) ist noch voll kompatibel zum alten Turbo Pascal für DOS oder CP/M z.B Deshalb mag ich Freepascal auch so sehr:-) Sogar für AVR und ARM ist es geeignet:-) Leider ist aber im uC Bereich die Community noch recht klein oder das gerade bei Freepascal /Lazarus der Freiheitsgedanke sehr ausgeprägt ist, Du kannst deine Programme uneingeschränkt nutzen ohne irgendwelche Bedingungen auch vermarkten etc... Tun die sich etwas schwer mit den Controllern und den Definitionsdateien dafür Es lohnt sich anzusehen:-) https://www.lazarus-ide.org/ https://www.freepascal.org/
Peter K. schrieb: > Das heutige Freepascal das mit C++ vergleichbar ist Also so wie ich das verstehe ist Pascal kaum mit C++ vergleichbar. C++ ist so komplex dass es ziemlich lange gedauert hat, bis ein einheitlicher Standard fertig war, der dann auch von all den Anbietern umgesetzt wurde. Peter K. schrieb: > Na die Abwärtsompatibilität behält Pascal ja auch bei erfreulicherweise. Das führt halt entweder zu ein paar Macken oder schränkt die Entwicklung ein.
Gast
#7206321
keine Ahnung, hatte es jetzt nur aus dem Wiki übernommen "Der Funktionsumfang von Object Pascal ist vergleichbar mit dem von C++, wobei sich die Syntax stark unterscheidet. Variablen müssen deklariert und einem Datentyp zugeordnet werden. Es gibt Klassen mit Konstruktoren und Destruktoren, Methoden und Properties. Methoden können virtuell sein. Die Vererbung unterstützt nur eine Basisklasse; Interfaces ermöglichen Mehrfachvererbung. Für die Speicherverwaltung von Objekten ist der Programmierer selbst verantwortlich. Strings sind davon nicht betroffen, da sie als elementarer Datentyp unterstützt werden. Bis Delphi 2005 wurden Objekte grundsätzlich auf dem Heap angelegt. Dies ermöglicht es, in Delphi jedes Objekt als Ergebnis einer Funktion an den Aufrufenden zu übergeben. In anderen Programmiersprachen, wie z. B. C++, können Objekte sowohl im Heap als auch im Stack angelegt werden. Objekte im Stack können nicht als Rückgabewert übergeben werden, da diese beim Verlassen der Funktion zusammen mit dem restlichen Stackframe der Funktion gelöscht werden. Somit wurde hier eine Designentscheidung getroffen, die dem Delphi-Programmierer die Entscheidung zwischen Heap/Stack abnimmt und immer die flexiblere Lösung wählt. Als Nachteil dieser Technik ergibt sich unmittelbar, dass der Programmierer seine erzeugten Objekte selbst aus dem Speicher entfernen muss. Bei Objekten im Stack ist dies nicht notwendig. Seit Delphi 2006 werden auch Records mit Methoden unterstützt, womit sich Stackobjekte ähnlich wie in C++ erstellen lassen."
Peter K. schrieb: > keine Ahnung, hatte es jetzt nur aus dem Wiki übernommen > "Der Funktionsumfang von Object Pascal ist vergleichbar mit dem von C++, So wie ich das verstehe unterstützt Pascal keine templates, bzw. bei weitem nicht in dem Umfang wie C++. Weil diese ein sehr wichtiger und mächtiger Bestandteil von C++ sind, der aber auch gleichzeitig viel Verwirrung und Inkompatibilitäten stiftet, kann man hier IMO nicht wirklich von "vergleichbar" sprechen. Peter K. schrieb: > Bis Delphi 2005 wurden Objekte grundsätzlich auf dem Heap angelegt C++ hat hier also auch die flexiblere Speicherverwaltung, wichtig für Mikrocontroller, und halt nicht nur für Records. Dass Pascal allgemein anfangs eine kleinere Nutzerbasis hatte und im akademischen Umfeld verbreitet war, während es bei C und C++ einen kommerziellen Wildwuchs gab, konnte Pascal wohl besser "unter Kontrolle" bleiben.
Peter K. schrieb: > @Wilhelm steht oben > Es ist sonst ziemlich gut scheinbar und erst recht sein C Buch. Naja ... Wer etwas beschreibt, was im Übergang von pre-standardisierten zu standardisiertem C++ (< 1998) mal richtig war, und das ohne Hinweis, der sollte sich mal fragen, ob er auf der Höhe der Zeit ist. Und das ganz am Anfang eines Werkes, was ein Lehrbuch sein will. Diese eklatanten Fehler ganz am Anfang haben mich veranlasst, tatsächlich da mal rein zu schauen. Zwei Kapitel habe ich ausgewählt und ca. jeweils 10s reingeschaut. Das Kapitel über unions ist ebenfalls falsch, weil er dort UB (undefined behaviour) beschreibt. Dann das Kapitel über systemnahe Programmierung enthält auch eklatante Fehler. Zudem wird überall new/delete verwendet und es gibt kein Kapitel über intelligente Zeiger. Sorry, aber das ist im Jahr 2022 einfach veraltet. Weiter habe ich nicht geschaut, das hat mir gereicht. Ich kann Dir nur das Buch von U. Breymann empfehlen. Und immer ein Blick in cppreference.
Gast
#7206496
Peter K. schrieb: > C++ Das Grundalgen Buch Es gibt auch ein Biologiebuch, das den Begriff C++ benutzt? Pascal hatte immer auch tolle Tutorials, sehr gute Werkzeuge oder auch vorbildliche Hilfen zu Windowsprogrammierung. Bei C++ muss man kämpfen, und bei Haskell die Zähne zusammenbeißen.. Zum Hin- und Herübersetzen fand ich u.a. Accelerated C++ sehr schön. Außerdem braucht man noch was aktuelles, um sich nicht unnötig mit gestrigem Code aufzuhalten. Die etwas übertriebenen Fehlermeldungen beim gcc sind auch nochmal ein Kapitel für sich. Vorzugsweise auch schauen, was mit dem Watcom-Compiler geht. Bei Windows 11 oder Linux könnte man ja die 64-Bit Variante ausprobieren. https://github.com/open-watcom/open-watcom-v2#open-watcom-v2-fork Und wenn man sich das jetzt noch denkt, wie das aussehen könnte, mit den coolen Pascal Tutorials oder den coolen Werkzeugen, Systemhilfen, oder Asm usw. nur eben für C++ und für Linux.. Was wäre überhaupt vergleichbar?
Niklas G. schrieb: > Peter K. schrieb: >> Ganz offenbar war es mal richtig.. > > Ne, nie ohne "using namespace std;" oder std:: . Du bist noch zu jung :) In der in der ersten Auflage von Bjarne Stroustrup "The C++ Programming Language" beschriebenen C++-Version gab es noch keine Namespaces, und die Namen der Headerfiles hatten (wie auch in C) die Endung ".h". Eine Zeitlang gab es bei den meisten C++-Compiler jeweils zwei Varianten der Headerfiles: - eine mit der Endung ".h" (bspw "iostream.h") und ohne Namespaces (aus Gründen der Abwärtskompatibilität) - eine ohne Endung (bspw. "iostream") und mit Namespace "std" (ISO-konform) Erstere wurden irgendwann hinausgeschmissen.
rbx schrieb: > Was wäre überhaupt vergleichbar? QtCreator? Solche vollintegrierten Sachen kommen in der OpenSource-Community nicht gut an, deswegen hat man da unter Linux eine etwas zerstückelte Tool-Landschaft für C und C++. Das ist aber heutzutage eher Nische. Unter Windows mit Visual Studio sieht das anders aus. Die Tools für Java, Kotlin, Android-App-Programmierung hingegen sind extrem leistungsfähig und überhaupt kein Vergleich zu C++- Tools. Da wäre ein Vergleich zu Pascal interessant... Yalu X. schrieb: > Du bist noch zu jung :) Wenn das so lange her ist, dass heutige Softwareentwickler das gar nicht mehr kennen, ist es vermutlich auch nicht mehr so relevant ;-) Yalu X. schrieb: > In der in der ersten Auflage von > > Bjarne Stroustrup "The C++ Programming Language" "This book was published in 1985 and is not up-to-date" Sind Bücher aus der Anfangszeit von Pascal, also aus den 70ern, uneingeschränkt weiter gültig?
Niklas G. schrieb: > Sind Bücher aus der Anfangszeit von Pascal, also aus den 70ern, > uneingeschränkt weiter gültig? Natürlich nicht. Die Entwicklung praktisch jeder Programmiersprache durchläuft am Anfang eine Phase, in der nichtabwärtskompatible Änderungen an der Sprachdefinition vorgenommen werden. Das war bei Pascal nicht anders als bei C und C++. Wer zu früh in eine neue Programmiersprache einsteigt, muss deswegen damit rechnen, dass er seinen Code noch ein paarmal überarbeiten muss.
Gast
#7206692
Die aktuelle Generation kann das ja sehr schön bei Python mitverfolgen z.B.
Peter K. schrieb: > Die aktuelle Generation kann das ja sehr schön bei Python mitverfolgen > z.B. Python ist jetzt über 20 Jahre alt. Bei der Umstellung von Version 2 auf 3 hat es kleinere syntaktische Änderungen und eine über zehn Jahre dauernde Phase zur Umstellung gegeben, in der beide Versionen unterstützt wurden. Zudem gab es schon früh eine umfangreiche Dokumentation für die Migration, Tools zur automatischen Konvertierung und Kompatibilitätsbibliotheken für Code, der beide Versionen unterstützt. Seit der Umstellung auf Version 3 wurden nurmehr Funktionen hinzugefügt, wie beispielsweise die f-Strings oder zuletzt das Structural Pattern Matching.
Gast
#7207339
jepp, wie gesagt, da kann man es mitverfolgen Zitat aus dem Netz "Die Frage stellt sich durchaus, da Python 3 nicht vollständig abwärtskompatibel zu Python 2 ist. Da aber alle wichtigen Bibliotheken und Frameworks mittlerweile mit Python 3 laufen, können Sie im Normalfall getrost auf die neuere Version setzen."
Peter K. schrieb: > Nein, ich habe hier 4 oder 5 Bücher über C und C++ und stoße ständig auf > soclhe Unterschiede oder Probleme.. Welche Bücher sind es denn? Das wäre mal interessant zu erfahren. Du hast bisher nur das online-Buch von Willemer genannt, mein Kommentar dazu: Beitrag "Re: use namespace oder std?"
Gast
#7207391
Peter Pan schrieb: >> In einem anderen vor mir leigendem Lehrbuch steht das >> Beipsiel.#include <iostream.h> >> void main() >> { >> cout << "Hello World"; >> } >> >> Das funktioniert nicht mal.... > > Die haben es echt geschafft "Hello World" aus dem Standardwerk FALSCH > abzuschreiben?! Nein. Das war mal gültiges C++. Heute ist das C++ Leben komplizierter, und du musst mehr tippen (*). Inzwischen werden schon C++ Features abgekündigt, die aus dem C++ Standard von 2011 stammen... Das Dreckzeugs ist mit sich selbst inkompatibel. Probiere mal ein 15 Jahre altes C++ Programm mit modernen Tools zu übersetzen, oder ein 5 Jahre altes C++ Programm mit alten Tools... (*) Dafür gibt es jetzt das "auto" Keyword, weil keiner da den Überblick behalten kann, und/oder Arthritis in den Fingern bekommt.
Gast
#7207395
Niklas G. schrieb: > Bei C und C++ schon, die alle konsistent unter einen Hut zu bekommen ist > nicht so einfach. Dazu noch der historisch gewachsene Charakter und die > Abwärtskompatibilität von C++ zu C... Das ist eigentlich kein Problem. C war immer schon einfach strukturiert, einfach zu lesen, effizient zu übersetzen, und hatte genau einen richtigen Weg etwas zu machen. Es war auch einfach zu lernen und der Ausbildungsstand war sehr gut. C++ ist dagegen einen Müllhalde aus Komplexität... Moderne C++ Template Programmierung treibt das auf die Spitze, da kommen weltweit vielleicht noch 100 Entwickler mit.
Udo K. schrieb: > Probiere mal ein 15 Jahre altes C++ Programm mit modernen Tools zu > übersetzen, oder ein 5 Jahre altes C++ Programm mit alten Tools... C++ ist eine der Sprachen mit denen das am besten geht. Ein korrektes(!) 20 Jahre altes C++ Programm lässt sich problemlos übersetzen wenn man eben C++98 einstellt. Abwärtskompatibilität, insbesondere zu C, ist eines der Hauptfeatures von C++, aber eben nur zu den standardisierten Versionen und nicht zu den informellen Versionen davor. Wenn man alle alten Zöpfe abschneidet kommt Rust heraus. Udo K. schrieb: > C++ ist dagegen einen Müllhalde aus Komplexität... Ein Gutteil der Komplexität ergibt sich aus den Notwendigkeiten der Abwärtskompatibilität. Müsste man z.B. nicht die schrägen Regeln zur Integer Promotion aus C unterstützen, wäre einiges einfacher. Udo K. schrieb: > Es war auch einfach zu lernen Ja, dem Anfänger erschließt sich die Bedeutung von "char* argv[]" sofort. Und warum
1 | |
nicht funktioniert. Und warum man keine Arrays zurückgeben kann. Und warum man die Länge von Arrays nicht anhand des Zeigers ermitteln kann. Und warum man zu einem Array nicht einfach was hinzufügen kann. Und warum es keinen Listen-Typ gibt. Wie man das alles aus fast allen anderen Sprachen gewohnt ist.
Gast
#7207421
Niklas G. schrieb: > C++ ist eine der Sprachen mit denen das am besten geht. Ein korrektes(!) > 20 Jahre altes C++ Programm lässt sich problemlos übersetzen wenn man > eben C++98 einstellt. Abwärtskompatibilität, insbesondere zu C, ist > eines der Hauptfeatures von C++, aber eben nur zu den standardisierten > Versionen und nicht zu den informellen Versionen davor. Wenn man alle > alten Zöpfe abschneidet kommt Rust heraus. Konkret geht es mit dem einfachen Beispiel hier mit dem aktuellen MS Compiler nicht. Auch nicht mit -std:c++14, und -std:c++98 liefert nur Fehler. Genauso mit clang-cl. Und das betrifft nur den Compiler. Die "Standard" Libs werden aber noch viel öfter "angepasst". Kaum einer hat wirklich den Durchblick, und wo man den Durchblick nicht hat, kommt bescheidener und ineffizienter Code raus. Es hat schon gute Gründe warum heute die Mehrheit der Windows Programme, die von einem einzigen Entwickler gebaut werden, Borland Delphi verwenden. C++ ist ein Komplexitätsmonster, wo alles geht aber nix einfach ist. Auch C++ Frameworks sind viel zu komplex. Kein grosses Problem wenn man 24/7 C++ programmiert und/oder noch jung und lernbegierig ist.
Beitrag #7207422 wurde von einem Moderator gelöscht.
Gast
#7207425
Niklas G. schrieb: > Abwärtskompatibilität von C++ zu C C ist kein Subset von C++. Es gibt unzählige Situationen, wo gültiger C code nicht gültiger C++ Code ist, oder in welchem der selbe code was komplett anderes bedeutet.
Udo K. schrieb: > Das ist eigentlich kein Problem. C war immer schon einfach > strukturiert, einfach zu lesen, effizient zu übersetzen, und hatte genau > einen richtigen Weg etwas zu machen. Es war auch einfach zu lernen und > der Ausbildungsstand war sehr gut. Hier stimmte ich keiner einzigen Aussage zu. Udo K. schrieb: > C++ ist dagegen einen Müllhalde aus Komplexität... Moderne C++ Template > Programmierung treibt das auf die Spitze, da kommen weltweit vielleicht > noch 100 Entwickler mit. Die template-Syntax ist zugegebenermaßen nicht besonders intuitiv. Wenn Du TMP meinst: viele Leute machen sich einfach nicht klar oder sind nicht bereit oder in der Lage zu verstehen, was dort eigentlich geschieht. Das man nämlich hier Funktionen (im mathematischen Sinn einer Abbildung) schreibt, die folgende Arten von Abbildungen machen können: 1) Wert -> Wert 2) Wert -> Typ 3) Typ -> Wert 4) Typ -> Typ (wobei die Werte compile-zeit konstant sind). Man kann also mit Typen "rechnen". Wer diesen Abstraktionsschritt nicht schafft, der hat es sicher schwer. Wer es aber versteht, hat auch mit TMP wenig Probleme.
Gast
#7207438
Niklas G. schrieb: >> C++ ist dagegen einen Müllhalde aus Komplexität... > > Ein Gutteil der Komplexität ergibt sich aus den Notwendigkeiten der > Abwärtskompatibilität. Müsste man z.B. nicht die schrägen Regeln zur > Integer Promotion aus C unterstützen, wäre einiges einfacher. Nein. Die Komplexität steigt ja mit jeder neuen Ausgabe immer weiter an. Die Integer Promotion ist doch Pipifax, und nicht der Rede wert. Der Grund dürfte darin liegen, dass Einfachheit kein Ziel von C++ ist. Was hätten die Vollpfosten sich ersparen können, wenn sie die wichtigen Datentypen wie String und Array einfach in die Sprache fix eingebaut hätten. Im Prinzip ist die C++ Geschichte der Versuch grundlegende Typen wie String und Array so in die Sprache zu integrieren, dass der Anwender der Sprache keinen Unterschied zu einem eingebauten fixen Typ sieht. Bis jetzt funktioniert das nicht wirklich gut. Im Gremium sitzen zudem keine einfachen Anwender sondern Typen, die vom Bücherschreiben (sehr gut) leben.
Gast
#7207440
Wilhelm M. schrieb: > Die template-Syntax ist zugegebenermaßen nicht besonders intuitiv. Die Fehlermeldungen sind es noch viel weniger... Die Templates waren einfach ein unausgegorener Hack mit explodierender Komplexität und x Fehlermöglichkeiten in jeder Codezeile. Probiere doch mal eine Liste als Template zu schreiben, wo eine Anwenderklasse in mehreren Listen enthalten sein kann, und wo die Links der Liste in der Anwender-Klasse selbst enthalten sind. Viel Spass. Oder versuche einfach mal die Template vector Klasse zu verstehen...
Udo K. schrieb: > Konkret geht es mit dem einfachen Beispiel hier mit dem aktuellen MS > Compiler nicht. Auch nicht mit -std:c++14, und -std:c++98 liefert nur > Fehler. > Genauso mit clang-cl. Das Beispiel war aber nicht nach Standard-C++ korrekt, nur nach dem "prähistorischen" C++ ohne Namespaces. Wie gesagt ist C++ nur zu den Standard-Versionen abwärtskompatibel, nicht den informellen ersten Entwürfen. Udo K. schrieb: > Kaum einer hat wirklich den Durchblick Du vielleicht nicht. Auch die Standard-Bibliothek entfernt sehr selten Abwärtskompatibilität, wo es wirklich kaum anders sinnvoll ist. Aber auch dann kann man immer noch "-std=c++98" angeben und erhält die alten Features wieder. Udo K. schrieb: > Es hat schon gute Gründe warum heute die Mehrheit der Windows Programme, > die von einem einzigen Entwickler gebaut werden, Borland Delphi > verwenden. Steile These! Das wird wohl eher C# sein. DPA schrieb: > C ist kein Subset von C++. Es gibt unzählige Situationen, wo gültiger C > code nicht gültiger C++ Code ist "Unzählig" ist stark übertrieben. C++ ist i.W. zu alten C-Versionen kompatibel, Dinge aus neuen C-Versionen werden teilweise nicht übernommen, insbesondere weil C++ bereits bessere Mechanismen dafür hat. z.B. C-Generics übernehmen macht sehr wenig Sinn, weil C++ bereits Overloads hat. Udo K. schrieb: > Nein. Die Komplexität steigt ja mit jeder neuen Ausgabe immer weiter > an. Klar, wie bei allen Sprachen. Udo K. schrieb: > Die Integer Promotion ist doch Pipifax, und nicht der Rede wert. Für dich vielleicht, gerade im Embedded-Kontext kann das lustige Überraschungen bedeuten. Udo K. schrieb: > Der Grund dürfte darin liegen, dass Einfachheit kein Ziel von C++ ist. Fällt dir früh auf. Udo K. schrieb: > Was hätten die Vollpfosten sich ersparen können, wenn sie die wichtigen > Datentypen wie String und Array einfach in die Sprache fix eingebaut > hätten. Das haben die Vollpfosten bei C auch nicht gemacht. Zur Kompatibilität zu C und für hardwarenahe Programmierung sind die "rohen" Datentypen wichtig. Und dann macht es eben Sinn, die abstrakteren Typen darauf aufzubauen anstatt parallel einen weiteren Mechanismus in der Sprache einzubauen. Außerdem verfolgt die C++-Kernsprache auch das Konzept des Minimalismus - alles was nicht unbedingt in die Sprache muss, kommt auch nicht rein, sondern in die Standard-Bibliothek. Udo K. schrieb: > Im Gremium sitzen zudem keine einfachen Anwender sondern Typen, die vom > Bücherschreiben (sehr gut) leben. Der C-Standard ist auch nicht gratis.
Udo K. schrieb: > Im Gremium sitzen zudem keine einfachen Anwender sondern Typen, die vom > Bücherschreiben (sehr gut) leben. Ich bin froh, dass im Committee keine einfachen Anwender sitzen! Sondern Leute, die mehr Sachverstand haben. Doch wenn Dich etwas stört, steht es Dir frei, ein Paper zu schreiben und zum Review einzureichen. Auch darfst Du Dich um einen Platz im Committee bewerben, bei entsprechender Expertise natürlich.
Gast
#7207457
Wilhelm M. schrieb: >> Das ist eigentlich kein Problem. C war immer schon einfach >> strukturiert, einfach zu lesen, effizient zu übersetzen, und hatte genau >> einen richtigen Weg etwas zu machen. Es war auch einfach zu lernen und >> der Ausbildungsstand war sehr gut. > > Hier stimmte ich keiner einzigen Aussage zu. Wäre schön, wenn du das Begründen könntest...
Udo K. schrieb: > Die Templates waren einfach ein unausgegorener Hack mit explodierender > Komplexität und x Fehlermöglichkeiten in jeder Codezeile. Anfangs ja, mittlerweile ist es ein anerkanntes Paradigma und ermöglicht effiziente und abstrakte Programmierung. Sowas wie Boost.Spirit gibt es nur dank templates und auch in keiner andere Sprache. Udo K. schrieb: > Probiere doch mal eine Liste als Template zu schreiben, wo eine > Anwenderklasse in mehreren Listen enthalten sein kann, und wo die Links > der Liste in der Anwender-Klasse selbst enthalten sind. Viel Spass. Boost.Intrusive enthält so was, und es ist auch kein großes Problem. Mehrfach-Vererbung kann hier helfen. Udo K. schrieb: > Oder versuche einfach mal die Template vector Klasse zu verstehen... Ist in Stroustrup's Buch detailliert erläutert.
Udo K. schrieb: > Wilhelm M. schrieb: >> Die template-Syntax ist zugegebenermaßen nicht besonders intuitiv. > > Die Fehlermeldungen sind es noch viel weniger... Hat sich bei clang und auch gcc enorm gebessert. Und durch concepts allemal. > Die Templates waren einfach ein unausgegorener Hack mit explodierender > Komplexität und x Fehlermöglichkeiten in jeder Codezeile. Am Anfang vielleicht (sie entsprachen auch nicht ganz den Vorstellungen von B.S. und Stepanov) > Probiere doch mal eine Liste als Template zu schreiben, wo eine > Anwenderklasse in mehreren Listen enthalten sein kann, und wo die Links > der Liste in der Anwender-Klasse selbst enthalten sind. Viel Spass. Die Links der Liste in der Anwenderklasse? Warum sollte ich diese Abhängigkeit schaffen? Scheint mir wenig sinnvoll und gegen Grundprinzipien zu verstoßen. > Oder versuche einfach mal die Template vector Klasse zu verstehen... Schulstoff.
Wilhelm M. schrieb: > Die Links der Liste in der Anwenderklasse? Warum sollte ich diese > Abhängigkeit schaffen? Scheint mir wenig sinnvoll und gegen > Grundprinzipien zu verstoßen. Die Links kommen nicht direkt in die Klasse, sondern eine template-Hilfsklasse die zur Listen-Implementation gehört, von der man eine Member-Variable in der Anwenderklasse anlegt, oder von der die Anwenderklasse ableitet. Das ist ein bisschen effizienter als die "saubere" Implementation (à la std::list) weil man weniger allokieren muss. Ein angenehmer Nebeneffekt ist dass man aus einem Zeiger auf die Klasse direkt einen Iterator bekommt.
Udo K. schrieb: > Wilhelm M. schrieb: >>> Das ist eigentlich kein Problem. C war immer schon einfach >>> strukturiert, einfach zu lesen, effizient zu übersetzen, und hatte genau >>> einen richtigen Weg etwas zu machen. Es war auch einfach zu lernen und >>> der Ausbildungsstand war sehr gut. >> >> Hier stimmte ich keiner einzigen Aussage zu. > > Wäre schön, wenn du das Begründen könntest... Warum sollte ich? Das sind erstmal Behauptungen von Dir aus Deiner persönlichen Sichtweise, die Du auch nicht begründest.
Niklas G. schrieb: > Wilhelm M. schrieb: >> Die Links der Liste in der Anwenderklasse? Warum sollte ich diese >> Abhängigkeit schaffen? Scheint mir wenig sinnvoll und gegen >> Grundprinzipien zu verstoßen. > > Die Links kommen nicht direkt in die Klasse, sondern eine > template-Hilfsklasse die zur Listen-Implementation gehört, von der man > eine Member-Variable in der Anwenderklasse anlegt, oder von der die > Anwenderklasse ableitet. Mmh ... erscheint mir eher wie ein Hack. > > Das ist ein bisschen effizienter als die "saubere" Implementation (à la > std::list) weil man weniger allokieren muss. Leuchtet mir auch nicht ein. Beispiel?
Wilhelm M. schrieb: > Mmh ... erscheint mir eher wie ein Hack. Ja schon. Manchmal nimmt man es in Kauf. Wilhelm M. schrieb: > Leuchtet mir auch nicht ein. Beispiel? Da empfehle ich einfach anzuschauen wie und warum Boost es macht: https://www.boost.org/doc/libs/1_80_0/doc/html/intrusive.html#intrusive.introduction https://www.boost.org/doc/libs/1_80_0/doc/html/intrusive/intrusive_vs_nontrusive.html https://www.boost.org/doc/libs/1_80_0/doc/html/intrusive/performance.html
Gast
#7207481
Niklas G. schrieb: > Udo K. schrieb: >> Konkret geht es mit dem einfachen Beispiel hier mit dem aktuellen MS >> Compiler nicht. Auch nicht mit -std:c++14, und -std:c++98 liefert nur >> Fehler. >> Genauso mit clang-cl. > > Das Beispiel war aber nicht nach Standard-C++ korrekt, nur nach dem > "prähistorischen" C++ ohne Namespaces. Wie gesagt ist C++ nur zu den > Standard-Versionen abwärtskompatibel, nicht den informellen ersten > Entwürfen. Morgen ist halt C++11 "prähistorisch". C++23 erklärt gerade C++11 prähistorisch... > > Udo K. schrieb: >> Kaum einer hat wirklich den Durchblick > > Du vielleicht nicht. Auch die Standard-Bibliothek entfernt sehr selten > Abwärtskompatibilität, wo es wirklich kaum anders sinnvoll ist. Aber > auch dann kann man immer noch "-std=c++98" angeben und erhält die alten > Features wieder. Wie gesagt, geht auf einer der verbreitesten Platformen -std=c++98 nicht... Und die Aussage mit dem Durchblick kam auch von jemandem der im C++ Gremium sitzt. Und wie ich schon sagte, ist das kein grosses Problem, wenn man 7 Tage die Woche 24 Stunden C++ programmiert. > > Udo K. schrieb: >> Es hat schon gute Gründe warum heute die Mehrheit der Windows Programme, >> die von einem einzigen Entwickler gebaut werden, Borland Delphi >> verwenden. > > Steile These! Das wird wohl eher C# sein. Interessanterweise sind viele Einzelkämpfer nach wie vor bei Delphi. Der Grund dürfte sein, dass die Sprache nicht so wichtig ist, aber die mitgelieferten Libs sind entscheidend. > > Udo K. schrieb: >> Der Grund dürfte darin liegen, dass Einfachheit kein Ziel von C++ ist. > > Fällt dir früh auf. Das weiß ich schon seit C++98. Wobei ja nicht alles an C++ schlecht ist, man muss sich halt die Rosinen rauspicken. > Zur Kompatibilität zu C und für hardwarenahe Programmierung sind die "rohen" Datentypen > wichtig. Und dann macht es eben Sinn, die abstrakteren Typen darauf > aufzubauen anstatt parallel einen weiteren Mechanismus in der Sprache > einzubauen. Außerdem verfolgt die C++-Kernsprache auch das Konzept des > Minimalismus - alles was nicht unbedingt in die Sprache muss, kommt auch > nicht rein, sondern in die Standard-Bibliothek. Genau das macht keinen Sinn, weil es viel zu viel Komplexität und Implementierungsunsicherheit in die Sprache reinbringt. > Udo K. schrieb: >> Im Gremium sitzen zudem keine einfachen Anwender sondern Typen, die vom >> Bücherschreiben (sehr gut) leben. > > Der C-Standard ist auch nicht gratis. C++ Gurus, die zum Teil auch im Gremium sitzen verdienen mit Lehrbüchern ihr Geld, für den Standard zahlt man trotzdem noch mal. Das ist auch bei C so. Und leider orientiert sich C inzwischen immer mehr an C++: In Zukunft werden auch alte funktionierende C Programme nicht mehr kompilieren, und das völlig unnötigerweise, weil der neue Standard meint irgendein jahrelang funktionierendes Feature wäre nicht mehr zeitgemäß.
Niklas G. schrieb: > Wilhelm M. schrieb: >> Mmh ... erscheint mir eher wie ein Hack. > > Ja schon. Manchmal nimmt man es in Kauf. Ah, Du meinst "internal storage". Sorry, aus den Posts habe ich das nicht erkannt. Nun, bevor man das macht, sollte man ggf. messen und überlegen, ob contiguous allokation ala std::vector nicht eh besser ist.
Udo K. schrieb: > Morgen ist halt C++11 "prähistorisch". C++23 erklärt gerade C++11 > prähistorisch... Nein. Nur das was vor den Standards kam. Alles was standardisiert ist, wird noch lange unterstützt werden. Udo K. schrieb: > Wie gesagt, geht auf einer der verbreitesten Platformen -std=c++98 > nicht... Welches Beispiel, und zu welchem Standard was es kompatibel? Udo K. schrieb: > Der Grund dürfte sein, dass die Sprache nicht so wichtig ist, aber die > mitgelieferten Libs sind entscheidend. Die .net Library ist extrem umfangreich. Die Java Standard Library auch. Udo K. schrieb: > Genau das macht keinen Sinn, weil es viel zu viel Komplexität und > Implementierungsunsicherheit in die Sprache reinbringt. Ich find's super das die Sprache so mächtig ist, dass man komplexe Datentypen selbst implementieren kann, von Strings über Vectoren zu Bäumen, Graphen oder whatever. Udo K. schrieb: > weil der neue Standard meint > irgendein jahrelang funktionierendes Feature wäre nicht mehr zeitgemäß. Die Welt dreht sich weiter, neue Erkenntnisse kommen hinzu, neue bessere Techniken werden erfunden. Gerade C und C++ sind sehr konservativ und langsam. Und wie gesagt werden alte Standards nach wie vor unterstützt, man kann halt lediglich ein paar alte Features, die in neuen Standards entfernt wurden, nicht mit neuen Features mischen.
Gast
#7207506
Wilhelm M. schrieb: >> Oder versuche einfach mal die Template vector Klasse zu verstehen... > > Schulstoff. Das hast du dir nicht wirklich angeschaut, oder? Alleine die eine Zeile "#include <vector>" wird zu über 42000 Zeilen Template Code expandiert...
Beitrag #7207515 wurde von einem Moderator gelöscht.
Udo K. schrieb: > Alleine die eine Zeile > "#include <vector>" wird zu über 42000 Zeilen Template Code > expandiert... Bei mir sind es 14400, und die ersten 10500 sind nur Abhängigkeiten/Utilities. Und dafür kann der Vector mehr als die Vektoren in den meisten Programmiersprachen (außer Rust). Blickst du bei der ganzen Delphi Library durch?
Niklas G. schrieb: > Udo K. schrieb: >> Alleine die eine Zeile >> "#include <vector>" wird zu über 42000 Zeilen Template Code >> expandiert... > > Bei mir sind es 14400, und die ersten 10500 sind nur > Abhängigkeiten/Utilities. Und dafür kann der Vector mehr als die > Vektoren in den meisten Programmiersprachen (außer Rust). Und weiterhin sind sehr viele Zeilen einfach der Abwärtskompatibilität geschuldet. Wenn Du das alles weglässt bzw. from-scratch mit modernem C++ neu schreibst, kann Du es sehr kurz und knapp machen (und trotzdem die Kompatibilität zu den std-algos bewahren).
Gast
#7207528
Zum Punkt: Pascal/Delphi: Ich geb Dir recht, Pascal/Delphi sind gute Sprachen für Programmiereinsteiger gewesen vor längerer Zeit und hat auch für die GUI-Programmierung/GUI-Prototypen-Entwicklung längere Zeit ne Rolle gespielt. Durch .net ist das weitgehend abgelöst worden, und Python übernimmt da auch massiv was davon. Grundsätzlich spricht glaube ich wenig dagegen, auch heute noch Pascal einzusetzen: Clang oder GCC haben Frontends dafür, mit denen du auch gegen C-Code linken kannst - d.h. beide Programmiersprachen im selben Projekt nutzen. Der Trick liegt dann eher dabei, eine Entwicklungsumgebung zu finden, die mit beiden Programmiersprachen gleichzeitig umzugehen weiß bzw. die Organisation des Kompilierens über Makefiles bzw. CMake zu organisieren. Auch für Mikrocontroller spielen die Pascal-Derivate noch ne Rolle, z.B. ADA. Kannste sogar für safety-critical-Zeug nutzen. Für FPGAs eben VHDL, was in der Simulation der Sache zumindest ähnelt. Zur eigentlichen Frage: Namespaces sind ein Konzept, was wohl hauptsächlich in der STL und bei den Boost-Bibliotheken benutzt wird - bei der C++-Windows-Programmierung gibts das quasi nicht auf C++-Ebene. Crossplatform kann's vielleicht ne Rolle spielen, aber auch in Qt wirds relativ begrenzt genutzt. Welchen Nutzen bringt's? Du kannst damit eben Funktionen und Klassen, die den selben Namen haben über Namensräume unterscheiden. Halt z.B. eine Funktion std::cout und myNamespace::cout haben, und über using bzw. explizite Qualifizierung sagen, welche du haben möchtest. Die nächst-höhere Stufe ggü. Namensräumen sind halt statische Funktionen in Klassen, da wirkt quasi der Klassenname als Namensraum - das Prinzip ist aber nicht viel anders. Da musste sogar dann den Klassennamen davor schreiben. Die höchste Stufe sind quasi 'dynamische Namenräume' - halt Objekte, die von ner Klasse erzeugt werden. -> siehst also, der Sinn und Zweck von Namensräumen ist es, Dinge zu kategorisieren. Ist also Geschmackssache. Grundsätzlich aber auch hier "Keep-It-Simple (but not Simpler than that)". Wenn du Code mit anderen Komponenten teilen musst, spricht aber vieles dafür, explizite Qualifizierung (halt std:: davor) zu nutzen.
PS: Ein Grund warum die C++ Standard Library so kryptisch aussieht ist dass hier für interne Zwecke nur reservierte Bezeichner verwendet werden dürfen, d.h. mit doppeltem Unterstrich oder Unterstrich+Großbuchstabe. Solche Bezeichner sind im Usercode verboten, so werden Kollisionen vermieden. Auch das hilft bei der Abwärtskompatibilität. Wenn eine neue Version der Bibliothek intern einen neuen Bezeichner "_M_bla" verwendet kann es keine Kollisionen geben, weil "_M_bla" nie im Usercode definiert sein darf. Wenn dein alter Code aber so etwas enthält:
1 | |
2 | |
Gibt es Probleme. Dieser Code war aber nie korrekt, und hat nur zufällig mal funktioniert. Daher ist es wichtig, immer korrekten Code zu schreiben welcher auch solche Regeln befolgt und eben keine Bezeichner der Form "_M_bla" definiert, sodass solche Probleme nicht auftreten können. So etwas hingegen
1 | |
2 | |
ist korrekt und erlaubt. Wenn eine neue C++ -Version für den Vektor eine neue öffentliche Memberfunktion "ozapftis" einführt, gibt es hier eine Kollision. Die neue Funktion ist im Standard dokumentiert, entsprechend muss der Code dann angepasst werden, um mit der neuen Version kompiliert werden zu können. Man kann aber immer noch im Compiler die alte C++-Version einstellen, in welcher der Vektor dann opzapftis nicht definiert, und der Code weiterhin funktioniert. Das wird ermöglicht durch eine Menge Fallunterscheidungen im Vektor-Code, wodurch es zwar komplexer wird, aber eben Abwärtskompatibilität gegeben ist. Die Ursache für diese Probleme liegt im C-Präprozessor, der bekanntlich eine stupide Textersetzung ist die auch Interna der Standardbibliothek verbiegen kann. Andere Sprachen ohne Präprozessor haben solche Probleme nicht. Nicht ohne Grund versucht man in C++ so weit wie möglich ohne ihn auszukommen, aber leider ist er aus Kompatibilitätsgründen zu C noch drin. Exakt das gleiche Problem hat C natürlich auch, nur dass die Bibliothek nicht so umfangreich ist und nicht so viele interne Bezeichner braucht. db8fs schrieb: > bei der C++-Windows-Programmierung > gibts das quasi nicht auf C++-Ebene. Nur beim Win32-API, weil das eben ein C-API ist. Da aber viele Programme noch weitere Bibliotheken à la Boost verwenden, kommen da auch Namespaces zum Einsatz.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.