use namespace oder std?

[Peter K. (Gast)]

using namespace std;
oder
 std::cout << "Hello World!";

Was ist der Vor/Nachteil?
Was nutzt ihr und wieso?

[Oliver S. (oliverso)]

Was sagt denn dein Lehrer?

Oliver

[Volker Z. (vzavza)]

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.

[MikeH (Gast)]

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.

[Peter K. (Gast)]

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.

[Peter K. (Gast)]

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

[Niklas G. (erlkoenig)]

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":

using std::cout;
using std::string;

Wobei mit etwas Gewöhnung das Tippen von "std::string" o.ä. auch kein 
Problem mehr ist.

[DPA (Gast)]

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.

[Oliver S. (oliverso)]

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

[Wilhelm M. (wimalopaan)]

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.

[Peter K. (Gast)]

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?

[Peter K. (Gast)]

"
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

[Wilhelm M. (wimalopaan)]

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?

[Peter K. (Gast)]

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

[rbx (Gast)]

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.

[Niklas G. (erlkoenig)]

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?

[Peter K. (Gast)]

Ich habe gerade mal das Beispiel auspobiert mit using davor
Wieso ist das using hier falsch verwendet?
Ohne Using geht es natürlich problemlos

#include <iostream>


int main()
{
  using std::cout<<"Hello World";

    return 0;
}

[Oliver S. (oliverso)]

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

[Niklas G. (erlkoenig)]

Peter K. schrieb:
> Wieso ist das using hier falsch verwendet?

Das ist halt keine C++ -Syntax. Was soll das "using" da bewirken?!

[Wilhelm M. (wimalopaan)]

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?

[Yalu X. (yalu) (Moderator)]

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

using std::cout, std::endl, std::hex, std::dec, std::fixed, std::setw,
      std::setprecision;

die nervigen Wiederholungen von "std::" weglassen könnte, bspw. so:

using std (cout, endl, hex, dec, fixed, setw, setprecision);

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:

using namespace std {
  // Deklaration 1;
  // Deklaration 2;
  // ...
}

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.

[IUnknown (Gast)]

```cpp
#include <iostream>

using std::cout;

int main()
{
    cout << "Hello World";
    return 0;
}
```

[Peter K. (Gast)]

???
Was genau willst Du damit sagen?
Du verwendest es so? Aber die Frage, warum, ist damit ja nicht 
beantwortet;-)

[J. S. (jojos)]

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.

[loeti2 (Gast)]

Ich finde

#using

 grauenvoll.
Ist eine Frage der Gewöhnung aber

std::

 vor jede benutzte Funktion zu schreiben bringt mich nicht um.
Wo ich eher Zweifel habe, ob

auto

 nun gut ist oder nicht.
Die KiCAD-Entwickler entfernen es ja wieder nach und nach aus ihrem 
Code.

[Wilhelm M. (wimalopaan)]

loeti2 schrieb:
> Ich finde

#using

 grauenvoll.

Was soll das sein?

> Ist eine Frage der Gewöhnung aber

std::

 vor jede benutzte
> Funktion zu schreiben bringt mich nicht um.

Jede wohl kaum?

> Wo ich eher Zweifel habe, ob

auto

 nun gut ist oder nicht.
> Die KiCAD-Entwickler entfernen es ja wieder nach und nach aus ihrem
> Code.

Das wird nicht überall gehen ;-)

[Peter K. (Gast)]

In einem anderen vor mir leigendem Lehrbuch steht das Beipsiel.

#include <iostream.h>


void main()
{
    cout << "Hello World";
}

Das funktioniert nicht mal....

[Niklas G. (erlkoenig)]

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++...

[Peter K. (Gast)]

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...

[Niklas G. (erlkoenig)]

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.

[Peter K. (Gast)]

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

#include <iostream>


void main()
{
    using namespace std;
    cout << "Hello World";
}

[Peter K. (Gast)]

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

[Niklas G. (erlkoenig)]

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?

[Peter K. (Gast)]

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?

[Niklas G. (erlkoenig)]

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?

[Wilhelm M. (wimalopaan)]

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!

[Peter K. (Gast)]

@ 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

[Peter Pan (Gast)]

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...

[Niklas G. (erlkoenig)]

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.

[Peter Pan (Gast)]

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.

[Peter K. (Gast)]

@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.

[Niklas G. (erlkoenig)]

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...

[Peter K. (Gast)]

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/

[Niklas G. (erlkoenig)]

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.

[Peter K. (Gast)]

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."

[Niklas G. (erlkoenig)]

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.

[Wilhelm M. (wimalopaan)]

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.

[rbx (Gast)]

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?

[Yalu X. (yalu) (Moderator)]

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.

[Niklas G. (erlkoenig)]

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?

[Yalu X. (yalu) (Moderator)]

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.

[Peter K. (Gast)]

Die aktuelle Generation kann das ja sehr schön bei Python mitverfolgen 
z.B.

[Ein T. (ein_typ)]

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.

[Peter K. (Gast)]

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."

[Wilhelm M. (wimalopaan)]

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?"

[Udo K. (udok)]

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.

[Udo K. (udok)]

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.

[Niklas G. (erlkoenig)]

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

"ich heiße " + Name + " und bin " + Alter + " Jahre alt".

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.

[Udo K. (udok)]

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.

[DPA (Gast)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Udo K. (udok)]

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.

[Udo K. (udok)]

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...

[Niklas G. (erlkoenig)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Udo K. (udok)]

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...

[Niklas G. (erlkoenig)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Niklas G. (erlkoenig)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Wilhelm M. (wimalopaan)]

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?

[Niklas G. (erlkoenig)]

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

[Udo K. (udok)]

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äß.

[Wilhelm M. (wimalopaan)]

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.

[Niklas G. (erlkoenig)]

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.

[Udo K. (udok)]

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...

[Niklas G. (erlkoenig)]

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?

[Wilhelm M. (wimalopaan)]

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).

[db8fs (Gast)]

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.

[Niklas G. (erlkoenig)]

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:

#define _M_bla hans wurst
#include <vector>

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

#define opzapftis 42
#include <vector>

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.