Wird JAVA C/C++ vom Markt verdrängen?

Gregor

phlox81 schrieb:

Die Frage nach dem nächsten C++ Standard ist in der Tat interessant,
wann kommt eigentlich der erste Java ISO Standard mal raus?

Hi. Java wird nicht durch eine Standardisierungsorganisation, wie der ISO standardisiert. Das heißt aber nicht, dass es nicht standardisiert ist. Es gibt sehr genaue Dokumente darüber, wie die Sprache definiert ist, wie die JVM definiert ist usw.. Jeder kann diese Dokumente nutzen, um sich seine eigene Implementierung der Sprache zu schaffen.

Siehe da:

Was genau erwartest Du jetzt eigentlich von einem Standard bei einer Organisation wie der ISO, was durch solche offen zugänglichen Dokumente nicht abgedeckt wird?

Artchi

Naja, Java ist ein Industriestandard, das ist ein Unterschied zu einem Standard (zu deutsch "Norm"). Schau doch mal warum Java kein ISO- und auch kein ECMA-Standard werden konnte: weil SUN noch viele Rechte an Java behalten wollte, angefangen bei dem Markennamen "Java" bis hin zur Bestimmung wie Java weiter entwickelt wird.

Was heißt das, für den Anwender von Java? Er muß z.B. Lizenzgebühren für die Marke Java abdrücken... ein Beispiel nur!

Was wäre aber, wäre Java ISO-Norm? Genau, SUN würde praktisch alle Rechte an Java verlieren. Aber der Anwender könnte somit ohne Problem den Namen Java auf seine Produkte drauf pappen. Ich kann z.B. in meine C++ Anwendung in den Info-Dialog schreiben: "Diese Software wurde mit C++ entwickelt." Keiner kann von mir Lizenzgebühren verlangen.

Weiterhin muß eine ISO-Norm von mehrere Ländern/Firmen in einem gemeinsamen Gremium und Komitee weiter entrwickelt und verabschiedet werden. SUN hätte hier keine Bestimmungsgewalt mehr, da andere Firmen immer ein Veto bei bestimmten Features einlegen könnte.

Genau das ist z.B. beim letzten ISO-C++-Komitee-Meeting in Berlin passiert: viele Compilerhersteller haben ein bestimmtes Features (im Bereich Mathematik) des TR1-Draft aus Kostengründen abgelehnt. Gut, d.h. im C++0x-Standard wird dieses Feature nicht rein kommen, obwohl andere es gerne drinn gehabt hätten.

AT&T, Bjarne Stroustrup und HP haben z.B. damals ebenfalls ihre Rechte an C++ und die STL (bzw. eine Abwandlung davon) an die ISO abgetreten. Diese können heute davon nicht mehr direkt profitieren. Eigentlich nur Ruhm und Ehre...

Die Boost-Libs die in den TR1 rein gekommen sind (z.B. Smartpointer) gehören jetzt NIEMANDEM mehr rechtlich. Sind jetzt in der ISO-Norm drin.

Also, es ist schon ein Unterschied, ob es ein Standard ist oder "nur" ein unverbindlicher Industriestandard.

Artchi

Gregor schrieb:

Hi. Java wird nicht durch eine Standardisierungsorganisation, wie der ISO standardisiert. Das heißt aber nicht, dass es nicht standardisiert ist. Es gibt sehr genaue Dokumente darüber, wie die Sprache definiert ist, wie die JVM definiert ist usw.. Jeder kann diese Dokumente nutzen, um sich seine eigene Implementierung der Sprache zu schaffen.

Darf ich dann das Java-Logo oder ein "Java Powered" oder "Designed for Java" oder "Java Compatible" auf mein Produkt (z.B. JVM und Runtime) pappen?

Ich denke mal nicht. SUN will irgendwelche Zertifizierungsgebühren haben, damit ich das machen dürfte. Wennn dem nicht so ist, dann würde es SUN höchstens _dulden_. Aber sie könnten morgen ihre Meinung ändern.

Lasse mich aber gerne eines besseren aufklären.

Gregor

Artchi schrieb:

Also, es ist schon ein Unterschied, ob es ein Standard ist oder "nur" ein unverbindlicher Industriestandard.

"Unverbindlich" ist wohl eher der Standard bei der ISO, ECMA oder ähnlichem. Da Sun den Markennamen Java besitzt, hat es Kontrolle darüber, was sich Java nennen darf. Bei Standards, die bei der ISO oder ECMA oder so vorliegen, interessiert das einfach keinen. Das Resultat sind zum Beispiel Compiler, die nicht standardkonform sind. Damit hatte C++ ja lange Zeit zu kämpfen. Bei Java hat man letztendlich eine Garantie, dass da, wo Java draufsteht auch Java drin ist. ...oder zumindest, dass jede Implementation von Java durch eine ganze Reihe Kompatibilitätstests gegangen ist.

Deine Argumentation bezüglich Suns Kontrolle beüglich der Entwicklung von Java stimmt nicht mit der Realität überein. In der Realität wird Java durch den Java Community Process www.jcp.org weiterentwickelt. Dem gehören einige hundert Firmen an und auch die Entscheidungen, was zum Beispiel in eine Javaversion aufgenommen wird, werden da von Gremien getroffen, in denen Vertreter mehrerer Firmen sitzen. Sun hat da auch nur eine einzige Stimme und kann dort überstimmt werden. ...und da werden durchaus auch bestimmte APIs und so weiter abgelehnt.

Gedankenspiele wie "Sun könnte den JCP auflösen, wenn es keine Lust mehr darauf hat", kann man sicherlich auch durchspielen. Man sollte sie aber auch als das sehen, was sie sind: Gedankenspiele. Die Realität sieht momentan so aus, dass der JCP existiert und es ist nicht abzusehen, dass der in irgendeiner Form irgendwann aufgelöst wird.

Weiterhin erfolgt die Entwicklung von Java sehr transparent. Man kann sich beispielsweise jede Woche einen neuen "Snapshot" der nächsten Javaversion runterladen, kann ihn diskutieren, auf Fehler aufmerksam machen, Fehlerkorrekturen vorschlagen usw.. Die Entwickler, die an Java arbeiten, sind da sehr nah an der Nutzergemeinde dran. Die hören, was in den entsprechenden Foren usw. vorgeschlagen wird und setzen sich auch mit der Community auseinander. Was will man mehr?

Gregor

Artchi schrieb:

Darf ich dann das Java-Logo oder ein "Java Powered" oder "Designed for Java" oder "Java Compatible" auf mein Produkt (z.B. JVM und Runtime) pappen?

Ich denke mal nicht. SUN will irgendwelche Zertifizierungsgebühren haben, damit ich das machen dürfte. Wennn dem nicht so ist, dann würde es SUN höchstens _dulden_. Aber sie könnten morgen ihre Meinung ändern.

Lasse mich aber gerne eines besseren aufklären.

Wie schon im Beitrag eben gesagt: Das darfst Du natürlich nicht. Du musst aber keine Zertifizierungsgebühren zahlen, sondern die Tests bestehen, die glaube ich im "Java Compatibilitiy Kit" enthalten sind. Das kostet. ...wobei ich meine, mal gehört zu haben, dass Sun das für offene Implementierungen durchaus auch kostenlos macht. Dazu kann ich aber nichts genaues sagen.

...und meiner Meinung nach hätten andere Sprachen durchaus auch eine striktere Kontrolle des Standards nötig.

DEvent

Naja, jetzt nehmen wir mal boost mit ins boot, wer ernsthaft C++ programmiert kommt da nicht drum rum:

Das ist ja das Problem an C++, man kommt nicht drum herum irgendwelche Libs zu nehmen. Bei Java kommt alles "von Haus aus".

Bei Java habe ich eigentlich sowas wie synchroniced gemeint.
Java ist halt neuer als der letzte C++-Standard. Hat natürlich auch andere Ziele als C++.

Ich hoffe der nächste C++-Standard wird:
- Die Header-Include-System rausschmeisen und durch eine Art packages ersetzen.
- Generics hinzufügen
- Threads in der Sprache unterstützen
Das sind so die wichtigsten Dinge die ich an C++ misse.

templates sind in C++ mächtiger, auch wenn Generics einiges Bietet was auch für C++ interessant wäre.

Ich habe nicht den Eindruck das Templates mächtiger sind. Kann man mit Templates Klassen dynamisch zur Laufzeit erzeugen? Gibt es eine Typüberprüfung bei Templates?

Ich erinnere mich noch an die 5 Zeilen langen Compiler-Fehler wenn ich mal den falschen Typ in eine STL-Klasse geschrieben habe. Da kann man dann ewig rumrätzeln weil das oft nicht eindeutig ist.

Man kann zwar mit Generics nicht solche Tricks wie die 100ste Potenz zur Compilerzeit ausrechnen, aber wer braucht sowas schon? Wenn ich sowas brauche mach ich mir eine Lookup-Table.

GPC

DEvent schrieb:

Naja, jetzt nehmen wir mal boost mit ins boot, wer ernsthaft C++ programmiert kommt da nicht drum rum:

Das ist ja das Problem an C++, man kommt nicht drum herum irgendwelche Libs zu nehmen. Bei Java kommt alles "von Haus aus".

Das wird auch in C++ bald der Fall sein, denn boost findet starken Einzug im C++ Standard bzw. hat schon im TR1 und TR2 Einzug gefunden.

Ich hoffe der nächste C++-Standard wird:
- Die Header-Include-System rausschmeisen und durch eine Art packages ersetzen.
- Generics hinzufügen

Ich sehe ja irgendwie, dass du über die neue Typsicherheit in Java begeistert bist, aber in C++ braucht imho keiner wirklich Generics.

- Threads in der Sprache unterstützen

Siehe boost.

templates sind in C++ mächtiger, auch wenn Generics einiges Bietet was auch für C++ interessant wäre.

Ich habe nicht den Eindruck das Templates mächtiger sind. Kann man mit Templates Klassen dynamisch zur Laufzeit erzeugen?

Ich schätze, du weißt, dass man es nicht kann. Aber weißt du auch, dass sie dafür nicht gedacht wurden? Denn bei Templates passiert ALLES zur Compile Time.

Gibt es eine Typüberprüfung bei Templates?

Wie meinen? Einen String in einen int-vector einfügen usw. klappt nicht, wenn du darauf anspielst.

Man kann zwar mit Generics nicht solche Tricks wie die 100ste Potenz zur Compilerzeit ausrechnen, aber wer braucht sowas schon? Wenn ich sowas brauche mach ich mir eine Lookup-Table.

Machst du dir auch ne Lookup Table, wenn du n Policy-basiertes Klassendesign möchtest?

MfG

GPC

Artchi

@Devent! Die unverständlichen Fehlermeldungen haben nichts mit C++ zu tun, sondern sind die Schuld des Compiler-Herstellers. Das erstmal als wichtiger Punkt! Weiterhin hast du geschrieben "Damals"... eben! Damals, wir haben aber heute. Und schau dir mal den VC++ 8.0 an, der hat viel verständlichere Template-Fehlermeldungen. Verbessert wurden sie auch schon im VC++ 7.1 und sind noch besser geworden. D.h. hier wird kontinuierlich dran gearbeitet. Was auch zeigt, das z.B. MS seinen C++ Compiler ernst nimmt und was somit die Position von C++ im Markt stärkt.

Michael E.

DEvent schrieb:

Ich habe nicht den Eindruck das Templates mächtiger sind. Kann man mit Templates Klassen dynamisch zur Laufzeit erzeugen? Gibt es eine Typüberprüfung bei Templates?

Ich kenne auch noch nicht die volle Vielfalt von Templates, aber allein das, was Alexandrescu in seinem ersten Kapitel von Modern C++ Design macht und was ich schon über Policies, Traits, Metaprogramming etc. gelesen hab, bringt mich zu der Überzeugung, dass Generics da nicht mithalten können. Ich freu mich schon auf den Tag, an dem mein Modern C++ Design ankommt

DEvent

Denn bei Templates passiert ALLES zur Compile Time.

Das stört mich halt. Ich will mich Situationen dynamisch zur Laufzeit anpassen. Wieso kann man nicht beides intergrieren? Templates und Generics.

Wie meinen? Einen String in einen int-vector einfügen usw. klappt nicht, wenn du darauf anspielst.

Ich meinte, dass es manchmal verlangt wird das ein Template-Typ ein bestimmtes Interface hat, also bestimmte Methoden implementiert. Manche Klassen sollen halt nicht jeden x-beliebigen Typ haben können. Mit Templates kann ich das nicht eingrenzen. Es wird nur beim Compilieren an der Zeile 10567 irgendein komischer Fehler angezeigt. Meistens in einer fremd-Lib dessen Quellcode ich ja nicht kenne.

Die unverständlichen Fehlermeldungen haben nichts mit C++ zu tun, sondern sind die Schuld des Compiler-Herstellers.

ok wenn sich das gebessert hat. Mit damals hab ich vor 4 Jahren gemeint.

Michael E.

DEvent schrieb:

Denn bei Templates passiert ALLES zur Compile Time.

Das stört mich halt. Ich will mich Situationen dynamisch zur Laufzeit anpassen. Wieso kann man nicht beides intergrieren? Templates und Generics.

Was willst du denn dynamisch machen, was nicht mit Polymorphie geht?

Ich meinte, dass es manchmal verlangt wird das ein Template-Typ ein bestimmtes Interface hat, also bestimmte Methoden implementiert. Manche Klassen sollen halt nicht jeden x-beliebigen Typ haben können. Mit Templates kann ich das nicht eingrenzen. Es wird nur beim Compilieren an der Zeile 10567 irgendein komischer Fehler angezeigt. Meistens in einer fremd-Lib dessen Quellcode ich ja nicht kenne.

Constraints sollen AFAIK mit dem nächsten Standard kommen.

groovemaster

Gast_neu schrieb:

Wie nennt man eigendlich die Leute die immer gleich "Troll" schreiben?

Registrierte?
Nein, das Problem ist einfach, dass in der Vergangenheit immer wieder Leute durch solche Threads trollen wollten. Und das sind idR Unregs. Von daher hast du als Unregistreierter schon mal schlechte Karten. Wenn du es mit dem Thema aber wirklich ernst meinst, dann solltest du solche Kommentare einfach ignorieren.

DEvent schrieb:

Das ist ja das Problem an C++, man kommt nicht drum herum irgendwelche Libs zu nehmen. Bei Java kommt alles "von Haus aus".

Das kann man aber auch positiv für C++ auslegen. Dort kannst du halt nehmen, was du willst. Bei Java _musst_ du das nehmen, was "von Haus aus" dabei ist. Von dem all-inclusive Paket Java profitieren eigentlich nur Anfänger.

DEvent schrieb:

Ich habe nicht den Eindruck das Templates mächtiger sind. Kann man mit Templates Klassen dynamisch zur Laufzeit erzeugen?

Wozu sollte man das in C++ wollen? Klassen sind nichts anderes als Schablonen. Diese als "lebendige" Dinger anzusehen, ist nicht wirklich sinnvoll. Oder meinst du das mehr in Richtung Reflection? Das ist dann aber ein anderes Thema. Ich kann da eigentlich nur immer wieder sagen, das statische Typsystem von C++ ist kein Bug, sondern ein Feature.

DEvent schrieb:

Ich erinnere mich noch an die 5 Zeilen langen Compiler-Fehler wenn ich mal den falschen Typ in eine STL-Klasse geschrieben habe. Da kann man dann ewig rumrätzeln weil das oft nicht eindeutig ist.

Ja, das stört sicherlich viele Leute (mich eingeschlossen). Aber wie Artchi schon sagte, das ist nicht das Problem der Sprache, sondern der Compiler. Und daran wird in Zukunft sicherlich noch einiges gemacht. Es gibt ja auch schon jetzt Tools, die diese Template Fehlermeldungen filtern und nur die wichtigen Informationen in lesbarer Form ausspucken.

DEvent schrieb:

Man kann zwar mit Generics nicht solche Tricks wie die 100ste Potenz zur Compilerzeit ausrechnen, aber wer braucht sowas schon? Wenn ich sowas brauche mach ich mir eine Lookup-Table.

Die Stärken von Templates liegen aber auch an ganz anderen Stellen. Meta Programmierung ist ja nur eine spezielle Anwendung davon.

GPC

DEvent schrieb:

Wie meinen? Einen String in einen int-vector einfügen usw. klappt nicht, wenn du darauf anspielst.

Ich meinte, dass es manchmal verlangt wird das ein Template-Typ ein bestimmtes Interface hat, also bestimmte Methoden implementiert. Manche Klassen sollen halt nicht jeden x-beliebigen Typ haben können. Mit Templates kann ich das nicht eingrenzen. Es wird nur beim Compilieren an der Zeile 10567 irgendein komischer Fehler angezeigt. Meistens in einer fremd-Lib dessen Quellcode ich ja nicht kenne.

Das ist jetzt schon möglich:

template <typename T>
struct Foo;

template< >
struct Foo<int> {
  //...
};

template< >
struct Foo<double> {
  //...
};

Jetzt lässt er für Foo nur Instantierungen für int und double zu.

EDIT: Rechtschreibfehler korrigiert...

MfG

GPC

Michael E.

GPC schrieb:

Das ist jetzt schon möglich:

[...]

Jetzt lässt er für Foo nur Instantierungen für int und double zu.

Das ist aber nur sehr eingeschränkt. Wie sagst du zum Beispiel, dass der Template-Typ von Bar erbt?

Interessanter Artikel: http://www.artima.com/cppsource/cpp0x.html

DEvent

Das kann man aber auch positiv für C++ auslegen. Dort kannst du halt nehmen, was du willst. Bei Java _musst_ du das nehmen, was "von Haus aus" dabei ist. Von dem all-inclusive Paket Java profitieren eigentlich nur Anfänger.

Seit wann musst du das ? Du kannst die packaged doch rausschmeisen oder nicht benutzen. Benutzt halt deinen Vector oder deine Liste.
Nagut für solche sachen wie Reflection oder Swing musst du das von Java verwendet, das stimmt.

Oder meinst du das mehr in Richtung Reflection? Das ist dann aber ein anderes Thema. Ich kann da eigentlich nur immer wieder sagen, das statische Typsystem von C++ ist kein Bug, sondern ein Feature.

Ja ich meinte Reflections.
Java hat doch auch ein statisches Typsystem. Alle Klassen sind abgeleitet von Object.

Walli

GPC schrieb:

Man kann zwar mit Generics nicht solche Tricks wie die 100ste Potenz zur Compilerzeit ausrechnen, aber wer braucht sowas schon? Wenn ich sowas brauche mach ich mir eine Lookup-Table.

Machst du dir auch ne Lookup Table, wenn du n Policy-basiertes Klassendesign möchtest?

Der war gut .

GPC

Michael E. schrieb:

GPC schrieb:

Das ist jetzt schon möglich:

[...]

Jetzt lässt er für Foo nur Instantierungen für int und double zu.

Das ist aber nur sehr eingeschränkt. Wie sagst du zum Beispiel, dass der Template-Typ von Bar erbt?

So:

#include <iostream>

template <typename T>
struct Bar {
  T t;
};

template <typename T>
struct Foo;

template< >
struct Foo<int> : public Bar<int> {
  //...
};

template< >
struct Foo<double> : public Bar<double> {
  //...
};

int main() {
  Foo<int> f;
  f.t = 7;
  std::cout<<f.t<<std::endl;
  return 0;
};

Interessanter Artikel: http://www.artima.com/cppsource/cpp0x.html

Yupp, wenn der neue Standard nur mal kommen würde

MfG

GPC

Jester

@GPC: ich glaube, er wollte eigentlich festlegen, daß T von einem festen Typ erben muß. Das geht aber auch. Zum Beispiel mit STATIC_ASSERT aus Loki/Boost nebst der Abfrage, ob es erbt aus boost::mpl. Natürlich kann man das auch von Hand schreiben. Die grobe Idee ist die, zu prüfen ob sich ein T* in ein GeforderteBasisKlasse* umwandeln läßt. Dazu deklariert man zwei Funktionen:

char f(...); 
char[2] f(GeforderteBasisKlasse*);

T * p;
sizeof(f(p) == sizeof(char[2])

Der letzte Vergleich sagt, ob T Unterklasse der anderen ist.
Ein STATIC_ASSERT läßt sich so bauen:

template<bool> assertion;

template <> assertion<true> {};

Das geht für assertion<false> nicht durch den Compiler, da die allgemeine Variante nur deklariert, aber nicht definiert ist. Weil das aber alles recht umfangreich ist,wenn man es ordentlich machen will (es gibt noch Tricks um bessere Compilerfehlermeldungen zu bekommen) nimmt man am Besten ne fertige Lib.

MfG Jester

GPC

ups, hab ich ihn wohl falsch verstanden... aber wie du sagtest, geht's das geforderte auch. Das Compiler Assertion Template erinnert mich gerade daran, wie ich Modernes C++ Design gelesen hab und total überrascht war, wie einfach sich das bauen lässt und wie genial es ist, man muss nur draufkommen

MfG

GPC

Artchi

@DEvent! Was ist eigentlich schlecht daran, wenn ich eine fremde Lib nehmen muß, weil es sowas in der Std-Lib nicht gibt? Das hört sich so an, als ob Java-Entwickler ohne fremde Libs auskommen. Aber dem ist ja auch nicht so. Wir haben in unseren Java-Projekten sehr viele fremde Libs die uns die Java1.5-Runtime nicht von Haus aus bieten kann. Das ganze könnte man jetzt unendlich lang spinnen, und dein Argument würde nur bei einer Sprache ziehen, die alle Libs auf diesem Planeten mitliefert. Ist aber völlig absurd.

Die Standard-Lib von C++ hat halt eine definierte Basis. Klar, ich gebe zu: mittlerweile fehlen wirklich essentielle Sachen, die man täglich braucht. Z.B. eine Thread-Lib. Aber diese wird wohl im C++0x-Standard rein kommen. Nur müssen wir halt noch etwas warten, da die Roadmap vorsieht, das die letzten Vorschläge für C++0x bzw. dessen TR2 bis Oktober 2006 eingereicht werden dürfen.