Warum hat C++ so eine aufwendige Syntax?
-
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/...
-
Vielleicht endet Java ja auch mal so wie C++, weil jeder meint er braucht was eigenes. Eclipse hat ja auch Jobs als Erweiterung zu den standard Threads.
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/jobs/Job.htmlJava hat den Vorteil, dass schon von Anfang an eine größere API dabei war. So verwenden fast alle die gleichen "Basis Klassen" (String, ...) für ihre zusätzlichen APIs. In C/C++ hat man da ne bunte Mischung.
-
Undertaker schrieb:
ja, die template-syntax ist ziemlich gruselig, aber man kann nicht C++ allein die schuld geben. oft sieht man, dass C++ user das ganze noch verschlimmern, indem sie einbuchstabige bezeichner wählen und alles in eine zeile quetschen, wie hier erst geschehen: http://www.c-plusplus.net/forum/viewtopic-var-t-is-188053-and-highlight-is-.html
wer solchen code schreibt, für den wäre vielleicht APL besser geeignet
Ist mir egal was du denkst. Ich weiß das mein Code-Stil viel besser als von manch anderen hier ist und ich auch zu denen gehöre die sich darüber gedanken machen, wie etwas auszusehen hat.
Muss auch natürlich zu meiner Verteidigung sagen, dass ich mit TMP am rumspielen gewesen bin und anstatt sich mit Variablennamen rumzuschlagen kann man schnell und einfach Ein-Bustaben Variablen wählen und solange ich meine Codeschnipsel verstehe und es nur zu Testzwecken ist, kann das auch ruhig so aussehen ...