Здравствуйте, Erop, Вы писали:
E>А у вас множественное наследование бывает?

Нет, даже композиции нет. Концепция такая — компоненты состоят только из свойств,
действий(объекты-оболочки для указателей на функции-члены) и
ссылок(объекты-указатели на другие компоненты, включающие информацию о типе на который должны
указывать). Причем, классы компонентов помещаются в динамические библиотеки. Есть главная
программа, в которой можно подгрузить библиотеки, создать необходимые компоненты, настроить
связи между ними, просмотреть/изменить значения свойств, выполнить действия для компонентов,
сохранить/открыть компоненты.

Расскажу о проекте, чтобы требования были лучше понятны и не выглядели надуманными. Система не
коммерческая и используется для научно-исследовательских работ студентов. Например, поставлена
задача для группы студентов: "Использование искусственных нейронных сетей для прогнозирования
временных рядов". Студент должен исследовать разные виды нейронных сетей, алгоритмов обучения,
влияние на результат различных параметров обучающей выборки шаблонов и т.д. У студентов есть
несколько вариантов организации своей работы: воспользоваться матлабом, специализированным ПО
или реализовать все эксперименты самому на С++. По ряду причин последний вариант наиболее
эффективный при условии хорошего владения средствами языка. Вот в этом и проблема. Группе
студентов тяжело все разработать и запрограммировать "с нуля" в условиях постоянно меняющихся
требований(постоянно появляются новые идеи), отсутвия должных навыков групповой работы, да и
вообще опыта разработки ПО. Для решения этих проблем и была разработана описываемая система.
Теперь так — студентам дается образец кода одного из компонентов и
поясняются несложные правила написания компонентов(от какого класса наследовать, как определять
свойства, связи и действия), а также готовая главная программа. Каждому дается своя задача на
разработку компонента(ов), например кто-то делает компонент NuralNetwork, кто-кто
GeneticAlgorihtm, кто-то Crossover, кто-то Patterns и т.д. Затем в основной прогармме это все
связывается и запускается. Если появилась идея, типа "а давайте попробуем полносвязную нейронную
сеть...", деаем еще один компонент, меняем одну связь в главной программе и смотрим на
результат. Кроме этого есть уже готовые компоненты, написанные "предыдущими покаолениями"
студентов. Когда получаем приемлемый результат исследований, то компонент может быть легко заюзан в отдельном
демонстрационном или рабочем приложении. Главное что мы получили — четкое разделение, повторное
использование кода и скорость реализации идей. Текущая проблема с системой — большое количество
глюков в компонентах из-за непрофессионализма разработчиков. Насущная задача — доработка системы
таким образом, чтобы студентам было как можно проще создавать компоненты и оставалось как можно
меньше возможностей для ошибок, а те что все же допущены можно бы было лекго обнаруживать при
общем тестировании компонента до того, как он будет использоваться.

E>На самом деле в этой всей системе есть один косяк. Свойства, по идее, можно бы регить на тип,
а не на экземпляр...
E>Так и быстрее и веселее должно быть.

Согласен, но как это красиво реализовать. Ведь такие параметры свойств, как имя, атрибут "только
для чтения" и другое относятся к типу, а значение свойства — у каждого объекта свое.

On 02/23/2012 01:19 PM, niralex wrote:

> Нет, даже композиции нет. Концепция такая — компоненты состоят только из свойств,
> действий(объекты-оболочки для указателей на функции-члены) и
> ссылок(объекты-указатели на другие компоненты, включающие информацию о типе на
> который должны
> указывать).

По-моему простой список свойств тут подошёл бы лучше.
Плюс возможно объект-flyweigh для реализации логики работы с этими свойствами.

Здравствуйте, night beast!

Хочу заметить, что согласно стандарту (в новом это 18.2.4) макрос offsetof применим только к standard-layout class и поэтому (IMHO) данный прием niralex'у не подходит.

Здравствуйте, MasterZiv, Вы писали:

MZ>On 02/23/2012 01:19 PM, niralex wrote:

>> Нет, даже композиции нет. Концепция такая — компоненты состоят только из свойств,
>> действий(объекты-оболочки для указателей на функции-члены) и
>> ссылок(объекты-указатели на другие компоненты, включающие информацию о типе на
>> который должны
>> указывать).

MZ>По-моему простой список свойств тут подошёл бы лучше.
MZ>Плюс возможно объект-flyweigh для реализации логики работы с этими свойствами.

не понял идею, можно подробнее. Что такое паттерн flyweigh представление имею.

> MZ>По-моему простой список свойств тут подошёл бы лучше.
> MZ>Плюс возможно объект-flyweigh для реализации логики работы с этими свойствами.
>
> не понял идею, можно подробнее. Что такое паттерн flyweigh представление имею.
> Re[8]: Может ли объект "узнать" где он создается? <message/4631013.aspx>


Ну пример кода твоего класса покажи ...

Здравствуйте, niralex, Вы писали:

E>>На самом деле в этой всей системе есть один косяк. Свойства, по идее, можно бы регить на тип,
N>а не на экземпляр...
E>>Так и быстрее и веселее должно быть.

N>Согласен, но как это красиво реализовать. Ведь такие параметры свойств, как имя, атрибут "только
N>для чтения" и другое относятся к типу, а значение свойства — у каждого объекта свое.

Ну, на мой взгляд, тут бы надо что-то в консерватории подправить. Например пересадить студней не какой-то язык с строенной поддержкой всех этих дел. На дельфи там, или на шарп...

Но если вам С++ милее всего, то можно примерно всё тоже самое замутить и на нём, конечно же.

Только я немного переформулирую твою задачу, чтобы немного отстраниться от ваших дел.

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

Первое, что нам понадобится -- это способ как-то сослаться на данные неизвестного типа. Это должно быть копируемое данное, которое можно вернуть из функции и потом у него расспросить, что за тип там внутри, прочитать, записать и т. д.
Есть много разных библиотек, которые решают эту задачу по всякому, так что я не буду заострять внимание на этом всём подробно. Просто напишу какой-то DataRef для бедных. А для реальных задач уже можно будет сделать хорошо, или взять библиотечный.

Итак, к вашим услугам относительно безопасный void* :

#include <assert.h>
#include <vector>
#include <map>
#include <string>
////////////////////////////////////////////////////////////////
//  TestDataRef
class DataRef {
    const type_info& type;
    void* const dataPtr;
public:
    DataRef() : type( typeid( void ) ), dataPtr( 0 ) {}
    template<typename T> 
    DataRef( T& data ) : type( typeid( T ) ), dataPtr( &data ) { assert( dataPtr != 0 ); }
    bool IsNull() const { return dataPtr == 0; }
    
    template<typename T> 
    bool CheckType() { return type == typeid( T ); }
    template<typename T> 
    bool CheckType( const T& ) { return CheckType<T>(); }
    
    template<typename T> 
    T& GetRef() 
    { 
        assert( CheckType<T>() && dataPtr != 0 ); 
        return *static_cast<T*>( dataPtr );
    }
    
    template<typename T> 
    operator T&() { return GetRef<T>(); }

    template<typename T>
    void operator = ( const T& t ) { GetRef<T>() = t; }

};

Вот пример, как это работает:

////////////////////////////////////////////////////////////////
//  TestDataRef

template<typename T>
bool SetAs( DataRef r, const T& val )
{
    const bool res = r.CheckType( val );
    if( res ) {
        r = val;
    }
    return res;
}

bool TestDataRef()
{
    int x = 0;
    std::string y = "vava";

    DataRef dInt( x );
    DataRef dStr( y );
    
    const std::string testText( "qqq" );

    return 
        SetAs( dInt, 5 ) &&
        !SetAs( dInt, testText ) &&
        ! SetAs( dStr, 5 ) &&
        SetAs( dStr, testText ) &&
        x == 5 && y == testText;
}

///////////////////////////////////////////////////////////////

У меня, на VC 2008 TestDataRef() возвращает true.

Теперь, когад у нас есть, что возвращать из методов того самого интерфейса, мы можем его описать и попробовать реализовать:

////////////////////////////////////////////////////////////////
//    MappedFieldsOf

//    Тот самый интерфейс
class IMappedValues {
public:
    virtual std::vector<std::string> GetAllNames() = 0;
    virtual DataRef GetValue( const std::string& name ) = 0;
    template<typename T> T& GetRef( const std::string& name ) 
    {
        DataRef ref = GetValue( name );
        assert( !ref.IsNull() && ref.CheckType<T>() );
        return ref;
    }
protected:
    virtual ~IMappedValues() {}
};

//    Макросы для декларации публикуемых полей класса. пишутся прямо внутри определения класса
#define FIELD_MAPPING_BEGIN( THE_CLASS ) \
public:\
    static void constructMapOfFieldsPrivateFunction( MappedFieldsOf<TestClass>::MapOfDescriptors* dst_ ) \
    { \
        typedef TestClass TheClass_; \
        typedef MappedFieldsOf<TheClass_> MappedFieldsOfTheClass_; \
        typedef const MappedFieldsOfTheClass_::IFieldDescriptor& FieldDesc_; \

#define MAP_FIELD_EXT( FIELD, NAME ) \
    { \
        static FieldDesc_ tmp_ = MappedFieldsOfTheClass_::getFieldDescriptorImpl( &TheClass_::FIELD ); \
        dst_->Push( NAME, &tmp_ ); \
    }

#define MAP_FIELD( FIELD ) MAP_FIELD_EXT( FIELD, #FIELD )


#define FIELD_MAPPING_END() \
    }


template<typename TClass> 
class MappedFieldsOf : public IMappedValues {
public:
    virtual std::vector<std::string> GetAllNames()
    {
        return getMapOfFieldsDescriptors().GetAllNames();
    }
        
    virtual DataRef GetValue( const std::string& name )
    {
        const IFieldDescriptor* res = getMapOfFieldsDescriptors().Find( name );
        return res != 0 ? res->GetFieldOf( static_cast<TClass*>( this ) ) : DataRef();
    }
protected:
    
    class IFieldDescriptor {
    public:
        virtual DataRef GetFieldOf( TClass* ) const { return DataRef(); }
    };
    
    template<typename TField>
    class FieldDescriptorImpl : public IFieldDescriptor {
        TField TClass::*const fieldPtr;
    public:
        FieldDescriptorImpl( TField TClass::*ptr ) : fieldPtr( ptr ) { assert( ptr != 0 ); }
        virtual DataRef GetFieldOf( TClass* theThis ) const 
        { 
            assert( theThis != 0 );
            return DataRef( theThis->*fieldPtr ); 
        }
    };

    template<typename TField>
    static FieldDescriptorImpl<TField> getFieldDescriptorImpl( TField TClass::*ptr ) { return ptr; }
    class MapOfDescriptors;
private:
    static const class MapOfDescriptors {
    public:
        MapOfDescriptors( void (*f)( MapOfDescriptors* ) ) { f( this ); }
        
        const IFieldDescriptor* Find( const std::string name ) const
        {
            storage_t::const_iterator p = storage.find( name );
            return p != storage.end() ? p->second : 0;
        }
        void Push( const std::string& name, const IFieldDescriptor* desc )
        {
            assert( desc != 0 );
            storage[name] = desc;
        }
        std::vector<std::string> GetAllNames() const
        {
            std::vector<std::string> res;
            for( storage_t::const_iterator i = storage.begin(); i != storage.end(); ++i ) {
                res.push_back( i->first );
            }
            return res;
        }
    private:
        typedef std::map<std::string, const IFieldDescriptor*> storage_t;
        storage_t storage;

    }& getMapOfFieldsDescriptors()
    {
        static MapOfDescriptors m( TClass::constructMapOfFieldsPrivateFunction );
        return m;
    }
};

Ну и напишем теперь пример использования:

////////////////////////////////////////////////////////////////
//  TestMappedFieldsOf


class TestClass : public MappedFieldsOf<TestClass> {
    FIELD_MAPPING_BEGIN( TestClass )
        MAP_FIELD( X )
        MAP_FIELD_EXT( Y, "YStr" )
    FIELD_MAPPING_END()
public:
    int X;
    std::string Y;

};

bool TestMappedFieldsOf()
{
    TestClass x;
    x.X = 7;
    IMappedValues* mf = &x;
    const std::string testText( "qqq" );

    std::vector<std::string> names = mf->GetAllNames();
    int count = 0;
    for( size_t i = 0; i < names.size(); ++i ) {
        count += SetAs( mf->GetValue( names[i] ), 5 );
        count += SetAs( mf->GetValue( names[i] ), testText );
    }
    return x.X == 5 && x.Y == testText && count == names.size();
}

У меня, на том же компиляторе, TestMappedFieldsOf() возвращает true

---

Тут всё сделано довольно прямо, есть несколько смонительных мест.
Место 1 -- синглетон Майерса, используемый для хранения отображения на класс. Недостатки такие, что в наивной реализации не дружит с многопоточным окружением + если обратиться слишком поздно, то может уже быть разрушен.
Лечится известно как.

Место 2 -- Юзается вот какой трюк:

int bCount = 0;

class A { public: int a; };
class B : public A { 
public: 
    B() {}
    ~B() 
    { 
        bCount++; 
    }
    mutable int b; 
};

int& foo()
{
    static const A& a = B();  // !!!
    return static_cast<const B&>( a ).b;
    assert( bCount == 0 );
}

bool testIt() 
{
    foo() = 6;
    foo() = 3;
    return foo() == 3 && bCount == 0;
}

Обрати внимание на строку // !!!
Мы там создаём временный объект — наследник, и продлеваем ему время жизни при помощи статической сонстантной ссылки на базу. Это позволяет нам не указывать при регистрации поля его тип, а выводить его...

Собсвтенно вот.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, niralex, Вы писали:

E>>>На самом деле в этой всей системе есть один косяк. Свойства, по идее, можно бы регить на тип,
N>>а не на экземпляр...
E>>>Так и быстрее и веселее должно быть.

N>>Согласен, но как это красиво реализовать. Ведь такие параметры свойств, как имя, атрибут "только
N>>для чтения" и другое относятся к типу, а значение свойства — у каждого объекта свое.

E>Ну, на мой взгляд, тут бы надо что-то в консерватории подправить. Например пересадить студней не какой-то язык с строенной поддержкой всех этих дел. На дельфи там, или на шарп...

"Встроенная" поддержка не всегда подходит... или мы не до конца с ней раобрались

E>Но если вам С++ милее всего, то можно примерно всё тоже самое замутить и на нём, конечно же.

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

Здравствуйте, niralex, Вы писали:

N>Да, вариант похоже решает задачу, но мне еще нужно до конца с ним разобраться, прикинуть насколько сложно будет переписать существующий код,
Можно как-то поменять DataRef, тем более, что DataRef достаточно на коленке написана тут.
Ну и, нсколько я понял, у вас всё время пишутся новые компоненты

N>и пугают, конечно, макросы (почему-то всегда старался их избегать).
Ну это да. И правильно старался (тут принято на "ты" обращаться к коллегам).
Но тут на компромисс некий приходится идти, так как при таком подходе сложнее допустить ошибку.

Правда там у меня есть ошибка в макросе. В FIELD_MAPPING_BEGIN( THE_CLASS ) вместо typedef TestClass TheClass_; должно быть typedef THE_CLASS TheClass_; \

Здравствуйте, niralex, Вы писали:

NB>>здесь

Автор: enji
Дата: 20.02.12

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

Ну и что? Идея точно такая-же — из this свойства и имени класса-контейнера получаете указатель на класс-контейнер, и вызываете метод registerProperty()

Здравствуйте, niralex, Вы писали:

E>>Но если вам С++ милее всего, то можно примерно всё тоже самое замутить и на нём, конечно же.

N>Да, вариант похоже решает задачу, но мне еще нужно до конца с ним разобраться, прикинуть насколько сложно будет переписать существующий код, и пугают, конечно, макросы (почему-то всегда старался их избегать). В любом случае сасибо за внимание к моим проблемам. Честно говоря впечатлен уровнем профессионализма и отзывчивостью лично вашими и других экспертов. Подобного отношения к новичкам не встречал нигде.

Кстати, а чего вы тот-же Qt не заюзаете? Свойства там есть и как раз такие, как вам нужны. Плюс поддержка от ИДЕ и очень хороший хелп

Здравствуйте, niralex, Вы писали:
N>Расскажу о проекте, чтобы требования были лучше понятны и не выглядели надуманными. Система не
N>коммерческая и используется для научно-исследовательских работ студентов. Например, поставлена
N>задача для группы студентов: "Использование искусственных нейронных сетей для прогнозирования
N>временных рядов". Студент должен исследовать разные виды нейронных сетей, алгоритмов обучения,
N>влияние на результат различных параметров обучающей выборки шаблонов и т.д. У студентов есть
N>несколько вариантов организации своей работы: воспользоваться матлабом, специализированным ПО
N>или реализовать все эксперименты самому на С++.
Немного не в тему, но наверное тебе будет интересно посмотреть на ROOT

Здравствуйте, niralex, Вы писали:


N>Можно ли в конструкторе объекта без параметров каким-либо образом получить указатель на объект в котором он создается (в случае композиции):
N>Буду очень благодарен за любые решения, идеи или ссылки на материалы, где можно почитать по теме

Чем мешает/неудобен конструктор с параметром ?

Здравствуйте, enji, Вы писали:

E>Здравствуйте, niralex, Вы писали:

NB>>>здесь

Автор: enji
Дата: 20.02.12

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

E>Ну и что? Идея точно такая-же — из this свойства и имени класса-контейнера получаете указатель на класс-контейнер, и вызываете метод registerProperty()

Там, например, не нравится то, что используется offsetof. Может это и предубеждение, но не хочется использовать решение, когда есть какие-то сомнения.

Здравствуйте, enji, Вы писали:

E>Здравствуйте, niralex, Вы писали:

E>>>Но если вам С++ милее всего, то можно примерно всё тоже самое замутить и на нём, конечно же.

N>>Да, вариант похоже решает задачу, но мне еще нужно до конца с ним разобраться, прикинуть насколько сложно будет переписать существующий код, и пугают, конечно, макросы (почему-то всегда старался их избегать). В любом случае сасибо за внимание к моим проблемам. Честно говоря впечатлен уровнем профессионализма и отзывчивостью лично вашими и других экспертов. Подобного отношения к новичкам не встречал нигде.

E>Кстати, а чего вы тот-же Qt не заюзаете? Свойства там есть и как раз такие, как вам нужны. Плюс поддержка от ИДЕ и очень хороший хелп

1. По независящим от меня причинам, студентов(основных пользователей этой системы) учат работать в Embarcadero RAD Studio C++Builder. Перейти на QT самостоятельно в сжатые сроки смогут единицы.
2. По "политическим" мотивам предпочитаем разрабатывать свои велосипеды. Проект не коммерческий, в шею никто не гонит, делаем для себя, почему бы и не попробовать...

Здравствуйте, Tonal-, Вы писали:

T>Здравствуйте, niralex, Вы писали:
N>>Расскажу о проекте, чтобы требования были лучше понятны и не выглядели надуманными. Система не
N>>коммерческая и используется для научно-исследовательских работ студентов. Например, поставлена
N>>задача для группы студентов: "Использование искусственных нейронных сетей для прогнозирования
N>>временных рядов". Студент должен исследовать разные виды нейронных сетей, алгоритмов обучения,
N>>влияние на результат различных параметров обучающей выборки шаблонов и т.д. У студентов есть
N>>несколько вариантов организации своей работы: воспользоваться матлабом, специализированным ПО
N>>или реализовать все эксперименты самому на С++.
T>Немного не в тему, но наверное тебе будет интересно посмотреть на ROOT

Спасибо за ссылку. Действительно интересно. Если подойдет и воспользуемся, обязательно отпишусь.

Здравствуйте, dev_proxy_stub, Вы писали:

__>Здравствуйте, niralex, Вы писали:


N>>Можно ли в конструкторе объекта без параметров каким-либо образом получить указатель на объект в котором он создается (в случае композиции):
N>>Буду очень благодарен за любые решения, идеи или ссылки на материалы, где можно почитать по теме

__>Чем мешает/неудобен конструктор с параметром ?

Если имеется ввиду, что в качестве параметра конструктора свойства передавать указатель на родителя, то недостаток вижу в том, что это небезопасно. Например, кто-то передаст вместо this указатель на другой компонент... Ошибку можно будет искать очень долго. А учитывая, что множество студентов с разным уровнем подготовки будут писать множество классов, это обязательно когда-нибудь счучится.

> Если имеется ввиду, что в качестве параметра конструктора свойства передавать
> указатель на родителя, то недостаток вижу в том, что это небезопасно. Например,
> кто-то передаст вместо this указатель на другой компонент...

Почему this ? Это that а не this. Ну и тип объекта компилятор в состоянии проверить.

Здравствуйте, niralex, Вы писали:

E>>Кстати, а чего вы тот-же Qt не заюзаете? Свойства там есть и как раз такие, как вам нужны. Плюс поддержка от ИДЕ и очень хороший хелп

N>1. По независящим от меня причинам, студентов(основных пользователей этой системы) учат работать в Embarcadero RAD Studio C++Builder. Перейти на QT самостоятельно в сжатые сроки смогут единицы.
N>2. По "политическим" мотивам предпочитаем разрабатывать свои велосипеды. Проект не коммерческий, в шею никто не гонит, делаем для себя, почему бы и не попробовать...

в блдере есть собственные свойства и средства для их рантайм-перебора. Кстати, если проект не коммерческий — то каким боком тут рад-студия? она весьма недешевая...
Насчет перехода на qt — не надо на него переходить. Достаточно просто заюзать свойства оттуда, а гуй пишите на чем писали

Здравствуйте, niralex, Вы писали:

N>Там, например, не нравится то, что используется offsetof. Может это и предубеждение, но не хочется использовать решение, когда есть какие-то сомнения.

Можно без него, но тогда придется честно хранить указатель, что даст 4 байта на каждое свойство в каждом экземпляре. А то и все 8

Еще можно хранить не указатель, а сдвиг относительно this и надеяться, что он влезет в byte ну или в word

Здравствуйте, niralex, Вы писали:


N>Если имеется ввиду, что в качестве параметра конструктора свойства передавать указатель на родителя, то недостаток вижу в том, что это небезопасно. Например, кто-то передаст вместо this указатель на другой компонент...

Вот для этих кого-то и придумали юнит-тесты.