Warum hat C++ so eine aufwendige Syntax?
-
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.
-
Der Durchschnitt schrieb:
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.
Hat einen ganz einfachen Grund: Ein Standard gehoert niemanden.
-
DEvent schrieb:
Hat einen ganz einfachen Grund: Ein Standard gehoert niemanden.
1. Nein, das muss nicht zutreffen.
2. Was ist so schlimm daran, wenn es sozusagen jemanden mit Veto-Recht gibt? Ihr müsst schon auch Gründe liefern, denn ansonsten bewegen wir uns auf einem Niveau ala "Ich verwende kein Windows, weil es nicht OpenSource ist. Zwar kann ich nicht C programmieren und würde auch nie den Source ansehen, aber ich will die Möglichkeit dazu trotzdem haben."Für mich ist das alles nur Rumgeplärre, das darauf hinauf lässt, dass Java wie C++ keine Firma haben darf, die die Verantwortung für die Weiterentwicklung übernimmt und auch demzufolge Engagement einfließen lässt. Stattdessen soll sich die Entwicklung lieber schleppend fortbewegen, angelehnt an die Tragik der Allmende. Solange ich mich an der Entwicklung beteiligen kann, ist mir doch egal, wie das realisiert ist. Andere Sprachen sind einfach nur OpenSource-Projekte an denen man mitarbeiten kann (wie PHP oder Ruby), Java wird durch Sun standardisiert und C++ eben durch ISO. Jeder wie er will, aber lächerlich ist es einfach von Sun einen ISO-Standard zu fordern, um offener bei der Weiterentwicklung zu sein, wenn man bedenkt, dass von den oben genannten Sprachen gerade C++ diejenige ist, bei der man sich am wenigsten an der Weiterentwicklung beteiligen kann.
-
so ein blödsinn. c# ist auch von der ecma und iso standardisiert. inwiefern kann ich mich aktiv an der entwicklung von c# beteiligen?
-
so ein blödsinn. c# ist auch von der ecma und iso standardisiert. inwiefern kann ich mich aktiv an der entwicklung von c# beteiligen?
Microsoft kocht ja sowieso schon seit eher ein eigenes Süppchen. Das kann man gar nicht mit der restlichen Industrie vergleichen.
-
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?
Warum sollte ich oder ein Kollege nicht im C++-Komitee sitzen dürfen? Und das du einen Kollegen im JCP kennst, ist schön für dich. Aber ich kenne keinen Kollegen im JCP, obwohl ich seeehr viele Java-Kollegen von vielen Firmen habe. Aber das macht nichts, ich muß keinen selber kennen oder selber drin sitzen, damit ein Prozess offen ist. Diese Logik verstehe ich absolut nicht.
Der ISO-C++-Prozess ist sehr offen. Jeder kann ihn verfolgen, jeder kann sich selber einbringen durch aktive Arbeit (Diskussion, CRs und Proposals) und das ohne das man Mitglied sein muss. Nein, ganz im Gegenteil, ich kann per EMail ein Proposal einsenden und muß auch keine Firma o.ä. sein. Das Komitee nimmt sich meinem Proposal an. Das Komitee wünscht sogar, das man sein Proposal auf den Meetings pers. vorstellt, damit man auch z.B. auftauchende Fragen beantworten kann. Und in den Meetings kann jeder andere persönlich teilnehmen, auch wenn er nicht unbedingt was beitragen will und das Spektakel live miterleben. Das Komitee lädt dazu sogar herzlich ein.
Also, wie offen soll das ganze noch sein? Ach ja, ich muß jemanden im Komitee pers. kennen, damit es offen ist. LOL
Zum Thema Java und GPL: schön das SUN seinen Compiler und JRE unter GPL gestellt hat. Das ist aber nicht die Marke Java (ist immer noch eine geschützte Marke die Geld kostet) und auch nicht die Spezifikation. Nur eine Implementierung ist unter GPL. Und noch etwas: die GPL heißt nicht, das jemand seine Rechte an einem Werk aufgibt. Ganz im Gegenteil, er kann später das Werk sogar unter eine andere Lizenz (auch proprietär) stellen und die Rechte an eine andere Person/Organisation abgeben. GPL heißt nicht, das etwas Public Domain ist. Wenn man pech hat, kann der nächste Besitzer einem mit Lizenzkosten o.ä. belasten. Sowas nenne ich nicht gerade einen freien Standard.
C++ aber ist keine geschützte Marke. Wenn ich einen Compiler entwickle, kann ich ihn bedenkenlos "C++-Compiler" nennen. Das darf ich mit Java nicht machen, SUN würde mir ihre Rechtsanwälte aufhetzen, wenn ich eine JRE rausbringe und sie Java-RE oder Java-Compatible nennen würde.
Also, bitte hier nicht verrückt spielen, und juristische Fakten (und ein Trademark und GPL sind juristisch definiert) verdrehen.
-
Der Durchschnitt schrieb:
angelehnt an die Tragik der Allmende
Hier haben wir sogar etwas schlimmeres als Allmende. Java gehört jemand anderem und trotzdem nutzt du es. Inwieweit stellst du sicher, dass eure Interessen konvergieren? (OK, wenn Java jetzt Open Source ist, ist das Problem schon wesentlich geringer.)
Das Problem ist ja, es kann nicht jeder ein Stück Sprache selber besitzen. Bei "immateriellen Vermögensgegenständen" muss man IMHO zweimal nachdenken bevor man seine Econ 101 Prinzipien anwendet.
-
Artchi schrieb:
Warum sollte ich oder ein Kollege nicht im C++-Komitee sitzen dürfen? Und das du einen Kollegen im JCP kennst, ist schön für dich. Aber ich kenne keinen Kollegen im JCP, obwohl ich seeehr viele Java-Kollegen von vielen Firmen habe. Aber das macht nichts, ich muß keinen selber kennen oder selber drin sitzen, damit ein Prozess offen ist. Diese Logik verstehe ich absolut nicht.
Der ISO-C++-Prozess ist sehr offen. Jeder kann ihn verfolgen, jeder kann sich selber einbringen durch aktive Arbeit (Diskussion, CRs und Proposals) und in den Meetings kann jeder persönlich teilnehmen und das Spektakel live miterleben. Das Komitee lädt dazu sogar herzlich ein.Also, wie offen soll das ganze noch sein? Ach ja, ich muß jemanden kennen, damit es offen ist. LOL
Meinetwegen können die auch Kaffee und Kuchen bei den Meetings verteilen aber solange die nichts in einen C++ Standard (es muss ja nicht der C++ Standard sein) aufnehmen was nicht seit mindestens 10 Jahren gefordert wird, habe ich dennoch herzlich wenig davon. Ich habe auch nie gesagt, dass man Mitglieder im Komitee kenn muss, sondern wollte einfach nur zeigen, dass man beim JCP auch ein bindendes Stimmrecht erhalten kann.
Wo wir gerade beim Thema sind, wo kann ich mich für das C++-Komitee bewerben? Ich, als Firma, habe (natürlich nur angenommen) eine großartige Innovation für C++ entwickelt und möchte bei der Standardisierung von dieser Aufsicht führen, wie mache ich da in C++?Artchi schrieb:
Zum Thema Java und GPL: schön das SUN seinen Compiler und JRE unter GPL gestellt hat. Das ist aber nicht die Marke Java (ist immer noch eine geschützte Marke die Geld kostet) und auch nicht die Spezifikation. Die Implementierung ist unter GPL. Und noch etwas: die GPL heißt nicht, das jemand seine Rechte an einem Werk aufgibt. Ganz im Gegenteil, er kann später das Werk unter eine andere Lizenz (auch proprietär) stellen und die Rechte an eine andere Person/Organisation abgeben. GPL heißt nicht, das etwas Public Domain ist.
C++ aber ist keine geschützte Marke. Wenn ich einen Compiler entwickle, kann ich ihn bedenkenlos "C++-Compiler" nennen. Das darf ich mit Java nicht machen, SUN würde mir ihre Rechtsanwälte aufhetzen, wenn ich eine JRE rausbringe und sie Java-RE oder Java-Compatible nennen würde.
Also, bitte hier nicht verrückt spielen, und juristische Fakten (und ein Trademark und GPL sind juristisch definiert) verdrehen.
Fakt ist aber nunmal, dass es eine Vielzahl an Runtimes gibt, die sich Java-Compatible nennen dürfen und den achso unerträglichen Aufwand aufsich genommen haben. Selbst wenn die CEOs von z.B. IBM und BEA einen Kopfstand vor Jonathan Schwartz machen mussten, ist mir das egal. Ich fordere ja nicht, dass Java Public-Domain gemacht wird, warum sollte ich auch?
MrN schrieb:
Hier haben wir sogar etwas schlimmeres als Allmende. Java gehört jemand anderem und trotzdem nutzt du es. Inwieweit stellst du sicher, dass eure Interessen konvergieren? (OK, wenn Java jetzt Open Source ist, ist das Problem schon wesentlich geringer.)
Inwiefern sollte das jetzt besser oder schlechter sein als "C++ gehört niemandem und trotzdem nutzt du es." Du kannst dich als einzelner ja auch nicht gegen Änderungen im nächsten Standard wehren. Ansonsten verstehe ich wohl nicht ganz, was du meinst.
-
Um die Diskussion in die Richtung zu lenken, in die ich eigentlich wollte, angelehnt an meinen vorherhigen Post:
Ich verstehe ja die Gründe, warum C++ keine umfangreiche Standard-Library mitbringt, aber warum gibt es nicht einfach zusätzliche Standards, die ein Compiler-Hersteller nicht implementieren muss? In Java wird ja auch bei weitem nicht alles in der Java SE Spezifikation festgehalten. Warum ist es nicht möglich einen C++-GUI Standard zu entwickeln, so dass z.B. Trolltech hergehen und sagen kann: "Hey, seht her, Qt kann man auch über die standardisierte C++-GUI-API verwenden."P.S.: Das sollte jetzt eigentlich keine "Seht-her-wie-es-in-Java-funktioniert"-Antwort werden, aber mir gefällt dieser Ansatz nunmal. Ob diese "periphären Standards" nun durch die ISO standardisiert werden, ist mir dann aber wieder egal.
-
Der Durchschnitt schrieb:
MrN schrieb:
Hier haben wir sogar etwas schlimmeres als Allmende. Java gehört jemand anderem und trotzdem nutzt du es. Inwieweit stellst du sicher, dass eure Interessen konvergieren? (OK, wenn Java jetzt Open Source ist, ist das Problem schon wesentlich geringer.)
Inwiefern sollte das jetzt besser oder schlechter sein als "C++ gehört niemandem und trotzdem nutzt du es." Du kannst dich als einzelner ja auch nicht gegen Änderungen im nächsten Standard wehren. Ansonsten verstehe ich wohl nicht ganz, was du meinst.
1. Du kannst dich am Standard-Prozess beteiligen.
2. Du kannst deine eigene C++-Variante bauen und die dann C++/Extended nennen. Es gibt niemanden, der dich daran hindert.Wie gesagt, wenn Java wirklich vollständig Open Source und ohne Patentgefahr ist, gibt es die Probleme da auch nicht.
Es ging mir einfach nur darum, dass man vorsichtig sein sollte bevor man mit ökonomischen Begriffen antanzt.
PS: Es heißt "peripher", nicht "periphär". :p
-
Mr. N schrieb:
1. Du kannst dich am Standard-Prozess beteiligen.
2. Du kannst deine eigene C++-Variante bauen und die dann C++/Extended nennen. Es gibt niemanden, der dich daran hindert.Nunja, beides trifft auch auf Java zu (sogar "zutreffender" wie ich meine).
P.S.: Korinthenkacker, aber das weißt du ja.
-
2. Du kannst deine eigene C++-Variante bauen und die dann C++/Extended nennen. Es gibt niemanden, der dich daran hindert.
Dass das nicht funktionieren würde, sieht man schön am Beispiel "D" bzw. es wird sich zeigen. Einzig und allein Microsoft hat sich in diese Richtung engagiert, aber das wohl nur um MFC-Anhänger nicht zu verlieren. Viel mehr Aussagekraft hätte es aber, wenn das Standardisierungs-Komitee Bemühungen in ein derartiges Projekt tätigt.