Ansi C Operator überladen?

CStoll

pale dog schrieb:

Ich weiß ja auch nicht was der Compiler aus einem builtin operator+ macht.

warum nicht? addition/multiplikation etc. hat fast jede CPU und wenn man sich mal den asm-output des compilers angeschaut hat, weiss man ungefähr, was der daraus macht. z.b. weiss man dann, dass zum addieren von 'ints' kein funktionsaufruf nötig ist (an beliebiger stelle). ein 16-bitter könnte für die addition zweier longs z.b. eine funktion aufrufen, für die addition zweier fliesskommawerte sowieso. das weiss man einfach, wenn man sein system kennt und manchmal ist dieses wissen von bedeutung.

Im Endeffekt ist trotzdem alles eine Funktion, auch wenn die teilweise inline aufgelöst werden könnten (aber das kann der Compiler je nach Typ auch mit deinen eigenen Operatoren machen)

rüdiger schrieb:

Ich kann die add-Methode auch a-Methode nennen und schon ist die ebenfalls sehr unscheinbar...

du siehst aber trotzdem, dass es eine funktion ist. egal wie sie heisst. wieviele funktionsaufrufe stecken wohl in:
sometype_t s;
othertype_t a;
for (s=0; s<100; s++)
  a[s] = s*s;
in C, mit kenntnis meiner target-CPU und meines verwendeten compilers weiss ich auf den ersten blick wieviele es sind. weisst du es auch in einer sprache, in der man die operatoren alle umdefinieren kann? wohl nur, wenn man sich vorher tonnenweise anderen code verinnerlicht hat.

Soll ich?

Default-Ctor von sometype_t
Default-Ctor von othertype_t
op=
op<
op++
op[]
op*
op=

Das macht 8 Funktionsaufrufe (und bis zu 7 Typ-Umwandlungen, um die Parameter zu korrigieren)

Simon2 schrieb:

pale dog schrieb:

...
klar, aber ich kann es erkennen, wenn ich den code sehe:...
hättest du aber einen der operatoren, das = oder das << überladen, dann würde man schon weniger aussagen über den code machen können:...

Sorry, aber warum ? operatoren SIND einfach nur Funktionen (die allerdings ein wenig einfacher aufgerufen werden können).

nicht immer. wir sind ja mittlerweile bei C++ gelandet, da gibt es beides, die selbstgemachten (operator() funktionen) und die eingebauten operatoren.

Die eingebauten Operatoren sind aus Sicht des Programmierers auch nur Funktionen (die der Compiler eventuell besonders gut optimieren kann).

Simon2 schrieb:

pale dog schrieb:

MFK schrieb:

pale dog schrieb:

in einem quelltext sieht man aber 'a = b + c;' und das sieht aus wie die addition zweier primitiver datentypen.

Das mag für dich so aussehen. Ich sehe da einen operator+ und einen operator=, und weiß, was das bedeuten kann.

und woher?...

Weil's im Quellcode so steht !

ja, aber in welchem? in der zeile 'a = b + c;' jedenfalls nicht.

Wo schaust du nach, wenn du z.B. "a.add(b);" liest und wissen willst, was es bedeuten soll? Richtig - in der Definition der Methode add(). Genauso sieht sich ein halbwegs erfahrener C++ Programmierer zunächst an, was hinter a, b und c steht, und findet in der entsprechenden Klassendefinition die richtigen Operatoren.

Apollon schrieb:

pale dog schrieb:

[...] aber echt übel: denk doch mal an C++ iostreams, wie da die shift-operatorn missbraucht werden.
*das* ist richtig mies!

Aber auch nur, weil Du die Analogie nicht raffst.

was hat ein- und ausgabe mit bitgeschubse zu tun?
genau so gut hätten sie operator+() für das hinzufügen in einen stream und operator-() für das auslesen von streams definieren können.
eine analogie (+ bedeutet etwas dazutun und - bedeutet etwas wegnehmen) ist da, aber käme dir das nicht seltsam vor: 'cout + "hello, world";'

Bei den Streams schiebt man nicht mehr einzelne Bits, sondern ganze Objekte - und da kannst du die Operatoren auch als Pfeile ansehen, die die Richtung vorgeben, in die die Daten fließen.

pale dog

MFK schrieb:

Du hast anscheinend so lange in deiner C-Welt gelebt, dass du Dinge wie Operatorüberladung nur ablehnen kannst, weil sie nicht in dein Weltbild passen.

total ablehnen würde ich nicht sagen, es ist nur sehr schwierig, op-overloading sinnvoll anzuwenden d.h. meistens macht es eben keinen sinn und in der realität entsteht oft fehlerträchtiger und schwer verständlicher code dadurch. um mal wieder C++ als negativbeispiel zu nehmen: viele C++-fans basteln sich stringklassen, oder benutzen vorhandene, bei denen der operator+() zum zusammenfügen von strings überladen ist. das mag im ersten augenblick intuitiv wirken, hat aber den haken, dass a+b nicht b+a ist. für mich wäre das z.b. ein grund, operator+() als stringverketter erst gar nicht in betracht zu ziehen.
(ich hoffe hier sind jetzt nicht zu viele 'man's drin)
übrigens, hier: http://richardhaleshawgroup.com/RHSGroup/Community/blogs/richard_hale_shaws_blog/archive/2005/10/06/176.aspx
wenn man diese liste beachtet, würde man op-overloading wahrscheinlich nie einsetzen...

CStoll schrieb:

was hat ein- und ausgabe mit bitgeschubse zu tun?
genau so gut hätten sie operator+() für das hinzufügen in einen stream und operator-() für das auslesen von streams definieren können.
eine analogie (+ bedeutet etwas dazutun und - bedeutet etwas wegnehmen) ist da, aber käme dir das nicht seltsam vor: 'cout + "hello, world";'

Bei den Streams schiebt man nicht mehr einzelne Bits, sondern ganze Objekte - und da kannst du die Operatoren auch als Pfeile ansehen, die die Richtung vorgeben, in die die Daten fließen.

okay, aber warum haben sie nicht operator=() genommen (dem stream etwas zuweisen)?
würde doch auch gehen, oder nicht?

CStoll

Ja, in manchen Fällen ist das eine Design-Entscheidung (und + für String-Verkettung ist möglicherweise grenzwertig), aber das ist kein generelles Problem der Sprache, sondern höchstens des Verständnisses. Jedes Sprachmittel hat sein Probleme und Fallstricke, aber deswegen macht es noch lange keinen Sinn, es zu verbieten.

pale dog

CStoll schrieb:

Jedes Sprachmittel hat sein Probleme und Fallstricke, aber deswegen macht es noch lange keinen Sinn, es zu verbieten.

da hast du recht, aber wenn jemand eine programmiersprache entwickelt, sollte er sich genau überlegen, was man einbaut, wie es funktioniert, welche vor- und nachteile dadurch entstehen, ob missbräuchliche anwendung forciert wird usw.usw...
sozusagen: 'usability' einer programmiersprache, auch in bezug auf les- und wartbarkeit von codes. das ist natürlich nicht einfach...

CStoll

Dann mach's besser Ich bin vielleicht nicht ganz so paranoid wie du, aber in meinen Augen sieht "a=b+c;" einfach besser und übersichtlicher aus als "a.assign(sum(b,c));" (außerdem ist die intuitive Bedeutung von Operatoren klarer als bei Funktionsnamen). Und Müll fabrizieren kann man mit beiden Konstruktionen genauso viel.

Also warum sollte man ein existierendes Sprachmittel (Operatoren) nur für eine kleine Gruppe an Datentypen erlauben, während alle anderen mit umständlichen Methodenverschachtelungen hantieren müssen?

Marc++us

@pale dog: ich verstehe Dein Problem nicht ganz. Ich gebe zu, daß man mit der Operatorüberladung furchtbare Dinge tun kann, z.B. einen Funktionsaufruf in ein + packen, das kann kein Mensch mehr lesen. [Es gab ein furchtbares Beispiel dafür in Borlands Fensterbibliothek TurboVision für DOS, so um 1994, da haben sie MenuItems mit + an die Menüs angehängt. In keiner Weise intuitiv.]

Aber was kann man daraus folgern? Nichts.

Denn es ist auch erlaubt, alle Klassennamen und Methodennamen mit nur einem Buchstaben zu benennen, oder man nennt alles a1, a2, a3, a4 - auch das wäre unlesbarer Code, und ist trotzdem legales C++ (bzw ist das Beispiel auf jede Sprache übertragbar).

Und ab dem Punkt sagt man eben "jeder Programmierer ist seines eigenen Glückes (und Unglückes) Schmied"... Sprachmittel unvernünftig einzusetzen lässt sich durch die Sprache selbst nicht wirklich verhindern. Schaffst Du das Mittel ab, finden findige Programmierer andere Wege, ihre Programme obfuscated zu machen.

Gast++

Hab den Thread mal quer gelesen und erspar es mir infolge des mittlerweile doch ergheblichen Umfanges jeweils zu zitieren. Es mag sein dass ich einiges wiederhole, das bitte ich die jeweiligen Urheber mir zu verzeihen.

"Missbrauch von '>>' und '<<' in der STL"
Genau diese Konstrukte waren für mich vor zehn Jahren der Grund es mal mit C++ zu versuchen.
Die sind intutiv zu verstehen und verschlanken den Code ungemein

Ein

printf("Hausnummer:%i\t Name:%s\n",42,"RMS")

isr sicherlich schwerer lesbar als das iostream-Pendant.

Konfusion
Als ich dann verstand dass man auch '[]' überladen kann war mir klar dass das die geeignte Sprache für mich wäre. Was soll

myVec[42];

denn wohl anderes sein das 43. Element von etwas Array-ähnlichem - dass man bei 0 anfängt weiss auch der "C"-ler.

Effizienz
"String + String ist ein Funktionsaufruf, a + b nicht" - das vergleicht Äpfel mit Birnen. Wenn man eine

class Int {/***/};

mit allen Operatoren denn zu brauchen meint könnte mandarüber hinaus die Operatoren auch noch

inline

deklarieren.

Und ob aus

int c = a + b;

nun wirklich einfach

push eax
mov  eax,a
add  eax,b
mov  c,eax
pop  eax

wird, mag ich auch noch bezweifeln.

Ich sehe überhaupt keine prinzipiellen Bedenken gegen Überladungen, ganz im Gegenteil: das Klassenkonzept von C++ ermöglicht es mit Überladungen das Verhalten einer Instanz in der "Aussenwelt", hier also die Sprachumgebung, genauestens zu definieren.
Dass man nicht mit

Int::operator+

substrahieren sollte verstehet sich wohl von selbst.

Ferner wird gegen C++ immer wieder mangelnde "Mächtigkeit" ( im Sinne von CPU-Befehlen pro Codezeile) ins Feld geführt; gerade aus der Java-Gemeinde.
Mit Operatoren kann ich ähnliche Mächtigkeit erreichen wie sie sonst nur Skriptsprachen anbieten; da sind die Operatoren halt nicht überladen sondern per se mehrdeutig.

Für mich ist es ein Qualitätsmerkmal einer allgemeinen Klasse wenn mehrere überladene Operatoren für sie definiert sind - z.B. gearde

ostream& operator<<(...)

weil sie dann viel schlanker zu verwenden ist.

Grüsse

Gast++

rüdiger

pale dog schrieb:

CStoll schrieb:

Jedes Sprachmittel hat sein Probleme und Fallstricke, aber deswegen macht es noch lange keinen Sinn, es zu verbieten.

da hast du recht, aber wenn jemand eine programmiersprache entwickelt, sollte er sich genau überlegen, was man einbaut, wie es funktioniert, welche vor- und nachteile dadurch entstehen, ob missbräuchliche anwendung forciert wird usw.usw...
sozusagen: 'usability' einer programmiersprache, auch in bezug auf les- und wartbarkeit von codes. das ist natürlich nicht einfach...

Ich finde den Weg mit Operator-Überladung sinnvoll. Er passt einfach zur Objekt Orientierung. Wenn man Operatoren hat, dann sollten diese auch für Objekte umrüstbar sein.

Besser als eine Programmiersprache wo künstliche Barrieren gezogen werden und Klassen keine Typen sind und alles was man mit Variablen machen kann mit Objekten nicht funktioniert vice versa. Das sieht imho nach nicht verstandenem OOP oder aufgefrickeltem OOP aus.

(Und böse Sachen kann ich gerade in C mit allen Sprachmitteln machen #define int double )

pale dog schrieb:

rüdiger schrieb:

pale dog schrieb:

rüdiger schrieb:

Und wieder: Wo ist der Unterschied zwischen einer Methode add und einem operator+ ?

der operator+ erscheint, wenn er benutzt wird, nicht als 'operator+' sondern als einfaches '+' d.h. man sieht ihm in seiner unscheinbarkeit nicht an, dass sich dahinter ein ganzer wust von code verbirgt. bei einer funktion 'add()' dagegen (auch wenn ihr name irreführend sein mag), sieht jeder blinde mit krückstock den funktionsaufruf und kann konsequenzen berücksichtigen, die dadurch entstehen.

Ich weiß ja auch nicht was der Compiler aus einem builtin operator+ macht.

warum nicht? addition/multiplikation etc. hat fast jede CPU und wenn man sich mal den asm-output des compilers angeschaut hat, weiss man ungefähr, was der daraus macht. z.b. weiss man dann, dass zum addieren von 'ints' kein funktionsaufruf nötig ist (an beliebiger stelle). ein 16-bitter könnte für die addition zweier longs z.b. eine funktion aufrufen, für die addition zweier fliesskommawerte sowieso. das weiss man einfach, wenn man sein system kennt und manchmal ist dieses wissen von bedeutung.

Und ich denke hier sieht man genau das Problem. Du entwickelst eben viel für Embedded Systeme und (meinst zumindest) den Wert eines jeden Operators zu kennen.

_Aber_ du weißt ja selbst, dass das was passiert vom Typ abhängt. Also von dem verwendeten Operator oder sagen wir um es konform zu halten. Wie der Operator für den Builtin-Typ überladen wurde. Bei a+b weißt du nicht was der Compiler machen wird. Wenn es foats sind wird er was ganz anderes machen als bei ints. Wo ist also der Unterschied ob du nun der Unterschied ob wir neben float und int auch noch bignum und vector haben? (ganz zu schweigen davon, dass der Compiler selbst bei der Addition von zwei Integern je nach Situation ganz unterschiedliche Konstrukte bauen wird)

rüdiger schrieb:

Ich kann die add-Methode auch a-Methode nennen und schon ist die ebenfalls sehr unscheinbar...

du siehst aber trotzdem, dass es eine funktion ist. egal wie sie heisst. wieviele funktionsaufrufe stecken wohl in:
sometype_t s;
othertype_t a;
for (s=0; s<100; s++)
  a[s] = s*s;
in C, mit kenntnis meiner target-CPU und meines verwendeten compilers weiss ich auf den ersten blick wieviele es sind. weisst du es auch in einer sprache, in der man die operatoren alle umdefinieren kann? wohl nur, wenn man sich vorher tonnenweise anderen code verinnerlicht hat.

Nein weißt du nicht. Du musst dazu die Typen von s und a kennen uns selbst wenn, ist das Beispiel ja ideal, weil der Compiler hier viel optimieren kann. Erzeugt er SIMD-Instruktionen, wird aus dem s*s ein pow(s,2), macht er eine einfache Schleife oder löst er das schon zur Compile-Zeit auf?

Marc++us schrieb:

Und ab dem Punkt sagt man eben "jeder Programmierer ist seines eigenen Glückes (und Unglückes) Schmied"... Sprachmittel unvernünftig einzusetzen lässt sich durch die Sprache selbst nicht wirklich verhindern. Schaffst Du das Mittel ab, finden findige Programmierer andere Wege, ihre Programme obfuscated zu machen.

Man kann mit jeder Programmiersprache Blödsinn machen und Sprachfeatures missbrauchen. Außerdem: Wer will schon eine Programmiersprache die sich wie eine Programmiernanny aufführt?

Simon2

rüdiger schrieb:

...Wer will schon eine Programmiersprache die sich wie eine Programmiernanny aufführt?

Hmmmmmmmmmm - nein, ich sag's doch lieber nicht.

Gruß,

Simon2.

pale dog

Marc++us schrieb:

Sprachmittel unvernünftig einzusetzen lässt sich durch die Sprache selbst nicht wirklich verhindern. Schaffst Du das Mittel ab, finden findige Programmierer andere Wege, ihre Programme obfuscated zu machen.

klar, aber dann macht man's ja mit absicht.
mit op-überladung baut man sich obfuscation ein, obwohl man's eigentlich gut meint.

Gast++ schrieb:

"Missbrauch von '>>' und '<<' in der STL"
Genau diese Konstrukte waren für mich vor zehn Jahren der Grund es mal mit C++ zu versuchen.

im ernst? ich fand an C++ (damals) konstruktoren/destruktoren virtuelle funktionen und vererbung toll.
'<<' und '>>' fand ich aber schon immer schrecklich.

Gast++ schrieb:

Ein
printf("Hausnummer:%i\t Name:%s\n",42,"RMS")
isr sicherlich schwerer lesbar als das iostream-Pendant.

naja, kommt drauf an. wenn man bei cout erst anfängt mit 'manipulators' herumzufummeln, dann geht's mit printf oft einfacher. cout versucht ja auch anhand des typs die richtige ausgabe zu machen, was z.b. bei 'volatile' voll daneben geht.

Gast++ schrieb:

Effizienz
"String + String ist ein Funktionsaufruf, a + b nicht" - das vergleicht Äpfel mit Birnen....

so ist es. denn op-overloading lässt äpfel wie birnen und birnen wie äpfel aussehen

Gast++ schrieb:

Und ob aus
int c = a + b;
nun wirklich einfach
push eax
mov  eax,a
add  eax,b
mov  c,eax
pop  eax
wird, mag ich auch noch bezweifeln.

vielleicht nicht exakt so, wie du's hier zeigst, aber annähernd so, jedenfalls ohne irgendwelche calls dazwischen.

Gast++ schrieb:

Für mich ist es ein Qualitätsmerkmal einer allgemeinen Klasse wenn mehrere überladene Operatoren für sie definiert sind - z.B. gearde
ostream& operator<<(...)
weil sie dann viel schlanker zu verwenden ist.

schlank? ja, du musst wenig quelltext schreiben um diese funktionalität zu nutzen, aber was compiler und linker daraus machen ist alles andere als schlank

Mr. N

pale dog schrieb:

so ist es. denn op-overloading lässt äpfel wie birnen und birnen wie äpfel aussehen

Was ist der Unterschied zwischen einem Funktionsaufruf und sonst irgend einem Code? Ich sehe da keinen fundamentalen Unterschied.

pale dog

Mr. N schrieb:

pale dog schrieb:

so ist es. denn op-overloading lässt äpfel wie birnen und birnen wie äpfel aussehen

Was ist der Unterschied zwischen einem Funktionsaufruf und sonst irgend einem Code? Ich sehe da keinen fundamentalen Unterschied.

der wichtigste unterschied ist die zeit, die funktionsaufrufe brauchen.
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]);

mal angenommen 'array' ist eine schicke, nach allen regeln der OOP designten klasse, der operator[] ist überladen und macht einen bereichs-check
wenn man glück hat, kann man die funktionsaufrufe mit inline weg kriegen. ist aber nur glück, denn 'inline' heisst für den c++ compiler: 'mach mir bitte-bitte-bitte keinen funktionsuafruf rein', doch wenn der compiler nicht will denkt er 'leck mich' (und schweigt sich drüber aus).
aber angenommen er ist so gnädig und macht es doch, dann hast du immer noch die bereichsprüfung drin, die alles ausbremst.
und um beim thema zu bleiben: dem [] sieht man's nicht an...
...aber trotzdem behaupten viele immer noch, C++ wäre für hardwarenahe programmierung geeignet

Mr. N

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.

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.

pale dog schrieb:

mal angenommen 'array' ist eine schicke, nach allen regeln der OOP designten klasse, der operator[] ist überladen und macht einen bereichs-check

Sowas macht doch keiner ... Oder halt nur als assert, aber das is dann ja egal.

pale dog schrieb:

wenn man glück hat, kann man die funktionsaufrufe mit inline weg kriegen. ist aber nur glück, denn 'inline' heisst für den c++ compiler: 'mach mir bitte-bitte-bitte keinen funktionsuafruf rein', doch wenn der compiler nicht will denkt er 'leck mich' (und schweigt sich drüber aus).

Der Compiler entscheidet da in der Regel sehr vernünftig. Anhand so Regeln wie (keine Garantie, ob die zutrifft):

Ist der vollständig optimierte Funktionscode größer oder kleiner als 64 KB? Wenn er kleiner ist, wird er geinlinet, sonst nicht. Sowas finde ich vernünftig.

pale dog schrieb:

aber angenommen er ist so gnädig und macht es doch, dann hast du immer noch die bereichsprüfung drin, die alles ausbremst.

Klar. Hat man aber nicht .

pale dog schrieb:

und um beim thema zu bleiben: dem [] sieht man's nicht an...

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.

pale dog schrieb:

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

Das ist jetzt polemisch...

Simon2

pale dog schrieb:

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

Also nach einer Diskussion um Sprachkonsistenz kommst Du jetzt mit Performance ?
Und die soll schlechter werden, wenn man dem User ermöglicht (wohlgemerkt: Nicht zwingt !!), eigene Varianten zu schreiben ?

Sehe ich wirklich nicht.

Gruß,

Simon2.

rüdiger

pale dog schrieb:

Mr. N schrieb:

pale dog schrieb:

so ist es. denn op-overloading lässt äpfel wie birnen und birnen wie äpfel aussehen

Was ist der Unterschied zwischen einem Funktionsaufruf und sonst irgend einem Code? Ich sehe da keinen fundamentalen Unterschied.

der wichtigste unterschied ist die zeit, die funktionsaufrufe brauchen.

Aber den braucht er ja auch, wenn man keine Operator-Überladung sondern eine Methode genommen hätte...

(ganz zu schweigen davon, dass der Compiler den Operator ja inlinen kann...)

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.