Klassenmethoden vs Funktionen

Hi,
in einem meiner Bücher steht, daß der Aufwand, der für den Aufruf von Klassenmethoden betrieben werden muss, 'erheblich' höher gegenüber gewöhnlicher Funktionen ist. Leider wird nicht näher darauf eingegangen, und genau das interessiert mich doch so sehr .
Weiss hier jemand näheres dazu, wie gross der Unterschied tatsächlich ist und wovon das abhängt?
Wären demnach diese 2 Funktionen in deren Ausführungseffektivität wirklich verschieden?

//Klassenmethode
void klasse::func() {}
//funktion
void func(klasse& obj) {}

icb bin kein speedfreak oder ähnliches, mich interessiert nur die Technik dahinter .

Grüsse
Chris

ach ja , die zweite Funktionen in meinem Beispiel ist NICHT Element der Klasse.

Konrad Rudolph

Welches Buch war das? Kann es sein, dass sich der Autor auf virtuelle Methoden bezog? Denn eine nicht-virtuelle Methode sollte in den meisten Implementierungen *dasselbe* sein wie eine gewöhnliche Funktion -- und damit auch nicht langsamer.

CStoll

technisch gesehen dürfte es kaum Unterschiede zwischen beiden Varianten geben - zumindest solange du es mit einer "normalen" (einfachen) Methode zu tun hast. In der Regel bekommen Klassenmethoden lediglich einen zusätzlichen Parameter 'klasse*const this', über den sie auf die Klassenmember zugreifen können.

Interessant wird es erst, wenn virtuelle Methoden und Polymorphie ins Spiel kommen. Bei einer virtuellen Methode hängt es von dynamischen Typ des Objekts ab, welche Funktion tatsächlich aufgerufen wird - und dazu muß das Programm vor dem Aufruf erst herausfinden, welche Typ das Objekt hat.
(idR bekommt das Objekt dafür einen zusätzlichen vptr, der auf eine Tabelle mit "seinen" Methoden zeigt - beim Aufruf wird erst der vptr zur vtable verfolgt und dort dann die Methode rausgesucht, die dran kommt)

Erstmal danke für die Anworten.
Ist aus dem Buch c++ von A bis Z , Zitat:
4.3.1 Inline-Methoden(explizit und implizit)
Wie Sie bereits bei den Funktionen erfahren haben, stellt ihr Aufruf keinen unerheblichen Aufwand da(Stichwort: Stack(-Frame)). Dasselbe gilt auch in Bezug auf die Klassenmethoden, die im Grunde auch nur Funktionen(für eine Klasse) sind. Im Gegensatz zu "gewöhnlichen" Funktionen ist der Aufwand, der für den Aufruf von Klassenmethoden betrieben werden muss, noch erheblich höher.
---

Dann wird weiter auf inline eingegangen.

ups wieder was vergessen. Das thema viruelle Funktionen ist noch weit entfernt.

Konrad Rudolph

Also, aus dem Zitat schließe ich, dass der Autor sich wahrscheinlich implizit auf virtuelle Funktionen bezieht -- oder einfach keinen blassen Schimmer hat, das glaube ich zwar eher weniger, das Buch "C++ von A bis Z" hat aber durchaus einige Fehler drin.

queer_boy

das ist schlicht und einfach blödsinn. man kann nicht void (*)() mit void (klasse::*) () vergleichen, wenn dann müsste man die elementfunktion mit einer void (*)(klasse*) vergleichen. zählt man noch den aufwand bei der wartung (den vorteil von klassen) hinzu, dann sind elementfunktionen wahnsinnig viel effizienter als äquivalente freistehende funktionen. genauso kann man auch mit virtuellen funktionen argumentieren: wenn man die funktionalität nachbilden wollte, würde man wohl selbst so etwas wie einen vptr implementieren - inklusive der nachteile, dass man sich dann auch selbst darum kümmern müsste und die arbeit nicht dem compiler abgeben könnte.

Konrad Rudolph

queer_boy schrieb:

genauso kann man auch mit virtuellen funktionen argumentieren: wenn man die funktionalität nachbilden wollte, würde man wohl selbst so etwas wie einen vptr implementieren - inklusive der nachteile, dass man sich dann auch selbst darum kümmern müsste und die arbeit nicht dem compiler abgeben könnte.

Das halte ich für falsch, denn virtuelle Funktionen sind eine Technologie, welche für *ein Paradigma* benötigt werden -- nämlich OOP. Oft kann man dieselbe Lösung aber auch durch andere Paradigmen erreichen, ohne die komplette Funktionalität virtueller Funktionen abbilden zu müssen. Ich spreche speziell von generischer Programmierung und den Techniken der Funktionsüberladung und partiellen Template-Spezialisierung von Klassen.

finix

queer_boy schrieb:

das ist schlicht und einfach blödsinn. man kann nicht void (*)() mit void (klasse::*) () vergleichen, wenn dann müsste man die elementfunktion mit einer void (*)(klasse*) vergleichen.

Rat einfach mal was jeder hier im Thread, einschließlich des OPs, getan hat?

queer_boy schrieb:

zählt man noch den aufwand bei der wartung (den vorteil von klassen) hinzu, dann sind elementfunktionen wahnsinnig viel effizienter als äquivalente freistehende funktionen.

Äh? Klassen mit minimaler Methodenanzahl sind überschaubarer, hinzufügen oder entfernen von Operationen erfordert keine Neukompilation unbeteiligten Codes, weniger potenzielle Fehlerquellen aufgrund interner Zustände.

queer_boy schrieb:

genauso kann man auch mit virtuellen funktionen argumentieren: wenn man die funktionalität nachbilden wollte, würde man wohl selbst so etwas wie einen vptr implementieren - inklusive der nachteile, dass man sich dann auch selbst darum kümmern müsste und die arbeit nicht dem compiler abgeben könnte.

Richtig. Du vergisst allerdings zu erwähnen dass dies nur einmal implementiert werden muss, und dabei den Vorteil hat dass man das Objektsystem seinen Bedürfnissen anpassen kann.