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

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?

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'

C++ hat ganz normale pointer
es handelt sich um keine workarounds
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

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.

pale dog

okay jungs, ich wusste dass ihr das nicht nicht so hinnehmen würdet
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!
sieht das jemand anders?

btw: PHP war ursprünglich auch rein prozedural, wurde dann aber um OO features erweitert - und - was soll ich sagen? es wirkt auf mich genau so zusammengefrickelt wie C++, das dereinst aus C entstanden ist.

dot

pale dog schrieb:

okay jungs, ich wusste dass ihr das nicht nicht so hinnehmen würdet
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!
sieht das jemand anders?

ich seh jedenfalls, dass das nicht beantwortet, warum oben von dir genannte punkte zu "diversen nachteilen" bei OOP führen.

DEvent

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.

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?

Technisch unterscheidet sich das vielleicht nicht, aber semantisch - Build-ins stehen für sich selbst, Referenzen für jemand anderes.

Nein, man kann es auch so sehen: Es gibt eine abzählbare Menge von Buildin-Objekten. Die bei Programmstart (oder wann auch immer) erzeugt werden.

int a = 5;
int b = a;
b = b + 5;

Die Referenz "a" zeigt auf das Object "5". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "5". Dann zeigt die Referenz auf das Objekt 10. Die Referenz a wird aber nicht verändert, sie zeigt immernoch auf das Objekt 5.

Foo a = new Foo();
Foo b = a;
b.add(5);

Die Referenz "a" zeigt auf das Object "Foo_1". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "Foo_1". Dann verändere ich den Zustand von dem Objekt "Foo_1". Die Referenz a und b wird aber nicht verändert, sie zeigt immernoch auf das Objekt "Foo_1".

(mit "zeigt" meine ich "referenziert")

Somit kriegt man wirklich nie in Java die richtigen Objekte in die Hand, sondern nur Referenzen darauf. Genauso wie bei echten Objekten und wie bei Buildins. Ist das jetzt konsitent genug?

Wer übrigens Operatorüberladungen in Java haben will, da gibt es so ein Projekt, das die Sprache Java bereichert. Ist aber 100% kompatibel zu dem normalen Java, weil die Operator-Aufrufe in normale Methoden-Aufrufe umgewandelt werden.

Übrigens: Wenn man will das eine Methode (add, sub, mul, ...) bei Zahlen-Klassen immer die selbe ist, kann man sich ja eine Klassenhierachie bauen oder ein Interface definieren.

Die Generics sind in Java gut, den sie erfüllen das was man von ihnen wollte: Statische Typsicherheit. Wer auf Perfomance aus ist, der kann die Java-Native-Collection-Lib benutzen. Da gibts die FloatArray, FloatList usw. Und wenn man unbedingt Perfomance braucht, der will auch bestimmt ganz genau definieren mit welchem Datentyp man arbeiten sollte. Also sehe ich dort kein Vorteil von Generalizität. Wenn du einen beliebigen Datentyp hinwirfst, dann kann man deine Micro-Verbesserungen eh vergessen.

Gast++

Im Kreis ich finde wir uns drehen...

Deshalb versuch ich einfach nochmal eine kleine Fallstudie anzuregen:

http://www.c-plusplus.net/forum/viewtopic-var-p-is-1290219.html

Die Erkenntnis dem Programmierer aus dem Tun fliesst zu!

Grüsse

*this

Töss,

was ne scheiß Diskussion, die eh zu keinem Resultat kommt...

Bitte bei 100 Seiten schliessen, damit der dämliche Thread verschwindet!!!

Post 2

Post 3

Post 4

Post 5

Post 6

Post 7

Post 7

Post 8

Post 9