c++ vs. java... was hat zukunft
-
CStoll schrieb:
Ich muß mir eine eigene Methode schreiben und einsetzen, wenn ich mit dem Default-Verhalten des Zuweisungsoperator nicht einverstanden bin.
mit dem defaultverhalten des zuweisungsoperators hat das nichts zu tun. der ist zum 'zuweisen' da, und nicht um objektkopien zu erzeugen
CStoll schrieb:
Wo bitteschön unterscheidet sich das von C++
für flache objektkopien hat java die 'Object.clone()' funktion. die ist aber meistens nicht ausreichend, weil viele objekte selber andere objekte haben und die wiederum weitere objekte usw.
in Java kann man diese ganze objekthirarchie in einen 'ObjectOutputStream' schieben (im speicher) und das neue objekt einschliesslich aller zugehörigen objektkopien dann aus dem 'ObjectInputStream' herausholen. das funzt immer gleich, völlig egal wie so'n objekt intern aufgebaut ist.
C++ hat sowas ja nicht. in C++ muss man jedem objekt seine spezialisierte copy-funktion verpassen, wenn man ähnliches erreichen will...
-
pale dog schrieb:
CStoll schrieb:
Ich muß mir eine eigene Methode schreiben und einsetzen, wenn ich mit dem Default-Verhalten des Zuweisungsoperator nicht einverstanden bin.
mit dem defaultverhalten des zuweisungsoperators hat das nichts zu tun. der ist zum 'zuweisen' da, und nicht um objektkopien zu erzeugen
Und da sieht man mal wieder die unterschiedlichen Sichtweisen in C++ und Java. C++ arbeitet mit Objekten - und da bewirkt eine "Zuweisung" eine Objektkopie; Java arbeitet mit Referenzen (und nichtmal das konsequent) und benötigt eine eigene clone()-Methode zum Erzeugen von Kopien (letztere dürfte wohl am ehesten C++'s op= entsprechen).
CStoll schrieb:
Wo bitteschön unterscheidet sich das von C++
für flache objektkopien hat java die 'Object.clone()' funktion. die ist aber meistens nicht ausreichend, weil viele objekte selber andere objekte haben und die wiederum weitere objekte usw.
in Java kann man diese ganze objekthirarchie in einen 'ObjectOutputStream' schieben (im speicher) und das neue objekt einschliesslich aller zugehörigen objektkopien dann aus dem 'ObjectInputStream' herausholen. das funzt immer gleich, völlig egal wie so'n objekt intern aufgebaut ist.
C++ hat sowas ja nicht. in C++ muss man jedem objekt seine spezialisierte copy-funktion verpassen, wenn man ähnliches erreichen will...
Sag blos, ich kann jedes Objekt ohne Vorbereitungen durch so einen ObjektStream jagen, um es zu kopieren. Der Link, den du dort oben gegeben hast, sagt da etwas anderes:
Unfortunately, this approach has some problems, too:
[list=1][]It will only work when the object being copied, as well as all of the other objects references directly or indirectly by the object, are serializable. (In other words, they must implement java.io.Serializable.) Fortunately it is often sufficient to simply declare that a given class implements java.io.Serializable and let Java’s default serialization mechanisms do their thing.
[]Java Object Serialization is slow, and using it to make a deep copy requires both serializing and deserializing. There are ways to speed it up (e.g., by pre-computing serial version ids and defining custom readObject() and writeObject() methods), but this will usually be the primary bottleneck.
[*]The byte array stream implementations included in the java.io package are designed to be general enough to perform reasonable well for data of different sizes and to be safe to use in a multi-threaded environment. These characteristics, however, slow down ByteArrayOutputStream and (to a lesser extent) ByteArrayInputStream.
The first two of these problems cannot be addressed in a general way. We can, however, use alternative implementations of ByteArrayOutputStream and ByteArrayInputStream that makes three simple optimizations:Wenn ich nichts komplett missverstehe, mußt du sogar zwei Methoden schreiben (im Ernstfall sogar für jede Klasse, die du als Member nutzen willst), um eine tiefe Kopie zu bewerkstelligen - in C++ reicht dazu ein vernünftiger Copy-Ctor.
-
CStoll schrieb:
Sag blos, ich kann jedes Objekt ohne Vorbereitungen durch so einen ObjektStream jagen, um es zu kopieren. Der Link, den du dort oben gegeben hast, sagt da etwas anderes:
normalerweise reicht ein 'implements Serializable' im kopf der klassen, die man 'klonen' will, das wirkt sich auch auf unterklassen aus.
wenn irgendwelche feinheiten gebraucht werden, kann man's noch erweitern, indem man 'readObject' und 'writeObject' überschreibt. im normalfall braucht man's aber nicht.
guckst du: http://java.sun.com/developer/technicalArticles/Programming/serialization/
-
Java wurde anfänglich als ein "besseres" C++ verkauft. Der Gedanke war imemr irgendwie: Wir nehmen die komplizierten sachen aus C++ raus und vereinfachen das Sprachkonzept. Diese Vereinfachung wurde aber stark dadurch erreicht, daß die Programmierer in ihren Möglichkeiten (im Vergleich zu C++) drastisch eingeschränkt wurden. Je nach Projekt kann dies beides sein: Fluch oder Segen...
Liest man vor allem ältere Java-Bücher, dann lesen die sich nicht von ungefähr meistens wie: Java ist besser als C++ weil es eine eingebaute GC hat, usw.
dabei ist das doch quatsch. C++ kann ALLES was Java kann (naja, und vieles mehr halt). Nur das man als Programmierer zugegebeneerweise mehr Arbeit leisten muß. UND mehr Wissen haben muß (letzteres trifft aber vor allem auf viele möchtegern-progger einfach nciht zu),
C++ und GC z.B. stehen nicht im Widerspruch, nur weil die GC nicht in die Sprache selbst eingebaut ist (wo sie imho auch ueberhaupt nicht hingehört). C++ dagegen öffnet mir die freie Wahl wie ich meinen Speicher verwalte, ob nu mit GC oder nicht. Aber auch mit welcher GC, und wie genau die funktioniert... Bei Java dagegen kann ich ncihtmal sagen welche GC denn zumm Einsatz kommt weil dies von der Zielplattform abhängt... Für triviale Projekte mag dies ja ok sein, aber wenn die Speicehrverwaltung Performancekritisch wird hätte ich schon gerne etwas mehr Kontrolle darüber als in Java...
Beide Sprachen haben ihre Daseinsberechtigung, wobei C# durchaus eher Java das Wasser abgraben wird als C++, weil C# und Java eher auf die gleichen Zielgruppen von Anwendungsentwicklern ausgerichtet sind während C++ eher im Bereich der reinen Systementwicklung nach wie vor Puntken kann. Und wenn man sich erstmal eingehender mit C# auseinandergesetzt hat und dessen Stärken erkennt bleibt für Java als einzige daseinsberechtigung die fehlende Kompatibilität *nix basierter Systeme zu C#... (Btw, man kann ganze Webapplikationen easy in C# schreiben unter dem ASP...) Gerade im Bereich der Anwendungsentwicklung kann die Kombination C# und .Net die Entwickler enorm entlasten, wodurch Projekte schlicht schneller fertig werden und auch besser laufen. Ok, man verkauft im gegenzug seine Seele an MS, aber auch daran kann man sich gewöhnen.
Wenn es wirklihc um Zukunft geht, glaube ich eher das C# auf dem Vormarsch ist und dabei vor allem vom Java-Lager nimmt, weil gerade C# und Java eher auf die gleiche Zielgruppe von Entwicklern ausgerichtet ist (Anwendungsentwicklung), C++ wird sich zwar konsolidieren, aber in den Bereichen der Systementwicklung noch lange Zeit seine Daseinsberechtigung haben wird. Was Java angeht... ich denke eher das seine Verbreitung nachlassen wird.
Ich sehe es an mir selber. Seit Jahren will ich endlich mal ein Projekt in Java machen, aber am Ende wirds dann doch immer entweder C++ weil zu Systemnah, oder C# weils schlicht einfacher udn schneller geht. (Event driven design for the win)
-
pale dog schrieb:
CStoll schrieb:
Sag blos, ich kann jedes Objekt ohne Vorbereitungen durch so einen ObjektStream jagen, um es zu kopieren. Der Link, den du dort oben gegeben hast, sagt da etwas anderes:
normalerweise reicht ein 'implements Serializable' im kopf der klassen, die man 'klonen' will, das wirkt sich auch auf unterklassen aus.
wenn irgendwelche feinheiten gebraucht werden, kann man's noch erweitern, indem man 'readObject' und 'writeObject' überschreibt. im normalfall braucht man's aber nicht.
guckst du: http://java.sun.com/developer/technicalArticles/Programming/serialization/
Ist immer noch reichlich kompliziert (vor allem verstehe ich nicht, daß man für eine einfache Kopie immer den Umweg über einen Byte-Stream gehen muß). In C++ kannst du (fast) jedes Objekt von Haus aus kopieren. Und die Ausnahmefälle, wo das nicht möglich ist, dürften genauso selten auftreten wie die Fälle, wo dein 'implements Serializable' nicht ausreicht.
lokos schrieb:
Java wurde anfänglich als ein "besseres" C++ verkauft. Der Gedanke war imemr irgendwie: Wir nehmen die komplizierten sachen aus C++ raus und vereinfachen das Sprachkonzept. Diese Vereinfachung wurde aber stark dadurch erreicht, daß die Programmierer in ihren Möglichkeiten (im Vergleich zu C++) drastisch eingeschränkt wurden. Je nach Projekt kann dies beides sein: Fluch oder Segen...
Genau, und im Zuge der Vereinfachung sind auch die nützlichen C++ Bestandteile eliminiert worden, die den Java Entwicklern zu kompliziert erschienen sind - möglicherweise weil sie sie nicht verstanden haben.
-
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
Sag blos, ich kann jedes Objekt ohne Vorbereitungen durch so einen ObjektStream jagen, um es zu kopieren. Der Link, den du dort oben gegeben hast, sagt da etwas anderes:
normalerweise reicht ein 'implements Serializable' im kopf der klassen, die man 'klonen' will, das wirkt sich auch auf unterklassen aus.
wenn irgendwelche feinheiten gebraucht werden, kann man's noch erweitern, indem man 'readObject' und 'writeObject' überschreibt. im normalfall braucht man's aber nicht.
guckst du: http://java.sun.com/developer/technicalArticles/Programming/serialization/
Ist immer noch reichlich kompliziert (vor allem verstehe ich nicht, daß man für eine einfache Kopie immer den Umweg über einen Byte-Stream gehen muß).
was ist daran kompliziert 2 wörtchen hinzuschreiben?
das mit den streams hat einen einfachen grund: man kann komplexe objekte auf eine einheitliche weise in dateien ablegen oder sie über netzwerke senden.CStoll schrieb:
In C++ kannst du (fast) jedes Objekt von Haus aus kopieren.
ja, flache kopien, das konnte C ohne ++ schon mit structs machen, als struppi noch die wolle aus'm teddybär'n gezupft hat.
-
pale dog schrieb:
...
ja, flache kopien, das konnte C ohne ++ schon mit structs machen, als struppi noch die wolle aus'm teddybär'n gezupft hat.
Naja, ein bischen mehr schon. Immerhin werden auch selbstgeschriebene CopyCtoren von tief verschachtelten Klassen aufgerufen ...
IMO Vorteil ggü. selbstgeschriebenen Funktionen (Huch - wo ist dann da das OO bei Java geblieben ? ): Man kann nicht vergessen, sie aufzurufen.
Letztlich finde ich den Unterschied aber eher marginal und legitimiert IMO keineswegs eine Überlegenheit der einen oder andern Sprache.Gruß,
Simon2.
-
Zum Thema "Java ist sicherer":
http://www.heise.de/newsticker/meldung/89821
-
lokos schrieb:
Beide Sprachen haben ihre Daseinsberechtigung, wobei C# durchaus eher Java das Wasser abgraben wird als C++, weil C# und Java eher auf die gleichen Zielgruppen von Anwendungsentwicklern ausgerichtet sind während C++ eher im Bereich der reinen Systementwicklung nach wie vor Puntken kann. Und wenn man sich erstmal eingehender mit C# auseinandergesetzt hat und dessen Stärken erkennt bleibt für Java als einzige daseinsberechtigung die fehlende Kompatibilität *nix basierter Systeme zu C#... (Btw, man kann ganze Webapplikationen easy in C# schreiben unter dem ASP...) Gerade im Bereich der Anwendungsentwicklung kann die Kombination C# und .Net die Entwickler enorm entlasten, wodurch Projekte schlicht schneller fertig werden und auch besser laufen. Ok, man verkauft im gegenzug seine Seele an MS, aber auch daran kann man sich gewöhnen.
Ich hab mal gehört unter den *nix gibts C# mit MONO, hab ich mich da geirrt?
-
darthdespotism schrieb:
lokos schrieb:
Beide Sprachen haben ihre Daseinsberechtigung, wobei C# durchaus eher Java das Wasser abgraben wird als C++, weil C# und Java eher auf die gleichen Zielgruppen von Anwendungsentwicklern ausgerichtet sind während C++ eher im Bereich der reinen Systementwicklung nach wie vor Puntken kann. Und wenn man sich erstmal eingehender mit C# auseinandergesetzt hat und dessen Stärken erkennt bleibt für Java als einzige daseinsberechtigung die fehlende Kompatibilität *nix basierter Systeme zu C#... (Btw, man kann ganze Webapplikationen easy in C# schreiben unter dem ASP...) Gerade im Bereich der Anwendungsentwicklung kann die Kombination C# und .Net die Entwickler enorm entlasten, wodurch Projekte schlicht schneller fertig werden und auch besser laufen. Ok, man verkauft im gegenzug seine Seele an MS, aber auch daran kann man sich gewöhnen.
Ich hab mal gehört unter den *nix gibts C# mit MONO, hab ich mich da geirrt?
Ja, es gibt Mono. Mono will dieses Jahr die Implementierung von .Net 2.0 fertigstellen... Aktuell ist .Net aber schon wieder bei 3.5 . Ich will Mono nicht schlecht reden, aber gegen den Versionswahn von Kleinweisch anzukommen ist nicht einfach...
-
lokos schrieb:
C++ kann ALLES was Java kann (naja, und vieles mehr halt).
Interessant. Ich mach mit Java folgendes:
Ich habe ein Programm, das aus einzelnen völlig unzusammenhängenden Bausteinen besteht. Es wird an keiner Stelle im Programm gesagt, welche Bausteine da sind und welche nicht. Es gibt auch keine externe Datei, in der die Bausteine eingetragen sind. Und die Bausteine haben auch keine Methoden, durch die sie sagen können, was sie sind und wie sie zu benutzen sind. Mein Programm untersucht sich beim Start dann praktisch selbst, findet heraus, was es kann, und generiert aus diesen Informationen eine grafische Benutzungsschnittstelle, um alle Bausteine inklusive ihrer Kombinationen für den Benutzer nutzbar zu machen.
Wie macht man das in reinem C++?
-
Simon2 schrieb:
pale dog schrieb:
...
ja, flache kopien, das konnte C ohne ++ schon mit structs machen, als struppi noch die wolle aus'm teddybär'n gezupft hat.
Naja, ein bischen mehr schon. Immerhin werden auch selbstgeschriebene CopyCtoren von tief verschachtelten Klassen aufgerufen ...
...die man aber erst schreiben muss und die für jede klasse anders aussehen.
Simon2 schrieb:
IMO Vorteil ggü. selbstgeschriebenen Funktionen (Huch - wo ist dann da das OO bei Java geblieben ?
): Man kann nicht vergessen, sie aufzurufen.wieso vergessen? machste einfach 'ObjectOutputStream().writeObject(...)' und alles geht automatisch.
Simon2 schrieb:
Letztlich finde ich den Unterschied aber eher marginal und legitimiert IMO keineswegs eine Überlegenheit der einen oder andern Sprache.
sag ich ja auch immer. wer Java mit c++ vergleicht, vergleicht äpfel mit birnen.
aber auf mich hört ja keiner...
Gregor schrieb:
Wie macht man das in reinem C++?
du weisst doch selber, dass das nicht geht
-
phlox81 schrieb:
Zum Thema "Java ist sicherer":
http://www.heise.de/newsticker/meldung/89821"Java ist sicherer" ist wie folgt zu verstehen: In Java gibt es Sicherheitskonzepte. Natürlich haben die auch Lücken (Die JVM ist schließlich in C++ geschrieben). In C++ gibt es aber erst gar keine.
-
ich finde diese "diskussion" ist absolut lächerlich.
jeder der hier denkt das eine sei aus irgendwelchen gründen besser als das andere, hat imo irgendo was nicht ganz verstanden...
-
pale dog schrieb:
Gregor schrieb:
Wie macht man das in reinem C++?
du weisst doch selber, dass das nicht geht
Ich lass mich bei solchen Dingen immer gerne überraschen. Ich kann C++ nicht gut genug, um endgültig beurteilen zu können, ob es da nicht elegante Wege gibt, bestimmte Funktionalitäten von Java nachzubilden. Meistens kommt aber nur ein "Ich kann die JVM ja nachprogrammieren!". ...weiß nicht, ob man das zählen lassen sollte. ...zumal man dann ja immer noch eine andere Sprache für das eigentliche Programm nutzt.
-
@Gregor
Symbol-Tabelle des Binaries auslesen. (natürlich gibt es komfortablere Lösungen. Aber du willst ja reines C++)Gregor schrieb:
phlox81 schrieb:
Zum Thema "Java ist sicherer":
http://www.heise.de/newsticker/meldung/89821"Java ist sicherer" ist wie folgt zu verstehen: In Java gibt es Sicherheitskonzepte. Natürlich haben die auch Lücken (Die JVM ist schließlich in C++ geschrieben). In C++ gibt es aber erst gar keine.
Anders gesagt: In Java bekommt man Sicherheitslücken frei Haus. In C++ muss man sie erst selbst coden.
-
Gregor schrieb:
pale dog schrieb:
Gregor schrieb:
Wie macht man das in reinem C++?
du weisst doch selber, dass das nicht geht
Ich lass mich bei solchen Dingen immer gerne überraschen. Ich kann C++ nicht gut genug, um endgültig beurteilen zu können, ob es da nicht elegante Wege gibt, bestimmte Funktionalitäten von Java nachzubilden. Meistens kommt aber nur ein "Ich kann die JVM ja nachprogrammieren!". ...weiß nicht, ob man das zählen lassen sollte. ...zumal man dann ja immer noch eine andere Sprache für das eigentliche Programm nutzt.
Man könnte das Konzept von IDispatch
http://en.wikipedia.org/wiki/IDispatch
übernehmen. Btw. wie "rein" ist das Java das Du dazu verwendest?
Nutzt es die Laufzeitbiblithek?
Das wäre es nämlich legitim auch für C++ Bibliotheken zu verwenden.
Grüsse
*this
-
Gast++ schrieb:
Btw. wie "rein" ist das Java das Du dazu verwendest?
Nutzt es die Laufzeitbiblithek?
Das wäre es nämlich legitim auch für C++ Bibliotheken zu verwenden.Du darfst die C++ Standardbibliothek selbstverständlich verwenden. IMHO gehört die zur Sprache dazu. Ich nutze auch die Java-Standardbibliothek. Allerdings nur den ganz zentralen Kern davon.
rüdiger schrieb:
@Gregor
Symbol-Tabelle des Binaries auslesen. (natürlich gibt es komfortablere Lösungen. Aber du willst ja reines C++)Elegant ist das ja nicht gerade.
...aber durchaus interessant. 
-
Gast++ schrieb:
Man könnte das Konzept von IDispatch
http://en.wikipedia.org/wiki/IDispatch
übernehmen.soll man das halbe windows nachbauen
btw: Java bringt seine eigene infrastruktur schon mit, deshalb war die aufgabe von Gregor auch etwas unfair...
-
Gregor schrieb:
Du darfst die C++ Standardbibliothek selbstverständlich verwenden. IMHO gehört die zur Sprache dazu. Ich nutze auch die Java-Standardbibliothek. Allerdings nur den ganz zentralen Kern davon.
So kann man das nicht vergleichen.
Entweder wir lassen auch in Java alle Bibliotheken heraus oder wir lassen in C++ alle externen Bibliotheken zu.Dsss Java eine grössere Laufzeitbibliothek hat als ein Standard-C++ ist unbestreitbar.
Allrdings glaube ich dass eine Lösung mit dem IDispatch-Konzept, ggf RTTI und wenns ganz ganz schlimm kommt mit der Symboltabelle schon recht komplett wäre.
Statt AWT/Swing würde ich dann die MFC, Qt o.ä. einsetzen; das muss erlaubt sein.
Grüsse
*this
