c++ vs. java... was hat zukunft
-
schlauher als du schrieb:
in der objektorientierten programmierung is jede klasse auch ein typ.
Nein. Es muss in der OOP ja noch nicht einmal Klassen geben.
ob ich mit einer bestimmten programmiersprache einen '+' operator auf eine instanz dieses types darauf anwenden kann ist lediglich ein sprachfeature und ändert wohl nix an den konzepten der objektorientierten programmierung
Sicher. Aber das ist ja nur einer der Punkte wo man sieht, das es in Java Typen und Klassen gibt und die sehr verschieden sind.
-
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
-
-
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Die bringt der Klapperstorch...
*SCNR*
Man kann z.B. in Perl 5 objektorientiert programmieren indem man ein en Hash(aka Python: Dictionary {}, C++ STL: map<T>) geeignet ausstattet.
Beim "normalen" Weg mit Perl Objekte zu erzeugen passiert eigentlich nichts anderes; nur halt in meist einem Modul das an die Stelle einer Klasse als Instanzfabrik tritt.Grüsse
*this
-
Gast++ schrieb:
...in meist einem Modul das an die Stelle einer Klasse als Instanzfabrik tritt.
und kann die auch verschiedene objekte erzeugen oder sind die alle gleich?
sobald man die struktur von objekten bestimmen kann, hat man ja doch wieder klassen...
-
pale dog schrieb:
und kann die auch verschiedene objekte erzeugen
Das kann ein Modul durchaus; man könnte sogar die Vererbungshierarchie zur Laufzeit setzen! (Macht man allerdings i.A. nicht ohne Grund)
pale dog schrieb:
oder sind die alle gleich? sobald man die struktur von objekten bestimmen kann, hat man ja doch wieder klassen...
Andersrum : Man kann das so nutzen; aber man muss es nicht!
Man kann auch einfach in einen Hash eine Funktionsreferenz einfügen und dem (Hash)Objekt so Methoden verpassen. Dazu muss man nicht vorab eine Klasse definiert haben.
Grüsse
*this
-
irgendwie macht das eh keinen sinn mit dir zu reden. du hast auch irgendwie gar kein interesse war dazuzulernen oder so. is auch sinnlos, wenn du meine sätze nur zur hälfte liest
der gleiche schrieb:
du kansnt die natürlich auch separat benutzen
aber dass du ungern auf links klickst hab ich schon bemerkt.
ich hoffe, dass niemand mal im real life mit dir darüber reden muss, viel spaß noch beim projekt
-
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Schau dir zB ECMAScript an. Das ist OO aber da gibt es keine Klassen.
-
der gleiche schrieb:
irgendwie macht das eh keinen sinn mit dir zu reden. du hast auch irgendwie gar kein interesse war dazuzulernen
Du hingegen scheinst ein grosses Bedürfnis zu haben etwas "lehren" zu wollen.
Es ist nicht das erste Mal das ich erlebe dass Kritik an Java zunächst mal als Wissensdefizit abgetan wird.
Das ist nicht nur höchst einfältig sondern führt dazu dass Java in weniger Projekten eingesetzt wird als es es möglich wäre, da so keine ernsthafte Diskussion einsetzt.
der gleiche schrieb:
oder so. is auch sinnlos, wenn du meine sätze nur zur hälfte liest
der gleiche schrieb:
du kansnt die natürlich auch separat benutzen
aber dass du ungern auf links klickst hab ich schon bemerkt.
Wenn Deine Sätze einander widersprechen ("nur im EE" vs "auch separat") löse ich den Widerspreuch ökonomisch und spare - höchstwahrscheinlich überflüssige - Arbeit.
Da Du mich bereits der Lüge zu zeihen versucht hast sehe ich für anderweitige Höflichkeit keine Veranlassung mehr.
der gleiche schrieb:
ich hoffe, dass niemand mal im real life mit dir darüber reden muss
Brauch ich nicht, solange mir immer andere Spezifikationen mit einm zusätzlichen "J" im Namen genannt werden wenn ich nach der Implementierung eines Protokolls frage.
Für mich ist es unwichtig ob es "JAX-RPC" unterstützt; gefordert war "XML-RPC".
Der Begriff hingegen findet sich nicht auf den von Dir zitierten Seiten (ich hätts mir denken können).Grüsse
*this
-
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Schau dir zB ECMAScript an. Das ist OO aber da gibt es keine Klassen.
ja, hab's überflogen.
es gibt verschiedene typen von objekten und sie haben sogar ein property namens '[[class]] "A string value indicating the kind of this object."'
die objekte werden nur nicht erzeugt wie etwa in Java, recht seltsames zeug, Javascript eben...
-
An dieser Stelle wird mir das dann doch (auch endlich) zu wild. Die eigentliche Frage war, ob sich ein Blick auf Java lohnt. Meine Antwort: Ja, auf jeden Fall. Je gründlicher und länger, desto besser.
Alles andere, was sich hier auf den letzten 4 Seiten entwickelt hat, ist nur noch schreien im finsteren Wald und teilweise dermassen unqualifiziert und am Thema vorbei, dass man den Thread lieber schliessen sollte.
-
pale dog schrieb:
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.Ja, was denn nun? "sehr weit entfernt" oder "Versuch, es aufzumotzen"? Und übrigens wird C++ sehr wohl noch weiterentwickelt.
Übrigens ist Java noch weiter von C entfernt - ist das jetzt besser oder schlechter? (und BASIC oder Delphi erst - die sind so weit von C entfernt, daß sie noch nichtmal die selbe Syntax verwenden :D)
...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!)
Willst du etwa behaupten, in Java gibt es keine Probleme? Vielleicht gibt es dort nicht die Schwierigkeiten, die du hier genannt hast, aber bestimmt genug andere.
(apropos: Wie arbeitet eigentlich der Default Copy-Ctor und Zuweisungsoperator in Java? (tiefe Kopie oder flache Kopie?) Und was muß man machen, wenn einem dieses Verhalten nicht gefällt?)C-ähnliche, objektorientierte sprachen wie etwa Objective-C und D scheinen mir da wesentlich durchdachter zu sein...
Von Objective-C weiß ich nur, daß es eine eigene Syntax verwendet, die intern dann in C-Quelltext übersetzt wird, bevor er durch den Compiler gejagt wird (da ist C++ wesentlich homogener). D wäre einen Blick wert, aber da ist es noch zu früh, sein Potential zu erkennen.
-
pale dog schrieb:
ja, hab's überflogen.
es gibt verschiedene typen von objekten und sie haben sogar ein property namens '[[class]] "A string value indicating the kind of this object."'
die objekte werden nur nicht erzeugt wie etwa in Java, recht seltsames zeug, Javascript eben...die Objekte werden eben on-the-fly also während der Benutzung konstruiert. Das finde ich einen ganz netten Ansatz. Macht JavaScript _programmiertechnisch_ imho wesentlich interessanter als den Namensvetter.
[quote="CStoll"]Von Objective-C weiß ich nur, daß es eine eigene Syntax verwendet, die intern dann in C-Quelltext übersetzt wird, bevor er durch den Compiler gejagt wird (da ist C++ wesentlich homogener).[/url]
Objective-C finde ich schon interessant (gibt ja auch Objective-C++!). Was es im Gegensatz zu C++ anders macht ist die dynamische Objektorientierung mit einem MOP. Das erlaubt eben dynamischere Spielereien, wie man es aus Lisp oder Smalltalk kennt.
Aber als wesentlich durchdachter würde ich es jetzt auch nicht bezeichnen. Weiß nicht woran net das fest macht.
-
SammyRukka schrieb:
...Die eigentliche Frage war, ob sich ein Blick auf Java lohnt. Meine Antwort: Ja, auf jeden Fall....
1.) Dem stimme ich vollkommen zu !
2.) Auch der Blick auf C++ lohnt sich auf jeden Fall
3.) Wer immer später mal ernsthaft("professionell") programmieren will, wird versuchen, sich möglichst viel anzusehen und nicht als erstes untersuchen, was er sich denn "...sparen könnte..."Gruß,
Simon2.
OT schrieb:
Die letzten paar Threadseiten waren mir ein wenig zu sehr von "Gemächtvergleich" geprägt, als dass ich mich ernsthaft damit beschäftigen wollte.
(eine Kommunikationsplage, die ich nur aus diesem Forum kenne - vertritt jemand eine andere Meinung, hat er sofort "... ja überhaupt keine Ahnung und sollte zu Zukunft schweigen und alles abnicken, was der Meister von sich gibt ..." )
-
CStoll schrieb:
pale dog schrieb:
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.Ja, was denn nun? "sehr weit entfernt" oder "Versuch, es aufzumotzen"? Und übrigens wird C++ sehr wohl noch weiterentwickelt.
beides. ein komischer flickenteppich eben. es wurde auch vieles von C übernommen aber ohne 100% abwärtskompatibel zu sein. es gibt nicht umsonst das zitat "C++ is multiparadigm in the same way a dog with 4 table legs nailed onto it is an octopus"
CStoll schrieb:
Übrigens ist Java noch weiter von C entfernt - ist das jetzt besser oder schlechter?
besser. Java versucht gar nicht erst C-kompatibel zu sein. Java hat einen komplett anderen weg eingeschlagen - und der erfolg spricht ja für sich.
...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!)
Willst du etwa behaupten, in Java gibt es keine Probleme? Vielleicht gibt es dort nicht die Schwierigkeiten, die du hier genannt hast, aber bestimmt genug andere.
klar gibt es welche, aber ich behaupte dass benutzer und gerade einsteiger wesentlich weniger schwierigkeiten mit Java haben als mit C++, allein schon deshalb, weil C++ user sich auch noch mit C-macken auseinandersetzen müssen.
(apropos: Wie arbeitet eigentlich der Default Copy-Ctor und Zuweisungsoperator in Java? (tiefe Kopie oder flache Kopie?) Und was muß man machen, wenn einem dieses Verhalten nicht gefällt?)
Java-klassen haben keinen default copy-ctor, man muss sich selber einen schreiben, wenn man sowas braucht. der zuweisungsoperator für objekte kopiert referenzen d.h. es wird kein neues objekt erzeugt oder irgendwelche members dupliziert.
-
pale dog schrieb:
...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!)
Willst du etwa behaupten, in Java gibt es keine Probleme? Vielleicht gibt es dort nicht die Schwierigkeiten, die du hier genannt hast, aber bestimmt genug andere.
klar gibt es welche, aber ich behaupte dass benutzer und gerade einsteiger wesentlich weniger schwierigkeiten mit Java haben als mit C++, allein schon deshalb, weil C++ user sich auch noch mit C-macken auseinandersetzen müssen.
Dafür muß sich ein Java-User mit genug Java-Macken beschäftigen
Und wenn man gezwungen wird, für ALLES eine Klasse anzulegen (selbst zur Zwischenlagerung einiger Hilfsfunktionen, die man im überall Projekt braucht), oder sich Gedanken über die Unterschiede zwischen 'int' und 'Int' zu machen (und die Frage, warum man eigene Objekte nicht per Value übergeben kann), dann lenkt das nur von der eigentlichen Arbeit ab.(apropos: Wie arbeitet eigentlich der Default Copy-Ctor und Zuweisungsoperator in Java? (tiefe Kopie oder flache Kopie?) Und was muß man machen, wenn einem dieses Verhalten nicht gefällt?)
Java-klassen haben keinen default copy-ctor, man muss sich selber einen schreiben, wenn man sowas braucht. der zuweisungsoperator für objekte kopiert referenzen d.h. es wird kein neues objekt erzeugt oder irgendwelche members dupliziert.
Und was muß ich machen, wenn ich Java-Objekte echt kopieren will? Das dürfte sich technisch auch nicht wesentlich von dem unterscheiden, was in C++ nötig ist, oder?
-
CStoll schrieb:
Und was muß ich machen, wenn ich Java-Objekte echt kopieren will? Das dürfte sich technisch auch nicht wesentlich von dem unterscheiden, was in C++ nötig ist, oder?
doch, das ist schon ziemlich unterschiedlich. guckst du: http://javatechniques.com/blog/faster-deep-copies-of-java-objects/
-
Und die Zusammenfassung? Ich muß mir eine eigene Methode schreiben und einsetzen, wenn ich mit dem Default-Verhalten des Zuweisungsoperator nicht einverstanden bin. Wo bitteschön unterscheidet sich das von C++ (abgesehen davon, daß ich die Methode in Java nicht "operator=" nennen kann)?
-
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.