Ansi C Operator überladen?

[lolz]

pale dog, ss hat gar keinen Sinn (mehr) mit dir zu diskutieren. Auf jeder Seite sagen mehrere Leute, dass du ständig Argumente gegen die OP nennst die für alle Formen von Funktionen gelten. Aber trotzdem tust du es immer wieder...

[Christoph]

pale dog schrieb:

dem array-index operator sieht man die internen schweinereien nicht an.
soviel (neben bei noch) zum thema 'information hiding'

Aus diesem Grund gibt es in guter Dokumentation die O-Notation oder ein Hinweis auf die verwendete Implementierung.
Auf normalen CPUs (nicht Mikrocontroller) ist es doch relativ egal ob da nun ein paar Takte mehr oder weniger verbraucht werden, solange der Algorithmus passt. In den seltenen Fällen wo die letzten Millisekunden benötigt werden, kann man immer noch später optimieren.

[pale dog]

lolz schrieb:

pale dog, es hat gar keinen Sinn (mehr) mit dir zu diskutieren.

naja, das glaube ich auch
wir haben mittlerweile alle pros und cons von op-überladung aufgezählt, haben unsere ansichten mitgeteilt und uns nicht frech dabei angepöbelt. so muss das sein.
mir fällt jedenfalls nix mehr ein, also lasst uns aufhören.
hat jedenfalls spass gemacht...

[mikey]

Spaß macht sowas immer. Schlimm wird es erst dann, wenn Gegner und Befürworter keine Einigung finden, bzw. pro und contra nicht einsehen können, sondern immer stur ihre felsenfeste Meinung durchsetzen wollen.

[DEvent]

Doch, man sieht sofort, dass das ein potenzieller Funktionsaufruf ist, wenn das Objekt von keinem Primitivtypen ist. Und den Typen muss man ja eh kennen.

Mal ein kurzer Einwand, ich dachte eben darum ging es doch: Man soll den Typen nicht kennen. Ob es ein primitiver Typ ist oder nicht, man wendet die Operatoren wie gewohnt an.

Deswegen gibt es doch die primitiven Typen in modernen OOP-Sprachen doch immernoch: Man will etwas atomares, etwas "Hardwarenahes". Das hat man mit den primitiven Typen. Das wiederspricht sich aber mit Operatorüberladung: Denn Operatoren sind auch etwas atomares.

Meine Vorderung wäre: Entweder primitive Typen oder Operatorüberladungen. Wenn man Operatorüberladungen zulässt, dann soll bitte auch alles ein Objekt sein, damit es nichts mehr atomares in der Sprache gibt.

[Mr. N]

DEvent schrieb:

Man soll den Typen nicht kennen.

Ob ich ein int oder ein double dividiere ist nicht egal. So ergebnismäßig.

[rüdiger]

DEvent schrieb:

Deswegen gibt es doch die primitiven Typen in modernen OOP-Sprachen doch immernoch:

hö?

Man will etwas atomares, etwas "Hardwarenahes".

hö?

Das hat man mit den primitiven Typen.

hö?

Das wiederspricht sich aber mit Operatorüberladung: Denn Operatoren sind auch etwas atomares.

hö?

Wer ist "man"? Du?

[Gast]

DEvent schrieb:

Deswegen gibt es doch die primitiven Typen in modernen OOP-Sprachen doch immernoch: Man will etwas atomares, etwas "Hardwarenahes".

Dass primitive Typen nicht unbedingt "atomar" oder "hardwarenah" sind, wurde hier im Thread schon an Beispielen genannt.

[DEvent]

Tim schrieb:

DEvent schrieb:

Deswegen gibt es doch die primitiven Typen in modernen OOP-Sprachen doch immernoch: Man will etwas atomares, etwas "Hardwarenahes".

Dass primitive Typen nicht unbedingt "atomar" oder "hardwarenah" sind, wurde hier im Thread schon an Beispielen genannt.

Das habe ich wohl übersehen. Primitive Typen sind aber in dem Sinn des Wortes atomar, da man sie nicht weiter zerlegen kann. Ein Objekt kannst du in seine Methoden und Attribute zerlegen, einen primitive Typen nicht.

@rüdiger:
Wieso ist den in Java und C# primitiven Typen wie int, float, double, usw. immernoch enthalten? Wieso gibt es Wrapper-Klassen für diese Typen? Wieso hat man nicht gleich die primitiven Typen als Objekte konzepiert, die ebenfalls von Object abgeleitet sind?

[rüdiger]

DEvent schrieb:

@rüdiger:
Wieso ist den in Java und C# primitiven Typen wie int, float, double, usw. immernoch enthalten? Wieso gibt es Wrapper-Klassen für diese Typen? Wieso hat man nicht gleich die primitiven Typen als Objekte konzepiert, die ebenfalls von Object abgeleitet sind?

Das soll jetzt was beweisen? Gerade in Java und C# sind die Builtin-Typen doch nicht hardwarenahe oder atomar.

[Ben04]

DEvent schrieb:

Primitive Typen sind aber in dem Sinn des Wortes atomar, da man sie nicht weiter zerlegen kann. Ein Objekt kannst du in seine Methoden und Attribute zerlegen, einen primitive Typen nicht.

Naja, Threads sehen das leicht anderes und sowieso geht folgendes:

union Foo{
  int a;
  char b[sizeof(int)];
};

Obwohl int primitive ist kann es noch weiter zerlegt werden. :p

Den Zusammenhang mit Operatoren ergibt sich mir jedoch nicht. Erwartet irgend jemand ernsthaft von:

Matrix<2, 2> a, b;
a += b;

dass += sich auf genau eine Prozessorbefehl abbilden lässt?

[Bashar]

man Vektorbefehle

SCNR

[Zeus]

Technisch gesehen hat C# keine Datentypen, dass sind alles Datentypen aus der Runtime.

[Zwergli]

DEvent schrieb:

@rüdiger:
Wieso ist den in Java und C# primitiven Typen wie int, float, double, usw. immernoch enthalten? Wieso gibt es Wrapper-Klassen für diese Typen? Wieso hat man nicht gleich die primitiven Typen als Objekte konzepiert, die ebenfalls von Object abgeleitet sind?

Wieder mal C# und Java über ein Kamm gescherrt oder? Nur Java kennt diese primitiven Datentypen mit Wrapperklassen. C# hat diese nicht, sondern da sind die Datentypen von Object abgeleitet. Wobei Zeus Kommentar natürlich richtig ist, das sind CLR Datentypen und nicht C# Datentypen. Wobei die C# Spec schon die CLR bedingt, von daher sinds doch die Datentypen von C#

[Simon2]

pale dog schrieb:

Mr. N schrieb:

Du bist auf das wichtigste übrigens nicht eingegangen:

Mr. N schrieb:

Doch, man sieht sofort, dass das ein potenzieller Funktionsaufruf ist, wenn das Objekt von keinem Primitivtypen ist. Und den Typen muss man ja eh kennen.

ja, muss man auch.
man muss sein innenleben kennen, damit man damit nicht auf die nase fällt....

Nein - muss man nicht ! Ein vernünftig designter operator ist selbsterklärend.
Bei einer Funktion habe ich viel öfter die Notwendigkeit, mir anzusehen, was sie wirklich macht, weil es einfach viel mehrdeutiger ist, was z.B. clear(), erase(), ... machen könnte.

pale dog schrieb:

ich würde mir das ding ganz genau ansehen wollen....

Warum ? Das mag vielleicht ein persönliche Vorliebe von Dir zu sein - nötig ist es nicht (mehr als bei normalen Funktionen).

Gruß,

Simon2.

[pale dog]

Simon2 schrieb:

pale dog schrieb:

Mr. N schrieb:

Du bist auf das wichtigste übrigens nicht eingegangen:

Mr. N schrieb:

Doch, man sieht sofort, dass das ein potenzieller Funktionsaufruf ist, wenn das Objekt von keinem Primitivtypen ist. Und den Typen muss man ja eh kennen.

ja, muss man auch.
man muss sein innenleben kennen, damit man damit nicht auf die nase fällt....

Nein - muss man nicht ! Ein vernünftig designter operator ist selbsterklärend.
Bei einer Funktion habe ich viel öfter die Notwendigkeit, mir anzusehen, was sie wirklich macht, weil es einfach viel mehrdeutiger ist, was z.B. clear(), erase(), ... machen könnte.

pale dog schrieb:

ich würde mir das ding ganz genau ansehen wollen....

Warum ? Das mag vielleicht ein persönliche Vorliebe von Dir zu sein - nötig ist es nicht (mehr als bei normalen Funktionen).

ich wollte mich künftig eigentlich raushalten aus der diskussion, aber - jetzt muss ich doch noch mal antworten
[] ist ungleich [] (siehe mein posting, das du teilweise zitiert hast)
das eine ist ein simpler array-zugriff, das andere ist ein überladener operator.
ersteres ist in wenigen µS von jedem 8-bitter erledigt, das andere stellt hohe anforderungen an die maschine.
vielleicht kannst du's nicht nachvollziehen, weil du ohne zu zucken >600MB fette libraries benutzt (boost), oder ein .NET framework oder was-weiss-ich...
aber diese beiden [], die im quelltext gleich aussehen, sind definitiv unterschiedlich

[rüdiger]

pale dog schrieb:

ich wollte mich künftig eigentlich raushalten aus der diskussion, aber - jetzt muss ich doch noch mal antworten
[] ist ungleich [] (siehe mein posting, das du teilweise zitiert hast)
das eine ist ein simpler array-zugriff, das andere ist ein überladener operator.
ersteres ist in wenigen µS von jedem 8-bitter erledigt, das andere stellt hohe anforderungen an die maschine.

Achtung, schockierende Neuigkeiten für dich. In C (oder vermutlich auch Java) ist / ungleich / und + ungleich + und das ganz ohne Operator-Überladung. Skandal!

(Ganz zu schweigen davon, dass der überladene op[] per definition nicht langsam sein muss, in den meisten Fällen dürfte ja wieder ein array-zugriff in µS rauskommen. Wenn der überladene op[] komplex ist, dann wäre dies auch eine Methode at() und man kommt ja eh nicht drum rum diese dann aufzurufen)

[CStoll]

pale dog schrieb:

Simon2 schrieb:

pale dog schrieb:

Mr. N schrieb:

Du bist auf das wichtigste übrigens nicht eingegangen:

Mr. N schrieb:

Doch, man sieht sofort, dass das ein potenzieller Funktionsaufruf ist, wenn das Objekt von keinem Primitivtypen ist. Und den Typen muss man ja eh kennen.

ja, muss man auch.
man muss sein innenleben kennen, damit man damit nicht auf die nase fällt....

Nein - muss man nicht ! Ein vernünftig designter operator ist selbsterklärend.
Bei einer Funktion habe ich viel öfter die Notwendigkeit, mir anzusehen, was sie wirklich macht, weil es einfach viel mehrdeutiger ist, was z.B. clear(), erase(), ... machen könnte.

pale dog schrieb:

ich würde mir das ding ganz genau ansehen wollen....

Warum ? Das mag vielleicht ein persönliche Vorliebe von Dir zu sein - nötig ist es nicht (mehr als bei normalen Funktionen).

ich wollte mich künftig eigentlich raushalten aus der diskussion, aber - jetzt muss ich doch noch mal antworten
[] ist ungleich [] (siehe mein posting, das du teilweise zitiert hast)
das eine ist ein simpler array-zugriff, das andere ist ein überladener operator.
ersteres ist in wenigen µS von jedem 8-bitter erledigt, das andere stellt hohe anforderungen an die maschine.

Und der Vorteil der Operator-Überladung ist, daß dir das im Grunde egal sein kann (aber diesen Punkt scheinst du noch nicht kapiert zu haben). Beides stellt technisch gesehen einen Index-Zugriff dar. Punkt.

vielleicht kannst du's nicht nachvollziehen, weil du ohne zu zucken >600MB fette libraries benutzt (boost), oder ein .NET framework oder was-weiss-ich...

Wenn es dir um Performance geht, kannst du ja drangehen und die verwendeten Operatoren durchoptimieren. Aber technisch macht es keinen Unterschied, ob du den Index-Zugriff auf eine Array-Klasse nun als "normale" Methode at() oder als operator[] realisierst (und aus Sicht eines C++ Programmierers ist letzteres konsequenter - C-style Arrays werden schließlich auch nicht über Methoden indiziert).

PS: Und Boost als "Gesamtwerk" ist vielleicht 600MB groß - für eine konkrete Anwendung mußt du aber nur einzelne Teilbibliotheken verwenden, die dann deutlich kompakter sind. (und du ersparst dir damit den Aufwand, entsprechende Aufgaben nochmal neu zu lösen ;))

[pale dog]

CStoll schrieb:

Und der Vorteil der Operator-Überladung ist, daß dir das im Grunde egal sein kann

es kann mir nicht egal sein und es ist mir nicht egal.
ich setze nun mal andere prioritäten.

CStoll schrieb:

(aber diesen Punkt scheinst du noch nicht kapiert zu haben).

doch, hab' ich. mit überladenen op's werden benutzern von objekten bekannte syntaxelemente in die hand gegeben, die ihnen das handling mit diesen objekten erleichern.
seiteneffekte, nebenwirkungen u.ä. sind (mit aufgesetzten C++ scheuklappen) 'egal'
frei nach dem motto: 'es ist egal wie der hase läuft, hauptsache er läuft'

[CStoll]

Wenn du Probleme mit C++ Sprachmitteln hast, kannst du gerne in deiner C-Welt bleiben. Andernfalls solltest du wenigstens versuchen, die Vorteile von C++ zu sehen.

Ich für meinen Teil finde es auf jeden Fall konsequenter, wenn ich meine eigenen Zahlenklassen in einer natürlichen Syntax verrechnen kann oder auf Elemente eines Arrays per op[] zugreife als wenn ich dafür umständlich verschachtelte Funktionsaufrufe verwenden müsste (bei int/double bzw. C-style Arrays klappt das schließlich auch).

PS: Klar - jedes Sprachmittel kann man verwenden, um die Sprache aus den Angeln zu heben (das geht sogar mit C-Mitteln). Aber das ist noch lange kein Grund dafür, es zu verbieten. Und wenn doch, wo ziehst du die Grenze der "Zulässigkeit"?