Verleitet C++ zum komplizierteren denken?

knivil schrieb:

C++ ist nicht dazu gemacht, jeden Scheiss anzubieten.

doch, ist es. die tendenz war schon immer da. mit C++0x geht's lustig weiter in die richtung.

volkard

audacia schrieb:

class Stone
{
    void foo (void);
};

(void)?

knivil schrieb:

Du willst mir jetzt sagen, was der Erfinder von C++ sich gedacht hat aber dennoch nicht erreicht hat? Und dann sowas wie OOP in C++ produziert hat? So in der Art: was will mir der Autor damit sagen?

lies mal meinen Satz - da geht es um die Erfinder der OOP, nicht um den Erfinder von C++. Das ist nicht das selbe. Um die Sache abzukürzen:

„I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.“

(Turing-Preisträger A.Kay)

volkard

Also eins kann ich Euch sagen: Die Erfinder der natürlichen Zahlen hatten nicht im Sinn, daß es mal Gigabytefestplatten gibt.
(frei nach u_ser-l)

volkard

u_ser-l schrieb:

lies mal meinen Satz - da geht es um die Erfinder der OOP, nicht um den Erfinder von C++. Das ist nicht das selbe.

Sag mir, wer die OOP erfunden hat, und zeige mir eine Quelle, die Deine Behauptung stützt.

u_ser-l schrieb:

...da geht es um die Erfinder der OOP, nicht um den Erfinder von C++. Das ist nicht das selbe. Um die Sache abzukürzen:
„I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.“
(Turing-Preisträger A.Kay)

alan kay war smalltalk-freak. der erfinder von c++ hat sich aber an simula orientiert (auch 'ne oo-sprache), weil er die schon kannte.

volkard schrieb:

Sag mir, wer die OOP erfunden hat

http://de.wikipedia.org/wiki/Alan_Kay
(unter 'leistungen')

volkard

#fricky schrieb:

volkard schrieb:

Sag mir, wer die OOP erfunden hat

http://de.wikipedia.org/wiki/Alan_Kay
(unter 'leistungen')

Scherzkeks!
1970 am Palo Alto Research Center wurde Smalltalk gebaut.
Da war Objektorientierte Programmierung in Simula und Lisp schon eine halbe Ewigkeit im Gange.
Außerdem wollte ich mit der Frage nicht zeigen, daß Du die Historie nicht kennst, sondern u_ser-ls letztes Fragment einer Argumentation entwurzeln.
Du darfst bei Simula weitersuchen.

audacia

volkard schrieb:

audacia schrieb:
class Stone
{
    void foo (void);
};
(void)?

Hm?

volkard

audacia schrieb:

volkard schrieb:
audacia schrieb:
class Stone
{
    void foo (void);
};
(void)?
Hm?

Das (void) da ist sehr ungewöhnlich. Das war mal in C nötig, weil () beliebig viele Argumente akzeptierte (Ich hoffe, daß es inzwischen auch in C repariert worden ist.).

knivil

u_ser-l schrieb:

lies mal meinen Satz - da geht es um die Erfinder der OOP, nicht um den Erfinder von C++. Das ist nicht das selbe.

Ich weiss, dass das nicht das gleiche ist. Aber impliziet sagst du, dass C++ als auch der Erfinder dieser Sprache OOP nicht verstanden hat.

nein, das sage ich nicht und würde mir ein solches Urteil auch nie anmaßen wollen.

Ich sage lediglich, daß C++ unter den vorgegebenen Randbedingungen (Kompatibilität mit C inkl. Hardwarenähe, statische Typisierung) kompliziert sein muß. Darunter fallen syntaktische Klimmzüge und Einschränkungen in der Expressivität, von denen dynamisch typisierte OOP-Sprachen unberührt bleiben.

volkard

u_ser-l schrieb:

Ich sage lediglich, daß C++ unter den vorgegebenen Randbedingungen (Kompatibilität mit C inkl. Hardwarenähe, statische Typisierung) kompliziert sein muß. Darunter fallen syntaktische Klimmzüge und Einschränkungen in der Expressivität, von denen dynamisch typisierte OOP-Sprachen unberührt bleiben.

Das kann sogar sein. Warum nicht gleich so?

*john 0

u_ser-l schrieb:

Ich sage lediglich, daß C++ unter den vorgegebenen Randbedingungen (Kompatibilität mit C inkl. Hardwarenähe, statische Typisierung) kompliziert sein muß. Darunter fallen syntaktische Klimmzüge und Einschränkungen in der Expressivität, von denen dynamisch typisierte OOP-Sprachen unberührt bleiben.

Das ist aber kein Designfehler von C++! Es war sogar erklärtes Ziel so vorzugehen, da Stroustrup seine negativen Erfahrungen mit Simula gesammelt hatte. Ganz im Gegenteil war Stroustrup zu Anfangs von Simula begeistert. Denn dynamisch typisierte Sprachen haben nämlich ihre eigenen Probleme, und das ist vor allem die Tatsache, daß sie relativ langsam sind. Dank des Vorschritts sind Computer mittlerweile für viele Anwendungsfälle schnell genug, so daß man da Sprachen mit vielen dynamischen Elemente einsetzen kann. Aber fürs Numbercrunching sind solche Sprachen nicht geeignet - viel zu langsam.

Dann kommt natürlich noch der Designaspekt dazu. Bei dynamisches Sprachen setzt man auf Unit Testing mit Fehlern zur Laufzeit, und in statischen Sprachen setzt man auf Typfehler während der Übersetzung des Programms (siehe SPARK).

Wichtig ist nun, daß man die Sprache passend zum Anwendungsfall auswählt. Wenn die Sprache nicht zum Problem paßt, dann ist das nicht ein Fehler der Sprache sondern des Entwicklers.

*john 0

u_ser-l schrieb:

ja, so ist es - OOP sollte eigentlich die Programmierung syntakisch wie semantisch vereinfachen, und tut das auch in vielen Sprachen, aber bei C/C++ liegt der Sonderfall vor, daß Objektprogrammierung im Rahmen einer statisch typisierten Sprache weitgehend nur simuliert wird, was (im Verein mit der C-Kompatibilität) die bekannten syntaktischen Klimmzüge erforderlich macht.

Da wird nicht simuliert! Es ist echtes OOP! Einiges wird in C++ nicht direkt unterstützt, aber das trifft etwa auch auf Smalltalk zu. Was von OOP-Ideologen oft als einzig wahres OOP definiert wird. Simula ist übrigens älter als SmallTalk.

Einfaches Beispiel:
In SmallTalk kann man nicht befriedigend die Vektor-Matrix-Multiplikation umsetzen, da man immer wieder in Probleme läuft. Die Auswahl der richtigen Muliplikation hängt nämlich vom Typ beider Argumente der Multiplikation ab, und das kann man im klassischen Modell "Nachricht wird an Objekt versendet" nicht abbilden. Dazu bedarf es dann des Multiple Dispatchs Patterns etwa von CLOS. Ist somit SmallTalk gar keine OOP-Sprache?

~john schrieb:

Wichtig ist nun, daß man die Sprache passend zum Anwendungsfall auswählt. Wenn die Sprache nicht zum Problem paßt, dann ist das nicht ein Fehler der Sprache sondern des Entwicklers.

so ist es. dann erzähl uns doch mal zu welchem anwendungsfall C++ passt.

~john schrieb:

In SmallTalk kann man nicht befriedigend die Vektor-Matrix-Multiplikation umsetzen, da man immer wieder in Probleme läuft. Die Auswahl der richtigen Muliplikation hängt nämlich vom Typ beider Argumente der Multiplikation ab,

verstehe ich nicht - wenn die Matrix ein Array von Zeilen ist, und jede Zeile ein Array von Werten, dann implementiert jede Zeile und auch die Matrix den do: Iterator - man geht mit Matrix do: ... über alle Zeilen a_i, in jeder Zeile mit Array do: ... über die Elemente a_ij, holt dabei vom Vektor das j-te Elemente v_j; bildet dann für jede Zeile i: s_i = sum_j a_ij * v_j und gibt das Array der s_i zurück.

~john schrieb:

Es ist echtes OOP!

es ist das Maximum an OOP, was man realisieren kann, ohne die Kompatibilität mit C aufzugeben.

Abgesehen davon, Zeiger, mit denen man im Speicher spazierengehen kann, widersprechen den OO-Prinzipien. Statisch getypte Variablen widersprechen der Polymorphie von Bezeichnern. Richtige OO sieht nun mal anders aus. Für reine OO braucht man fast keine Syntax außer "Objekt Nachricht" und evtl. ein paar Regeln für Blocks [ .. | ... ].

volkard

u_ser-l schrieb:

verstehe ich nicht - wenn die Matrix ein Array von Zeilen ist, und jede Zeile ein Array von Werten, dann implementiert jede Zeile und auch die Matrix den do: Iterator - man geht mit Matrix do: ... über alle Zeilen a_i, in jeder Zeile mit Array do: ... über die Elemente a_ij, holt dabei vom Vektor das j-te Elemente v_j; bildet dann für jede Zeile i: s_i = sum_j a_ij * v_j und gibt das Array der s_i zurück.

Da hat aber jemand die Objektprogrammierung nicht verstanden.

*john 0

u_ser-l schrieb:

verstehe ich nicht

Ok, für die Anhänger der Philosophie "Typfehler werden durch Unit Testing abgefangen" war das ein schlechtes Beispiel. Es ist nicht alles eine Matrix, aber das ist euch nicht beizubringen. Es gibt trotzdem Beispiel bei denen Multiple Dispatching notwendig ist.

u_ser-l schrieb:

es ist das Maximum an OOP, was man realisieren kann, ohne die Kompatibilität mit C aufzugeben.

Ich wußte schon immer, daß die ganzen C++ Nörgler Unwissende sind. Aber danke, daß du das jetzt bestätigst. Nein, das ist nicht das Maximum, Objective-C hat denselben Dispatching Mechanismus wie SmallTalk. Bei C++ war der Verzicht auf dynamic dispatching eine bewußte Designentscheidung, weil das dynamic dispatching langsam ist. Auch 40 Jahre später ist das immer noch so.

~john schrieb:

u_ser-l schrieb:

es ist das Maximum an OOP, was man realisieren kann, ohne die Kompatibilität mit C aufzugeben.

Nein, das ist nicht das Maximum, Objective-C hat denselben Dispatching Mechanismus wie SmallTalk.

Gut, dann ist C++ nicht das maximal Mögliche an OO unter Wahrung der C-Kompatibilität. Ist das jetzt auf einmal ein Vorzug von C++ ?