Ansi C Operator überladen?

pale dog

Mr. N schrieb:

pale dog schrieb:

der wichtigste unterschied ist die zeit, die funktionsaufrufe brauchen.

Etwa 5 Takte. Außer natürlich ein Page Fault (schlimmstensfalls mit Laden ausm Swap) kommt dazwischen, aber das is ja auch bei normalem Speicherzugriff so.

das ist ja systemabhängig. auch wenn's weniger takte und alle interrupts disabled sind, es summiert sich aber auf...

Mr. N schrieb:

pale dog schrieb:
stell dir vor, du müsstest ~1MB byteweise von einem buffer an irgendeine hardware schaufeln oder umgekehrt. jeder funktionsaufruf in dem code würde zu 1040000 funktionsaufrufen:
for (long n=0; n<1040000; n++)
    send_over_spi (array[n]);
Das ist auch ohne array als Objekt bescheuert.

ist es. aber leider hat man nicht immer einen coprozessor oder 'ne DMA-logik, die der gequälten CPU sowas abnehmen könnten.

Mr. N schrieb:

pale dog schrieb:

...aber trotzdem behaupten viele immer noch, C++ wäre für hardwarenahe programmierung geeignet

Das ist jetzt polemisch...

ja, muss auch mal sein :p

Simon2 schrieb:

pale dog schrieb:

...
der wichtigste unterschied ist die zeit, die funktionsaufrufe brauchen....

Also nach einer Diskussion um Sprachkonsistenz kommst Du jetzt mit Performance ?

naja, Mr.N hat doch nach funktionsaufrufen gefragt und wann die stören könnten.

Mr. N

pale dog schrieb:

naja, Mr.N hat doch nach funktionsaufrufen gefragt und wann die stören könnten.

Nein, ich habe gefragt, wieso du bei der Unterscheidung so ne Krise kriegst.

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.

Übrigens: Für long long / __int64 wird auf deinem x86 bestimmt auch zur Multiplikation ein Funktionsaufruf verwendet. Ähnlich bei float und double auf Maschinen ohne FPU.

:p

pale dog

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.
ich würde mir das ding ganz genau ansehen wollen. es könnte sowas sein:

typedef unsigned char Array[MAXSIZE];

das wäre gut
es könnte aber auch sowas sein:

class Array
{
  ...
  public: int operator[](int i)
  {
    for (long s=0; l<0xfffff; s++)
    {
      // do smth. very useful here ;)
    }
    return calculated_value;
  }        
  ...
};

das wäre schlecht

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

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?

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.

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)