Blick in die Kristallkugel
-
Gab es keinen C++ Standard vor 98?
Bei Java gibt es durchaus einige Dinge, bei neuen Versionen, die alten Code ungültig machen. ...zum Beispiel das neue enum-Schlüsselwort, das mit 5.0 kam. So gesehen bist du schon auf alte Compiler angewiesen, wenn du alten Javacode kompilieren möchtest. ...der Bytecode sollte dann allerdings auch auf aktuellen JVMs lauffähig sein.
-
iostream.h schrieb:
das war nie standard
Naja, ist eigenlich ziemlich egal, was es nun war. Vor 10 Jahren hat man es in C++ genutzt und jetzt geht es nicht mehr. Wie kann man da so sicher sein, dass soetwas nicht in Zukunft auch passiert?
-
Gab es keinen C++ Standard vor 98?
richtig
-
Gregor@Home schrieb:
Vor 10 Jahren hat man es in C++ genutzt und jetzt geht es nicht mehr.
oft geht's noch. man bekommt aber ein warning. bei java erscheinen ja auch die deprecated meldungen
-
Vor '98 gab es keinen C++ -Standard; die Standardisierung dauerte also fast 10 Jahre.
Gibt es eigentlich einen Java-Standard ?
Und wieso wird eigentlich C noch weiterentwickelt und neu standardisiert ?
Da Standard-C++ (also C++'98) die *damalige* Version von C als Untermenge enthält,
kann man doch in Schwierigkeiten laufen, wenn man etwa in C'99 programmiert und
eines Tages mit einem Standard-C++ Compiler übersetzen will..., oder ?
-
Gregor@Home schrieb:
Gab es keinen C++ Standard vor 98?
Bei Java gibt es durchaus einige Dinge, bei neuen Versionen, die alten Code ungültig machen. ...zum Beispiel das neue enum-Schlüsselwort, das mit 5.0 kam. So gesehen bist du schon auf alte Compiler angewiesen, wenn du alten Javacode kompilieren möchtest. ...der Bytecode sollte dann allerdings auch auf aktuellen JVMs lauffähig sein.
Genau, es gab erst 1998 den ersten Standard. Davor hat halt jeder mehr oder weniger gemacht was er will.
Was ist denn mit enum in Java? Was macht es denn ungültig?
enum ist doch in Java5.0 ganz neu und dadurch ist doch nichts raus geflogen. Ich habe jedenfalls nichts gefunden, was rausgeflogen ist. Man kann mit dem neuen JDK auch alte Projekte compilieren. Kein Problem.
-
Cacheline schrieb:
Gibt es eigentlich einen Java-Standard ?
Java ist nicht in der ECMA oder ISO standardisiert. Sun macht da ihr eigenes Ding, weil die ja Geld verdienen wollen. Wer eine Java VM oder Java Compiler entwickelt, und ein Java-Logo drauf pappen will, muß es bei Sun zertifizieren lassen... natürlich gegen Geld. Deshalb heißen auch diese ganzen inoffiziellen Java-implementierungen Cafe oder so damit es ja keinen Ärger mit Sun gibt.
Cacheline schrieb:
Und wieso wird eigentlich C noch weiterentwickelt und neu standardisiert ?
Da Standard-C++ (also C++'98) die *damalige* Version von C als Untermenge enthält,
kann man doch in Schwierigkeiten laufen, wenn man etwa in C'99 programmiert und
eines Tages mit einem Standard-C++ Compiler übersetzen will..., oder ?Ehm, was hat jetzt C und C++ miteinander zutun? C99 und zukünftiges C++ müssen nicht compatibel sein... sind sie ja jetzt schon nicht! Du kannst mit einem C++98 Compiler keinen C99-Code compilieren (wenn C99 voll ausgeschöpft wird), geht also jetzt schon nicht mehr! Aber das ist auch OK, weil das völlig zwei verschiedene Sprachen sind (wann begreifen das eigentlich die Leute?).
C wird deshalb noch entwickelt, weil es noch massiv eingesetzt wird, z.B. in der Autoindustrie. Deshalb verstehe ich nicht, warum hier immer gesagt wird, das C++0x auch weiterhin auf Toastern laufen muß? Schliesslich ist C eher dafür in der Industrie vertreten. naja, egal...
-
Du kannst mit einem C++98 Compiler keinen C99-Code compilieren (wenn C99 voll ausgeschöpft wird)<<
Eben - das ist aber ein entscheidender Punkt.
Zukunftssicherer C-Code sollte demnach wohl keine C'99-Erweiterungen enthalten
dürfen, denn C++0x soll voraussichtlich Standard-C++ als Untermenge enthalten,
also "nur" das in C++'98 enthaltene C'89.Grüße
-
Hallo???? Jemand zu Hause???? Was hat C++0x mit C-Code zu tun?????????????????
-
Cacheline schrieb:
Zukunftssicherer C-Code sollte demnach wohl keine C'99-Erweiterungen enthalten
dürfen,C und C++ sind unterschiedliche Sprachen. Und das C Standard Komitee hat beschlossen die beiden Sprachen mehr zu trennen.
denn C++0x soll voraussichtlich Standard-C++ als Untermenge enthalten,
Nein. C++0x wird C++98 erweitern. Nix untermenge oder so.
also "nur" das in C++'98 enthaltene C'89.
Sehe keinen Grund warum so sachen wie restrict nicht aufgenommen werden _könnten_ Viel eher will man nicht, weil man C und C++ etwas separieren will.
C ist etwas anderes als C++. Du hast mit echten C Anwendungen ja auch schon deine liebe not sie nach C++ zu portieren...
-
Also, C++ ist doch aus C entstanden, was ursprünglich als C mit Klassen geplant war hat sich weiter zu C++ entwickelt und wurde eine eigenständige Sprache. Aber aufgrund der Entwicklung ist es doch nur natürlich, dass der damalige C-Standard unterstützt wird. Dadurch, dass C++ aber eben nicht mehr nur ein Aufbau von C ist, sondern vielmehr eine eigene Sprache geworden ist müssen aber auch neuere Entwicklungen von C nicht berücksichtigt werden. Der alte Standard wird aber denke ich immer weiterhin unterstützt werden. Denn gerade älterer Code ist doch noch voll mit C-Teilen, daher kommt wohl auch dieses ganze "iostream.h" und "void main" in den Büchern. Irgendwie konnten sich die C-Entwickler wohl nie ganz umstellen, zumindest nicht diejenigen, die sich auch als Autoren versucht haben.
Dadurch, dass neuere C-Entwicklungen nicht in C++ berücksichtigt werden, werden die beiden Sprachen mehr voneinander getrennt, was nicht unbedingt schlecht sein muss.
Naja, und wenn Du in 10 Jahren heutigen Code übersetzen möchtest, dann brauchst ja nur nen Compiler(+Linker) für diese Plattform. Dieser braucht ja nur den heutigen Standard unterstützen und nicht den zukünftigen. Die Frage ist halt nur, ob Du in 10 Jahren für eine andere Plattform übersetzen möchtest, als Du heute benutzt, aber das Problem gibt es wohl bei jeder Sprache.
Ich denke nicht, dass es eine Zukunft ohne ASM, C, C++ und auch Java geben wird. Dieser ganze .NET-Hype wird wohl noch zunehmen, aber man hat doch schon bei Java gesehen, dass die VM (.NET-Framework) und die "Abhängigkeit" von einer Firma (hier Sun, bei .NET Mircosoft) doch eher bremsen, anstatt die Verbreitung voranzutreiben. Klar, im Anwendungsbereich macht das evtl. noch Sinn, aber auf kleineren Systemen?
Und Stroustrup träumt ja auch noch von einer einheitlichen GUI in C++, mal sehen, was die Zukunft noch bringt. Träumen darf man ja.
-
Was war ursprünglich C mit Klassen geplant? C++ nicht. Du meinst wohl eher ObjectiveC, das ist wirklich C mit Klassen und wird heute noch intensiv auf MacOS X als Hauptsprache eingesetzt, weil das damals in NeXT-Step intensiv benutzt wurde.
C++ ist eine eigene Sprache die _auch_ C als Untermenge drin hat. Aber nicht weil C cool ist, sondern weil Bjarne damit die C-Programmierer ködern wollte - was auch sehr schlau war.
-
Stroustrup: 'Die C++ Programmiersprache', 4. Auflage, Seite 11, Absatz 4 schrieb:
Frühe Versionen der Sprache, allgemein als >>C with Classes<< bekannt, sind seit 1980 in Gebrauch. Die Sprache wurde ursprünglich entwickelt, weil ich einige ereignisgesteuerte Simulationen schreiben wollte, wofür Simula67 bis auf Effizienzbetrachtungen ideal gewesen wäre. >>C with Classes<< wurde in wichtigen Projekten eingesetzt, in denen die Möglichkeiten zum Schreiben von Programmen, die minimal Zeit und Speicherplatz benötigen, gründlich getestet wurden. Es fehlten jedoch das Überladen von Operatoren, Referenzen, virtuelle Funktionen, Templates, Ausnahmen und viele weitere Details. Die erste Nutzung von C++ außerhalb einer Forschungseinrichtung begann im Juli 1983.
Vielleicht war es nicht so ganz geplant, aber erstmal wurde es so umgesetzt, alles weitere war im ursprünglichen Konzept aber nicht enthalten, so, wie ich das verstanden habe.
-
Artchi schrieb:
Was ist denn mit enum in Java? Was macht es denn ungültig?
enum ist doch in Java5.0 ganz neu und dadurch ist doch nichts raus geflogen. Ich habe jedenfalls nichts gefunden, was rausgeflogen ist. Man kann mit dem neuen JDK auch alte Projekte compilieren. Kein Problem.Es entsteht ein Problem, wenn du "enum" als Bezeichner in altem Code verwendet hast. Du kannst dann nicht "mit den neuen Sprachfeatures" kompilieren, weil enum jetzt ein Schlüsselwort ist und somit nicht mehr für Bezeichner zur Verfügung steht. Das ist übrigens auch ein Grund, warum das neue foreach so aussieht:
for(String a : b)
Wenn man ein "foreach(String a in b)" daraus gemacht hätte, hätte man 2 neue Schlüsselwörter benötigt, die sich zumindest im Fall von "in" wohl gar nicht mit altem Code vertragen hätten.
-
Cacheline schrieb:
Gibt es eigentlich einen Java-Standard ?
Nicht bei einer Standardisierungsorganisation wie der ISO oder der ECMA. Aber natürlich gibt es eine Java-Spezifikation, in der die Sprache festgelegt ist:
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
Die Standardbibliothek wird wohl durch die Referenzimplementierung von Sun vorgegeben, die wiederum ein Resultat das "Java Community Process" ist, in dem beispielsweise neue APIs festgelegt werden usw.:
http://www.jcp.org/en/home/index
Wenn du dir mal die Mitglieder des JCP anguckst, wirst du feststellen, dass nicht nur Sun an der Entwicklung von Java beteiligt ist, sondern letztendlich die ganze Industrie, die in dem Bereich tätig ist, wenn man von MS absieht. Entscheidungen werden im JCP demokratisch durch ein Gremium getroffen, Sun hat da auch nur eine Stimme.
Um eine Implementierung von Java als Java bezeichnen zu dürfen, muss man AFAIK Kompatibilitätstests bestehen, die Sun im JCK (Java Compatibility Kit) zur Verfügung stellt. Das Problem daran war früher, dass eine Lizenz des JCK etwa 100k$ oder so kostet. Das ist wohl ein Grund, warum es keine vernünftigen FOSS-Javaimplementierungen gibt. AFAIK gibt es da aber inzwischen Extraregelungen für FOSS-Produkte, durch die so ein Test für diese auch kostenlos möglich ist. Ob es dadurch mehr FOSS-Javaimplementierungen geben wird, bleibt aber abzuwarten. Ich vermute eher, dass in dem Bereich deshalb so wenig gemacht wird, weil Java für die meisten Leute eh offen genug ist und deshalb nur wenige Leute genug FOSS-Idealismus haben, um da selbst etwas auf die Beine zu stellen.
Hmmm... bin ich vom Thema abgekommen? ...egal.
-
Artchi schrieb:
Wer eine Java VM oder Java Compiler entwickelt, und ein Java-Logo drauf pappen will, muß es bei Sun zertifizieren lassen... natürlich gegen Geld. Deshalb heißen auch diese ganzen inoffiziellen Java-implementierungen Cafe oder so damit es ja keinen Ärger mit Sun gibt.
Die würden auch dann nich den Namen Java verwenden dürfen, wenn sie so viel Geld wie MS hätten. Das Problem ist, dass die einfach inkompatibel sind bzw. nicht das leisten, was für Java vorgesehen ist. :p
-
Nein. C++0x wird C++98 erweitern. Nix untermenge oder so. <<
Was ? C++'98 enthält C'89 als Untermenge und C++0x wird voraussichtlich C++'98
als Untermenge enthalten.
-
mantiz schrieb:
Dieser ganze .NET-Hype wird wohl noch zunehmen, aber man hat doch schon bei Java gesehen, dass die VM (.NET-Framework) und die "Abhängigkeit" von einer Firma (hier Sun, bei .NET Mircosoft) doch eher bremsen, anstatt die Verbreitung voranzutreiben. Klar, im Anwendungsbereich macht das evtl. noch Sinn, aber auf kleineren Systemen?
Hä? Ist Java auf Handys etwa kein relevantes Thema? Oder verstehe ich dich hier falsch? Es gibt ja sogar JStamp und ähnliches.
-
Ähm, hab' mich wohl unglücklich ausgedrückt. Ich meinte .NET bzgl. der kleineren Systeme. Java auf Handys ist mir sehr wohl bekannt.