борьба с шаблонами

[Dimka]

Вад, реальные типы можно сравнить через

Код: (C++)

typeid(*this) == typeid(T)

(требует include<typeinfo>).

[Алексей++]

сделал родительский класс весь шаблоном - оказалось так будет лучше . Только разнести в h и cpp не удалось - компилиться всё компилилось, а потом всё, что в cpp - unresolved symbol )))

[Вад]

Если я правильно всё помню, по стандарту весь код шаблона должен быть в заголовке. На то есть резон: весь код шаблона должен быть доступен по месту специализации шаблона, поскольку шаблон сам по себе - не тип: он описывает семейство типов (классов или функций). И каждая специализация генерирует свой отдельный тип (входящий в семейство), с полным набором методов, используя код шаблона. Ведь для каждого типа-аргумента шаблона требуется сгенирировать набор методов по заданному образцу (вот хотя бы как в примере с new-delete: нужно для каждого типа сгенерировать отдельный код, который вызывает именно для этого типа операторы new или delete). Примерно такой принцип.

[Алексей++]

а ещё такой вопрос - по идее, конструктор и деструктор в данном коде после подстановки в шаблон будут иметь имена Child и ~Child()
Почему это не вызывает конфликта с именами методов в самом классе Child , вызовы происходят нормально- порядок проверил в отладчике (1,2,3,4)

Код:

template<class T>
class Parent
{
public:
	Parent<T>()
	{
		// 1
	}

	virtual ~Parent<T>()
	{
		// 4
	}
};

class Child : public Parent<Child>
{
public:
	Child()
	{
		// 2
	}

	virtual ~Child()
	{
		// 3
	}
};

void main()
{
	Child A;
}

[Вад]

Parent<Child> - это полноценный тип, его в общем случае можно использовать непосредственно (как vector<int>, например). У него будут свои конструктор и деструктор, сгенерированные из шаблона.

[Алексей++]

какая то непонятная проблема.

сначала пример, который работает как надо

Код:

struct sss0
{
	void fff0()
	{
		int iii=1;
		OnReceive();
	}

	virtual void OnReceive()
	{
		int iii=1;
	}
};


template<class T>
struct sss1: public sss0
{
	virtual void OnReceive();
	virtual void MyReceive();
};

template<class T>
void sss1<T>::OnReceive()
{
	MyReceive();
}

template<class T>
void sss1<T>::MyReceive()
{
	int iii=1;
}


struct sss2:public sss1<sss2>
{
	virtual void MyReceive();
};

void sss2::MyReceive()
{
	int iii=1;
}

вызов:

sss2 S2;
S2.fff0();
//как и хотелось, попадаем в -> sss2::MyReceive()


--------------------------------------------------------------
теперь так:

Код:

template<class T, int nN>
class CParent: public CAsyncSocket
{
private:
	virtual void OnReceive(int nErrorCode);

	virtual void MY_OnReceive();
};


template<class T, int nN>
void CParent<T,nN>::OnReceive(int nErrorCode)
{
	MY_OnReceive();
}

template<class T, int nN>
void CParent<T,nN>::MY_OnReceive()
{
	int iii=1;
}

//-----------------------------------------------

class Child : public CParent<Child,10>
{
public:
	virtual void MY_OnReceive();
};

void Child::MY_OnReceive()
{
	int iii=1;
}

CAsyncSocket - это MFC-шный асинхронный сокет, у него имеется виртуальная void OnReceive() , которая вызывается, когда пришли какие то данные. Так вот, происходит почему то следующее:

Код:

//где то внутри вызвалась
CAsyncSocket::OnReceive();

	//попали в
	CParent<T,nN>::OnReceive()

		//пришли в
		CParent<T,nN>::MY_OnReceive()

		//хотя должны были придти в Child::MY_OnReceive() !!!

где ошибка ?


Код выше и ниже вроде одинаковый, либо у меня уже просто ступор и что то я не вижу

[Dimka]

Алексей1153++, private-члены не наследуются. Вообще сочетание private и virtual смысла не имеет. Замени private на protected.

[Алексей++]

не помогло

[Алексей++]

а чего эт они, кстати, не наследуются ? Непонимяу

[Вад]

Алексей1153++, потому что они private. Доступны только данному классу (ну и друзьям, емнип). По стандарту так

[Алексей++]

тогда почему же

template<class T>
struct sss1: public sss0
{
   virtual void OnReceive();
   private: virtual void MyReceive();
};

sss2 S2;
S2.fff0();

прекрасно работает ? )

[Dimka]

Алексей1153++, потому что в обоих классах оба методы (с одинаковой сигнатурой) объявлены виртуальными. В таблице виртуальных функций есть только одна ссылка на метод с такой сигнатурой. Объект с точки зрения класса-предка думает, что обращается к своему закрытому методу на уровне класса предка, но тот же объект с точки зрения класса-потомка, конструктор которого выполнялся позже конструктора предка, заменил для этой сигнатуры старый адрес на адрес своего метода.

Тем не менее наследования тут нет. Это два одноимённых метода, причём второй (в потомке) заменяет первый. Достигаемый эффект полиморфизма - это торчащие из реализации языка уши, то, что называется "дырявой абстракцией". Смена сигнатуры метода у потомка приведёт к развалу всего механизма работы.

[Алексей++]

ну переделал на protected, один хрен, загадка какая то

[Алексей++]

уже матерюсь вслух )))

ну никак...

а вот так попробовал - всё отлично

Код:

template<class T, int nN>
class CParent: public CAsyncSocket
{
	protected:
	void OnConnect(int nErrorCode);
	virtual void MY_OnReceive();
};


template<class T, int nN>
void CParent<T,nN>::OnConnect(int nErrorCode)
{
	MY_OnReceive();
}

template<class T, int nN>
void CParent<T,nN>::MY_OnReceive()
{
	int iii=1;
}

//-----------------------------------------------

class Child : public /*CAsyncSocket//*/CParent<Child,10>
{
	protected:
	void MY_OnReceive();
};

void Child::MY_OnReceive()
{
	int iii=1;
}


Child SSSSS;
SSSSS.Create(0,SOCK_STREAM,FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT | FD_CLOSE);

int sailen;
sockaddr_in sai;
sailen=sizeof(sai);
sai.sin_family=AF_INET;
sai.sin_port=0;
sai.sin_addr.s_addr=0;

SSSSS.Connect((sockaddr*)&sai,sailen);

после неудачного коннекта ожидаемо попадаем в CParent<T,nN>::OnConnect , потом из него в Child::MY_OnReceive()

.

В моём же классе какая то загадко, я уже фигею )))

[Алексей++]

вот выяснил путём экспериментов удивительную весчь - это две функции определены в CAsyncSocket абсолютно одинаково

   virtual void OnReceive(int nErrorCode);
   virtual void OnConnect(int nErrorCode);

также в Parent они одинаково переопределены.

И самое странное: если поставить вызов MY_OnReceive() в OnConnect, всё правильно вызывается, а если в OnReceive - то неправильно, вызывается метод CParent<T,nN>::MY_OnReceive()

хм....

[Dimka]

Лично меня всякое на вид бесцельное "колбашение" кода не вдохновляет. Хочешь помощи - объясни, какую задачу ты решаешь.

[Алексей++]

всего лишь виртуальные функции поиметь - в родителе вызовется , скажем, OnAccept, там клиентский сокет подключится, а затем в дитё должно вызваться нечто вроде virtual OnAfterAccept() для дополнительных операций после подключения клиента

[Dimka]

Код: (C++)

class Connection
 {
  protected:
   virtual void onOpened() = 0;
   virtual void onClosed() = 0;
  public:
   void open()
    {
     this->onOpened();
    }
   void close()
    {
     this->onClosed();
    }
 };

class MyConnection:
  public Connection
 {
  protected:
   virtual void onOpened()
    {}
   virtual void onClosed()
    {}
 };

Причём тут шаблоны и многоуровневые наследники, я не знаю. Если нужны уточнения и второй уровень потомков, то:

Код: (C++)

class MySpecificConnection:
  public MyConnection
 {
  protected:
   virtual void onOpened()
    {
     MyConnection::onOpened();
    }
   virtual void onClosed()
    {
     MyConnection::onClosed();
    }
 };

(На собираемость и работоспособность не проверял.)

[Алексей++]

dimka, неть, ты не понял. CAsyncSoket уже имеет виртуальные функции, поэтому Connection (который надо бы от него произвести) не может содержать эти функции как чистые виртуальные.

Я всё делаю правильно, загвоздка похоже в шаблоне - сейчас избавляюсь от него снова, оставлю лишь NEW и DELETE . Потом о результатах отпишусь

[Dimka]

Алексей1153++, я не не понял, я тебе показал, что никаких загвоздок в реализации такой идеи нет.

чистые виртуальные

Ррр.

оставлю лишь NEW и DELETE

Я вообще не понимаю, зачем эти методы. Ты в начале сказал "не важно, зачем, просто удобно". Не вижу я в них никакого удобства. Все такие действия выполняют конструктор и деструктор самого объекта, т.е. достаточно использовать обычные операторы new и delete. Если нужно абстрагироваться от конкретного типа, то использовать шаблон проектирования "фабричный метод"/"виртуальный конструктор" и виртуальный деструктор.

[Алексей++]

воистину ррр )  Я щас сам побултыхаюсь, может усё получится

[Алексей++]

а вот разобрался.

(кстати, заодно понял, что в конструкторе и деструкторе виртуальные функции ведут себя плохо )

причина была такая :

в классе-шаблоне
template<class T>
class Child : Parent ...

создавал новый экземпляр так
Child<T>* ... = new Child<T>

поэтому вызывались виртуальные функции класса Child<T> , а не T

сделал так
T* ... = new T
 - теперь всё нормально.

А долбился долго так изза того, что компилятор считает типы Child<T> и T при приведении - одинаковыми! И спокойно делал неявные приведения


(Child<T>*) T*
и
(T*) Child<T>*

[Dimka]

Без комментариев.

[Вад]

А я прокомментирую Это не шаблоны зло, это беспорядочные связи беспорядочное наследование и эксплуатирование предков - зло. Шаблоны тут вообще ни при чём. Замени шаблон на обычный класс, подставив туда вместо T* свой Child* (или чем там шаблон специфицируешь) - получишь тот же набор развлечений "кто кого пытается вызвать".

По мне, может статься, стоило изначально обернуть этот сокет аккуратненько, чтобы не распускал свои виртуальные методы куда не просят. Для чего вообще требовалось его наследовать?

[Алексей++]

По мне, может статься, стоило изначально обернуть этот сокет аккуратненько, чтобы не распускал свои виртуальные методы куда не просят. Для чего вообще требовалось его наследовать?

так с этого всё и начиналось )  Сначала без всяких шаблонов хотелось обойтись. Но понадобилось в родительском классе поиметь массив из дочерних классов, и тогда началось:

чтобы создать объект дитя, надо неким образом вызвать new Child в родителе, а это возможно только, если применить виртуальную функцию, которая отработает внутри самого дитя (при чём - уже реально созданного объекта, поэтому виртуальная функция и отпала. Осталось применить шаблон, в котором все действия по выделению и освобождению памяти - это new T и detete T

отказаться от шаблона таким образом не вышло )

(с шаблонами ранее дела не имел, поэтому так парюсь)

[Вад]

Алексей1153++, не совсем понял. Хранить массив дочек в родителе - для этого полиморфизм есть (допустим, ты синглетон с потомками затеял, и хочешь для всех в иерархии хранить по экземпляру). Но чтобы вызвать конструктор - всё равно нужно знать тип конструированного объекта. То есть, у тебя есть фабрика, которая знает про всех потомков? Тогда зачем вся пляска с шаблонами? Если нет фабрики, то не пойму, как ты создаёшь объекты для всех потомков. Тут уже как-то обсуждалась тема, почему невозможны виртуальные конструкторы

[Алексей++]

не знаю, что такое фабрика, у меня сделано так:

класс сокета, производный от CAsyncSoket описывает объект, который можно назначить сервером или клиентом. В сервере создаётся массив для подключенных пар клиентов. И вот от всего этого безобразия можно производить класс, в котором уже не задумываешься об управлении подключениями, а просто назначаешь тип - сервер или клиент.
Пришлось использовать как виртуальные функции так и шаблон )) Может, и не самое красивое вышло решение, но зато работает как нужно теперь

[Вад]

А может, кесарю - кесарево, а слесарю - слесарево? То есть, сокеты (включая слушающий у сервера) отдельно, а хранение клиентских подключений - отдельно? (кстати, у клиента тоже возможно несколько подключений?) Какой смысл городить огород в потомке самого сокета?

[Алексей++]

массив пар в клиенте не создаётся, а в сервере выделяется через new. Ежели всё красиво получится - в виде статьи попробую написать )

[Dimka]

Ежели всё красиво получится - в виде статьи попробую написать )

А я бы не советовал.