Warum hat C++ so eine aufwendige Syntax?
-
Artchi schrieb:
Warum werden solche Dinge nicht genannt?
Vielleicht weil die Miniproblemchen, die Du zulässt keine Sau interessieren? Vielleicht würdest Du die anderen Probleme auch erkennen, wenn Du Deine rosarote Brille abnähmest und aufhören würdest Dir hier auf die Schulter zu klopfen:
Weil die Leute nie intensiv mit C++ gearbeitet haben aber trotzdem ne große Fresse haben und die uralten Argumente, die sie mal gelesen/gehört haben, bringen.
-
Undertaker schrieb:
Simon2 schrieb:
- compilerübergreifendes Lib- und Klassen-Binärformat
es gibt für libs einige verbreitete binärformate wie elf/dwarf usw, allerdings enthalten libs immer maschinencode und sind daher nicht zwischen verschiedenen prozessoren austauschbar. was würde das also bringen?
Er meint sicherlich innerhalb einer Plattform. Also wenn ich unter Win32 bin, würde ich gerne in MSVC statische Libs nutzen, die jemand mit seinem g++ gebaut hat. Alleine die Bytegröße der nativen Datentypen unterscheidet sich von Compiler zu Compiler auf ein und der selben Plattform. MS hat unter Windows zumindest mit den COM-Specs eine absolute Vorgabe gemacht. Nützt aber C++ nichts, da die COM-Specs C-basiert sind... oder wie man sowas auch immer klassifizieren will.
Aber der C- und C++-Standard macht keine Vorgaben in dem Bereich, weil er nur eine Sprache und keine Plattform beschreibt. Also werden wir da auch nichts erwarten können. Aber um ehrlich zu sein, ich habe da kein Problem mit der aktuellen Situation. Wenn ich eine Library anbiete, habe ich mehrere Möglichkeiten:
- ich biete die Lib als Source an mit einem Buildfile (vorzugsweise Compiler-übergreifendes Format, z.B. bjam). Hier stellt Opensource den kleinsten Aufwand für beide Seiten (Kunde und Anbieter)
- bei Closedsource baue ich die Lib mit den verbreitesten Compiler vor (bzw. was die Kunden wünschen, ich muß ja nicht 10 Compiler kaufen, wenn meine Kunden nur Libs für MSVC und MinGW wünschen)
- ich biete bei Closedsource meinen zahlenden Kunden die Lib im Source an, falls ich kein Bock habe zu viele Compiler zu besorgen.
Hier sehe ich also das kleinste Problem. Bedarf sehe ich weiterhin im Bereich der Sprache und des Buildverfahrens.
-
Simon2 schrieb:
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
Ja, und dann ne Performance wie Javascript.
-
w schrieb:
Simon2 schrieb:
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
Ja, und dann ne Performance wie Javascript.
Das mein abgeleitetes Simon2int evtl. nicht mehr die Performance eines ints hat, leuchtet mir ja ein, aber warum sollte int langsamer werden ?
Gruß,
Simon2.
-
Simon2 schrieb:
w schrieb:
Simon2 schrieb:
- Grenze zu primitiven Typen aufheben (ableitbar, Operatoren überladen, ...)
Ja, und dann ne Performance wie Javascript.
Das mein abgeleitetes Simon2int evtl. nicht mehr die Performance eines ints hat, leuchtet mir ja ein, aber warum sollte int langsamer werden ?
Gruß,
Simon2.
Wenn du einen Simon2int haben willst, warum willst du diesen von int ableiten? Damit du operator+(int,int) benutzen kannst? Wenn deiner Klasse dieser genügt, dann reicht doch auch eine implizite Umwandlung von Simon2int zu int mit einem operator int in deiner Simon2int Klasse.
Ich kann darin keinen Vorteil erkennen und für mich macht das so viel Sinn wie das Überladen der Scope-Operatoren.
-
Simon2 schrieb:
Das mein abgeleitetes Simon2int evtl. nicht mehr die Performance eines ints hat, leuchtet mir ja ein, aber warum sollte int langsamer werden ?
Dann soll int ein primitiver Typ bleiben (also + -> add ax, 123) und zusätzlich so ne Art Klasse sein, von der man ableiten kann (also überschriebenes + -> Funktionsaufruf)? Das ist ja noch kaotischer und komplizierter. Naja, in C++ kann man ja auch ints als Exception werfen...
-
lolz schrieb:
...Wenn du einen Simon2int haben willst, warum willst du diesen von int ableiten? Damit du operator+(int,int) benutzen kannst?....
Warum will man überhaupt ableiten ?
Andersherum wird für mich ein Schuh draus: Warum darf man von allem Ableiten aber von int&Co nicht ? Das schränkt IMO die Möglichkeiten (z.B. von Metaprogrammierung) unnötig ein.
Ja, ja, ja, ich weiß: Performance, C-Compliance, .... die historischen Ursachen kenne ich.
Trotzdem würde ich mir eine größere Konsistenz wünschen.Gruß,
Simon2.
-
w schrieb:
...Dann soll int ein primitiver Typ bleiben (also + -> add ax, 123) und zusätzlich so ne Art Klasse sein, von der man ableiten kann (also überschriebenes + -> Funktionsaufruf)? Das ist ja noch kaotischer und komplizierter. Naja, in C++ kann man ja auch ints als Exception werfen...
1.) Die Umsetzung in eine konkrete Maschinensprache haben IMO nichts in einem Sprachkonzept zu suchen.
2.) Was soll denn daran chaotisch und kompliziert sein ? Stören Dich auch die vtables, die man beim Übergang C->C++ hinzugekommen sind ?
3.) Insgesamt hinterlassen Dein Stil und Deine Argumentation(sweise) eher den Eindruck als wolltest Du nur rumpöbeln - weniger nach Interesse an einer Diskussion.
Gruß,
Simon2.
-
-
w schrieb:
Dann soll int ein primitiver Typ bleiben (also + -> add ax, 123) und zusätzlich so ne Art Klasse sein, von der man ableiten kann (also überschriebenes + -> Funktionsaufruf)?
wenn man es inline ausführt, würde, so es möglich wäre, bei:
inline int operator+(const int& a, const int& b) { return a+b; }exakt die gleiche befehlsfolge rauskommen wie "a+b;".
wozu man das tatsächlich braucht kann, außer um ein paar konvertierungsprobleme zu lösen, sei mal dahin gestellt.w schrieb:
Das ist ja noch kaotischer und komplizierter. Naja, in C++ kann man ja auch ints als Exception werfen...
wieso sollte man keine ints werfen können? stört doch keinen, wenn man nur einen fehlercode zurückgeben will, da braucht man doch nicht erst großartig eine klasse für zu erzeugen.
-
ghorst schrieb:
w schrieb:
Dann soll int ein primitiver Typ bleiben (also + -> add ax, 123) und zusätzlich so ne Art Klasse sein, von der man ableiten kann (also überschriebenes + -> Funktionsaufruf)?
wenn man es inline ausführt, würde, so es möglich wäre, bei:
inline int operator+(const int& a, const int& b) { return a+b; }exakt die gleiche befehlsfolge rauskommen wie "a+b;".
wozu man das tatsächlich braucht kann, außer um ein paar konvertierungsprobleme zu lösen, sei mal dahin gestellt.Und woher soll der Compiler jetzt wissen, dass du hier keine Endlosrekursion bauen willst, sondern er hier den Maschienencode für eine Addition zwischen zwei Integern einfügen soll?
-
gute frage. nächste frage.
kein ahnung. müsste man vllt einen satz pragmas drumherum setzen. war auch nur als beispiel gedacht und ist in c++ auch nicht zulässig, wobei ein rekursiver operatoraufruf schon ulkig wäre.
-
warum in aller welt will jemand von einem value type ableiten? die sind nicht zum ableiten gedacht.
es gibt ein paar dirty hacks wo man es gerne macht - aber dann will man eher code reuse betreiben als ein sauberes design haben (was natürlich durchaus legitim sein kann). aber int hat keinen code den ich reusen könnte wenn ich davon ableite.
in so einem fall kommt eher eine has-a oder implemented-in-terms-of beziehung besser.
Der einzige Ansatz der mir hier einfällt wäre der C#/Java Ansatz mit int und Integer. Doch sehen wir uns an wofür man Integer verwendet:
um ein Objekt zu haben dass von Object ableitet.Wofür braucht man das? Um es in einen Polymorphen Container zu stecken. Wie oft braucht man polymorphe container von Object? Also ich habe soetwas noch nie gebraucht - es widerspricht dem OOD. In Java hat man Container of Object ja nur gehabt (wohl gemerkt: gehabt!) weil es keine templates gab. diese container waren furchtbar, deshalb hat man dann ja auch generics implementiert.
also kann mir mal jemand kurz erklären wann er je von Integer geerbt hat? Oh, warte - die Klasse ist ja final... Ne, aber Spaß beiseite: gebt mir ein Beispiel wo es sinnvoll ist von int zu erben.
Bedenkt: int hat kein public interface dass ich sinnvoll erben kann. Ich komme so nie in eine sinnvolle is-a beziehung. weil mir die polymorphie fehlt.
das dagegen sinn macht, wäre ein auto-boxing für 4.sqrt() == 2
sowas finde ich wunderschön. aber auch hier will man nicht von int erben.was in c++ eine katastrophe ist, sind die compile times und die unterschiedlichen compiler. das ist wirklich ein enormes problem von c++. ein weiteres ist, dass es keine standardisierte library gibt. boost ist zwar ein schritt in die richtige richtung, aber man braucht dauernd extrene libraries. das problem dabei ist: es gibt soviele, dass man idR nicht davon ausgehen kann dass im Team genug Know How mit der lib da ist. ergo hat man dauernd lernphasen die man zB in Java nicht hat. Jeder der in Java programmiert hat zu wissen wie man Threads erstellt, suspended, resumed,... aber nicht jeder C++ programmierer kennt sich mit pthreads aus - er kennt sich zwar mit threads generell aus, aber diese bestimmte lib muss ihm noch nicht untergekommen sein. weiters gibt es ja wieder kompatibilitaetsprobleme mit den libs zu den compilern...
also wenn jemand c++ kritisieren will - das ist der richtige ansatz
-
eine patchwork sprache halt
-
ghorst schrieb:
gute frage. nächste frage.
kein ahnung. müsste man vllt einen satz pragmas drumherum setzen. war auch nur als beispiel gedacht und ist in c++ auch nicht zulässig, wobei ein rekursiver operatoraufruf schon ulkig wäre.Dadurch würde die scheinbare Ersparnis des Ableitens von int, aber verloren gehen, da man so doch wieder mehr Arbeit hat und das war doch das Ziel der ganzen Sache, wenn ich das richtig in Erinnerung hab.
Das alles natürlich unter der Annahme, dass das überhaupt Sinn macht (und wie ich oben schon sagte teile ich diese Meinung nicht).
-
Shade Of Mine schrieb:
was in c++ eine katastrophe ist, sind die compile times und die unterschiedlichen compiler. das ist wirklich ein enormes problem von c++. ein weiteres ist, dass es keine standardisierte library gibt. boost ist zwar ein schritt in die richtige richtung, aber man braucht dauernd extrene libraries. das problem dabei ist: es gibt soviele, dass man idR nicht davon ausgehen kann dass im Team genug Know How mit der lib da ist. ergo hat man dauernd lernphasen die man zB in Java nicht hat. Jeder der in Java programmiert hat zu wissen wie man Threads erstellt, suspended, resumed,... aber nicht jeder C++ programmierer kennt sich mit pthreads aus - er kennt sich zwar mit threads generell aus, aber diese bestimmte lib muss ihm noch nicht untergekommen sein. weiters gibt es ja wieder kompatibilitaetsprobleme mit den libs zu den compilern...
also wenn jemand c++ kritisieren will - das ist der richtige ansatz
in irgend einem anderen Thrad hab ich sowas ähnliches auch schon mal geschrieben, aber das ist wohl eines dieser Argumente von Leuten die sich nicht mit C++ auskennen.
-
Shade Of Mine schrieb:
ein weiteres ist, dass es keine standardisierte library gibt. boost ist zwar ein schritt in die richtige richtung, aber man braucht dauernd extrene libraries. das problem dabei ist: es gibt soviele, dass man idR nicht davon ausgehen kann dass im Team genug Know How mit der lib da ist. ergo hat man dauernd lernphasen die man zB in Java nicht hat. Jeder der in Java programmiert hat zu wissen wie man Threads erstellt, suspended, resumed,... aber nicht jeder C++ programmierer kennt sich mit pthreads aus - er kennt sich zwar mit threads generell aus, aber diese bestimmte lib muss ihm noch nicht untergekommen sein. weiters gibt es ja wieder kompatibilitaetsprobleme mit den libs zu den compilern...
Es gibt doch eine Std-Lib in C++. Nur wo willst du die Grenze ziehen, was in eine Std-Lib gehört? Selbst die java-StdLib ist NICHT ausreichend. Wer bei uns in einem Projekt arbeiten will, kommt mit der Java-StdLib nicht sehr weit. Ganz im Gegenteil, wir verbieten mehr oder weniger den Konzernprojekten direkt die Java-StdLib zu benutzen, wo wir der Meinung sind, etwas besseres zu haben (wir sind in einer Konzernabteilung tätig, die Konzernstandards entwickelt und definiert). In den regionalen Stellenanzeigen tauchen Java-Anforderungen auf, die sich auf unsere Konzernstandards beziehen. Wem sagt hier schon der Library- und Framework-Befriff, ACF, D+OOF und APF etwas? Ach, komisch? Wer bei uns im Konzern anfängt, fängt bei seinem Java-Wissen bei Null an.
Das die Java-Library nicht die täglichen Anforderungen erfüllt, sieht man daran, das solche Sachen wie OSGi erfunden wurden und von vielen Firmen eingesetzt werden. Weil die Java-Specs die Anforderungen nicht erfüllen, aber OSGi diese Lücke schliesst. OSGi ist auch so ne Sache, die hier bei uns jeder lernen muß. Da hilft ihm Java-Basics nichts. Selbst Threads werden bei uns nicht mit den Java-Std-Klassen erzeugt, sondern müssen mit unseren vorgegeben Klassen erzeugt und behandelt werden.
So sieht die Sache nämlich im alltäglichen Java-Business aus. Und nichts anderes ist auch bei C++ der Fall.
-
Artchi schrieb:
So sieht die Sache nämlich im alltäglichen Java-Business aus. Und nichts anderes ist auch bei C++ der Fall.
In wieviel Firmen hast du schon gearbeitet, dass du sagen kannst, dass es alltäglich ist, dass man für alles andere Libs nimmt, auch wenns das Zeug schon in Java Std gibt?
-
Klar, Spring, Hibernate und was es noch so alles gibt, existieren nur zum Spaß. Die benutzt keiner?
Ich arbeite mittlerweile in der dritten Firma, die Java als Kerngeschäft hat. Und ich habe hier viel Kontakt zu anderen Firmen, bei denen ich erfahre, was und wie sie arbeiten. Und ich kenne niemanden, der mit der Standard-Runtime/-technik auskommt.
Ich kenne sogar einen ehem. Firmenkollegen sehr gut, der hat sich für seine Java-Software einen Präprozessor gebaut. Ja, also richtig mit #ifndef usw. Weil er das für seine J2ME-Entwicklung benötigt. Als ich ihn letztens besucht habe und er mir das zeigte, bin ich aus allen Wolken gefallen. Aber er braucht das halt um seine Anforderungen befriedigen zu können, da die Standard-Java-Technik dafür nicht ausreicht. Und er kann sich damit einen Wettbewerbsvorteil holen, wenn er gegen andere J2ME-Softwareschmieden bestehen will. Obwohl er der größte Javafan ist, hat er trotzdem seine alte C-Erfahrungen einfliessen lassen. Und wir mußte feststellen und schmunzeln, das ein paar Dinge aus der C- und C++-Welt schon recht genial sein müssen, wenn man sie sogar in anderen Sprachen nachbaut um besser als die Konkurrenz arbeiten zu können.
Und ich wette, es gibt noch sehr viele andere Java-Schmieden da draussen, die ähnliche Dinge basteln, weil einfach die Java-Basis ihre Grenzen im professionellen Umfeld sehr schnell aufzeigt.
-
Artchi schrieb:
Es gibt doch eine Std-Lib in C++. Nur wo willst du die Grenze ziehen, was in eine Std-Lib gehört? Selbst die java-StdLib ist NICHT ausreichend.
Die Standardlib kann nie groß genug sein. Größer == Besser
So sieht die Sache nämlich im alltäglichen Java-Business aus. Und nichts anderes ist auch bei C++ der Fall.
Wieviele externe Java Libraries musstest du lernen? 2? 3?
also bei meinem letzten C++ Job hatte ich 3 externe APIs die ich kennen lernen musste. Bei meinem letzten Java Job waren es 0.
Klar gibt es auch ab und zu externe Libs, keine Frage. Das Problem aber ist: du kannst kein einziges C++ Programm schreiben ohne eine neue Lib zu verwenden. Das ist einfach die katastrophe bei der Know How verteilung. Wenn man nur auf eine Firma konzentriert ist, ists egal. Da hast du deinen Bereich den du können musst und das war es. Wenn man aber nun daran denkt neue Leute einzustellen, dann hat man schon mit C++ ein Problem. In Java kann man problemlos die meisten Sachen voraussetzen. Aber in C++? boost threads? ja, vielleicht. pthreads? wxWindows Threads? es gibt einfach so viele Libraries die alles das selbe machen. Der Grund warum es sie gibt ist nicht, weil sie etwas besonders anders machen als alle anderen, sondern einfach weil es keinen Standard gibt.
Das ist aus technlogischer Sicht sehr gut. Vielfalt bedeutet Entwicklung. Aber wenn es um produktivitaet geht, ist es ne katastrophe - weil man eben Know How nicht so einfach transferieren kann wie in Java/.NET/...