C++ vs. Java [Update]

volkard

Original erstellt von Gregor:
In diesem Thread sollte ein sehr kleines C++-Programm geschrieben werden, das wohl auch auf verschiedenen Plattformen kompiliert. Anscheinend ist da wohl doch schwerer als du es sagst. Oder willst du sagen, dass die Leute, die da die C++-Programme geschrieben haben, Idioten sind?

um was gings da? Daß manche keine crossplatformlib für ne gute uhr finden? also die ACE-Wrappers haben ne Klasse ACE_High_Res_Timer dabei.

/**
 * @class ACE_High_Res_Timer
 *
 * @brief A high resolution timer class wrapper that encapsulates
 * OS-specific high-resolution timers, such as those found on
 * Solaris, AIX, Win32/Pentium, and VxWorks.

uder wars was anderes? hab nach 40 beiträgen aufgehört, den thread zu lesen.

Shade Of Mine

Original erstellt von Gregor:
@ Shade : Kann ja sein, dass du besonders gut plattformunabhängig und compilerunabhängig programmieren kannst. In diesem Thread sollte ein sehr kleines C++-Programm geschrieben werden, das wohl auch auf verschiedenen Plattformen kompiliert. Anscheinend ist da wohl doch schwerer als du es sagst. Oder willst du sagen, dass die Leute, die da die C++-Programme geschrieben haben, Idioten sind?

Der code von kingruedi ist ein POSIX kompatibler code -> das haette er natuerlich besser machen koennen um windows auch mit einzubeziehen.

der C++ standard garantiert zum zeitmessen nur clock() welches aber nicht sonderlich genau ist - deshalb hat kingruedi die posix funktion gettimeofday genommen, das gehoert natuerlich versteckt ->

long getMicroSeconds()
{
#ifdef __WIN32__ || WIN32

    return GetTickCount();

#else

    timeval tv;
    timezone tz;
    gettimeofday(&tv,&tz);
    return tv.tv_usec;

#endif
}

und schon klappt es auch mit dem nachbarn!
alternativ kann man natuerlich crossplattform libraries verwenden

Bei Java nutzt man keine plattformspezifischen APIs. Man muss sich schon Mühe geben, damit ein Programm plattformabhängig wird.

Man kann mit C++ genauso plattformunabhaengige APIs verwenden, man muss aber nicht.

Ja mai, was muss man sich bei C++ für eine Mühe machen, seinen Code plattformunabhängig zu halten? Was ist, wenn jemand getTickCount() oder die Posix-Variante nicht kennt? Und bei den Bibliotheken, die es für versch. Betriebssysteme gibt, aht man auch so seine Probleme. Ich kann z.B.kein Qt mit dem icc kompilieren, weil in den Headern ständig so sachen wie typedef int bool; stehen. Das kompiliert der icc beispielsweise nicht.

volkard

Original erstellt von Doktor Prokt:
Was ist, wenn jemand getTickCount() oder die Posix-Variante nicht kennt?

und wenn die cross-platform-lib das nicht anbietet? dann ist er angeschmiert und muß googlen oder hier fragen.
ist bei java natürlich leichter. das, was java anbietet, sieht überall sehr ähnlich aus. natürlich ist die panik größer, wenn mal was nicht angeboten wird.
so hat halt alles seine vor- und nachteile.

Daniel E.

Original erstellt von Gregor:
Bei Java nutzt man keine plattformspezifischen APIs.

Ach? <ironie>Wie misst den so ein Java-System die Zeit ohne Uhr? Ich vergas: In Java haben wir ja per Definition eine Internetverbindung mit der wir, in Echtzeit, von der Sun-Seite die vergangene Zeit, in Planck-Zeit, seit der Erfindung Javas laden können. Oder hatten wir immer eine Uhr?</ironie>

Man muss sich schon Mühe geben, damit ein Programm plattformabhängig wird.

Jedes Programm hängt von einer Plattform ab. Siehe oben.

Original erstellt von Doktor Prokt:
Ich kann z.B.kein Qt mit dem icc kompilieren

QT ist IMHO auch ein schönes Beispiel wie C++ nicht aussehen sollte. Dann kann man ja gleich Java nehmen :).

PS: Mein Pascal-Compiler compilert meinen C-Code nicht. C kann nicht plattformunabhängig sein.

Ich möchte nur eines loswerden:
könnt ihr nicht mal damit aufhören euch wie in der Grundschule darüber zu streiten welches Matchbox-Auto das bessere ist???

Wer in Java programmieren will/ muss, soll das tun.

Wer hingegen C++ besser findet, ist ja auch keine Schande.

Nur darüber zu streiten was besser ist, ist einfach nur unsinnig.

Gregor

Mir kam es eigentlich mehr auf diesen anderen Fehler an, nicht das mit der Zeit:

Benchmark.cpp:38: use of 'less' is ambiguous;
Benchmark.cpp:12: first declared as 'int less(const void*, const void*)' here c:/c++/mingw/ include/c++/3.2/bits/stl_function.h:195: also declared as 'template<class _Tp> struct std::less' here

[ Dieser Beitrag wurde am 01.12.2002 um 17:32 Uhr von Gregor editiert. ]

Gregor

Original erstellt von Shade Of Mine:
**
Der code von kingruedi ist ein POSIX kompatibler code -> das haette er natuerlich besser machen koennen um windows auch mit einzubeziehen.
**

Ehrlich gesagt interessiert es mich garnicht, zu was der Code alles kompatibel ist. Das, worauf es mir ankam ist, dass erst das 4. Programm mit g++ kompilierbar war. Ganz schön schwach, wenn C++-Programme doch auf allen möglichen Compilern kompiliert werden sollen, um Plattformunabhängigkeit zu erreichen.

Gregor

Ach? <ironie>Wie misst den so ein Java-System die Zeit ohne Uhr? Ich vergas: In Java haben wir ja per Definition eine Internetverbindung mit der wir, in Echtzeit, von der Sun-Seite die vergangene Zeit, in Planck-Zeit, seit der Erfindung Javas laden können. Oder hatten wir immer eine Uhr?</ironie>

Nein! Das wird wohl mit nem Wrapper gelöst. Sowas, wie

long getMicroSeconds()
{
#ifdef __WIN32__ || WIN32

    return GetTickCount();

#else
   
    timeval tv;
    timezone tz;
    gettimeofday(&tv,&tz);
    return tv.tv_usec;

#endif
}

wohl. Allerdings vom Compiler bzw. von der JVM aus.

Jedes Programm hängt von einer Plattform ab. Siehe oben.

Nein. Das tut es nicht. Es kommt drauf an, wie abstrakt die Programmiersprache gehalten ist. Also wie stark diese von einer gegebenen Platform abstrahiert.

[ Dieser Beitrag wurde am 01.12.2002 um 19:00 Uhr von Gregor editiert. ]

Shade Of Mine

Original erstellt von Gregor:
[quote]Original erstellt von Shade Of Mine:
Ehrlich gesagt interessiert es mich garnicht, zu was der Code alles kompatibel ist. Das, worauf es mir ankam ist, dass erst das 4. Programm mit g++ kompilierbar war. Ganz schön schwach, wenn C++-Programme doch auf allen möglichen Compilern kompiliert werden sollen, um Plattformunabhängigkeit zu erreichen.

du musst mal von diesem Java ist das einzig wahre Trip runter kommen.
POSIX ist eine Standard. Wer sich nach diesem Standard richtet, kann seine Programme auf allen POSIX kompatiblen Systemen laufen lassen!

kingruedi hat mit less einen Fehler gemacht - das ist der Grund warum man using namespace std; nicht verwenden sollte! (less ist nähmlich im Standard schon definiert)

Wenn du keine solchen #ifdef konstrukte in C++ haben willst, nimmst du einfach eine Plattformunabhängige Library! (die versteckt das ganze vor dir, genau so wie deine VM)

was stoert dich an dem C++ konzept der PLattformunabhänigkeit? Es hat bis jetzt bestens funktioniert - und wird auch noch weiterhin funktionieren. Egal ob du es magst oder nicht, aber es ist und bleibt ein Ansatz der Plattformunabhänigkeit, genauso wie der Java Ansatz: Java als eine Plattform zu nehmen.

Gregor

Original erstellt von Shade Of Mine:
**du musst mal von diesem Java ist das einzig wahre Trip runter kommen.

...

was stoert dich an dem C++ konzept der PLattformunabhänigkeit? Es hat bis jetzt bestens funktioniert - und wird auch noch weiterhin funktionieren. Egal ob du es magst oder nicht, aber es ist und bleibt ein Ansatz der Plattformunabhänigkeit, genauso wie der Java Ansatz: Java als eine Plattform zu nehmen.**

Ich glaube, du machst es dir zu einfach! Ich bin nicht auf nem Java-Trip! :p Momentan bin ich dabei, ganz massiv C++ zu lernen. ...und zwar aus guten Gründen. C++ hat ne Menge Stärken. Zum Beispiel die Geschwindigkeit oder die Möglichkeit, systemnah programmieren zu können. IMHO ist Platformunabhängigkeit aber keine Stärke von C++. Da kommt es mir so vor, als ob hier einige andere ziemlich stark auf nem C++-Trip sind und sich die Sprache schöner reden als sie ist.

Gerard

Original erstellt von Gregor:
Da kommt es mir so vor, als ob hier einige andere ziemlich stark auf nem C++-Trip sind und sich die Sprache schöner reden als sie ist.

zum teil ja, aber du musst bedenken das Shade Of Mine kein durchschnitts Programmierer ist,

Shade Of Mine

Original erstellt von Gregor:
[QBIMHO ist Platformunabhängigkeit aber keine Stärke von C++[/QB]

Eine stärke wahrscheinlich nicht, da man schon ordentlich programmieren muss um Plattformunabhänig zu bleiben. Allerdings ist das möglich.

Der Ansatz ist nicht so komfortabel wie bei Java (es sei denn man macht es wie Java -> zB cygwin.dll ist eine POSIX Umgebung unter Windows, das ist wie die VM, die ist ja eine Java umgebung).

aber C++ ist dennoch Plattformunabhänig, sonst gäbe es ja wohl keine Crossplattformprogramme ala Mozilla, OpenOffice,...

Gregor

Es ist möglich. Das stelle ich garnicht in Frage. Die Frage ist aber doch, wieviel Aufwand dahinter steckt. Es ist eben nicht so, dass man sich ein Programm schreibt, was dann auf allen möglichen Platformen läuft, weil man ja überall Compiler hat. Man muss schon auf ne Menge Dinge achten und muss ne Menge Verrenkungen machen, damit das Programm auch auf vielen anderen Compilern kompilierbar ist.

So, wie viele hier die "Platformunabhängigkeit" von C++ darstellen, kriegt man den Eindruck, dass das ganz einfach wäre: Man schreibt sich einfach ein Programm und weil es ja überall Compiler gibt, ist das Programm platformunabhängig. Das ist so wohl meistens nicht der Fall.

...und das ist eigentlich auch der Unterschied zwischen Java und C++, auf den es mir hier ankommt. Bei Javaprogrammen muss man nunmal auf sehr wenige Dinge achten, damit das Programm platformunabhängig bleibt, bzw. damit der Ansatz der Platformunabhängigkeit, den man hier hat, funktioniert.

...und was den "Fehler" von Kingruedi betrifft:

Das ist IMHO kein Fehler von ihm. Auf seinem Compiler ist es wohl zugelassen und somit auch erlaubt. Es ist ein Fehler des Compilers, dass er das zuläßt.

Shade Of Mine

Original erstellt von Gregor:
Das ist IMHO kein Fehler von ihm. Auf seinem Compiler ist es wohl zugelassen und somit auch erlaubt. Es ist ein Fehler des Compilers, dass er das zuläßt.

Ich habe den standard gerade nicht bei der hand, aber IMHO IST es laut standard nicht erlaubt - weil es eben zu namenskonflikten kommt!

in java kannst du ja auch nicht einfach einer funktion den namen einer funktion aus der standard library geben, oder?

Gregor

Original erstellt von Shade Of Mine:
**
in java kannst du ja auch nicht einfach einer funktion den namen einer funktion aus der standard library geben, oder?**

Wenn es in Java zu Namenskonfikten kommt, dann meckert der Compiler. Ansonsten ist das in Java ja auch etwas ander gelöst. Es gibt ja keine Namespaces, sondern nur Packages, in denen Klassen stehen. Dadurch kommt es wohl insgesamt zu weniger Konflikten. Ich hatte zumindest erst an einer Stelle damit Probleme, als ich zwei Packages eingebunden habe, die beide eine Klasse mit gleichem Namen enthielten. Dann muss man halt genauer sagen, was man aus welchem Package haben will. Wenn man beide Klassen haben möchte, dann gibt man jeweils noch explizit den Packagenamen an.

...aber anscheinend weiß Kingruedis Compiler ja, was er machen soll, wenn er auf sowas stößt. Er erlaubt halt etwas mehr, als der Standard. ...und solche Dinge passieren doch auch, wenn man alles Standardkonform macht. Gibt es da z.B. nicht so eine Geschichte mit Templates, die laut Standard erlaubt ist, die viele Compiler aber nicht unterstützen?

Daniel E.

Original erstellt von Gregor:
Das wird wohl mit nem Wrapper gelöst.

Wie 'wrappt' man etwas das nicht existiert? Mit Java!
Die meisten Systeme geben dann irgendwas wie 'No clock found. Exiting.' von sich.

Gregor

Original erstellt von Daniel E.:
Wie 'wrappt' man etwas das nicht existiert? Mit Java!
Die meisten Systeme geben dann irgendwas wie 'No clock found. Exiting.' von sich.

Ich verstehe nicht, worauf du hinaus willst!

Daniel E.

Dass wrappen nichts hilft, wenn z.B. die Hardware nicht mitspielt (weil nicht vorhanden. Also hängt eben doch _jedes_ Programm von der Plattform (Hard- und Software) ab.

Mr. N

@Gregor: Stell dir einen ... eine Fernbedienung vor. Braucht die eine ms-genaue Uhr? Nö.