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

[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.

[Artchi]

Gregor schrieb:

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 ...

Da hast du mich leider falsch verstanden. Ich habe nichts gegen eine umfassende Standardlib! Ich habe nur gesagt, das ich in Java auch zusätzliche Libs benötige, wenn ich etwas mehr als ein HelloWorld machen will. Denn hier schreiben einige immer, das es schlecht ist, wenn man in C++ zus. Libs benötigt. Ich habe lädiglich klargestellt, das es in Java auch nicht anders ist, weil eine Standardlib nicht alle Bedürfnisse erfüllen kann (auch die von java nicht!). Und in C++ ist halt die Lib kleiner. Lies dir also bitte meinen letzten Beitrag dazu nochmal genauer durch.

Gregor schrieb:

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.

Und? Von Apache gibts auch XML-Libs die von vielen Projekten genutzt werden, weil es XML vorher auch nicht in der Java-Standardlib gab. Gut, heute ist XML in der Java-Standard-Lib drin. Apaches XML wird trotzdem geflegt und weiter genutzt.

Das kann ich jetzt für jeden Java-Bereich weiter aufzählen. Auch WebService-Libs (z.B. AXIS) gab es vorher nur als externe Libs. Komisch... Jetzt kommen sie anscheinend in Java 6 mit rein. Warum gabs die nicht schon vor Jahren in der java-Standardlib, wo es doch WebServices nicht erst seit heute gibt?

Was willst du mir also damit sagen, wenn es in C++ auch mehrere (externe) Libs gibt? Bei Java sieht es auch nicht anders aus. Nur das es bei C++ immer schlecht gemacht wird, wenn man externe Libs heranziehen muß. Obwohl es die Javainer (und C#er) auch nicht anders machen, weil ihre Standard-Lib das auch nicht von Haus aus alles anbietet.

Wie ich in meinem vorherigen Beitrag sagte: keine Standardlib einer Sprache kann von Haus aus ALLES abdecken. Und bei C++ wird halt weniger abgedeckt als bei anderen Sprachen. Was aber nicht heißt, das ich nicht dafür bin, das in die Standardlib ein paar Sachen mehr einfliessen sollten.

[Jester]

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.
Naja nur eine Hypothese.

Naja, mit entsprechenden Bibliotheken wird das etwa zu:

template <typename T>
class Blabla {
  STATIC_ASSERT(IsDerived<T, GeforderteBasisKlasse>::value);
  // ...
};

Und das ist eigentlich recht gut lesbar. Eingebaut ist natürlich aber auch nicht schlecht. Insbesondere dürfte es dem Compiler deutlich leichter fallen ne gute Fehlermeldung rauszugeben.

[Gregor]

Artchi: Mir kommt es so vor, dass Du dich auf folgenden Standpunkt stellst:

"Ist doch egal, wie umfassend die Standardbibliothek ist. Man könnte ja eh zusätzliche Bibliotheken benötigen. Und ob man jetzt eine oder 10 zusätzliche Bibliotheken benötigt, ist doch nun wirklich kein Unterschied."

Ich halte das für einen riesigen Unterschied. Und ich halte es für schlecht, zu sehr auf zusätzliche Bibliotheken angewiesen zu sein. Zwei Gründe habe ich dafür genannt.

Ich halte es für gut, dass die C++ Standardbibliothek etwas mehr Inhalt bekommen soll. Aber ehrlich gesagt kommt das, was da kommt, zu spät und ist zu wenig. Da ist immer noch eine Minimalismus-Mentalität zu sehen: Man nimmt nur das in die Standardbibliothek auf, was unbedingt nötig ist. Und das halte ich einfach für den völlig falschen Weg.

Naja, lassen wir das mal.

@Jester:

Jester schrieb:

Und das ist eigentlich recht gut lesbar. Eingebaut ist natürlich aber auch nicht schlecht. Insbesondere dürfte es dem Compiler deutlich leichter fallen ne gute Fehlermeldung rauszugeben.

...womit wir wieder bei der Frage wären, ob die Fehlermeldungen etwas mit der Sprache zu tun haben oder in erster Linie dem Compiler anzukreiden sind. Weiter oben hat ja irgendwer in diesem Thread gesagt, dass das in erster Linie eine Compilerfrage ist. Das sehe ich nicht so. Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

[groovemaster]

Gregor schrieb:

Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

Der zweite Teil ist korrekt, der erste nicht. Wie einfach oder kompliziert eine Fehlermeldung letztendlich ist, ist immer noch auf den Compiler zurückzuführen. Ich schrieb ja weiter oben, dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben. Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

[Jester]

Klar, er kann dann vielleicht auch genau sagen, warum er das template nicht instanziieren kann. Leider kann er die Semantik nicht erkennen und sagen: "Das geht so nicht, T muß von Basis erben."

[Konrad]

groovemaster schrieb:

(...) dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben.

STLFilt ist so ein Tool. Der Comeau Online-Compiler benutzt das zum Beispiel: http://www.bdsoft.com/tools/stlfilt.html

groovemaster schrieb:

Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

Dazu fand ich folgendes interessant:
http://erdani.org/publications/better_template_error_messages.html

[Gast]

Artchi schrieb:

Da hast du mich leider falsch verstanden. Ich habe nichts gegen eine umfassende Standardlib! Ich habe nur gesagt, das ich in Java auch zusätzliche Libs benötige, wenn ich etwas mehr als ein HelloWorld machen will. Denn hier schreiben einige immer, das es schlecht ist, wenn man in C++ zus. Libs benötigt.

Natürlich ist das mit C++ schlecht. Und vor allem nicht, dass man so oft welche braucht, sondern wie das vonstatten geht. Da hat nämlich jeder eine eigene Idee von.

Es gibt halt leider kein standardisiertes "C++ Objektmodell", stattdessen gibt es C-DLLs, COM-DLLs, sowie andere binaries unter anderen Betriebssystemen. Davon mal abgesehen, dass die Benutzung oft umständlich ist, haben die allermeisten Modelle erhebliche Probleme beim Austausch von Daten, dem Aufrufen einer Methode aus der Klasse in DLL B an einem Objekt aus der EXE A, Angabe von Callback-Funktionen. Ableiten von Bibliotheksklassen geht nicht geil und die Kontrolle der Lebenszeit eines Objekts aus einer fremd-Lib ist auch immer umständlich (Release() ... ja!), es beschränkt sich fast alles auf die Übergabe von Pointern (die dann auch nur auf gleichen Systemen funktioniert) und der Benutzung von Interfaces. Null flexibel, mal etwas direkter ausgedrückt. Und JETZT braucht man das auch noch 100mal. Die Schuld der Sprache ist das nicht, aber das ist das generelle Problem mit C++, dass es aus nicht viel mehr besteht als der Sprache.

Zum Vergleich dazu hat man mit der JIT-Compilierung in Java kein Problem, ich kann von fremden Klassen ableiten, alles findet im selben OS-Prozess statt, ich benutze den selben Speicherbereich, habe in meinem Programm echte Instanzen von Bibliotheksklassen und von davon abgeleiteten Klassen. Und man braucht es nur 10mal. Und das ist der feine Unterschied. Java bezeichnet nicht nur eine Sprache, sondern ein vernünftiges, standardisiertes Objektmodell und eine gut ausgestatte Standardbibliothek. Es ist völlig sinnlos, von C++ Seite aus es so darzustellen, als wäre das keine bessere Lösung, wenn es um die Benutzung von Libs geht. Sowas in die Richtung kann nur der einzige echt gute Weg sein.

Es geht mir hier nicht darum, Java/.Net/whatever generell als besser hinzustellen (wir wissen ja alle, was besser ist ), aber diese generelle Ignoranz, mit der teils erhebliche Nachteile bei vorhandenen Systemen nicht eingesehen werden, ist schon echt erstaunlich. Tim Sweeny von Epic Games hat eine IMHO recht interessante Präsentation über aktuelle Mainstream-Sprachen gemacht, an denen er auch eine Menge auszusetzen hat. Was C++ betrifft, so ragen vor allem die Punkte Nebenläufigkeit "C++ is ill-equiped for concurrency" und die mangelnde Modularität ("The Problem:
Users of a framework
want to extend the functionality
of the framework’s base classes!

The workarounds:
Modify the source
…and modify it again with each new version
Add references to payload classes, and dynamically cast them at runtime to the appropriate types.
These are all error-prone:
Can the compiler help us here?") heraus, wen es interessiert: http://lambda-the-ultimate.org/node/1277

groovemaster schrieb:

Gregor schrieb:

Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

Der zweite Teil ist korrekt, der erste nicht. Wie einfach oder kompliziert eine Fehlermeldung letztendlich ist, ist immer noch auf den Compiler zurückzuführen. Ich schrieb ja weiter oben, dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben. Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

Gregor sagt nichts anderes als dass es einfacher ist, für Java einen guten Compiler zu schreiben als für C++. Was ist daran auszusetzen? "Es gibt..." - na toll.

[Gast]

Bin zwar noch Anfänger in C++ aber ich denke nicht dass JAVA C++ verdrängen wird. C++ wird überall da eingesetzt werden wo Leistung gefragt ist, sprich: Grafik, Animation, Audio, Video, Spiele, Simulationen, Raytracing Betriebssysteme, Treiber, Rechnerdienste, Festplattentools, Monitoring, Messungen, Packer, Kryptografi, Webserver und Module dafür, Virtuelle Laufzeitumgebungen und und und.

Es ist auch bei der heutigen Rechnergeneration wichtig Resourcen zu sparen, würde mich ängern wenn ich 3-4 kleine Tools in der Taskleiste hätte, und die alle mehr Resourcen schlucken als nötig. Eine Rechnerumgebung besteht halt nicht aus nur einem Programm und bin da echt froh kein Java anzutreffen.

Ich denke es bleibt bei einer Koexistenz der beiden Sprachen und C# wird da Java was die Desktopanwendungen angeht ne Scheibe abschneiden.

Was portabel und sicher Programmieren angeht, so denke ich kann man mit C++/STL/Boost/wxWidgets/SDL/OpenGL so ziemlich alles sicher und portabel halten. Und Bibliotheken gibts ja für C++ wohl die meisten überhaupt. Auch wenn sie nicht so schön für Anfänger angepasst ist.

Denke auch man sollte eine Programmiersprache nicht zu sehr Abstrahieren, dann landen wir alle irgendwann wieder bei VisualBasic in drei Sandkasten virtuellen Maschinen die ab 10GB ein HelloWorld ausspucken, aber auch der Bäcker an der Ecke was tolles damit programmieren kann.

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

Gruß Chris

[Jester]

justchris schrieb:

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

rofl, Du hast Sorgen.

[Konrad Rudolph]

justchris schrieb:

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

Nein, daran habe ich in der Tat noch nicht gedacht, das halte ich nämlich für Quatsch. Die durchschnittliche Länge von Programmquellcodes steigt exponentiell, wenn man da Sprachen nicht so einfach wie möglich hält, ist diese Arbeit schon in kurzer Zeit nicht mehr zu bewältigen.

[Gast]

Konrad Rudolph schrieb:

Die durchschnittliche Länge von Programmquellcodes steigt exponentiell.

echt? dachte immer das mehr auf Libs gesetzt wird als früher und man daher weniger selbst das Rad neu erfindet. So kann man sich täuschen....

[Artchi]

@Pellaeon! Dein eMail-Account ist leider nicht erreichbar. Versuche seit gestern dir auf deine eMail die sich diesen Thread bezieht zu antworten. eMail kommt immer zurück...