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

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.

Marc++us

Mal was völlig anderes, wieso lautet die Frage "Wird JAVA C/C++ vom Markt verdrängen?" Betrachtet man das Alter von Java und C++, so erkennt man doch, daß für eine Verdrängung Java viel weiter auf dem Markt sein müßte. Offensichtlich ist der jetzige Zustand der Koexistenz mit seinen Anwendungsbereichen ziemlich stabil. Weder C++ noch Java werden je auf 90%+ Marktanteil kommen.

Interessanter wäre zu fragen, "was kommt nach der heutigen Generation der Sprachen C++ und Java, und wann wird es diese Sprachen verdrängen, und welche Features werden Sprachen der Post-C++ und Post-Java-Generation haben?"

Gregor

Artchi: Es gibt sicherlich viele Gründe, die dafür sprechen, eine sehr umfassende Standardbibliothek zu haben.

Zum Beispiel ist bezüglich der Standardbibliothek besonders viel Wissen unter den Entwicklern vorhanden. Wenn man als Entwickler den Job wechselt, kann man einen Großteil seines Wissens bezüglich der Standardbibliothek wiederverwenden. Das wird einfach in vielen Jobs genutzt. Da verliert man im neuen Job keine Zeit, in der man sich erst in wxWidgets einarbeiten muss, weil man im alten Job nur Qt genutzt hat. Andererseits haben die Firmen den Vorteil, dass sie bei der Standardbibliothek auf eine Bibliothek setzen, die die meisten Entwickler kennen. Ich weiß nicht, ob Du dem Wissen über Bibliotheken so wenig Bedeutung zubilligst, dass Du so einen Punkt nicht siehst?

Ein weiterer Grund ist zum Beispiel die Homogenität des Codes. Es gibt wenig Situationen der Art, dass man als Entwickler Bibliothek X und Y nutzen möchte, wobei X die Bibliothek U nutzt und Y die Bibliothek V und U und V unterschiedliche Bibliotheken mit ähnlichem Inhalt sind. Oder guck dir Qt an: Kaum nutzt man das, schon hat man sich den QString eingehandelt. Warum braucht diese Bibliothek eigentlich einen eigenen Stringtyp? Jetzt nutzt man in anderen Bereichen seines Codes einen anderen Stringtyp und muss dann plötzlich Konvertierungen durchführen usw..

Du meintest, C++ braucht jetzt langsam mal Unterstützung für Threads? Da gibt es ja auch in diversen Bibliotheken eigene Thread-Realisierungen. Was passiert denn eigentlich mit denen, wenn jetzt Threads aus Boost kommen? Verschwinden werden die nicht so schnell.

Gregor

Marc++us schrieb:

Interessanter wäre zu fragen, "was kommt nach der heutigen Generation der Sprachen C++ und Java, und wann wird es diese Sprachen verdrängen, und welche Features werden Sprachen der Post-C++ und Post-Java-Generation haben?"

...um mal etwas gegen Java zu sagen...

Ich glaube, Java wird innerhalb der nächsten 10 Jahre strukturelle Probleme bekommen, die damit zusammenhängen, dass es für 32Bit-Systeme gedacht ist. Es gibt zwar 64Bit-JVMs, die können sich aber an einige Dinge nicht anpassen, die tief in der Sprache bzw. der Plattform verwurzelt sind. Ich kann mir zum Beispiel nicht vorstellen, dass der Zugriff auf Array-Elemente in Java irgendwann einfach auf longs als Index umgestellt wird. Bestimmte Anwendungsgebiete werden in Zukunft sicherlich derartig große Datenstrukturen nutzen. ...und insgesamt werden die Datenmengen in allen Bereichen ansteigen. Naja, ich bin da allerdings insgesamt sehr uninformiert. Vielleicht gibt es da ja auch eine elegante Lösung.

Ok, das war jetzt sicherlich nicht eines der Sprachfeatures, die Du gemeint hast, aber ein Java-Nachfolger wird sicherlich komplett auf 64Bit-Systeme ausgelegt sein.

DEvent

Jester schrieb:

@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

Das haben sich halt die Entwickler von Java und C# und Co. auch angeschaut und gedacht: Wieso intergrieren wir sowas nicht einfach in die Sprache. So hat man die constraint intergriert.
Naja nur eine Hypothese.

edit: ok jetzt hab ich den Code verstanden

DEvent

Gregor schrieb:

Marc++us schrieb:

Interessanter wäre zu fragen, "was kommt nach der heutigen Generation der Sprachen C++ und Java, und wann wird es diese Sprachen verdrängen, und welche Features werden Sprachen der Post-C++ und Post-Java-Generation haben?"

...um mal etwas gegen Java zu sagen...

Ich glaube, Java wird innerhalb der nächsten 10 Jahre strukturelle Probleme bekommen, die damit zusammenhängen, dass es für 32Bit-Systeme gedacht ist. Es gibt zwar 64Bit-JVMs, die können sich aber an einige Dinge nicht anpassen, die tief in der Sprache bzw. der Plattform verwurzelt sind. Ich kann mir zum Beispiel nicht vorstellen, dass der Zugriff auf Array-Elemente in Java irgendwann einfach auf longs als Index umgestellt wird. Bestimmte Anwendungsgebiete werden in Zukunft sicherlich derartig große Datenstrukturen nutzen. ...und insgesamt werden die Datenmengen in allen Bereichen ansteigen. Naja, ich bin da allerdings insgesamt sehr uninformiert. Vielleicht gibt es da ja auch eine elegante Lösung.

Klar, List<T> oder Vector<T> oder eine andere Container-Klasse.
Was spricht dagegen den Array-Index auf long umzustellen ?

Gregor

DEvent schrieb:

Klar, List<T> oder Vector<T> oder eine andere Container-Klasse.
Was spricht dagegen den Array-Index auf long umzustellen ?

1. Das würde ne Menge Code kaputt machen. Stell dir ein

int temp = array.length;

im Code vor. Soetwas kommt sicherlich in sehr viel Code vor.

2. Die Containerklassen haben toArray-Methoden. Wenn Du in so einer Klasse zu viele Elemente hast, dann können diese Methoden entsprechend nicht funktionieren, wenn die Arrays nicht entsprechend umgestellt werden.

3. Die Containerklassen müssen die Elemente intern ja auch verwalten. Teilweise werden da intern auch Arrays genutzt. Wenn diese nicht die entsprechende Kapazität haben, dann gibt es ein Problem.

4. Die Containerklassen haben auch size()-Methoden. ...sicherlich nur ein kleineres Problem, aber die liefern auch ints zurück.

usw.

Konrad Rudolph

DEvent schrieb:

Das haben sich halt die Entwickler von Java und C# und Co. auch angeschaut und gedacht: Wieso intergrieren wir sowas nicht einfach in die Sprache. So hat man die constraint intergriert.

Ich kann nicht für Java sprechen aber in C# sind Kontextbeschränkungen (Constraints) der reinste Witz. Ich bin seit knapp einem Jahr dabei, gegen Microsofts halbgare Implementierung der Generizität Sturm zu rennen. C++ ist da sicherlich aufwendiger, dafür funktioniert es. In C# kann man ja nicht mal folgenden Code kompilieren:

T add<T>(T x, T y)
{
    return x + y;
}

Nun gut, es geht tatsächlich mit einem fiesen Trick (den ich allerdings noch nirgendwo im Internet entdeckt habe) aber dieser Trick ist nur begrenzt einsetzbar und damit nicht praxisrelevant. Z.B. ließe sich dann obiger Code nicht für 'int's aufrufen.