c++ vs. java... was hat zukunft

[Gregor]

Simon2 schrieb:

Meinst Du, ein operator=() wäre zu billig für das, was er kann ?
So viel teurer ist ein clone() coh auch nicht.

Ui... Du weißt ja gar nicht, wie teuer es ist, ein funktionierendes clone zu programmieren. ...abgesehen davon assoziiert man mit einem "=" natürlich etwas ganz anderes als mit einem ".clone()".

...aber von der Benutzung von clone wird in Java eh abgeraten. ...zu Recht.

[Gregor]

CStoll schrieb:

@Grogor: In C++ kannst du auch mit Referenzen und Zeigern arbeiten. Aber im Gegensatz zu Java kannst du selber entscheiden, wo du Zeiger verwendest und wo nicht.

Ich bin mir darüber im Klaren. Man mag es nicht für möglich halten, aber selbst ich habe schonmal C++ Code produziert.

[Simon2]

Also wenn man die Sprache nicht kennt, assoziiert man mit "=" sowieso einen Vergleich und keine Zuweisung; wenn man sie kennt, assoziiert man doch genau das: Eine Zuweisung. .... und mehr macht doch C++ auch nicht; nur dass man dort definieren kann, was man unter der Zuweisung eines Objekts an ein Anderes versteht.

Daneben gibt es noch die "Initialisierung mit =", die nur eine andere Schreibweise für den Aufruf eines CopyCtors ist; die finde ich persönlich ebenfalls intuitiv (wobei ich zugeben muss, dass dadurch "in der Breite" wohl mehr Verwirrung als Klärung entsteht).

Gruß,

Simon2.

[dot]

Simon2 schrieb:

Daneben gibt es noch die "Initialisierung mit =", die nur eine andere Schreibweise für den Aufruf eines CopyCtors ist; die finde ich persönlich ebenfalls intuitiv (wobei ich zugeben muss, dass dadurch "in der Breite" wohl mehr Verwirrung als Klärung entsteht).

muss nicht unbedingt ein CopyCtor sein. wenngleich intuitiv, ist afaik, aus syntaktischen gründen, in C++ die initialisierung mit = manchmal notwendig

[rüdiger]

Warum gibt es für die String-Klasse überhaupt eine Operator-Überladung in Java? Gerade dort ist sie doch eher fehl am Platz. Außerdem halte ich es für fehleranfällig das andere Typen implizit in ein String umgewandelt werden.

So wie ich es verstanden habe gib

1+2+"3"

etwas anderes als

"1"+2+3

Warum nimmt man also den operator+, wenn man sich noch nicht einmal an die Semantik des Operators hält?

Und warum wird einem teilweise eine Ähnlichkeit von Variablen und Zeigern vorgespielt? Das ist doch alles sehr verwirrend und sehr inkonsistent. Die Inkonsistenz geht ja auch bei den Literalen weiter. Es gibt für jeden Typ ein Literal, aber für die String-Klasse gibt es auch ein Literal (wenn ich es richtig verstanden habe). Gibt es zB auch für BigInteger ein Literal?

Gerade für die Zwecke für die Java hier beworben wird, sind andere Programmiersprachen doch eher geeignet. Wie ich schon einmal gefordert habe. Nennt mir ein Argument für Java ohne C++ zu erwehnen (und das Argument darf auf keine andere Programmiersprache in besserer Form zutreffen). :p

@Gregor

Als ich 2001 in dieses Forum gekommen bin, hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. Das deutet schonmal darauf hin, dass die Standardisierung von der Infrastruktur bzw. von der Organisation her nicht besonders sorgfältig oder professionell ist.

Die ISO-Kommission bringt eben keine Implementierung raus

Was genau meinst Du eigentlich?

Artchi beschwert sich doch zB immer, das man für die IBM-Produkte nur Java 1.4 benutzen kann.

Das ist denke ich auch ein Problem. Die Java-Releases sind ja nicht abwärts kompatibel. Wie lange pflegt SUN eine alte Java-Version? Werden Bugs/Sicherheitsprobleme etc. regelmäßig geupdatet oder werde ich gezwungen upzugraden?

[Simon2]

dot schrieb:

...
muss nicht unbedingt ein CopyCtor sein....

Stimmt !
Aber wo ist die Initialisierung syntaktisch notwendig ? Fällt mir gerade kein Beispiel zu ein...

Gruß,

Simon2.

[Gast]

Gregor schrieb:

Tim schrieb:

Gregor schrieb:

Insofern sollte man vielleicht doch nochmal genauer hingucken, ob man Java diesbezüglich sofort abschreiben kann.

Kann man. Für Echtzeitanwendungen nimmt man heute offensichtlich Python: http://www.google.de/search?q=realtime+python (1.440.000 hits)

Dein Link ist gut. Deine Schlussfolgerung nicht.

Was mich jetzt interessieren würde: Wo würdest du die Vorteile von Java für Echtzeitanwendungen sehen?

[pale dog]

dot schrieb:

pale dog schrieb:

hat es in einer OOP-sprache aber diverse nachteile.

würd mich jetzt interessieren welche das sind.

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

[Simon2]

pale dog schrieb:

dot schrieb:

pale dog schrieb:

hat es in einer OOP-sprache aber diverse nachteile.

würd mich jetzt interessieren welche das sind.

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

Also das sehe ich nun wirklich nicht als "Nachteil für eine OOP-Sprache". Ich kann in Java ebenso "unnütze Objekte erzeugen", weil ich mich mit der Sprache nicht auskenne (seien es nun "tote news" oder die berühmten "Situationen, wo man besser stringbuffer nehmen sollte")... und letztlich konnte C das auch schon.

Für einen C++er ist eben = nicht das "nahezu kostenlose Kopieren einer Referenz", sondern eine Objektoperation wie jede andere auch.

Gruß,

Simon2.

[Gregor]

Tim schrieb:

Was mich jetzt interessieren würde: Wo würdest du die Vorteile von Java für Echtzeitanwendungen sehen?

Es sind genau die gleichen Vorteile, wie auch in allen anderen Bereichen. ...denke, da wurde schon einiges zu gesagt. Ich habe nicht gesagt, dass sich Java "ganz besonders" für Echtzeitanwendungen eignet. Aber die Vorteile, die man in Java sehen kann, sind struktureller Natur und können somit auf alles bezogen werden, wo Java prinzipiell einsetzbar ist.

[dot]

Simon2 schrieb:

Aber wo ist die Initialisierung syntaktisch notwendig?

sry, da hab ich mich wohl veplappert^^ mir is nur unlängst mal bei nem template was passiert und er hielt ne variablendefinition dann für eine funktionsdeklaration.
das war aber ne dummheit meinerseits.

pale dog schrieb:

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

ich kann da aber nirgendwo ein problem mit dem verhalten des zuweisungsoperators erkennen.

[finix]

Jester schrieb:

CStoll schrieb:

Selbst wenn du der Meinung bist, daß diese Sichtweise konsistent ist, erklärt das noch immer nicht die Unterschiede zwischen Build-in Typen und eigenen Klassen.

Welche Unterschiede denn? Nochmal: Es gibt eingebaute Datentypen und Referenzen. Wo unterscheidet sich da jetzt was?

Du kannst keine Datentypen definieren die sich wie Built-ins verhalten.

[finix]

pale dog schrieb:

dot schrieb:

pale dog schrieb:

hat es in einer OOP-sprache aber diverse nachteile.

würd mich jetzt interessieren welche das sind.

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

Das hat jetzt genau was mit "OOP-Sprache" zu tun?

[Jester]

finix schrieb:

Jester schrieb:

Welche Unterschiede denn? Nochmal: Es gibt eingebaute Datentypen und Referenzen. Wo unterscheidet sich da jetzt was?

Du kannst keine Datentypen definieren die sich wie Built-ins verhalten.

Boah, das ist echt anstrengend hier. Vielleicht magst Du mal nachlesen worum es gerade geht?

[pale dog]

finix schrieb:

pale dog schrieb:

dot schrieb:

pale dog schrieb:

hat es in einer OOP-sprache aber diverse nachteile.

würd mich jetzt interessieren welche das sind.

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

Das hat jetzt genau was mit "OOP-Sprache" zu tun?

ach, du weisst doch, wie ich das meinte, für die 'sprache' an sich ist es natürlich egal, aber ich wollte darauf hinweisen, dass eben das erbe von C für ein 'OO programmiersystem' (ich sag jetzt nicht sprache ;)) nicht unbedingt vorteilhaft ist.
...und wieso die C++ fans aus dieser not immer eine tugend machen wollen, ist mir schon immer suspekt gewesen.

[dot]

pale dog schrieb:

dass eben das erbe von C für ein 'OO programmiersystem' (ich sag jetzt nicht sprache ;)) nicht unbedingt vorteilhaft ist.

wo genau liegt das problem daran?

[lokos]

Es gibt keine Objektorientierten Sprachen, es gibt nur bjektorientiertes Programmieren. Manche Sprachen unterstützen einen dabei mehr, andere weniger.

[pale dog]

dot schrieb:

pale dog schrieb:

dass eben das erbe von C für ein 'OO programmiersystem' (ich sag jetzt nicht sprache ;)) nicht unbedingt vorteilhaft ist.

wo genau liegt das problem daran?

naja, einiges,
C hat pointer --> C++ braucht etliche workarounds, genannt 'smart pointers'
C hat malloc/free --> C++ erfindet das rad neu, nennt es aber new/delete und zusätzlich delete[], weil's ja so intuitiv ist
C hat structs --> C++ nennt selbiges 'class', weil class sich nun mal mehr nach OOP anhört.
C hat einen void* --> C++ zwar auch, aber wozu braucht man ihn da?
to be continued...

btw: ich will damit nicht über C herziehen, ich mag C

[dot]

pale dog schrieb:

C hat pointer --> C++ braucht etliche workarounds, genannt 'smart pointers'

1. C++ hat ganz normale pointer
2. es handelt sich um keine workarounds
3. C++ stellt sie zur verfügung, es braucht sie nicht

pale dog schrieb:

C hat malloc/free --> C++ erfindet das rad neu, nennt es aber new/delete und zusätzlich delete[], weil's ja so intuitiv ist

1. new/delete machen nicht das gleiche wie malloc/free, niemand hat also das rad neu erfunden. es wurde lediglich der luftreifen draufgebaut.

pale dog schrieb:

C hat structs --> C++ nennt selbiges 'class', weil class sich nun mal mehr nach OOP anhört.

C++ class/structs haben aber mit C structs nicht viel am hut

pale dog schrieb:

C hat einen void* --> C++ zwar auch, aber wozu braucht man ihn da?

im prinzip für das gleiche wofür man ihn in C braucht.

pale dog schrieb:

to be continued...

gut

anyway, man kann C++ gleich wie java mögen oder nicht. die frage war: wo bitte liegen jetzt "diverse nachteile" in bezug auf OOP? das da oben ist nur eine (nur teilweise richtige) liste mit einigen wenigen der unterschiede zwischen C und C++!?

[rüdiger]

pale dog schrieb:

C hat pointer --> C++ braucht etliche workarounds, genannt 'smart pointers'

C++ braucht keine Workarrounds. Gibt ja auch normale Pointer in C++. Smart-Pointers gibt es nur für den Komfort und Exception-Sicherheit. Da muss man sich in C selbst drum kümmern.

C hat malloc/free --> C++ erfindet das rad neu, nennt es aber new/delete und zusätzlich delete[], weil's ja so intuitiv ist

zusätzlich new[]/delete[]. Weil malloc/free eben nicht mit Konstruktoren zusammen geht. Wäre wohl dämlich, wenn man Objekte noch explizit konstruieren müsste.

C hat structs --> C++ nennt selbiges 'class', weil class sich nun mal mehr nach OOP anhört.

C structs kann man ja auch nicht mit C++ class vergleichen. Und das man es class nennt ist ja wohl auch klar

C hat einen void* --> C++ zwar auch, aber wozu braucht man ihn da?

gar nicht, weil man C++ anders programmiert als C.