Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

V>>А каков механизм "интроспекции"? Как обходить будешь на дотнете? Ну т.е. строить самый первый план запросов? 
S>Обычным образом - это же данные. Плюс Reflection, т.е. про всех упомянутых мемберов я знаю чуть более чем всё. 
S>Вот подробный рассказ про то, как это делается под капотом:
S>http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx

V>>В общем, для плюсов доступна т.н. техника "статического визитора", которая не совсем является классическим вихитором, но устойчиво так называют из-за статического ad-hoc полиморфизма:
V>>[ccode]
V>>template<Builder builder, typename Entity, typename Value>
V>>void visit(Builder * builder, MemberBetweenPredicate<Entity, Value> betweenExp) {
V>>  builder->onMemberBetweenExp(betweenExp);
V>>  visit(builder, betweenExp.member);
V>>}

V>>template<Builder builder, typename Entity1, typename Value1, typename Entity2, typename Value2>
V>>void visit(Builder * builder, boost::lambda::expression::equal<Entity1, Value1, Entity2, Value2> equalOp) {
V>>  builder->onEqualOp(equalOp);
V>>  visit(builder, equalOp.left); 
V>>  visit(builder, equalOp.right);
V>>}
V>>...

V>>[/ccode]
S>Прикольно. То есть все Expression Trees процессятся статически, во время компиляции?
S>Как-то мне это кажется подозрительным. В какой-то момент всё равно произойдёт потеря информации о конкретном типе, т.е. рано или поздно всё свернётся в некий Predicate*.

V>>Не факт что в задаче персистить от запуска к запуску надо... Я же говорю - уже пошло слишком много деталей на одного меня.
S>Как правило, неперсистить неинтересно. За один запуск не получается получить так много данных, чтобы запросы по ним имело смысл делать в декларативном виде. (Тут я могу ошибаться, т.к. вроде бы на дотнете народ рапортовал об эффективности индексов в памяти супротив банального сканирования на объёмах от 16 элементов и выше)

S> Если любопытно, загляни в доку к boost::serialization. Выглядит это так (из примера):
V>>[ccode]
V>>class gps_position
V>>{
V>>    friend class boost::serialization::access;
V>>    friend std::ostream & operator<<(std::ostream &os, const gps_position &gp);

V>>    int degrees;
V>>    int minutes;
V>>    float seconds;

V>>    template<class Archive>
V>>    void serialize(Archive & ar, const unsigned int /* file_version */){
V>>        ar  & BOOST_SERIALIZATION_NVP(degrees)
V>>            & BOOST_SERIALIZATION_NVP(minutes)
V>>            & BOOST_SERIALIZATION_NVP(seconds);
V>>    }

V>>public:
V>>    // every serializable class needs a constructor
V>>    gps_position(){};
V>>    gps_position(int _d, int _m, float _s) : 
V>>        degrees(_d), minutes(_m), seconds(_s)
V>>    {}
V>>};
V>>[/ccode]

V>>Метод void serialize<>() вызывается для любого типа-архива как во время сериализации, так и для десериализации. 
V>>Вот пример исопльзования этого типа с XML-сериализацией: http://www.boost.org/doc/libs/1_43_0/libs/serialization/example/demo_xml.cpp
V>>Вот результат: http://www.boost.org/doc/libs/1_39_0/libs/serialization/example/demo_save.xml

V>>Отрывок из результата в XML:
V>>[xml]
V>><longitude>
V>>  <degrees>134</degrees>
V>>  <minutes>22</minutes>
V>>  <seconds>78.300003</seconds>
V>></longitude>
V>>[/xml]

S>>>Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.

V>>В любом случае для персиста потребуется арнтайм-метаинформация не только о типах прикладного языка, но и о структуре хранилища и об их взаимном ORM.В каком виде идет эта информация - не принципиально. ORM для C++ можно делать в технике, похожей на технику сериализации (это фактически одно и то же).
S>Да, при соблюдении определённых правил гигиены всё это может и сработать.

V>>Не очень. Компиляторы давно научились "склеивать" идентичный код, порожденный шаблонами для разных типов. Первые компиляторы С++ действительно порождали ОЧЕНЬ МНОГО бинарного кода, уникального для каждого инстанса шаблонной ф-ии или метода.
S>Да меня количество бинарного кода не очень колышет. SQL Server под свои внутренние структуры отжирает всё равно на порядки больше. Беспокоит в основном количество того кода, который придётся колбасить прикладному программисту. DML у нас изобилует лишними скобками и подчерками (и это мы ещё намеренно завинтили гайки насчёт произвольных выражений, т.к. у нас в качестве аргументов between() могут быть либо мемберы, либо константы).

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail