von c nach c++

chabayo

Ist eine Member-Funktion im Objekt selbst nicht (sozusagen) statisch??

Soll nicht heissen das ich dir nicht glaube (Gott bewahre), aber statische Funktionen wohl doch deshalb, weil wenn das Objekt zerstoert wuerde die Referenz nicht weiter Geltung haben koennte.

Aber im Objekt selbst ist die Funktion doch immer vorhanden...oder klappt das dann eher nicht, weil c-Funktionen einer c++-Klasse nicht dafuer ausgelegt sind mehrere Instanzen zu referenzieren?

Ich mein, um es direkt anzusprechen: das Gtk-Objekt Window dem das Signal zugeordnet wird ist ja selbst Member des selben Objektes wie die Signal-Funktion.

Erhard Henkes

Es gibt sehr gute C++-Tutorials:
http://www.henkessoft.de/C++/Links/links.htm

Gute C++-Tutorials:
Wolfgang Schröder
Toni Schornböck
Thomas Thron
Volkard Henkel

CStoll

chabayo schrieb:

Ist eine Member-Funktion im Objekt selbst nicht (sozusagen) statisch??

Nicht direkt. Eine Memberfunktion muß wissen, mit welchem Objekt sie hantieren soll, deshalb bekommt sie einen zusätzlichen Parameter "T* const this" übergeben (wie genau das aussieht, hängt von deinem Compiler ab). Und dieser Zusatzparameter ruiniert den Versuch, Memberfunktionen direkt zu übergeben.

mem_fun trennt diese Verbindung wieder auf, indem es einen "normalen" Funktionsaufruf in einen Methodenaufruf umwandeln kann. Alternativ könntest du um jede Callback-Funktion eine statische Hilfsfunktion wrappen (die das Zielobjekt entweder als Parameter erhält oder von woanders bekommt).

chabayo

CStoll schrieb:

chabayo schrieb:

Ist eine Member-Funktion im Objekt selbst nicht (sozusagen) statisch??

Nicht direkt. Eine Memberfunktion muß wissen, mit welchem Objekt sie hantieren soll,

...soll also heissen das eine Klasse im Speicher nur einmal vorhanden ist, und jedes Objekt den selben Code abarbeitet. (Ok, nicht gerade Weltbewegend diese Einsicht)

deshalb bekommt sie einen zusätzlichen Parameter "T* const this" übergeben (wie genau das aussieht, hängt von deinem Compiler ab). Und dieser Zusatzparameter ruiniert den Versuch, Memberfunktionen direkt zu übergeben.

mem_fun trennt diese Verbindung wieder auf, indem es einen "normalen" Funktionsaufruf in einen Methodenaufruf umwandeln kann. Alternativ könntest du um jede Callback-Funktion eine statische Hilfsfunktion wrappen (die das Zielobjekt entweder als Parameter erhält oder von woanders bekommt).

...ok, hat also etwas mit dem Argumentenstack zu tun, und dieser Art von Code ein ganz klares Fallbeispiel von c!=c++ ... hat aber jetzt >60 Minuten gedauert bis ich das begreifen konnte.

Danke CStoll - war toll...

joomoo

CStoll schrieb:

mem_fun trennt diese Verbindung wieder auf, indem es einen "normalen" Funktionsaufruf in einen Methodenaufruf umwandeln kann.

Wie würde man das ganze denn mit mem_fun lösen? Das mit der statischen Funktion kann ja nicht das Wahre sein, oder?

mfg.

Mathias

Nein, man würde es nicht mit mem_fun lösen und die statischen Funktionen sind normalerweise auch nicht das Wahre.

Die statischen Funktionen erhöhen meiner Meinung nach nur den Schreibaufwand, während ich mit mem_fun anfange meine Objekte in Teile zu zerlegen, mit denen man alleine nichts anfangen kann.
(Wenn ich objektorientiert programmiere (C++) ist es eine Vergewaltigung des Objektes, weil ich funktional auf den Objekten rumhample und wenn ich funktional programmiere (C) kann es eigentlich nicht sein, dass ich Wissen über die Implementierung von Objekten in C++ in funktionalen Code umsetzen muss.)

P.S.: In C++ braucht man normalerweise keine Funktionspointer. (Da kann man entweder gleich das Objekt übergeben oder man arbeitet mit Funktoren (Objekte, die sich wie Funktionen verhalten).)

chabayo

...es war mir bei meinem letzten Post scheinbar so klar...

...dann wieder nicht...und dann doch wieder...

...das Problem dabei ist also:

a) die Implementation der Signalbehandlung (ich weiss nicht wie man das nennt, hat ja nen speziellen Namen) ist auf c ausgelegt, und hat damit keinen Platz das (extra) Argument #T* const this# aufzunehmen...

b) und kann damit diesen Pointer den ein c++ Compiler in die stack-Operationen einbindet nicht bieten.

...

Das heisst nun man muesste einem Objekt ein paar Funktionen (wie CStoll anfuehrte) beistellen, welche dem Signal-(na wie bezeichnet man das Ding) der c-GTK-API uebergeben wird, und welche (von der technischen Aufgabe her) lediglich die zustaendige Methode eines Objektes instantiiert.

D.h. das jedes Objekt (Instanz einer Klasse!?) im Code seine eigene Funktion haben muss, weil ja der Aufruf object.methode() fuer jede Instanz von #object#
extra (anders) sein muss. Also:

function 1object_wrapper () { 1object.methode() }
function 2object_wrapper () { 2object.methode() }
function 3object_wrapper () { 3object.methode() }

...

Gedankenspiel:

Wenn aber der T* const this von der groesse her gleich dem gpointer data waere, frage ich mich ob es nicht eine Funktion geben koennte die die Argumentenliste so verdreht das der Platz im Stack der fuer den gpointer data vorgesehen wahr vom T* const this aufgefuellt wird, den ganzen speicherbereich so rotiert das der Pointer auf dem richtigen Byte steht, kann das nicht funktionieren!? warum?

Mathias

Man braucht nicht für jedes Objekt eine statische Funktion, sondern muss für die jeweilige Funktionalität also Memberfunktion ein statisches Gegenstück programmieren. Dieses greift dann intern auf die Memberfunktion des Objekts zu das verwendet werden soll.

class A
{
static A* pObject;

bool TestMe () { return true; }

static void SetObject (A* pO)
{ pObject = pO; }

static bool Test ()
{  if (pObject != NUL)
       return pObject->TestMe ();
   return false;
}
};

Der Umweg über die statische Variable ist nicht sehr schön aber an irgendeiner Stelle muß man ja die Objekte austauschen können.

Etwas komplizierter wird es natürliche wenn man mehrere Objekte des gleichen Typs z.B. bei einem Eventhandler anmelden möchte, das hat man allerdings auch in C wenn man eine Funktion n-mal anmeldet...

CStoll

chabayo schrieb:

Wenn aber der T* const this von der groesse her gleich dem gpointer data waere, frage ich mich ob es nicht eine Funktion geben koennte die die Argumentenliste so verdreht das der Platz im Stack der fuer den gpointer data vorgesehen wahr vom T* const this aufgefuellt wird, den ganzen speicherbereich so rotiert das der Pointer auf dem richtigen Byte steht, kann das nicht funktionieren!? warum?

Wenn die signal()-Funktion auich Parameter bereitstellen kann, könntest du diese ja nutzen:

class A
{
  bool test() { return true; }

public:
  static int test_static(void* ob)
  {
    return static_cast<A*>(ob)->test();
  }
};

...
A ob1,ob2;

g_signal_connect ( (gpointer) window , "focus-in-event" , A::test_static, ob1);
g_signal_connect ( (gpointer) window , "focus-in-event" , A::test_static, ob2);
//ich vermute mal, daß die signal() den letzten Parameter an ihre Signalfunktion weitergibt

joomoo

Gibt's da noch eine einfachere Version, sodass ich nicht ob-> vor meine Variablen schreiben muss?

mfg.