c++ vs. java... was hat zukunft
-
CStoll schrieb:
@pale dog: Was ich so beobachte, bist du recht gut in C unterwegs. Wie kommt es dann, daß du so gegen C++ stehst (ist doch viel näher an C als Java)?
ja, schon, aber C++ ist trotzdem sehr weit entfernt von C.
die sprache C++ wirkt auf mich ziemlich lieblos zusammengestückelt, so wie ein experimenteller versuch, C aufzumotzen, aber ohne irgendwann weiterzumachen.
...und die user haben ständig haarsträubende probleme damit (siehste ja hier im C++ forum z.b. 'delete' oder 'delete[]'?, muss ich einen copy-constructor schreiben?, hilfe, mein default-zuweisungsoperator geht nicht mehr!)
C-ähnliche, objektorientierte sprachen wie etwa Objective-C und D scheinen mir da wesentlich durchdachter zu sein...
-
Ob nun "leider" oder "zum Glück" irgendwelche Zustände bestehen oder nicht lass ich mal dahingestellt...
Wenn man C++ und Java miteinander vergleicht sind es zunächst mal Äpfel und Birnen. Zu "Java" gehört nicht nur die Sprache sondern auch die Platform, also eine umfangreiche Laufzeitbibliothek, ggf. sogar mit Applikationsservern für EJB und Webservices.
Desweiteren ist die VM selbst schon eine Art minimaler Applikationsserver, da sie zumindest einen Objektdienst (Garbage-Collection) bereitstellt.Wenn man einen Vergleich anstellen will sollte zunächst die Kandidaten hinsichtlich der Fertigungstiefe geeignet "normieren", also hier ein Paket für C++ mit
- Basis-Bibliothek (STL + Threading + Netzwerk + ...)
- GUI-Framwork/Bibliothek
- ...betrachten. Besonders beim ersten Punkt wird klar dass man mit C++ oft Anleihen bei einer anderen Sprache, nämlich "C" macht (Win32, pthreads, sockets - alles "C" APIs).
Zugleich führt dies für mich zum Hauptunterschied zwischen den beiden "Sprachen" (den Begriff cum grano salis verwandt; wie geschildert)
- Mit C++ muss man eine Infrastruktur selbst definieren und schreiben oder einbinden
- Java bringt eine Infrastruktur mit, die man aber ggf gar nicht braucht.Es wird im Zusammenhang mit Java oft auf zwei Punkte verwiesen
- Einfacheres Erstellen von "Business"-Anwendungen (was immer das sein mag)
- Platformunabhängigkeit (dass auch eine VM nur mit dem Wasser kochen kann das ihr das System anbietet ist ein anderes Thema denke ich)Beide Punkte könnten zutreffen; nur macht die Kombination oft wenig Sinn.
Wenn man die Mannkosten für eine "Business"-Anwendung mit den Kosten für einen zusätzlichen Server vergleicht, kann man letzteren oft einfach als Messfehler sehen.
Gehen wir bitte von einer 3/4-Tier (DB,App-Server,Web-Server,Browser) Inter/Intranet-Webanwendung aus.
Man sagt 100 Use-Cases (und die kommen ganz schnell mal zusammen) entsprächen 10 Bearbeiter-Jahren
=> 168 Std/Monat * 12 Monate * 10 * EURO 50/Std => ca. 1 MEuro
(Stundensatz : "Billiger interner MA incl Sozialabgaben und Gemeinkosten")
Daneben sind 20 - 30 KEuro für einen eigenen Projektserver eher ein Messfehler.
Java aus Gründen der Portabilität zu bevorzugen macht somit nur sehr eingeschränkt wirklich Sinn. Eigentlich zahlt man oft Laufzeitkosten an die VM für nichts ausser Garbage-Colletion. Soweit ich weiss wird genau dessen Funktionalitätät aber von Javarianern selbst oft bemängelt.
Bleibt das Argument "leichtere" oder "schnellere" Entwicklung:
- Wenn man mit C++ direkt auf OS-C-APIs aufsetzt und sich so erstaml eine Infrastruktur zusammenbastelt dauert's natürlich länger und wird teurer da man Systemprogrammierer braucht.
- "Ich kann Java" => "Der Mann ist bestimmt im EJB-Projekt verwendbar" ist geanuso stichhaltig wie "Ich kann VC++" => "Der Mann ist bestimmt im COM/ATL Projekt verwendbar". Bei Java wird eine Feinheit gerne verschwiegen - nämlich dass wohl niemnd mehr alle Java-Bibliotheken beherrscht.
Man wird sich höchstens schnell genug in die spezifischen Anforderungen einarbeiten können; also etwa so schnell wie ein C++-Programmierer in eine externe C++-Bibliothek die verwandt werden soll.
Zum Schluss nachmal etwas zum Thema "Java ist komplett objektorientiert", C++ nicht" => "Who cares? Who pays for this?"
Zwar gibt's in Java keine freien Funktionen, aber nichts hindert einen Entwickler daran in seinem "main" Objekt mit "schönen" langen prozeduralen Spaghettis zu häkeln; geanusowenig wie man unter C++ gezwungen ist ausser "main" eine einzige freie Funktion zu schreiben; zumindest wenn API-Aufrufe in irgendweinem C++-Framework / einer Bibliothek versteckt sind.
Solche Klimmzüge wie "class Class" oder auch "main()" als Klassenmethode lassen Java vielleicht puristisch erscheinen; Mehrwert hingegen produziert das per se noch nicht!
Also lasst uns doch bitte mal eine komplette Umgebung für C++ definieren (MFC,Boost,.NET,ODBC,... ) und dann über die Unterschiede von komplett instrumentalisierten C++ Projekten und Java Projekten sprechen.
Könnte mir denken dass beides in der Entwicklung aufs gleiche hinauslaüft aber der C++-Code schneller ist.
Grüsse
*this
-
- Mit C++ muss man eine Infrastruktur selbst definieren und schreiben oder einbinden
- Java bringt eine Infrastruktur mit, die man aber ggf gar nicht braucht.Das schlimme ist, das immer die Runtime-Library von Java mit der von Stdlib von C++ verglichen wird. Aber hier hinkt der Vergleich absolut. Ich hatte das ganze hier schon mal für das Thema "Keine GUI in der C++ Stdlib" erklärt. Das ganze lässt sich auch auf alle anderen Library-Bereiche beziehen. Die Stdlib von C++ unterliegt einer ISO-Norm, die Java Runtime nicht.
Ich kann mir aber für C++ sehr wohl eine Runtime aufbauen. Wie? In dem ich diese auf dem Zielrechner installiere. Genauso wie ich das mit der Java-Runtime auch machen muß. Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse und Chancen.
Im optimalen Fall, habe benutze ich als Runtime das native OS, dann brauch ich nur die EXE kopieren. Und die native Runtime a la Windows XP oder Vista ist schon seeeeeeeeeeehr mächtig!
-
Artchi schrieb:
Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse.
Dem schliess ich mich an; eine kleine Geschichte dazu:
Unlängst wollte ich mir einen kleinen Client für einen XML-RPC Server bauen.
=> Perl : v.h.
=> Python : v.h.
=> C++ : Google / Download / Compile / Install / Link / Run=> Java : SUN warf mir ein komplettes Webservice SDK entgegen; ca 500 MB + 500 MB für das Server-Environment. Jetzt erzeugt nach jedem Reboot irgendein Java-Update-Tool eine Exception.
Mag sein dass ich etwas falsch gemacht habe; ich hab nach "Java XML RPC" googled; bin bei SUN im Enterprise SDK gelandet und hab imo den ersten passenden Download genutzt.
=>
Müsste jetzt also ein Client > 500 MB Zusatzsoftware mitinstallieren? Von der Implementierung des Clients in Java habe ich Abstand genommen; für solchen Overhead habe ich einfach keine Zeit.
Grüsse
*this
-
Gregor schrieb:
darthdespotism schrieb:
- Java ist, und bleibt darauf ausgelegt interpretiert zu werden. Selbst wenn man Java in Maschienencode übersetzt, was ja möglich ist, dürfte es einem _guten_ C++ - Programm an performance hinterherhinken
Soweit die (hoffentlich soweit korrekten) Tatsachen.
In den meisten Fällen wird das stimmen, auch wenn man mit irgendwelchen Gedankenspielchen Fälle konstruieren kann, in denen Java von der Performance her theoretisch im Vorteil sein sollte. Du formulierst das allerdings als eine ziemlich absolute Aussage mit großer Dramatik. Diese Relevanz wird das in den meisten Fällen nicht haben. Der Unterschied ist IMHO nicht sooo groß. Hast Du diesbezüglich quantitative Vorstellungen? Oder hast Du mehr eine allgemeine Assoziation "C++ -> schnell" und "Java -> lahm"? Wenn man sich genauer klar gemacht hat, wie groß der Unterschied eigentlich ist, muss man sich auch überlegen, was einem der Performancevorteil wert ist.
Vielleicht hätti ich noch klarer sagen können
Mit C++ ist es möglich Programme zu schreiben, die schneller laufen als gleichermaßen optimierte Java-Programme. Das kann in manchen Fällen ausschlaggebend sein.
Das (nach der Aussage meines Informatiklehrers) aktuelle Java konnte ich neulich mit einem nahezu Codegleichen C-Programm testen (beziehungsweise eine Funktion), die ich mit dem MinGW übersetzt hatte. Dabei ist die C-Version etwa 100% schneller. Allerdings mag hier auch einiges daher kommen, dass die gesammte Funktion nur einige Sekunden läuft und bei längeren Programmen die VM schon läuft.
-
Also eine Java Runtime zu installieren ist nicht schlimm. Vorausgesetzt der User hat die Möglichkeit dazu (Adminrechte).
Bei deinem RPC-Server scheint es wohl eher ein Bug/Inkompatibilität zu sein... wie es ihn in jedem anderen Programm in jeder Sprache geben kann. Aber 500 MB für einen Server ist normal. Ist bei unseren IBM-Webspheres auch nicht anders. Mit dem SDK kommen wir auf 3 CDs.
Aber ist das nicht Offtopic??? Deshalb kein weiterer Beitrag dazu von mir.
-
pale dog schrieb:
Simon2 schrieb:
Kann vielleicht auch eher daran liegen, dass hier immer frustrierte Javafans auftauchen, die nicht verkraften, dass ihre Sprache immer noch nicht "den großen Bruder C++ verdrängt hat"
das glaube ich nicht.
so ein verdrängungsprozess läuft in etwa ab wie darwins 'natürliche auslese'
nach dem motto 'das bessere ist des guten feind' werden programmiersprachen mit dem höheren gebrauchswert andere zurückdrängen.
daran können alle flamewar-gestählten Java- und C++ freunde dieser welt nichts ändern...
Darwin sagte nicht dass der besser gewinnt sondern der besser angepasste. Und das dürfte in diesem Zusammenhang nicht unerheblich sein
-
[opinion]
quick 'n dirty, lahm, billig => Java
elegant, fast as hell, teuer => C++
[/opinion]Verdammte Flamewars...
greetz, Swordfish
-
Gast++ schrieb:
Artchi schrieb:
Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse.
Dem schliess ich mich an; eine kleine Geschichte dazu:
Unlängst wollte ich mir einen kleinen Client für einen XML-RPC Server bauen.
=> Perl : v.h.
=> Python : v.h.
=> C++ : Google / Download / Compile / Install / Link / Run=> Java : SUN warf mir ein komplettes Webservice SDK entgegen; ca 500 MB + 500 MB für das Server-Environment. Jetzt erzeugt nach jedem Reboot irgendein Java-Update-Tool eine Exception.
Mag sein dass ich etwas falsch gemacht habe; ich hab nach "Java XML RPC" googled; bin bei SUN im Enterprise SDK gelandet und hab imo den ersten passenden Download genutzt.
=>
Müsste jetzt also ein Client > 500 MB Zusatzsoftware mitinstallieren? Von der Implementierung des Clients in Java habe ich Abstand genommen; für solchen Overhead habe ich einfach keine Zeit.
Grüsse
*this
sorry kann ich nich nachvollziehen, bei meinem google liefert "java xml rpc" als erstes suchergebnis die apache xmlrpc library und ansonsten hauptsächlich javadoc seiten - und keine sun j2ee seite...
desweiteren, seit wann braucht man für einen *client* eine serversoftware? erst reicht kein "enterprise sdk". dass man für einen *client* keinen *server* braucht sollte jemandem der weiß wie man nen c++ compiler installiert eigentlich klar sein
google ich stattdessen nach "jdk download" komme ich auch auf die richtige webseite
um mir mein jdk runterzuladen (56 mb). und wenn ich mir dann noch immer arbeit ersparen will kann ich mir ja auch noch was google bei "java xml rpc" als erstes ergebnis ausspuckt runterladen, apache xmlrpc (oder ich benutze eine andere api) 
-
Artchi schrieb:
Also eine Java Runtime zu installieren ist nicht schlimm. Vorausgesetzt der User hat die Möglichkeit dazu (Adminrechte).
Bei deinem RPC-Server scheint es wohl eher ein Bug/Inkompatibilität zu sein... wie es ihn in jedem anderen Programm in jeder Sprache geben kann. Aber 500 MB für einen Server ist normal. Ist bei unseren IBM-Webspheres auch nicht anders. Mit dem SDK kommen wir auf 3 CDs.
Aber ist das nicht Offtopic??? Deshalb kein weiterer Beitrag dazu von mir.
Topic ist hier doch der Vergleich von C++ und Java.
Offtopic ist nur Deine etwas oberflächliche Systemberatung. Die war auch gar nicht erbeten; trotzdem Danke für Deine Bemühungen!
Grüsse
*this
-
kann besser googlen als d schrieb:
sorry kann ich nich nachvollziehen,
Richtig. Du kannst es nicht nachvollziehen. Passiert öfter, gell?
kann besser googlen als d schrieb:
bei meinem google liefert "java xml rpc" als erstes suchergebnis die apache xmlrpc library und ansonsten hauptsächlich javadoc seiten - und keine sun j2ee seite...
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil; wer darüber hinaus noch mitdenkt umso mehr...
Grüsse
*this
-
Gast++ schrieb:
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil
anscheined bist du der, der nicht lesen kann:
'apache link' schrieb:
Apache XML-RPC is a Java implementation of XML-RPC,
wer darüber hinaus noch mitdenkt umso mehr...
anscheinend hast du ja sehr viel mitgedacht, als du dir für einen xmlrpc client einen j2ee application server runtergeladen hast...
Grüsse
*this
grüsse,
der gleiche von oben mit anderem nick
-
[quote="lol geil"]
Gast++ schrieb:
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil
anscheined bist du der, der nicht lesen kann:
Apache XML-RPC is a Java implementation of XML-RPC,desweiteren, seit wann braucht man für einen *client* eine serversoftware? erst reicht kein "enterprise sdk". dass man für einen *client* keinen *server* braucht sollte jemandem der weiß wie man nen c++ compiler installiert eigentlich klar sein
Deshalb soll ich mir also Apache-Pakete instalieren? Weil ich eine Client-Lösung brauche? Interessanter Ansatz!
Bist Du sicher dass Du weisst was der Apache eigentlich ist? Oder XML-RPC?
Hast Du mal die Installationsroutinen von SUN, die Dich ständig auf einen fehlenden Server hinweisen, getestet bevor Dich hier zu Wort gemeldet hast ?=> Schwafel mich bitte nicht voll mit Deinem Halbwissen!
Grüsse
*this
-
Gast++ schrieb:
Bist Du sicher das Du weisst was der Apache eigentlich ist?
Der unreg meint eine Lib von der Apache Software Foundation, kein Modul für deren HTTP Server...
-
finix schrieb:
Gast++ schrieb:
Bist Du sicher das Du weisst was der Apache eigentlich ist?
Der unreg meint eine Lib von der Apache Software Foundation, kein Modul für deren HTTP Server...
...und bei weiteren unklarheiten: http://www-128.ibm.com/developerworks/xml/library/j-xmlrpc.html
http://www.xmlrpc.com/directory/1568/implementations
-
[quote="Gast++"]
lol geil schrieb:
Gast++ schrieb:
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil
anscheined bist du der, der nicht lesen kann:
Apache XML-RPC is a Java implementation of XML-RPC,desweiteren, seit wann braucht man für einen *client* eine serversoftware? erst reicht kein "enterprise sdk". dass man für einen *client* keinen *server* braucht sollte jemandem der weiß wie man nen c++ compiler installiert eigentlich klar sein
Deshalb soll ich mir also Apache-Pakete instalieren? Weil ich eine Client-Lösung brauche? Interessanter Ansatz!
Bist Du sicher dass Du weisst was der Apache eigentlich ist? Oder XML-RPC?
wow, du hast du ja heftig informiert. mit jedem post nehme ich dir deinen google-versuch weniger ab
Hast Du mal die Installationsroutinen von SUN, die Dich ständig auf einen fehlenden Server hinweisen, getestet bevor Dich hier zu Wort gemeldet hast ?
nein ich hab keine "installationsroutinen getestet", ich hab auch nie bei einer softwareinstallation von sun gesehen dass ein server benötigt wurde. bei welchem softwarepaket kam denn die meldung? beim jdk jedenfalls nicht - und mehr als das brauchst du für xml-rpc nicht
=> Schwafel mich bitte nicht voll mit Deinem Halbwissen!
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
-
lisp, haskell, ocaml, erlang, smalltalk, objective c, D
-
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
der gleiche wie oben schrieb:
wow, du hast du ja heftig informiert. mit jedem post nehme ich dir deinen google-versuch weniger ab
..und versteigst Dich dennonch zu solchem Quatsch.
Sei's drum;
@all:
was haben wir von unreg gelernt?- es gibt ein Paket von Apache.org das mir den Leistungsumfang wahrscheinlich geboten hätte.
=> Man bruacht also Third-Party-Tools offenbar auch unter Java.
Wenn ich das Problem mit C++ lösen will muss ich eine Bibliothek installieren; lös ich's mit Java muss ich dergleichen tun. Eigentlich dachte ich immer SUN sei für Java-Lösungen zumindest eine zentrale Anlaufstelle; auch das hat sich nach dem Vorhergehenden ja relativiert.
Welchen Unterschied macht das jetzt - abgesehen davon dass ich etwas was sich "Apache-irgenwas" nennt nieamls bei (Client-)Platformverantworlichen durchsetzen könnte ?
Grüsse
*this
-
Gast++ schrieb:
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
meister, wenn du nicht sagst *was* du von sun installiert hast, kann ich dir nicht sagen ob ich es auch installiert hab. logisch nich?
ich hab jedenfalls die glassfish installiert, wo so eine meldung nicht kam (hätte auch wenig sinn gemacht beim glassfish)..und versteigst Dich dennonch zu solchem Quatsch.
kappier ich nich aber egal jetz
=> Man bruacht also Third-Party-Tools offenbar auch unter Java.
du kannst einen xml-rpc aufruf sowohl unter java als auch unter c++ mit den standardmittel durchführen, natürlich geht es mit externen libraries um einen großen faktor einfacher
Eigentlich dachte ich immer SUN sei für Java-Lösungen zumindest eine zentrale Anlaufstelle; auch das hat sich nach dem Vorhergehenden ja relativiert.
von sun gibt es auch einen xmlrpc stack, der aber natürlich nicht in der standard edition mit enthalten ist mangels nachfrage, sondern nur im enterprise stack. du kansnt die natürlich auch separat benutzen, siehe: https://jax-ws.dev.java.net/ und https://jax-rpc.dev.java.net/
was haben wir von unreg gelernt?
dass gast++ gerne mal einfach so losbrüllt
-
der gleiche schrieb:
Gast++ schrieb:
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
meister, wenn du nicht sagst *was* du von sun installiert hast.
So langsam hast Du's, glaube ich, begriffen! Du hast die ganze Zeit über ein Paket schwadroniert das Du gar nicht kennst.
was haben wir von unreg gelernt?
dass gast++ gerne mal einfach so losbrüllt
Das passiert genau dann wenn jemand einfach mal so in's Blaue hineinlabert wie Du.
von sun gibt es auch einen xmlrpc stack, der aber natürlich standard edition mit enthalten ist mangels nachfrage, sondern nur im enterprise stack.
Richtig. Also in genau dem Paket das für die Entwicklung eines simplen XML-RPC Clients völlig überdimensioniert ist. Q.E.D.
Womit wir dann wieder am Anfang wären...
Grüsse
*this
