Создание экземпляра класса по имени

[Lasor]

Доброго времени суток.
Имеется шаблонный класс. Он является наследником базового абстрактного класса, в котором определены нужные методы.

//----------------------------------
//Базовый
//----------------------------------
class V
{
public:
    V(){}
    ~V(){}
    virtual string getName() = 0;
    virtual void notify() = 0;
    virtual void handle() = 0;
};
//----------------------------------
//Наследник
//----------------------------------
template <class T>
class E: public V
{
public:
    string getName();
    void notify();
    void handle();
};
//----------------------------------
//Отдельный
//----------------------------------
class B
{
public:
    B(){}
    void add(V *e)
    {
        tempName = e->getName();
        eList.push_back(e);
    }
    void go()
    {
        for (short i = 0; i < (short)evList.size(); i++)
        {
            eList[i]->handle();
        }
    }
private:
    string tempName;
    static vector <V*> eList;
};

Так оно всё работает замечательно, но при удалении наследника отдельный класс перестаёт функционировать(по понятным причинам).
Задачка следующего характера: перейти с указателей на базовый на экземпляры базового класса. Подскажите, возможно ли это?

[Abstraction]

Можно конструкцию, в которой сейчас используется E<T>, а хочется что-то другое?

[Lasor]

//--------------------------------
//Поток 1
//--------------------------------
class E_1:public E<E_1>
{
public:
    int someint;
};
E_1 *one;
one = new E_1;
one->someint = 1;
one->notify();
//--------------------------------
//Поток 2
//--------------------------------
class E_2:public E<E_2>
{
public:
    int someint;
};
E_2 *two;
two = new E_2;
two->someint = 2;
two->notify();
//--------------------------------
//Поток 3
//--------------------------------
B b;
b.go();

Примерно так.

[Granus]

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

Подробнее, что Вы здесь удаляете и что перестает работать?

[Lasor]

Я удаляю объекты one и two, ибо потоки заканчиваются.

[_Bers]

Сообщение от Lasor

Так оно всё работает замечательно, но при удалении наследника отдельный класс перестаёт функционировать(по понятным причинам).
Задачка следующего характера: перейти с указателей на базовый на экземпляры базового класса. Подскажите, возможно ли это?

Возможно. Но тебя не спасет. Получишь срезку.

У тебя ошибка архитектуры: нарушение прав владения объектами.

Ты создаешь экземпляры наследников. И скармливаешь их некоторому менеджеру - экземпляру класса B. Но он не владеет самими объектами.

Соответственно, при уничтожении этих объектов, менеджер ломается.

Лекарство:

1. Костыль: перед уничтожением объекта наследника, предупреждай об этом менеджера. Тогда он удалит у себя ненужный уже указатель, и сохранит работоспособность.

2. Хорошее решение: передай менеджеру право владением всеми теми объектами, с которыми он работает. Это означает, что наследники - собственность менеджера. Живут внутри его. И без его особого разрешения, никто их снаружи пригрохать не может.

3. Альтернативное решение: менеджер создает наследников. Наружу выдает интерфейсный указатель. Если снаружи интерфейсный указатель пригрохать, то перед гибелью, он успеет сообщить менеджеру о факте своей гибели. Менеджер соответственно, сможет принять меры и не поломается.

4. Решение в стиле ООП-с++:

Архитектура имеет вид: пользовательские механизмы, внешне ни с кем не связанные. Внутри себя они сами инициализируют ядро (менеджера). И общаются с ним по невидимой пользователю связи.

Механизмы пользователя можно создавать где угодно, и когда угодно. Они сами тут же связываются с ядром. Полностью автоматическая работа. Пользователю не нужно будет ничего в ручную пасти и подчищать.

Ядро контролирует ресурсы. А пользовательские механизмы - лишь представление этих ресурсов для пользователей. А на самом деле - средство для связи с ядром.

Поскольку ядро не доступно пользователям, то снаружи его не возможно повредить.

[Perchik71]

template <class T>
class E: public V
{
public:
    string getName();
    void notify();
    void handle();
};

в этом шаблоне класса нет смысла.

вот если его папа класс тоже был бы шаблонным и имел данную перемменую того типа, то другое дело.

[Lasor]

Сообщение от _Bers

Возможно. Но тебя не спасет. Получишь срезку.

У тебя ошибка архитектуры: нарушение прав владения объектами.

Ты создаешь экземпляры наследников. И скармливаешь их некоторому менеджеру - экземпляру класса B. Но он не владеет самими объектами.

Соответственно, при уничтожении этих объектов, менеджер ломается.

Лекарство:

1. Костыль: перед уничтожением объекта наследника, предупреждай об этом менеджера. Тогда он удалит у себя ненужный уже указатель, и сохранит работоспособность.

2. Хорошее решение: передай менеджеру право владением всеми теми объектами, с которыми он работает. Это означает, что наследники - собственность менеджера. Живут внутри его. И без его особого разрешения, никто их снаружи пригрохать не может.

3. Альтернативное решение: менеджер создает наследников. Наружу выдает интерфейсный указатель. Если снаружи интерфейсный указатель пригрохать, то перед гибелью, он успеет сообщить менеджеру о факте своей гибели. Менеджер соответственно, сможет принять меры и не поломается.

4. Решение в стиле ООП-с++:

Архитектура имеет вид: пользовательские механизмы, внешне ни с кем не связанные. Внутри себя они сами инициализируют ядро (менеджера). И общаются с ним по невидимой пользователю связи.

Механизмы пользователя можно создавать где угодно, и когда угодно. Они сами тут же связываются с ядром. Полностью автоматическая работа. Пользователю не нужно будет ничего в ручную пасти и подчищать.

Ядро контролирует ресурсы. А пользовательские механизмы - лишь представление этих ресурсов для пользователей. А на самом деле - средство для связи с ядром.

Поскольку ядро не доступно пользователям, то снаружи его не возможно повредить.

Дело в том, что не имеется возможности запретить удалять наследники, с которыми работает менеджер, ибо они могут быть созданы пользователем/другим разработчиком где-либо локально.
Решение, которое видится мне - создавать копии (не бейте по голове) наследников и передавать их менеджеру по методу notify(). Задача менеджера - обработать все подписчики наследника методом handle() (подписчиков, разумеется, несколько).
Для этого, попробую использовать списки типов.
Если кто-нибудь может показать, как записывать копии, буду рад.

[_Bers]

Держи:

http://ideone.com/tsEQTL

Пример-иллюстрация ковариантных функций, или как сделать копию наследника, через базовый интерфейс:

#include<iostream>
#include<vector>
 
    struct IObject
    {
        virtual ~IObject(){}
        virtual IObject* Clone()=0;
        virtual void Work()=0;
    };
    
    struct Concrete_Object1: IObject
    {
        virtual void Work()               { std::cout<<"Concrete_Object1: working\n";    }
        virtual ~Concrete_Object1()       { std::cout<<"Concrete_Object1: destroyed\n";  }
        virtual Concrete_Object1* Clone() { return new Concrete_Object1(*this);          }
    };
    struct Concrete_Object2: IObject
    {
        virtual void Work()               { std::cout<<"Concrete_Object2: working\n";    }
        virtual ~Concrete_Object2()       { std::cout<<"Concrete_Object2: destroyed\n";  }
        virtual Concrete_Object2* Clone() { return new Concrete_Object2(*this);          }
    };    
        
    struct Manager
    {
        ~Manager()
        {
            const size_t size = mObj.size();
            for(size_t n=0;n<size;++n){ delete mObj[n]; mObj[n] = 0l; }
        }
        
        void Connect(IObject* src){  mObj.push_back( src->Clone() ); }
        
        void Work()
        {
            const size_t size = mObj.size();
            for(size_t n=0;n<size;++n){ mObj[n]->Work(); }
        }
        std::vector<IObject*> mObj;
    };
 
 
int main()
{
   Manager man;
   IObject* agent1 = new Concrete_Object1();
   IObject* agent2 = new Concrete_Object2();
   
   man.Connect(agent1);
   man.Connect(agent2);
   
   delete agent1;
   delete agent2;
   
   man.Work();
   
   return 0;
}

[Lasor]

Сообщение от _Bers

Держи:

http://ideone.com/tsEQTL

Пример-иллюстрация ковариантных функций, или как сделать копию наследника, через базовый интерфейс:

#include<iostream>
#include<vector>
 
    struct IObject
    {
        virtual ~IObject(){}
        virtual IObject* Clone()=0;
        virtual void Work()=0;
    };
    
    struct Concrete_Object1: IObject
    {
        virtual void Work()               { std::cout<<"Concrete_Object1: working\n";    }
        virtual ~Concrete_Object1()       { std::cout<<"Concrete_Object1: destroyed\n";  }
        virtual Concrete_Object1* Clone() { return new Concrete_Object1(*this);          }
    };
    struct Concrete_Object2: IObject
    {
        virtual void Work()               { std::cout<<"Concrete_Object2: working\n";    }
        virtual ~Concrete_Object2()       { std::cout<<"Concrete_Object2: destroyed\n";  }
        virtual Concrete_Object2* Clone() { return new Concrete_Object2(*this);          }
    };    
        
    struct Manager
    {
        ~Manager()
        {
            const size_t size = mObj.size();
            for(size_t n=0;n<size;++n){ delete mObj[n]; mObj[n] = 0l; }
        }
        
        void Connect(IObject* src){  mObj.push_back( src->Clone() ); }
        
        void Work()
        {
            const size_t size = mObj.size();
            for(size_t n=0;n<size;++n){ mObj[n]->Work(); }
        }
        std::vector<IObject*> mObj;
    };
 
 
int main()
{
   Manager man;
   IObject* agent1 = new Concrete_Object1();
   IObject* agent2 = new Concrete_Object2();
   
   man.Connect(agent1);
   man.Connect(agent2);
   
   delete agent1;
   delete agent2;
   
   man.Work();
   
   return 0;
}

Интересный выход. Спасибо. Всё-таки, С++ действительно позволяет написать пару строк и потом сказать: "Это гениально!".
http://ideone.com/tsEQTL пока недоступен, увы...