Warum hat C++ so eine aufwendige Syntax?
-
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
-
deine mutter schrieb:
so jetzt aber ab in bett
Nicht ohne Artikel und Satzzeichen.
-
.filmor schrieb:
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.
Dieser Einstellung verdanken wir es, dass sich die gefühlte Geschwindigkeit der Betriebssysteme in den letzten Jahren radiziert hat, obwohl sich die Leistungsfähigkeit der Computerkomponenten potenzierte ...
-
Shade Of Mine schrieb:
Jester schrieb:
Geeignet impliziert für mich die Wertung: "Das kann man damit gut machen". Bist Du dieser Meinung?
Die Frage ist: für was?
Muß ich das jetzt wissen? Du schriebst doch für Webentwicklung.

-
Artchi schrieb:
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.
ich würde darauf nicht soviel geben. ja, standards sind schon wichtig, aber im endeffekt ist es fast egal, wer den daumen drauf hält, sofern sich diese organisation oder firma als vertrauenswürdig erwiesen hat. ob sie nun ISO, Sun, IEEE, VDE, IBM oder sonstwie heissen. wichtig ist nur, dass sie in der vergangenheit bewiesen haben, dass sie's ernst meinen und ihnen an der sache an sich gelegen ist (also z.b. nicht so'n verein wie microsoft). was ISO für C++ ist eben Sun für Java. Sun achtet z.b. sehr genau darauf, dass in Java keine unsinnigen features einfliessen.
Mr. N schrieb:
HTTP z.B. ist ja schon irgendwie unixig, finde ich... ist aber ein verdammt komplexes Protokoll.
du als C++ fan solltest mit hoher komplexität doch sehr vertraut sein. aber vielleicht schaust du dir mal PPP an, das ist noch etwas komplexer...

Mr. N schrieb:
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.
immerhin hatte M$ windows-NT schon einen objektorientierten microkernel als der 'linux' kernel noch ein gewaltiger klotz war, den man am stück compilieren musste.

-
Undertaker schrieb:
Sun achtet z.b. sehr genau darauf, dass in Java keine unsinnigen features einfliessen.
Falsch. Sun achtet sehr genau darauf, dass in Java keine Features einfließen, die Sun für unsinnig hält. Das ist ein kleiner aber feiner Unterschied!
-
Artchi schrieb:
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.
mann bist du ein troll

postest hier 8 jahre alte links vonwegen sun und iso und macht (java ist teilweise und wird komplett gpled soviel zum thema macht) und machst schön pro c++ hetze. ich glaube du hast noch immer nicht den unterschied zwischen dem jcp und dem c++ iso kommitee verstanden?
-
.filmor schrieb:
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.
Nix Unfug.
.filmor schrieb:
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.
Client? Ja, das geht, der kann dann aber nix - wobei du sicher vergessen würdest, das chunked TE zu implementieren, gelle?
Server? Nur wenn du dich nicht an die Spezifikation hälst und stattdessen überall Blödsinn machst. (Das kannst du mir glauben, ich programmiere gerade einen.)
.filmor schrieb:
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.
Für hugetlb ist ein Pseudodateisystem das richtige Mittel? Ne aber ansonsten geb ich dir Recht, Linux hat das sehr gut gelöst. Ist aber nicht "small and simple".
.filmor schrieb:
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.
Für dich gibts keine Sockets? Naja, ich mach mal demnächst mmap auf eine Pipe.

.filmor schrieb:
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.
Inzwischen wird C und Python verwendet. Du kannst mir aber nicht sagen, dass für soetwas wie ein Virtuelles Dateisystem (gnome-vfs, hatte bis vor ner Weile übrigens Race Conditions
) eine Skriptsprache sinnvoll wäre. GNOME hat viele Low-Level-Komponenten.Undertaker schrieb:
du als C++ fan solltest mit hoher komplexität doch sehr vertraut sein. aber vielleicht schaust du dir mal PPP an, das ist noch etwas komplexer...
Ich habe kein Problem mit der Komplexität von HTTP.
Undertaker schrieb:
immerhin hatte M$ windows-NT schon einen objektorientierten microkernel als der 'linux' kernel noch ein gewaltiger klotz war, den man am stück compilieren musste.
Windows NT hat keinen Microkernel, AFAIK ist das mehr so ein Hybridmodell. Naja, es ging mir eher darum, wie wenig Small-and-Simple UNIX ist und dass Windows genauso wenig simpel ist (wieviel RAM braucht Windows Vista nochmal?).
Was ich mit dem ganzen sagen will: Unnötige Komplexität mag zwar stören, aber manchmal ist sie nötig. Und sei es nur, damit man mit C kompatibel ist.
-
Undertaker schrieb:
...
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.


Sag' jetzt bitte, dass Du meinen Beitrag gelesen und verstanden hast:Simon2 schrieb:
...
Undertaker schrieb:
btw, verwende nicht C*/**C++*. diesen begriff gibt es eigentlich gar nicht. C ist eine eigenständige sprache und auf manchen gebieten nicht wegzudenken, im gegensatz zu C++, welches so gut wie immer durch etwas anderes (sinnvoll und vor allem vorteilhaft) ersetzbar ist.

Lies meinen Satz noch einmal und dann versuche zu verstehen, warum ich hier den Ausdruck "C/C++" verwendet habe.
(Kleiner Tipp: Auch der Satz "Mit Programmiersprachen wie C/C++/Java/Basic/... kann man Computern Anweisungen geben" enthält ein ähnliches Konstrukt)Gruß,
Simon2.
... und mich nicht meinst. Sonst kommst Du auf meine ignore-list.
Gruß,
Simon2.
-
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 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.
C# ist, wenn man so will, auch standardisiert und da braucht es auch keine 7 Jahre bis zu einer neuen Version. Zusätzlich enthält da eine neue Version wirklich Änderungen und nicht nur Features mit ähnlicher Gewichtung wie einzelne Bugfixes.
Artchi schrieb:
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.
Mich würde halt interessieren inwiefern es Java geschadet hat, dass es eben kein ISO-Java ist? Microsoft lies auch nur einen kleinen Teil von .NET standardisieren und das eben mit gutem Grund. Java ist im klassischen Sinn kein wirklicher Industriestandard, bzw. wenn dann ein offener Industriestandard. Ich sehe nur dass es eine Vielzahl an Implentierungen der Java SE gibt, selbst ohne ISO-Standard.
Artchi schrieb:
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.
Sun leitet bei weitem nicht jedes Komitee. Du kannst aber auch gerne ein JCP Member werden und dir dann das Java Compatibility Kit runterladen. Das kostet dich genau nichts und dass Sun Qualitätskontrolle bei Java SE Implementierungen durchführen muss, ist ja wohl klar.
Artchi schrieb:
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.
Änderungen in dieser Größenordnung werden beim JCP als Maintenance Relase eingestuft. Außerdem musst du schon Stellung beziehen, du kannst nicht einerseits auf ISO Standards beharren und im nächsten Moment den TR1 heranziehen, um lange Standardisierungszeiten bei C++ zu widerlegen.
Artchi schrieb:
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.
Du vergleichst hier proprietäre Compiler-Erweiterungen von Microsoft & Co. mit einem offenen Standardisierungsprozess (wenn auch nur für offene Industriestandards
)? ..Ich hab mich da jetzt ohnehin wieder auf etwas eingelassen, was ich gar nicht wollte, denn mir ging es eigentlich um Standards ausser Java SE, Java ME und Java EE selbst. Um es noch einmal klarzustellen, dass der Java-Standardisiserungs-Prozess offener ist, als das C++-Komitee: Ein Kollege von mir ist Mitglied in einem Komitee zu einem JCP-Standard. Wieviele Kollegen von dir sind im C++-Komitee? Aber von mir aus kannst dich ja gern weiter von Ideologie blenden lassen und auf einen ISO-Standard beharren. Ich kann nur sagen, dass ich mir z.B. JPA großteils mit dem Final Release der Spezifikation beigebracht habe. Bei C++ konnte ich mir damals das Final Release nicht einmal unentgeltlich herunterladen. Ich denke man sieht, welch ungemeine Vorteile ein ISO-Standard mit sich zieht ..
Ich gestehe, dass ich mir wirklich wünschen würde, dass Java 7 erst 2014 erscheint, wobei es dann natürlich kaum Neuerungen mit sich bringen darf und die Spezifikation muss natürlich etwas kosten ..
P.S.: Jetzt musste ich doch einen Login herausholen, weil der Spam-Schutz wohl einen Bug hat, denn selbst wenn ich die Rechnung korrekt beantworte (Ich hoffe, dass das außer Frage steht
), wird die Antwort nicht eingetragen.
-
Artchi schrieb:
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.
Ist zwar kein Standard, es bessert sich aber:
http://www.heise.de/open/news/meldung/89390Du vergleichst hier proprietäre Compiler-Erweiterungen von Microsoft & Co. mit einem offenen Standardisierungsprozess (wenn auch nur für offene Industriestandards )? ..
Ich hab mich da jetzt ohnehin wieder auf etwas eingelassen, was ich gar nicht wollte, denn mir ging es eigentlich um Standards ausser Java SE, Java ME und Java EE selbst. Um es noch einmal klarzustellen, dass der Java-Standardisiserungs-Prozess offener ist, als das C++-Komitee: Ein Kollege von mir ist Mitglied in einem Komitee zu einem JCP-Standard. Wieviele Kollegen von dir sind im C++-Komitee? Aber von mir aus kannst dich ja gern weiter von Ideologie blenden lassen und auf einen ISO-Standard beharren. Ich kann nur sagen, dass ich mir z.B. JPA großteils mit dem Final Release der Spezifikation beigebracht habe. Bei C++ konnte ich mir damals das Final Release nicht einmal unentgeltlich herunterladen. Ich denke man sieht, welch ungemeine Vorteile ein ISO-Standard mit sich zieht ..
Ich gestehe, dass ich mir wirklich wünschen würde, dass Java 7 erst 2014 erscheint, wobei es dann natürlich kaum Neuerungen mit sich bringen darf und die Spezifikation muss natürlich etwas kosten ..
Aehm irgendwie gefaelt mir der Text nicht. Java gehoert Sun, da ist das Wort "Standard" genauso fehl am Platz wie bei dem .doc Format von MS.
ABER: Wieso geht es eigentlich seit ca. 10 Seiten nur noch um C++VsJava? Das faengt an langsam laestig zu werden...
-
Simon2 schrieb:
Undertaker schrieb:
...
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.


Sag' jetzt bitte, dass Du meinen Beitrag gelesen und verstanden hast:Simon2 schrieb:
...
Undertaker schrieb:
btw, verwende nicht C*/**C++*. diesen begriff gibt es eigentlich gar nicht. C ist eine eigenständige sprache und auf manchen gebieten nicht wegzudenken, im gegensatz zu C++, welches so gut wie immer durch etwas anderes (sinnvoll und vor allem vorteilhaft) ersetzbar ist.

Lies meinen Satz noch einmal und dann versuche zu verstehen, warum ich hier den Ausdruck "C/C++" verwendet habe.
(Kleiner Tipp: Auch der Satz "Mit Programmiersprachen wie C/C++/Java/Basic/... kann man Computern Anweisungen geben" enthält ein ähnliches Konstrukt)Gruß,
Simon2.
... und mich nicht meinst. Sonst kommst Du auf meine ignore-list.
nein, ich meine nicht dich.
den selben fehler hat, weit nach unserer unterhaltung, noch so'n ignorant gemacht
-
DEvent schrieb:
Das faengt an langsam laestig zu werden...
lästig is nur dass herr Mr. N dauernd dazwischenquatscht und einen aus dem lustigen lesefluss herausreißt

-
árn[y]ék schrieb:
.filmor schrieb:
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.
Dieser Einstellung verdanken wir es, dass sich die gefühlte Geschwindigkeit der Betriebssysteme in den letzten Jahren radiziert hat, obwohl sich die Leistungsfähigkeit der Computerkomponenten potenzierte ...
Wieso sagen das eigentlich immer alle? Ich habe sowas weder bei meinem Umstieg von Windows auf Linux, noch von C++ auf Java gemerkt. Ich merke sowas auch nicht bei PHP oder bei Ruby. Ebenso wenig bei Eclipse oder anderen Programmen, bei denen das staendig behauptet wird.
-
DEvent schrieb:
Aehm irgendwie gefaelt mir der Text nicht. Java gehoert Sun, da ist das Wort "Standard" genauso fehl am Platz wie bei dem .doc Format von MS.
Frei nach wikipedia: "Ein Standard ist eine vergleichsweise einheitliche/vereinheitlichte, weithin anerkannte und meist auch angewandte (oder zumindest angestrebte) Art und Weise, etwas herzustellen oder durchzuführen, die sich gegenüber anderen Arten und Weisen durchgesetzt hat." Wieso ihr immer gleich auf eine ISO-Standard pocht, müsst ihr mir immer noch erst erklären.