c++ vs. java... was hat zukunft
-
pale dog schrieb:
...
nö, das ist exakt das gleiche was C macht. wenn du in C eine struct hast, die ihrerseit wieder structs beinhaltet, dann wird mit '=' eine bitweise kopie erzeugt. ...Sag mal - Du kannst mich doch verstehen - warum tust Du denn nicht ?
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt). C++ dagegen kann in "impliziten CopyCtoren" AUCH "explizite CopyCtoren" aufrufen.
Dieses "AUCH" ist das Quentchen Mehr, das ich meine.
Ja - C++ kann keine impliziten CopyCtoren für "tiefe Kopien" erzeugen, aber sie können eben dieses bischen mehr, so dass ich eine "ausreichend tiefe Kopie" bekomme (wenn mir für meine Klasse eine "flache" reicht, kann ich trotzdem implizit eine "tiefe" für meine Attribute/Basisklassen bekommen, wenn die das brauchen).Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... ud spätestens da ist C am Ende.
Gruß,
Simon2.
-
Simon2 schrieb:
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt).
unsinn, C kennt überhaupt keine konstruktoren.
Simon2 schrieb:
C++ dagegen kann in "impliziten CopyCtoren" AUCH "explizite CopyCtoren" aufrufen.
Dieses "AUCH" ist das Quentchen Mehr, das ich meine.dass C++ mehr möglichkeiten bietet als C will keiner bestreiten. ob alles davon wirklich sinnvoll und nützlich ist, ist natürlich ein anderes thema.
Simon2 schrieb:
Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... und spätestens da ist C am Ende.
ich hatte vor ein paar postings C erwähnt, weil CStoll 'implizite copy-ctors' als ein tolles C++ feature angepriesen hast, aber C die gleiche funktionalität für structs schon seit urzeiten hat - auch ganz ohne konstruktoren.
ein vergleich (oder flamewar ) C gegen C++ wäre genau so absurd wie C++ gegen Java.
gleichberechtigte flamewar-kontrahenten wären z.b. C# vs. Java oder etwa C vs. Pascal.
C++ kann man, meiner meinung nach, schlecht mit anderen sprachen vergleichen, weil es so'n schlüpfriges zwitterding und deshalb einzigartig ist.
... und wenn man's doch macht, kommen die seltsamsten argumente (wie etwas dass das OS für C++'s sicherheit zuständig ist. so ein quatsch!).
-
OK, da hilft nur, Dein Gedächtnis auffrischen:
pale dog schrieb:
Simon2 schrieb:
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt).
unsinn, C kennt überhaupt keine konstruktoren....
Erstaunlich - ich hätte Dir die Transferleistung zugetraut - sag nicht, dass ich mich getäuscht habe....
pale dog schrieb:
...
Simon2 schrieb:
Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... und spätestens da ist C am Ende.
ich hatte vor ein paar postings C erwähnt, weil du 'implizite copy-ctors' als ein tolles C++ feature angepriesen hast, ...
Zur Erinerung:
Simon2 schrieb:
pale dog schrieb:
...
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.
Naja, ein bischen mehr schon. ...Letztlich finde ich den Unterschied aber eher marginal ...
Simon2 schrieb:
...können eben dieses bischen mehr, ...
Merke: "Bischen", "marginal", "bischen"
Irgendwie bringe ich das nicht mit Deinem "... tolles C++ feature angepriesen ..." in Einklang und ebensowenig mit einem "flamewar", wie Du ihn herufziehen siehst...Gruß,
Simon2.
-
Um nochmal auf die Originalfrage zu kommen, halt was hat Zukunft.
Ich denke das die Diskussion einfach (wie so oft) komplett falsch geführt wird und damit meine ich nicht diesen: Ich-hab-aber-doch-recht-Stil einiger Leute.
Nein, ich meine, die Frage ist so falsch gestellt, denn sie impliziert die Annahme, daß eine Spache für sich betrachtet so etwas wie eine Zukunft haben könnte. Das aber ist falsch, denn die Gebiete der Programmierung sind nurmal sehr unterschiedliche und es gibt viele davon.
Selbst eine Exotische Sprache wie Erlang haben eine definierte Zukunft, weil sie ein Gebiet der Programmierung bedient auf dem sie genau das bietet was die entwickler brauchen.
Bevor man also über Zukunft redet muß man sagen, in welchem Bereich man denn arbeiten will. Wenn ich hardwarenah Programmieren muß, sagen wir z.B. Treiberentwicklung dann sage ich auf diesem Gebiet einer Sprache wie Java gar keine Zukunft vorraus,denn dafür ist die Sprache nicht gedacht.
Wenns um Anwendungsentwicklung geht sieht die Welt wieder anders aus, aber auch hier muß man die Frage weiter detailieren. Will man z.B. ausschließlich auf Microsoft-Plattform arbeiten, dann sehe ich eine riesige Zukunft für C#, eher wenig für C++ und gar keine für Java.
Anders sieht es bei Applicationen aus die entweder auf möglichst vielen Plattformen laufen sollen oder halt von vorneherein *nix basiert sind, da wird Java noch lange Zeit die Nase vorne haben wohingegen C++ hier schon jetzt kaum eine Gegenwart hat.
Bei reiner Systementwicklung, Realtime-Anwendungen und Performancekritischen Sachen wieder denke ich das C++ am meisten Punktet und auch hier noch lange Zeit einfach dei Sprache der Wahl sein wird. (Als kleiner randbemerkung, die VM von java ist soweit ich weis auch in C++ geschrieben, korrigiert mich wenn ich falsch liege... go figure)
Nur in solchen Zusammenhängen lassen sich sinnvolle Aussagen machen, eine pauschale Zukunft irgendeiner Sprache gibt es einfach nicht, denn welchen Nutzen hätte auch die beste aller Sprachen wenn es keine Anwendungsgebiete dafür gäbe...
Und gerade wenns im Professionelle Entwicklung geht zählt am ende nur eines wirklich: Wirtschaftlichkeit. Das heisst, man wählt immer die Sprache mit der man ein gegebenes Problem am einfachsten, schnellsten und saubersten Lösen kann. Ich gehe sogar soweit zu behaupten, daß ein guter Programmierer sich dadurch auszeichnet, daß er nicht auf eine einzige Sprache eingefahren ist.
-
pale dog schrieb:
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?
Wenn es wirklich nur darum ginge, "2 wörtchen hinzuschreiben", gar nichts. Aber dann wäre der Artikel auch nach der ersten Seite zu Ende. Auch bei Java mußt du noch die ganzen Sonderfälle beachten, in denen diese "2 wörtchen" nicht ausreichen. Im Vergleich dazu mußt du in C++ normalerweise gar nichts machen, wenn du Okjekte kopierbar machen willst (und ebenfalls einige Sonderfälle beachten, in denen dieses Default-Verhalten nicht reicht).
das mit den streams hat einen einfachen grund: man kann komplexe objekte auf eine einheitliche weise in dateien ablegen oder sie über netzwerke senden.
Ich will dir gar nicht die Vorteile von Streams absprechen, aber sie für eine simple Kopier-Operation zu nutzen, hat was von "mit Kanonen auf Spatzen schießen". Wozu der Umweg? Gibt es denn keine Möglichkeit, ein Objekt direkt zu kopieren?
Gregor schrieb:
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.
Echt, das geht? Es ist zwar eine Weile her, daß ich mich mit Java beschäftigt habe, aber afair gibt es dort auch eine main()-Methode, die als Ausgangspunkt des Programms dient (und die wissen muß, was da ist, und was du benötigst).
PS: Nur damit niemand meine Aussagen in den falschen Hals bekommt:
Ich vertrete hier zwar die C++ Seite, aber deswegen will ich Java noch lange nicht verdammen. Ich versuche hier nur, die ständigen "C++ ist sch***"-Argumente einiger Java-Anhänger genauer auseinanderzunehmen.
-
Hi lokos,
ich stimme Dir zu ! Gut formuliert !!
lokos schrieb:
... Ich gehe sogar soweit zu behaupten, daß ein guter Programmierer sich dadurch auszeichnet, daß er nicht auf eine einzige Sprache eingefahren ist.
Oder wie ich schon auf Seite 3 sagte:
Simon2 schrieb:
Hi,
mein einziger Tipp:
Lerne keine Sprache, sondern lerne Programmieren !!!Alles Andere wird nicht zukunftsfähig sein.
Gruß,
Simon2.
Gruß,
Simon2.
-
CStoll schrieb:
Echt, das geht? Es ist zwar eine Weile her, daß ich mich mit Java beschäftigt habe, aber afair gibt es dort auch eine main()-Methode, die als Ausgangspunkt des Programms dient (und die wissen muß, was da ist, und was du benötigst).
Naja, man muß schon unterscheiden, ob die nötigen Informationen nochmals hinterlegt werden müssen, oder ob sie aus dem Rest automatisch generiert werden.
Wenn man sich natürlich auf den Standpunkt stellt, dass das kein Mehrwert sei (die Information muß schließlich vorliegen), dann sollte man sich vielleicht auf mal die Frage nach dem Mehrwert von templates stellen.
-
CStoll schrieb:
Gregor schrieb:
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.
Echt, das geht? Es ist zwar eine Weile her, daß ich mich mit Java beschäftigt habe, aber afair gibt es dort auch eine main()-Methode, die als Ausgangspunkt des Programms dient (und die wissen muß, was da ist, und was du benötigst).
Naja, ich mach halt am Anfang einen rekursiven Verzeichnisdurchlauf bzw. durchsuche die Jar-Datei, in der sich das Programm befindet. Dabei lese ich dann praktisch alle class-Dateien, die ich finde ein und stecke die darin enthaltenen Klassen in eine Datenstruktur, die so ähnlich wie ein UML-Klassendiagramm aufgebaut ist. Dann nutze ich ein bischen Reflection und Annotations, um rauszufinden, wie man Objekte bestimmter Klassen erzeugen kann, wie diese einzuordnen sind usw. Mit den Informationen bau ich mir dann praktisch einen Großteil der Benutzungsschnittstelle auf bzw. generiere bei Bedarf Dialoge, die auf Konstruktoren und Methoden von bestimmten Klassen abgestimmt sind.
(+noch ein bischen Unfug)
Naja, mir kam es dabei darauf an, die Kopplung zwischen den einzelnen Bausteinen so minimal wie möglich zu halten. ...ich hasse es irgendwie, solche Dinge in Listen einzutragen, seien sie nun in Form von Quellcode oder in Form von externen Dateien. Irgendwie haben solche Listen, die Eigenschaft, mit größer werdendem Programm immer weiter zu wachsen, was IMHO nicht gerade zur Beherrschung der Komplexität des Programms beiträgt. ...und GUI-Code mag ich auch nicht. ...letztendlich soll das darauf hinauslaufen, dass in dem Programm ab einem ganz bestimmten Punkt mit größer werdendem Programm vom MVC nur noch das M wächst. Es ist aus meiner Sicht völlig langweilig, C und V zu programmieren. Das ist also eine Art Experiment für mich.
Vielleicht hätte ich mir C++ zu diesem Zweck genauer angucken sollen. Die Symboltabelle stellt sicherlich einen Ansatzpunkt dar, so einen Mechanismus zu bauen. Andererseits muss man sich dann auch nochmal die Frage stellen, warum man da C++ einsetzt. Templates wären aus meiner Sicht so ein Grund. Ich könnte gewisse Template-Funktionalitäten gebrauchen, die mir die Generics in Java nicht bieten. Aber ich glaube, die Templates harmonieren nicht so gut mit diesem Ansatz. ...vermutlich überhaupt nicht.
-
Gregor schrieb:
...
Naja, ich mach halt am Anfang einen rekursiven Verzeichnisdurchlauf bzw. durchsuche die Jar-Datei, in der sich das Programm befindet. Dabei lese ich dann praktisch alle class-Dateien, die ich finde ein und stecke die darin enthaltenen Klassen in eine Datenstruktur, die so ähnlich wie ein UML-Klassendiagramm aufgebaut ist. Dann nutze ich ein bischen Reflection und Annotations, um rauszufinden, wie man Objekte bestimmter Klassen erzeugen kann, wie diese einzuordnen sind usw. Mit den Informationen bau ich mir dann praktisch einen Großteil der Benutzungsschnittstelle auf bzw. generiere bei Bedarf Dialoge, die auf Konstruktoren und Methoden von bestimmten Klassen abgestimmt sind. ...Schau an, bei mir macht das der C++-Compiler.
Ja, "Reflections" bekommt man in C++ nur ungenügend hin ... aber ehrlich gesagt: Das stört mich nicht. Beim Programmieren geht es nicht darum, sich bis zuletzt alles Mögliche offen zu halten, sondern Abläufe sinnvoll festzulegen ... selbst mit den Möglichkeiten von C++ haben wir schon Anwendungen, deren "Laufzeitflexibilität" so hoch ist, dass ihre Konfigurationsdateien dieselbe QS-Anforderungen haben wie Quellcode. (Du kannst es anders nennen als "KonfigDateien", aber letztlich wird auch Dein Programm zur Laufzeit die Entscheidung treffen müssen, was es jetzt gerade konkret tun muss ... und dafür braucht es die Information, die Du beim Programmieren weggelassen hast.)
Und damit haben wir letztlich nichts gewonnen, weil Änderungen an diesen "KonfigDateien" nicht mehr einfacher sind als Quellcodeänderungen und Fehler in ihnen genauso gravierende Auswirkungen haben, wie Fehler im Anwendungssource.Anders ausgedrückt: Ich kenne kaum Fälle, in denen "Reflections" (o.ä. Konzepte) wirklichen Gewinn bringen.
Bestenfalls sind sie ein eleganter Weg von "unneccessary cleverness"...Letztlich bewegen wir uns hier aber auch in einem Philosophie-Unterschied: In der "C++-Denke" versucht man eben, möglichst viel den Compiler einzubinden, während bei Java viel davon auf die Laufzeit verlagert wird (ohne IMO etwas dabei zu sparen).
Gruß,
Simon2.
-
Und woher weiß das Programm dann, welche der tausend Hilfsklassen und Dialogelemente des JAR-Archivs du nun wirklich brauchst (und wie z.B. die Dialog-Elemente auf dem Bildschirm verteilt werden müssen)?
-
Simon2 schrieb:
Ja, "Reflections" bekommt man in C++ nur ungenügend hin ... aber ehrlich gesagt: Das stört mich nicht. Beim Programmieren geht es nicht darum, sich bis zuletzt alles Mögliche offen zu halten, sondern Abläufe sinnvoll festzulegen ... selbst mit den Möglichkeiten von C++ haben wir schon Anwendungen, deren "Laufzeitflexibilität" so hoch ist, dass ihre Konfigurationsdateien dieselbe QS-Anforderungen haben wie Quellcode. (Du kannst es anders nennen als "KonfigDateien", aber letztlich wird auch Dein Programm zur Laufzeit die Entscheidung treffen müssen, was es jetzt gerade konkret tun muss ... und dafür braucht es die Information, die Du beim Programmieren weggelassen hast.)
Und damit haben wir letztlich nichts gewonnen, weil Änderungen an diesen "KonfigDateien" nicht mehr einfacher sind als Quellcodeänderungen und Fehler in ihnen genauso gravierende Auswirkungen haben, wie Fehler im Anwendungssource.Du hast mich nicht verstanden: Ich habe keine "KonfigDateien". Ich habe ausschließlich Quellcode. Wenn ich aus dem Programm eine bestimmte Funktionalität entfernen möchte, dann lösche ich halt genau diese Datei. Wenn ich etwas hinzufügen möchte, dann schreibe ich einfach eine entsprechende Quellcodedatei und stecke die resultierende .class-Datei in irgendein Unterverzeichnis des Programms. Sonst mach ich gar nichts.
Für mich geht es beim Programmieren nur um die Algorithmen, die auch wirklich neuartige Funktionalität mit sich bringen. Alles andere ist stinklangweilig. LAME! Programmierst Du, um andauernd den gleichen niveaulosen 08/15-Mist zu schreiben? Wie kann man daran Interesse entwickeln?
-
Gregor schrieb:
Für mich geht es beim Programmieren nur um die Algorithmen, die auch wirklich neuartige Funktionalität mit sich bringen. Alles andere ist stinklangweilig. LAME! Programmierst Du, um andauernd den gleichen niveaulosen 08/15-Mist zu schreiben? Wie kann man daran Interesse entwickeln?
Ernsthaft, mit der Aussage wäre C# + .NET für Dich die ideale Entwicklungsumgebung weil da genau diese 0815 Tasks Dir nahezu komplett vom Framework abgenommen werden und Du Dich fast komplett auf die eigendliche Anwendungsentwicklung konzentrieren kannst.
-
Simon2 schrieb:
pale dog schrieb:
Simon2 schrieb:
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt).
unsinn, C kennt überhaupt keine konstruktoren....
Erstaunlich - ich hätte Dir die Transferleistung zugetraut - sag nicht, dass ich mich getäuscht habe....
meine transferleistung war, default copy-ctors mit einer eigenschaft einer nicht-OO sprache zu vergleichen, was ich fast schon bereue, wenn daraufhin 'C++ ist besser als C' -aussagen kommen wie "C kann eben in impliziten CopyCtoren NUR implizite CopyCtoren .... und spätestens da ist C am Ende."
lokos schrieb:
Will man z.B. ausschließlich auf Microsoft-Plattform arbeiten, dann sehe ich eine riesige Zukunft für C#, eher wenig für C++ und gar keine für Java.
naja, ganz so würde ich das nicht sehen. mit C# ist natürlich einiges mehr möglich, wenn's um windows geht, aber Java ist auch unter windows durchaus eine brauchbare alternative.
lokos schrieb:
Bei reiner Systementwicklung, Realtime-Anwendungen und Performancekritischen Sachen wieder denke ich das C++ am meisten Punktet und auch hier noch lange Zeit einfach dei Sprache der Wahl sein wird.
eher C ohne ++. C++ hat einige versteckte bremsen und fallstricke, die bei performancekritischen programmen böse überraschungen bescheren können. selbst die abgespeckte variante 'embedded C++' erfreut sich in der fachwelt keiner grossen beliebtheit.
CStoll schrieb:
Wenn es wirklich nur darum ginge, "2 wörtchen hinzuschreiben", gar nichts. Aber dann wäre der Artikel auch nach der ersten Seite zu Ende. Auch bei Java mußt du noch die ganzen Sonderfälle beachten, in denen diese "2 wörtchen" nicht ausreichen. Im Vergleich dazu mußt du in C++ normalerweise gar nichts machen, wenn du Okjekte kopierbar machen willst (und ebenfalls einige Sonderfälle beachten, in denen dieses Default-Verhalten nicht reicht).
in der realität ist es aber wirklich recht einfach. kleines beispiel: ich hab' mal eine demo-anwendung in Java geschrieben. es war das eine ansammlung von konfigurierbaren AWT-fensterchen, die jedes für sich e-mail clients darstellten. der benutzer konnte aussehen, netzwerkeinstellungen, usw. pro client einstellen, sich neue clients generieren etc. wenn er auf einen 'sender-client' draufklickte, wurde eine 'kommando e-mail' zu einer maschine geschickt. die andere sorte clients empfing e-mails von maschinen, zeigte die messages an und fing an wild zu blinken. wie gesagt, eine demo-anwendung.
irgendwann rief einer an: "hey, dein programm gefällt mir echt gut, ich benutze es schon lange, aber ich find's nervig, wenn man nach dem starten immer alles neu einstellen muss".
naja, und dann hab ich einfach die komplette anwendung serialisiert und über einen 'ObjectOutputStream' auf die platte geschrieben. der einzige grund, warum die 'readObject' überschrieben werden musste, war, dass nach dem starten und einlesen ein paar threads gestartet werden mussten.
aufwand für die ganze aktion: ca. eine stunde!
ich denke, sowas in ein C++ programm einzubauen, was von vornherein nicht vorgesehen war, würde sehr sehr lange dauern...
-
Hast du auch den Rest meines Beitrags gelesen? Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
(und die Möglichkeiten, die C++ da bietet, gehen weit über die Entscheidung "flache Kopie vs. tiefe Kopie" hinaus)@Gregor: Wie gesagt, woher weiß Java, welche deiner Klassen wo und wie zusammengestellt werden sollen? Egal wo das ist, irgendwo mußt du diese Information auch abgelegt haben.
-
Gregor schrieb:
...
Du hast mich nicht verstanden: Ich habe keine "KonfigDateien". Ich habe ausschließlich Quellcode. Wenn ich aus dem Programm eine bestimmte Funktionalität entfernen möchte, dann lösche ich halt genau diese Datei. Wenn ich etwas hinzufügen möchte, dann schreibe ich einfach eine entsprechende Quellcodedatei und stecke die resultierende .class-Datei in irgendein Unterverzeichnis des Programms. Sonst mach ich gar nichts....Äh - ja, wo ist jetzt der Unterschied zu dem normalen Umgang mit Source ? Wo ist da die spezifische Reflectionnutzung ?
Was Du da beschreibst, mache ich genauso ... eben mit C++, aber das ginge mit Fortran, COBOL, ASM, .... genauso.@"Konfigdaten": Du schreibst "wenn ich .. möchte" - das ist genau die Entscheidung , von der ich sprach. Offensichtlich hast Du die aber gar nicht automatisiert, sondern machst das jedesmal manuell ("Dateien löschen/verschieben" ...) - nicht gerade ein Vorteil gegenüber KonfigDaten...
Gruß,
Simon2.
-
Simon2: Dir ist aber schon klar, dass selbst wenn er ne Konfigdatei hätte für zusätzliche Funktionalität auch deren Implementierung mitgeliefert werden muß? Inwiefern wäre es dann toller zustäzlich zum reinkopieren der neuen Implementierung (muß ja sowieso sein) noch irgendwo anders was einzutragen?
-
pale dog schrieb:
...
meine transferleistung war, default copy-ctors mit einer eigenschaft einer nicht-OO sprache zu vergleichen, ..... aber sie reicht doch auch bestimmt soweit, diese Eigenschaft verkürzend als "Default-Konstruktor" bennen zu dürfen, oder ?
"C++ ist besser als C" habe ich nicht gesagt; das Vergleichen hast Du eingeführt ("Das kann C auch") und ich habe lediglich darafu hingewiesen, dass das Konstruktionsverhalten in C++ schon etwas komplexer ist als in C.
Dem stimmst Du wahrscheinlich sowieso zu, weswegen ich auch gar nicht weiß, worüber wir uns hier streiten sollten.
Dass Du mit CStoll einen eigenen Disput hast, braucht uns ja wohl nicht zu stören, oder ?Gruß,
Simon2.
-
CStoll schrieb:
Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
das geht ja auch, indem man die 'Object.clone()' methode überschreibt. die default-version liefert eine flache kopie, in einer überschriebenen methode kann man das verhalten ändern wie man möchte.
allerdings ist davon abzuraten, sich mit 'clone()' tiefes kopieren selbst hinzufrickeln, weil ObjectOutput/ObjectInput-Streams das viel besser können (sie benutzen die 'reflection'-möglichkeiten der VM).
-
[quote="pale dog]naja, ganz so würde ich das nicht sehen. mit C# ist natürlich einiges mehr möglich, wenn's um windows geht, aber Java ist auch unter windows durchaus eine brauchbare alternative.
[/quote]Das kann nur von jemand kommen der noch keine größeren Projekte mit C# gemacht hat und die Sprache + .Net nur vom Hörensagen kennt... Sorry, im Vergleich zu C# + .Net unter Windows ist Java _keine_ Alternative wenn Aspekte wie Wirtschaftlichkeit und Einhalten von engen Deadlines im Vordergrund stehen...
[quote="pale dog]
eher C ohne ++. C++ hat einige versteckte bremsen und fallstricke, die bei performancekritischen programmen böse überraschungen bescheren können. selbst die abgespeckte variante 'embedded C++' erfreut sich in der fachwelt keiner grossen beliebtheit.
[/quote]Ab einer gewissen Projektgröße überwiegen die Vorteile von OOP im Bezug auf Wartbarkeit, Erweiterung etc eindeutig den Performancenachteilen gegenüber reinem C. C++ imho daher immer die erste Wahl und wenns überhaupt nicht anders geht, höchstens einzelne Module innderhalb der Projektes in reinem C.
Vorraussetzung natürlich man kann mit OOP umgehen, eine Fähigkeit die ich vielen abspreche, vor allem wenn ich solche Kommentare lese...
-
pale dog schrieb:
CStoll schrieb:
Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
das geht ja auch, indem man die 'Object.clone()' methode überschreibt. die default-version liefert eine flache kopie, in einer überschriebenen methode kann man das verhalten ändern wie man möchte.
Und damit sind wir wieder am Anfang der Diskussion - worin (abgesehen vom Namen) unterscheidet sich 'Object.clone()' von einem überladenen operator=?
allerdings ist davon abzuraten, sich mit 'clone()' tiefes kopieren selbst hinzufrickeln, weil ObjectOutput/ObjectInput-Streams das viel besser können (sie benutzen die 'reflection'-möglichkeiten der VM).
Wie gesagt, "flache Kopie" und "tiefe Kopie" sind nur zwei mögliche Konzepte. Und den Umweg über einen Stream halte ich immer noch für zumindest unintuitiv.
(würdest du wichtige Informationen für deinen Kollegen, der im selben Zimmer sitzt, mit der Post verschicken? Vermutlich ja :D)