#include <iostream>

typedef int Tfoo;

template<typename IMPL>
struct base
{
  base(Tfoo foo)
  : foo(foo)
  {
    reinterpret_cast<IMPL*>(this)->on_connect();
  }

  ~base()
  {
    reinterpret_cast<IMPL*>(this)->on_disconnect();
  }
private:
  Tfoo foo;
};

struct impl : base<impl>
{
private:
  typedef base<impl> base_type;
public:
  impl(Tfoo foo) : base_type(foo) {}

  void on_connect()
  {
    std::cout << "hello world!" << std::endl;
  }

  void on_disconnect()
  {
    std::cout << "good bye world!" << std::endl;
  }
};

int main()
{
	{
		Tfoo x = Tfoo();
		impl test(x);
	}

	std::cin.get();
}

Vermutlich ist der Aufruf im DTor definiert und der im CTor undefiniert(da impl noch nicht fertig konstruiert ist), richtig!?
Aber da es imho nur dieser Aufruf ist, der schief gehen wird(bzw. könnte), könnte man auch in impl im dtor das on_disconnect aufrufen und es wäre alles in Ordnung!?

Und ist es ein zumindest halbwegs sinnvoller Ansatz, um Verbindungs-Events zu signalisieren?

bb

Wieso nicht mit einem Scopeguard:

template<typename Guarded>
class ScopeGuard
{
public:
   ScopeGuard(Guarded & g) : guarded(g) { guarded.on_connect(); }
   ~ScopeGuard(){ guarded.on_disconnect(); }
private:
   Guarded & guarded;
};

int main()
{
    {
        Tfoo x = Tfoo();
        impl test(x); //jetzt ohne CRTP-Base
        ScopeGuard guard(test);
    }

    std::cin.get();
}

PS: Okay, ScopeGuard sollte bei Dir vielleicht AutoConnect oder so heißen. :xmas2:

mein ziel wäre es halt, dass man nur eine klasse für die verbindung schreiben muss und dann automatisch fkt. wie on_read, on_disconnect, on_connect aufgerufen werden würden...
das würde zwar auch mit runtime-polymorphie gehen, aber die ist hier ja eigtl nicht wirklich nötig - also wollt ich sie auch nicht unbedingt verwenden...

aber da der server-socket ja eh den verbindungstypen als template-argument bekommt, könnte ich dort zumindest das on_connect aufrufen, nachdem die verbindung erstellt wurde - nur die disconnect-notification bekommt man dort ja nicht mehr - also müsste man im dtor noch von hand on_disconnect aufrufen...
oder denk ich gerade zu kompliziert bzw. einfach falsch? ^^

bb

Aber da es imho nur dieser Aufruf ist, der schief gehen wird(bzw. könnte)

Da wäre ich mir nicht zu sicher. Beim reinterpret_cast habe ich kein gutes Gefühl, besonders wenn ein static_cast eher passt – mal ganz ungeachtet der Frage, ob das abgeleitete Objekt dann bereits konstruiert ist.

unskilled schrieb:

das würde zwar auch mit runtime-polymorphie gehen, aber die ist hier ja eigtl nicht wirklich nötig - also wollt ich sie auch nicht unbedingt verwenden...

Würde es wirklich? Du hättest dann einen virtuellen Aufruf im Konstruktor, das ist ebenso böse.

unskilled schrieb:

klingt eigtl gar nicht so schlecht - aber das ganze kann man nicht so einfach automatisieren...

Oder wenn du Tachyons AutoConnect zur Hauptkapselklasse ausbauen würdest? Sodass man gar keinen direkten Zugriff mehr auf impl hat (ein Name wie "impl" legt das ja auch nahe ;))? Eventuell in Kombination mit einer Factory? Nur ein paar Gedanken...

unskilled schrieb:

klingt eigtl gar nicht so schlecht - aber das ganze kann man nicht so einfach automatisieren...

Oder wenn du Tachyons AutoConnect zur Hauptkapselklasse ausbauen würdest? Sodass man gar keinen direkten Zugriff mehr auf impl hat (ein Name wie "impl" legt das ja auch nahe ;))? Eventuell in Kombination mit einer Factory? Nur ein paar Gedanken...

Jopp - das ist mir danach dann auch eingefallen - das ist aber schon wieder so viel Arbeit das alles zu ändern(und ab und an muss man da ja auch noch nachdenken >.<), dass ich jetzt erst mal nen paar Stunden anderweitig Zeit tot schlag xD

ty^^