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

VD>>>Странно. А ведь boost::bind это море очень не быстро компилируемого кода который использует уж совсем не кчемную функциональность языка вроде указателей на методы. И все это вмесо примитивной модификации языка.

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

VD>Приведи пример где ты их используешь. Я видел их использование только в коде который пытался эмулировать функцинальность делегата (назавем его так, чтобы отличать от того что есть в С++).

VD>Только перед тем как приводить убедись, что ты правильно меня понял. Речь идет не о С-шном указателе на глобальную функцию, а о С++-ном указателе на функцию-член класса.

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

Один из use case в которых я использую указатели на методы -- это реализация в объекте-классе чего-то типа конечного автомата. Наружу такой объект предоставляет, например, один метод: receive_event( event_t event ), а внутри себя должен выполнить действия в зависимости от состояния объекта. Решение в лоб выглядело бы так:

void some_class_t::receive_event( event_t event )
    {
        if( state_one == current_state() )
            {
                if( event_one == event )
                    do_something();
                else if( event_two == event )
                    switch_state( state_two );
                ...
            }
        else if( state_two == current_state() )
            { ... }
        ...
    }

А если применить указатели на методы:

void some_class_t::receive_event( event_t event )
    {
        (this->*m_state_handler)( event );
    }
void some_class_t::state_one_handler( event_t event )
    {
        if( event_one == event )
            do_something();
        else if( event_two == event )
            // Для переключения состояния просто меняем указатель на текущий обработчик.
            m_state_handler = &some_class_t::state_two_handler;
    }

А можно было бы пойти еще дальше. Скажем завести отдельный map< event_t, (some_class_t::*)() > для каждого состояния. И занести в эти map-ы указатели на методы, которые должны вызываться в конкретном состоянии по конкретному событию. Тогда смена состояния будет означать просто смену указателя на нужный map. А работа метода receive_event -- поиск указателя в map-е по идентификатору события и вызов найденого обработчика.

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

E>>Опиши.

VD>Ладно. Попробую...

<...Эмоциональное описание того, что тебе кажется неправильным поскипано...>

Твоя точка зрения понятна. Но, имхо, она не правильная, а я согласен со Страуструпом.

E>>

---

VD>Какое отношение этот рассказ имеет к вопросу? Повторю еще раз цитаты:
VD>>>>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...

E>>>Нет. Далеко не всегда.

VD>>И когда нельзя?
VD>>Раскрывай.

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

VD>Что же до сериализации, то это проблемы С++ в ремоутинге и КОМ-е они решаются.

Насколько я знаю, там все решается на уровне жестко определенных интерфейсов. Причем не только в КОМ-е, но и в Corba. Как только интерфейсы перестают удовлетворять потребностям приходится вводить новые интерфейсы. Затем новые. Затем опять новые и т.д.

А вот в Asn1 было введено понятие "extension points" -- это такие места в спецификации протокола, где говорится -- вот в этом месте в будущем может что-то появиться. Что именно, пока никто не знает. Но если появится, то все, что здесь будет, может быть проигнорировано. Благодоря таким extension points обе стороны смогут обмениваться данными даже если их версии протоколов сильно отличаются.

Вот я и спрашивал, поддерживает ли BinaryFormatter в .Net подобные фишки. И все мои примеры как раз были об этом.

VD>К сожалению я пишу в офлайне и тыкать по внешним ссылкам не могу.

Понятно. Только, если тебе интересно, то выбери время и сходи. А нет, так я не вижу смысла копипастить сюда несколько полтора десятка килобайт описаний.

VD> Так что ты лучше кратенько приведи обоснование почему нельзя передать сборку на клиента?

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

E>>Хочу отметить, что все приведенные случаи не требуют того, чтобы взаимодействующие стороны точно знали типы используемых для коммуникации объектов.

VD>Для передачи по сети нужна только сериализация. Если она делается вручную или генератором кода, то на клиенте сборка не обязательна.

Вот именно. Но я говорю о случаях, когда сериализация/десериализация на разных сторонах делается по разным версиям описания схемы данных.

VD> Ну, и всегда можно сделать простенькое решение которое сможет копировать нужные интерфесные сборки в автомате. Итго — это не языковая проблема. Это проблема дизайна.

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