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

AVK>Да нет, не шутка. Не зря Влад регулярно отсылает вас на форум ixbt по программированию с предложением почитать посты тов. Рыбкина. Это вполне серьезно. Впрочем, бывают даже более удивительные случаи — есть люди, которые считают и С злом и убеждены что надо всех принудительно заставлять писать на ассемблере.

Люди, которые считают, что "надо всех принудительно заставлять <...>" мне, кстати, неприятны, независимо от того, что стоит в <...>. Если только они не заставляют развивать свои мозги. Ну это так, замечание по ходу. А на самом деле — многое зависит от конкретных условий и многое же совершенно неизменно. Как эта вот Trtti > Tctti. Ну никуда не денешься от того, что даже:

mov eax, something
jz @@somewhere
jmp @@exit

потребует больше времени, чем... чем ничто!

AVK>Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий

А позиция Влада — в философском смысле.

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

ГВ>>Странно, а из твоих реплик складывается впечатление, что кодогенерация, это чуть ли не универсальная панацея. И кто это "мы", которые "вцепились в кодогенерацию"?

VD>Ну, кто вы, вы должны знать и сами.

Да нет, интересно знать, в чём же состоит "наше" "вцепление" в кодогенерацию?

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

ГВ>Всё время выпадает какое-то общее звено. Вот смотри. Нечто (exe-шник или длл) создаёт экземпляр некоторого класса, пользуясь только именем класса, а потом (по идее?) пытается преобразовать в тот тип, который нужен, чтобы вызвать некую операцию. Вопрос. Зачем тогда создавать объект неопределённого класса, если уже известно, каким он должен быть?
ГВ>Может быть, приведёшь пример конкретного сценария использования? Просто с rtti всегда так — потянешь за одну ниточку и лезет всё остальное.

Общий заголовок

struct I_Sensor
    :I_Object
{
//...
};

struct I_MyCoolSensor
    :I_Sensor
{
//...
};

в каждой DLL

template<class T>
Ref<T> CreateObject(const std::string& name)
{
    return dynamic_cast<T>(exe->CreateObject(name));
}

DLL 1

struct C_MyCoolSensor
    :I_MyCoolSensor
{
}

DLL_EXPORT_MAP_BEGIN()
    DLL_EXPORT_CLASS(C_MyCoolSensor)
DLL_EXPORT_MAP_END()

DLL 2

void DoSome(const std::string& sensorClassName)
{
    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
    {
        //....
    }
}

DLL 3

void DoSomeElse()
{
    if(Ref<I_MyCoolSensor> sensor=CreateObject<I_MyCoolSensor>("MyCoolSensor"))
    {
        //....
    }
}

EXE

map<string, Ref<I_Factory> > factoryMap;
void OnLoad()
{
    foreach(dll in dlls)
        foreach(factory in dll.factorys)
            factoryMap.add(factory.className, factory);
}

Ref<I_Object> CreateObject(const std::string& name)
{
    FactoryMapIter iter=factoryMap.find(name);
    if(iter!=factoryMap.end())
        return (*iter)->CreateObject();
    else
        return 0;
}

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

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

Большое спасибо за содержательный ответ. Теперь я потрачу день-два на сочинение содержательного ответа.

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

ГВ>>Может быть, приведёшь пример конкретного сценария использования? Просто с rtti всегда так — потянешь за одну ниточку и лезет всё остальное.

[разнообразный ccode]

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

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

Но всё-таки кое-что к чему можно "прицепиться", я таки нашёл .

Вот здесь, как я понимаю, ты иллюстрируешь использование общего для всех классов интерфейса:
WH>

WH>void DoSome(const std::string& sensorClassName)
WH>{
WH>    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
WH>    {
WH>        //....
WH>    }
WH>}
WH>

У меня возник вопрос: а почему бы не сделать так?

void DoSome(Ref<I_Sensor> sensor)

В любом случае внешний объект вызывает DoSome не просто так и, скорее всего знает о том, что будет использоваться именно Ref<I_Sensor>. Однако, здесь я могу ошибаться, поэтому предположу, что на месте I_Sensor может стоять произвольное имя. Тогда, собственно, имеем риск того, что dynamic_cast<> == 0.

А вот здесь:
WH>

WH>void DoSomeElse()
WH>{
WH>    if(Ref<I_MyCoolSensor> sensor=CreateObject<I_MyCoolSensor>("MyCoolSensor"))
WH>    {
WH>        //....
WH>    }
WH>}
WH>

пара небольших недостатков. 1) Необходимо вручную отслеживать согласование I_MyCoolSensor<->"MyCoolSensor" в каждом таком вызове и 2) опять-таки, если функция DoSomeElse вызывается для действий над интерфейсом определённого типа, то почему бы не вынести его в формальные параметры, например, так:

void DoSomeElse(Ref<I_MyCoolSensor>)

Как я понимаю, аргументом против такого решения служит то, что DoSomeElse вызывается чем-то, кто знать не знает о существовании I_MyCoolSensor. Но тогда, ИМХО, это снова не совсем хорошо, поскольку остаётся риск отказа в обработке из-за неверного выбора класса.

То есть, в принципе, я вижу в обоих частях примера один и тот же недостаток — риск того, что dynamic_cast<> вернёт 0 и предупредить это невозможно, поскольку никак не предоставлена информация для точного выбора класса.

ИМХО, защититься от этого можно, если разделить фабрики сущностей и фабрики интерфейсов, и декларировать допустимые преобразования "интерфейс-сущность-интерфейс", например, сопоставив интерфейсам и сущностям отдельные GUID-ы ( Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ).

Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.

Соответсвенно, задача исключения неопределённости, привносимой dynamic_cast<> сводится к тому, чтобы максимально автоматизировать регистрацию информации о связях интерфейсов с сущностями с одной стороныи, с другой стороны — предоставить информацию о допустимых типах аргументов и с третьей — не потерять вкусностей C++. Ну и ещё... случайно не написать такую же махину как CLR.

Пример такого обхода пока ещё не готов, заброшу несколько позже. Но пока что забавно получается.

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

ГВ>У меня возник вопрос: а почему бы не сделать так?
ГВ>

ГВ>void DoSome(Ref<I_Sensor> sensor)
ГВ>

Потому что объект еще не создан. Болие того не этапе компиляции не ивесно какой именно объект будет создан. Имя класса читается из конфига.

ГВ>В любом случае внешний объект вызывает DoSome не просто так и, скорее всего знает о том, что будет использоваться именно Ref<I_Sensor>. Однако, здесь я могу ошибаться, поэтому предположу, что на месте I_Sensor может стоять произвольное имя. Тогда, собственно, имеем риск того, что dynamic_cast<> == 0.
А как ты думаешь почему и написал if?

    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
    {
        //....
    }

ГВ>пара небольших недостатков. 1) Необходимо вручную отслеживать согласование I_MyCoolSensor<->"MyCoolSensor" в каждом таком вызове и 2) опять-таки, если функция DoSomeElse вызывается для действий над интерфейсом определённого типа, то почему бы не вынести его в формальные параметры, например, так:
Тут нужен несколько другой пример:
Переберем все сенсоры и для тех которые I_MyCoolSensor чтото сделаем.

void DoSomeWithMyCoolSensors(RefEnum<I_Sensor> sensors)
{
    while(Ref<I_Sensor> sensor=sensors->Next())
        if(Ref<I_MyCoolSensor> my_sensor=ref_cast<I_MyCoolSensor>(sensor))
        {
            //....
        }
}

ref_cast принимает и возвращает мои смартпоинтеры. Внутри вызывает dynamic_cast.

ГВ>То есть, в принципе, я вижу в обоих частях примера один и тот же недостаток — риск того, что dynamic_cast<> вернёт 0 и предупредить это невозможно, поскольку никак не предоставлена информация для точного выбора класса.
А это и не нужно. Просто проверяем входные данные и все.

ГВ>ИМХО, защититься от этого можно, если разделить фабрики сущностей и фабрики интерфейсов,
Это как?
ГВ>и декларировать допустимые преобразования "интерфейс-сущность-интерфейс",
А dynamic_cast для чего сделан?
ГВ>например, сопоставив интерфейсам и сущностям отдельные GUID-ы (
Зачем городить COM ручками? Пусть работает компилятор.
ГВ>Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ).
Ну ты эта того рефлкшен бы посмотрел.

ГВ>Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.
Ага. И перекомпилировать ВЕСЬ проект?

ГВ>Соответсвенно, задача исключения неопределённости, привносимой dynamic_cast<> сводится к тому, чтобы максимально автоматизировать регистрацию информации о связях интерфейсов с сущностями с одной стороныи, с другой стороны — предоставить информацию о допустимых типах аргументов и с третьей — не потерять вкусностей C++. Ну и ещё... случайно не написать такую же махину как CLR.

ГВ>Пример такого обхода пока ещё не готов, заброшу несколько позже. Но пока что забавно получается.
Ты бы вышел за приделы одного ехешника чтоли.
Просто если делать один ехешник то там много другие методы конторля чем ты говоришь, а если между длл то компаилтайм проверки уже работать не будут, а если и будут то при добавлении новой сущьности придется перекомпилять ВСЕ длл ну и какой тогда в них смысл?

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

ГВ>>и декларировать допустимые преобразования "интерфейс-сущность-интерфейс",
WH>А dynamic_cast для чего сделан?
Я сказал — "декларировать", а не "выяснить по ходу дела".

ГВ>>например, сопоставив интерфейсам и сущностям отдельные GUID-ы (
WH>Зачем городить COM ручками? Пусть работает компилятор.
Вот и я о том же — пусть работает компилятор.

ГВ>>Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ.
WH>Ну ты эта того рефлкшен бы посмотрел.
Я сказал — "в некотором роде".

ГВ>>Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.
WH>Ага. И перекомпилировать ВЕСЬ проект?
Отнюдь. Хотя при изменении какого-то интерфейса его пользователей по-любому перекомпилить надо.

ГВ>>Соответсвенно, задача исключения неопределённости, привносимой dynamic_cast<> сводится к тому, чтобы максимально автоматизировать регистрацию информации о связях интерфейсов с сущностями с одной стороныи, с другой стороны — предоставить информацию о допустимых типах аргументов и с третьей — не потерять вкусностей C++. Ну и ещё... случайно не написать такую же махину как CLR.

ГВ>>Пример такого обхода пока ещё не готов, заброшу несколько позже. Но пока что забавно получается.
WH>Ты бы вышел за приделы одного ехешника чтоли.
Есессно.

WH>Просто если делать один ехешник то там много другие методы конторля чем ты говоришь,
Не понял?

WH>а если между длл то компаилтайм проверки уже работать не будут, а если и будут то при добавлении новой сущьности придется перекомпилять ВСЕ длл ну и какой тогда в них смысл?
Нет, ВСЕ перекомпилять не нужно.

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

VD>>Нет. А должно?

ГВ>Мне — смешно. Как тебе — не знаю, вот и спросил.

Рад.

Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?

Они уже сейчас существуют.