C++ vs. Java [Update]

[Gast]

Original erstellt von volkard:
[quote]Original erstellt von Doktor Prokt:
[qb]Wie schon gesagt wurde, für große Programme. Hinzu kommt, daß Java absolut plattformunabhängig ist

zum hundertstenmal: java IST eine plattform.[/QB][/QUOTE]

"ich hab so einen muskelkater" - "das heißt nicht muskelkater, sondern alphahydroxipropionsäuresepsis"

"ich nehme jetzt mein lindan und bekämpfe insekten" - "das heißt nicht lindan, sondern 1,2,3,4,5,6 hexacyclohexan"

Hier ist der Begriff doch uninteressant, bedeutend sind doch die Vorteile.

[volkard]

Original erstellt von Doktor Prokt:
[QB]"ich nehme jetzt mein lindan und bekämpfe insekten" - "das heißt nicht lindan, sondern 1,2,3,4,5,6 hexacyclohexan"

γ-1,2,3,4,5,6-Hexachlorcyclohexan, soviel zeit muß sein!
ich sag ja auch nicht zu wasserstoff einfach wasser.

[Gregor]

Original erstellt von volkard:
zum hundertstenmal: java IST eine plattform.

Java IST eine Programmiersprache! :p ...was man aus seinem Java-Code letztendlich macht, das bleibt jedem selbst überlassen. Es gibt auch Möglichlkeiten, daraus eine ausführbare exe-Datei zu erstellen.

Du sagst IMHO zum hundertstenmal das Falsche! :p

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

[100]

Ist eigentlich die java exe datei schneller als wenn man das mit dem java interpreter ausführt? wird das also richtig dabei compiliert. weil ich habe schonmal so einen compiler für perl gesehen. der machte einfach den interpreter und die module (dll) zusammen in ein exe packet. beim ausführen hat sich das ganze dann entpackt und einfach wieder den interpreter ausgeführt. ist das beim java compiler auch so, oder wird da richtig compiliert?

[volkard]

Original erstellt von Gregor:
**Java IST eine Programmiersprache! :p ...was man aus seinem Java-Code letztendlich macht, das bleibt jedem selbst überlassen. Es gibt auch Möglichlkeiten, daraus eine ausführbare exe-Datei zu erstellen.
Du sagst IMHO zum hundertstenmal das Falsche! :p
**

vielleicht glaubstes dem ja:
http://www.research.att.com/~bs/bs_faq.html#Java

Du sagtes sowas wie

Hinzu kommt, daß Java absolut plattformunabhängig ist, wenn für versch. Plattformen die VM implementiert ist. So sieht z.B. ein Klickibunti Swingprogramm unter Windows haargenau 1:1 exakt so aus wie unter Linux, weil die Komponenten von Java auch noch selber gezeichnet werden. Außerdem gefällt mir persönlich bei Java, daß man wirklcih alles unter einem Hut hat. Fensterbibliothek, Threads, Netzwerkprogrammierung, alles einfach. Man muss keine externen Libs nehmen.

betrachte das mal unter der idee, daß die "absolute plattformunabhängigkeit" daher kommt, daß programme, die in der sprache java geschrieben wurden auf der plattform java laufen sollen. nur dann machts sinn. alles andere würde mir übrigens gestatten, so frei zu sein, die selbe "absolute plattformunabhängigkeit" für c++ zu postulieren, denn keiner hindert einen daran, ne vm und ne kleine lib für c++ zu bauen und die vm auf alle möglichen architekturen zu portieren. dann hättest du nur ein windargument erzeugt.

[Jester]

Diese "absolute" Plattformunabhängigkeit würde ich dann aber doch gerne mal sehen...

Wie kommt es dann, daß unter Linux die Prioritäten meiner Threads nicht beachtet werden. Unter Windows aber schon (so wie man's eigentlich erwarten könnte).
Dafür weckt Windows einen Thread, der mit sleep schlafen gelegt wurde erst wieder auf, wenn er wirklich dran ist. Linux gibt ihm Rechenzeit sobald wie möglich, also egal, wie viele Threads warten, der aufgewachte kriegt sofort Rechenzeit.

Fazit: Exaktes Timing unter Windows mit Prioritäten, exaktes Timing unter Linux mit sleep, wenn ich beide haben will muß ichs über Prioritäten und sleep lösen. Ist das nicht umständlich?
Deswegen war es zum Beispiel (mir) nicht möglich einen Thread-Dispatcher in Java zu schreiben, der ohne Mitarbeit der Threads funktionierte.

Wo ist sie denn nun, diese Plattformunabhängigkeit? (ich mein natürlich die "absolute")

[ Dieser Beitrag wurde am 01.12.2002 um 12:31 Uhr von Jester editiert. ]

[Gregor]

Original erstellt von volkard:
**
vielleicht glaubstes dem ja:
http://www.research.att.com/~bs/bs_faq.html#Java
**

Da steht :

Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation.

Gehen wir mal durch :

• Single Corporation : Unsinn. Es gibt nicht nur ne JVM von Sun. Es gibt z.B. auch JVMs von IBM oder von BEA. Zudem werden auch JVMs unter der GPL entwickelt. Z.B. Kaffe.
• "you can write programs for Windows/Intel or Java/JVM" : Unsinn. Normalerweise schreibt man Code für die JVM, weil das klug ist. Der Code läßt sich aber auch für andere Plattformen kompilieren. AFAIK kann man das z.B. mit dem GJC machen, oder? Außerdem gibt es Programme, wie "Excelsior Jet". Man kann sich aus Java-Code also auch ausführbare Dateien für andere Plattformen erzeugen. ...und dafür muss man NICHTS portieren, wie man es aus C++ kennt.

Java ist platformunabhängig. Allerdings wird aus Java-Code meistens Code für eine virtuelle Platform erzeugt. Die JVM. Das muss man aber nicht machen.

BTW : C++ ist nicht platformunabhängig, weil es keinen Compiler gibt, der C++-Code für die JVM kompiliert. :p Schonmal eine Platform, die häufig genutzt wird, auf der man mit C++ verloren hat. :p

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

[Gregor]

Original erstellt von volkard:
alles andere würde mir übrigens gestatten, so frei zu sein, die selbe "absolute plattformunabhängigkeit" für c++ zu postulieren

Tust du doch sowieso. Ich bin mir sicher, dass ich hier nen Thread finde, wenn ich suchen würde, in dem du sagst, dass C++ platformunabhängig ist, Java aber nicht.

Auch das ist natürlich Unsinn. In C++ sind ja sogar schon die Größen der primitiven Datentypen plattformabhängig. In Java nicht.

[Shade Of Mine]

Original erstellt von Gregor:
Auch das ist natürlich Unsinn. In C++ sind ja sogar schon die Größen der primitiven Datentypen plattformabhängig. In Java nicht.

Alle datentypen haben eine mindestgroesse!
Wenn eine Plattform diesen Datentyp groesser macht, um effektiver arbeiten zu koennen, dann darf sie das!

wenn ich also nicht portieren will, dann nehme ich einfach die plattformspezifische groesse -> ansonsten verlasse ich mich nicht darauf.

dank typedefs kann man auch ueberall die selben datentypengroessen haben!

"you can write programs for Windows/Intel or Java/JVM" : Unsinn. Normalerweise schreibt man Code für die JVM, weil das klug ist.

Ob du das fuer klug haeltst oder nicht steht doch nicht zur debatte.
Java bzw. die JVM ist eine Plattform - daruber braucht man garnicht zu diskutieren!

wann wirst du endlich begreifen, dass C++ einen anderen Ansatz der Plattformunabhaengigkeit hat?
Java verlangt eine VM
C++ einen Compiler

BTW : C++ ist nicht platformunabhängig, weil es keinen Compiler gibt, der C++-Code für die JVM kompiliert. Schonmal eine Platform, die häufig genutzt wird, auf der man mit C++ verloren hat.

Was meinst du: gibt es mehr Plattformen mit einem C++ Compiler oder mit einer Java VM?

[Gregor]

Original erstellt von Shade Of Mine:
**
Was meinst du: gibt es mehr Plattformen mit einem C++ Compiler oder mit einer Java VM?**

Für C++ gibt es so gut, wie garkeinen standardkonformen Compiler. Wir haben ja letzt schon gesehen, dass es anscheinend Probleme macht, Programme zu schreiben, die auf mehreren Compilern kompilieren. In C++ gibt es also noch nichtmal Compilerunabhängigkeit. Wie soll der C++-Ansatz der Platformunabhängigkeit dann überhaupt funktionieren?

[Shade Of Mine]

Original erstellt von Gregor:
Für C++ gibt es so gut, wie garkeinen standardkonformen Compiler. Wir haben ja letzt schon gesehen, dass es anscheinend Probleme macht, Programme zu schreiben, die auf mehreren Compilern kompilieren. In C++ gibt es also noch nichtmal Compilerunabhängigkeit. Wie soll der C++-Ansatz der Platformunabhängigkeit dann überhaupt funktionieren?

Also mein aktuelles Projekt laeuft sowohl unter Unix mit gcc und icc sowie unter windows mit VC++ 6 und 7, sowie Borland C++ Compiler 5.5 (somit wahrscheinlich auch Borland C++ Builder 5 und 6) sowie gcc (mingw) und digital mars c++ compiler.

andere compiler habe ich nicht zum testen verwendet da ich sie nicht besitze - aber wie du siehst, scheint das ja ganz gut zu funktionieren!

Wenn ich dann noch threads und sockets einbauen werde, dann werde ich cross-plattform bibliotheken verwenden und somit auch Plattformunabhaengig (diesmal im Sinne von Java) zu sein.

Im Sinne von Java deswegen - weil ich auf meiner ziel Plattformeinfach eine implementierung der Runtime Library erwarte.

wenn man nicht aufpasst, dann kann es natuerlich schwer sein ein Programm zu portieren, aber ich denke, man kann in Java genauso sich auf eine Plattform festlegen und dann gezielt diese API nutzen...

ich kenn mich mit Java nicht aus, deshalb kann ich keine gegen Argumente bringen, aber deine contra C++ Argumente scheinen mir auch nicht gerade sehr stichhaltig!

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

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

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

[Gast]

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.

[??? (bin vergesslich)]

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.