Warum hat C++ so eine aufwendige Syntax?
-
32 setien thread? Ne playstation is besser.
-
lolz schrieb:
Undertaker schrieb:
lolz schrieb:
Undertaker schrieb:
radiergummi schrieb:
Einem Java-Entwickler geht der Embedded-Bereich nunmal am ***** vorbei, so einfach ist das.
in dem bereich hat Java zwar nicht viel zu melden - C++ aber auch nicht
Bezweifel ich...warum? Ganz einfach, es gibt für immer mehr Microcontroller C++-Compiler.
du meinst sicher C compiler?
btw: in einigen der letzten beiträge wurde der begriff C/C++ verwendet.
ein C/C++ gibt es aber nicht. es gibt C und es gibt C++.
...und es gibt viele unterschiede zwischen den beiden.
Liste von Arm Chips
http://www.keil.com/arm/chips.aspokay, du hast recht
ab ARM-7 aufwärts, so mit 256K programmspeicher etc. kann man C++ wahrscheinlich einigermassen vernünftig nutzen. aber ich wette, die meisten nehmen doch lieber C (ich auch).
hier mal was zu C++ auf µC's: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus
(um von Java abzulenken)
-
Undertaker schrieb:
hier mal was zu C++ auf µC's: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus
(um von Java abzulenken)Compiliert ihr Embedded-Leute wirklich ohne Optimierung?
-
Undertaker schrieb:
[...]
okay, du hast recht
ab ARM-7 aufwärts, so mit 256K programmspeicher etc. kann man C++ wahrscheinlich einigermassen vernünftig nutzen. aber ich wette, die meisten nehmen doch lieber C (ich auch).
[..]Klar, auf den Kleinen bleiben die Programme auch klein und man ist mit C genauso gut bedient.
@Mr. N der Artikel unterstützt die Verwendung von C++.
-
macht ma hier zu schrieb:
32 setien thread? Ne playstation is besser.
tja für sowas hat man halt nur als arbeitsloser c++ horst zeit... ach moment artchi ist ja java programmierer hm
-
CStoll schrieb:
Vielleicht solltest du auch darauf achten, welche Seite hier den Begriff "C/C++" verwendet. (zumindest ich kann gut zwischen beidem unterscheiden)
du warst auch nicht gemeint. ich glaube auch nicht, dass du C/C++ in einem wort nennen würdest, denn was man von dir liest, deutet darauf hin, dass du in beiden sprachen sehr kompetent bist und die unterschiede sehr wohl kennst.
Mr. N schrieb:
Undertaker schrieb:
hier mal was zu C++ auf µC's: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus
(um von Java abzulenken)Compiliert ihr Embedded-Leute wirklich ohne Optimierung?
unsere compiler optimieren so gut, davon könnt ihr C++ weicheier nur träumen.
und wenn's der compiler mal nicht bringt, wird eben nachgeholfen.
-
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
hier mal was zu C++ auf µC's: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus
(um von Java abzulenken)Compiliert ihr Embedded-Leute wirklich ohne Optimierung?
unsere compiler optimieren so gut, davon könnt ihr C++ weicheier nur träumen.
Die üblichen C++-Optimierer sind sehr gut, aber danke der Nachfrage.
(Ansonsten gibts ja das LLVM-Projekt, das neben einer Virtual Machine auch diverse Neuerungen im Optimierungsbereich bringt und ein C++-Frontend - das vom GCC - hat.)
Undertaker schrieb:
und wenn's der compiler mal nicht bringt, wird eben nachgeholfen.
Das macht man im heterogenen PC-Umfeld halt doch lieber nicht.
-
ich frag mich grad, ob der vergleich zwischen c++ und c überhaupt angemessen ist, immerhin compiliert der comeau afaik nach C, weshalb man fast jedes C agument auch auf C++ übertragen kann
oder anders ausgedrückt:
"C ist schneller als C++"
"aber der Comeau spuckt denselben C code aus"
:p
-
otze schrieb:
"C ist schneller als C++"
"aber der Comeau spuckt denselben C code aus"
:pNur weil irgend nen Compiler C++ nach C transformiert, heißt das nicht, dass C und C++ gleich schnell. In der Tat kann (!) man Programme schreiben, die in C auch nicht schneller werden. In der Praxis werden C++ Programme jedoch etwas langsamer sein als vergleichbare C Programme, da man doch einige der Komfortfunktionen (Stichwort Indirektion bei Operatoren etc.) nutzt. Der Vorteil bei C++ liegt eher in der (einigermaßen) komfortablen Umsetzbarkeit von OOP und Möglichkeiten größere Projekte wartungsfreundlicher zu gestalten (Namespaces etc.). In Sachen Entwicklungs-Effizienz kommt es (leider) nicht wirklich an neuere Sprachen/Plattformen ran (was ja auch nicht weiter verwunderlich ist).
-
dsfdfg schrieb:
Das ist es ja, was ich meine. Nehmen wir mal an, dass ein entsprechender Standard in diesem Bereich fehlt, dann kann man als Firma beim JCP einen Request einreichen und sich an der Standardisierung beteiligen.
Kannst du auch in C++ machen. Meinst du, man kann nur Java-Libs standardisieren? Meinst du nicht, das es im C++-Bereich ähnlich läuft? Jemand entwickelt eine Library, sie wird in der Community akzeptiert, reicht sie darauf hin beim C++-komitee ein... und schwupps könnte sie im nächsten TR und somit nächsten C++-Standard drin sein, wenn die Mehrheit des Komitees diesen Proposal (entspricht deinem Request) zustimmt.
Du erzählst der C++-Community nicht wirklich neues und spannendes.
-
Mr. N schrieb:
Undertaker schrieb:
und wenn's der compiler mal nicht bringt, wird eben nachgeholfen.
Das macht man im heterogenen PC-Umfeld halt doch lieber nicht.
na, was glaubst du, was da für haarsträubende sachen gebastelt werden
otze schrieb:
ich frag mich grad, ob der vergleich zwischen c++ und c überhaupt angemessen ist,
ja, das ist nicht einfach. die meisten glauben ja, dass C++ einfach nur 'das besserere C' wäre, aber dem ist nicht so.
C verfolgt dieses, aus der unix-welt (und da kommt es ja auch her) bekannte 'keep-it-small-and-simple' prinzip. d.h. C ist klar strukturiert und überschaubar (wenn man mal von der syntax absieht, die einsteigern ganz schön kopfzerbrechen bereiten kann). C ist ein einfaches, schnörkel- und kompromissloses werkzeug. mit etwas übung weiss man, was man damit machen kann und für was man lieber etwas anderes nehmen sollte. habt ihr schon mal einen C gegen Java flamewar gesehen? ich nicht.
C++ dagegen versucht mit 'multi-paradigmen' (wie ich diesen begriff hasse
) und auf 'schweizer-offiziersmesser-basis' dem user möglichst viele möglichkeiten zu bieten. man hat für alles mindestens 10 verschiedene tricks auf lager, man kann OOP mit prozerural bedenkenlos mischen, sämtliche schutzmechanismen aushebeln, 20 verschiedene smart-pointer für jede gelegenheit, shift-operatoren als stream-I/O, trotz vieler balabla_cast<> einen verkrüppelten void*, teilweise C-kompatibilität usw. sowas hört sich zwar gut an (viel hilft viel :D), erfordert aber eine unglaubliche disziplin und verdammt viel wissen vom programmierer, damit er damit keinen quatsch baut und sein projekt in den abgrund stürzt.
der grundgedanke, C sinnvoll zu erweitern, ist meiner ansicht nach, mit C++ komplett gescheitert. leider hat C++ zu seiner blütezeit einen hype erlebt, was zu einer grossen verbreitung führte, so dass C++ heute noch teilweise sehr oft genutzt wird (wie wir ja alle wissen ).
es gibt bessere ansätze C zu erweitern, wie etwa Objective-C.
und wenn C++ auch nur ansatzweise das zeug dazu hätte, in absehbarer zeit etwas sinnvolles zu werden, dann wären sprachen wie Java und C# nie erfunden worden...
(ja, ich weiss, das war jetzt wieder zu polemisch, aber ihr kennt mich ja)
-
Artchi schrieb:
dsfdfg schrieb:
Das ist es ja, was ich meine. Nehmen wir mal an, dass ein entsprechender Standard in diesem Bereich fehlt, dann kann man als Firma beim JCP einen Request einreichen und sich an der Standardisierung beteiligen.
Kannst du auch in C++ machen. Meinst du, man kann nur Java-Libs standardisieren? Meinst du nicht, das es im C++-Bereich ähnlich läuft? Jemand entwickelt eine Library, sie wird in der Community akzeptiert, reicht sie darauf hin beim C++-komitee ein... und schwupps könnte sie im nächsten TR und somit nächsten C++-Standard drin sein, wenn die Mehrheit des Komitees diesen Proposal (entspricht deinem Request) zustimmt.
Du erzählst der C++-Community nicht wirklich neues und spannendes.
ich glaub du verstehst den JCP nich so ganz kann das sein?
ps: @Undertaker: dein neuer nickname is voll leed jetz find ich besser als pale dog *checker handbewegung mach*
-
aszf schrieb:
ps: @Undertaker: dein neuer nickname is voll leed jetz find ich besser als pale dog *checker handbewegung mach*
danke, der nächste ist schon in bearbeitung
-
Artchi schrieb:
dsfdfg schrieb:
Das ist es ja, was ich meine. Nehmen wir mal an, dass ein entsprechender Standard in diesem Bereich fehlt, dann kann man als Firma beim JCP einen Request einreichen und sich an der Standardisierung beteiligen.
Kannst du auch in C++ machen. Meinst du, man kann nur Java-Libs standardisieren? Meinst du nicht, das es im C++-Bereich ähnlich läuft? Jemand entwickelt eine Library, sie wird in der Community akzeptiert, reicht sie darauf hin beim C++-komitee ein... und schwupps könnte sie im nächsten TR und somit nächsten C++-Standard drin sein, wenn die Mehrheit des Komitees diesen Proposal (entspricht deinem Request) zustimmt.
Du erzählst der C++-Community nicht wirklich neues und spannendes.
Das kann man ja nun wirklich nicht vergleichen, denn wenn man etwa 7 Jahre warten muss (2003 bis ~2010) dann ist das absolut nicht als "schwupps" einzustufen. Zusätzlich bezweifle ich auch, dass das Komitee etwas in den Standard aufnehmen würde, was nicht essentiell für eine breite Masse an Software ist. Ich würde mich beispielsweise wundern, wenn das C++ Komitee einen Request annimmt, der festlegt, welche Metadaten man für Komponenten angeben kann und wie die dann von der IDE interpretiert werden sollen. Beim JCP werden ja auch Standards aufgenommen, die nicht direkt was mit Java SE zu tun haben, sondern wieder nur als externe Bibliothek (
!) verfügbar sind.Ich denke aber (nachdem du ja anscheinend beruflich auch Java-Programmierer bist), dass du das eigentlich ganz genau wissen müsstest.
-
Es wird hier immer witziger. Selbst wenn ein Normierungsprozess vorhanden ist, wird jetzt schon jedes einzelne Jahr gezählt, damit man sich aus der Peinlichkeit rauszieht. Warum sollte gerade der Rythmus des Java-Standardprozesses massgebend sein? Dann lies mal folgendes: Java ist kein Standard. Es ist höchstens ein Industriestandard, wie es auch das MS-Word-Doc-Format ist. Wäre Java Standard, würde auch Java 7 Jahre brauchen. Denn ISO ist ein ganz anderes Kaliber als ein Inhouse-Standard.
Wir können gerne bis auf Detail runter gehen, und es kommen immer mehr Fakten ans Licht, wo bei Java zwar alle zwei Jahre was neues rauskommt, aber der Stellenwert des "Standards" nicht an ISO-C++ ran kommt.
Java wird Inhouse von SUN bestimmt, die Firmen dürfen Requests stellen, aber SUN hat noch die Macht über den Spec. Wir können auch gerne über die Kosten für eine Java-Zertifikation reden. Wo Firmen wie IBM ordentlich Kohle an SUN abdrücken dürfen, damit sie überhaupt ein "Java" auf ihre Runtime und JVM kleben dürfen.
Und was die 7 Jahre angeht: 2006 gabs einen TR1, der mit deinen genannten "externen" Libs vergleichbar ist. Es hat also nicht wirklich 7 Jahre gedauert, bis sich was bei C++ getan hat.
Wir können auch Inhouse-C++ bestprechen: Borland bzw. Codegear und MS haben auch ihre eigenen C++-Compiler-Erweiterungen, die Libs und Sprache erweitern. Bei MS mit VC++ regelmäßig. Ist sehr gut mit dem von SUN definierten und abgesegneten Java vergleichbar.
-
Artchi schrieb:
Es wird hier immer witziger. Selbst wenn ein Normierungsprozess vorhanden ist, wird jetzt schon jedes einzelne Jahr gezählt, damit man sich aus der Peinlichkeit rauszieht. Warum sollte gerade der Rythmus des Java-Standardprozesses massgebend sein? Dann lies mal folgendes: Java ist kein Standard. Es ist ein Industriestandard. Wäre Java Standard, würde auch Java 7 Jahre brauchen. Denn ISO ist ein ganz anderes Kaliber als ein Inhouse-Standard.
Wir können gerne bis auf Detail runter gehen, und es kommen immer mehr Fakten ans Licht, wo bei Java zwar alle zwei Jahre was neues rauskommt, aber der Stellenwert des "Standards" nicht an ISO-C++ ran kommt.
Java wird Inhouse von SUN bestimmt, die Firmen dürfen Requests stellen, aber SUN hat noch die Macht über den Spec. Wir können auch gerne über die Kosten für eine Java-Zertifikation reden. Wo Firmen wie IBM ordentlich Kohle an SUN abdrücken dürfen, damit sie überhaupt ein "Java" auf ihre Runtime und JVM kleben dürfen.
Und was die 7 Jahre angeht: 2006 gabs einen TR1, der mit deinen genannten "externen" Libs vergleichbar ist. Es hat also nicht wirklich 7 Jahre gedauert, bis sich was bei C++ getan hat.
Wir können auch Inhouse-C++ bestprechen: Borland bzw. Codegear und MS haben auch ihre eigenen C++-Compiler-Erweiterungen, die Libs und Sprache erweitern. Bei MS mit VC++ regelmäßig. Ist sehr gut mit dem von SUN definierten und abgesegneten Java vergleichbar.
Was wetten dass das die Javaianer wieder ignorieren?
-
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
und wenn's der compiler mal nicht bringt, wird eben nachgeholfen.
Das macht man im heterogenen PC-Umfeld halt doch lieber nicht.
na, was glaubst du, was da für haarsträubende sachen gebastelt werden
Na ich meine natürlich nicht deine C-Frickler-Freunde.
Undertaker schrieb:
otze schrieb:
ich frag mich grad, ob der vergleich zwischen c++ und c überhaupt angemessen ist,
ja, das ist nicht einfach. die meisten glauben ja, dass C++ einfach nur 'das besserere C' wäre, aber dem ist nicht so.
C verfolgt dieses, aus der unix-welt (und da kommt es ja auch her) bekannte 'keep-it-small-and-simple' prinzip. d.h. C ist klar strukturiert und überschaubar (wenn man mal von der syntax absieht, die einsteigern ganz schön kopfzerbrechen bereiten kann). C ist ein einfaches, schnörkel- und kompromissloses werkzeug. mit etwas übung weiss man, was man damit machen kann und für was man lieber etwas anderes nehmen sollte. habt ihr schon mal einen C gegen Java flamewar gesehen? ich nicht.
C++ dagegen versucht mit 'multi-paradigmen' (wie ich diesen begriff hasse ) und auf 'schweizer-offiziersmesser-basis' dem user möglichst viele möglichkeiten zu bieten. man hat für alles mindestens 10 verschiedene tricks auf lager, man kann OOP mit prozerural bedenkenlos mischen, sämtliche schutzmechanismen aushebeln, 20 verschiedene smart-pointer für jede gelegenheit, shift-operatoren als stream-I/O, trotz vieler balabla_cast<> einen verkrüppelten void*, teilweise C-kompatibilität usw. sowas hört sich zwar gut an (viel hilft viel :D), erfordert aber eine unglaubliche disziplin und verdammt viel wissen vom programmierer, damit er damit keinen quatsch baut und sein projekt in den abgrund stürzt.
der grundgedanke, C sinnvoll zu erweitern, ist meiner ansicht nach, mit C++ komplett gescheitert. leider hat C++ zu seiner blütezeit einen hype erlebt, was zu einer grossen verbreitung führte, so dass C++ heute noch teilweise sehr oft genutzt wird (wie wir ja alle wissen ).
es gibt bessere ansätze C zu erweitern, wie etwa Objective-C.
und wenn C++ auch nur ansatzweise das zeug dazu hätte, in absehbarer zeit etwas sinnvolles zu werden, dann wären sprachen wie Java und C# nie erfunden worden...
(ja, ich weiss, das war jetzt wieder zu polemisch, aber ihr kennt mich ja)
Weißt du was? Das hab ich einfach nicht gelesen.
Hmm aber eins kommentier ich doch: keep-it-small-and-simple ist ein Mythos, der auf Unix nicht wirklich zutrifft und für gewisse Probleme sorgt. HTTP z.B. ist ja schon irgendwie unixig, finde ich... ist aber ein verdammt komplexes Protokoll (HTTP ist trotzdem gut). Und wieviele unterschiedliche Arten von Dateien, Pseudodateisysteme und Arten, mit dem Kernel zu kommunizieren (Beispiele: Syscalls, read/write, ioctl, Zugriff auf ein Pseudodateisystem...) hat Linux? Oder die allerschlimmsten Small-and-simple-Leute sind ja die von GNOME, verwenden C, aber GNOME ist die fetteste und langsamste Desktopumgebung die man kriegen kann (übrigens würden die auch auf keinen Fall C++ einsetzen wollen, eher noch C# oder Python
).Ich weiß, dass du Windows sowieso lieber magst, aber du hast von Unix-KISS geredet und Windows / Microsoft interessiert sich eh nen Dreck für Keep-it-small-and-simple.
-
Hier folgendes, dann weiß man, das SUN einfach seine Macht über Java nicht aufgeben wollte und es auch nicht will. Denn es würde nicht nur Verlust von Macht bedeuten, sondern auch Arbeit (7 Jahre harte Auseinandersetzung mit der Java-Welt):
Nicht mal bei der ECMA hat man es standardisieren lassen, dabei ist ECMA nun wirklich harmloser als ISO.
Wer jetzt die 7 Jahre bei C++ anmotzt, sollte bitte keinen Vergleich mit Java ziehen. Wenn, dann bitte erst, wenn Java auch ISO und somit ein echter weltweiter Standard ist.
-
Zu Java hab ich schon genug geflamed, das lass ich mal.
Aber da der Thread eh nichts mehr mit dem Thema zu tun hat...Mr. N schrieb:
keep-it-small-and-simple ist ein Mythos, der auf Unix nicht wirklich zutrifft und für gewisse Probleme sorgt.
Unfug.
Mr. N schrieb:
HTTP z.B. ist ja schon irgendwie unixig, finde ich... ist aber ein verdammt komplexes Protokoll (HTTP ist trotzdem gut).
Was ist denn an HTTP komplex? POST, GET und noch ein bisschen Firlefanz, das wars. Sowohl Client als auch Server kann man an einem Wochenende schreiben. In Sprachen wie Python sogar in ein paar Stunden.
Mr. N schrieb:
Und wieviele unterschiedliche Arten von Dateien, Pseudodateisysteme und Arten, mit dem Kernel zu kommunizieren (Beispiele: Syscalls, read/write, ioctl, Zugriff auf ein Pseudodateisystem...) hat Linux?
Für jeden Einsatzbereich (und die von dir genannten haben verschiedene Einsatzbereiche) das richtige Mittel. Unixiger gehts nicht.
Und außerdem gibt's meines Erachtens nur normale Dateien, Geräte und FIFOs. Und praktischerweise muss ein Programm nichtmal darüber Bescheid wissen, was es nun vor sich hat.Mr. N schrieb:
Oder die allerschlimmsten Small-and-simple-Leute sind ja die von GNOME, verwenden C, aber GNOME ist die fetteste und langsamste Desktopumgebung die man kriegen kann (übrigens würden die auch auf keinen Fall C++ einsetzen wollen, eher noch C# oder Python
).Wer C++ oder C statt einer Skriptsprache in einem Bereich einsetzen will, wo sehr oft Änderungen gemacht werden und es nicht zwingend ultra-schnell sein muss (zB die oberste Schicht von Desktopumgebungen, das womit der User tatsächlich arbeitet...) gehört gevierteilt.
-
so jetzt aber ab in bett