. А так же рекомендую, для общего развития, хотя бы бегло просмотреть книгу ASN.1 Complete by Prof John Larmouth -- знакомство с такой технологией, как ASN1 сильно расширяет кругозор.
E>Ничего личного, но перечисленные тобой вопросы от непонимания того, какие проблемы бывают при эксплуатации и развитии прикладных протоколов.
%) Ок... Сами же напрашиваетесь
Давайте по порядку... с "Версий интерфейсов". Устроит?
Занчится так... Что у нас есть:
1. Клиент.
2. Маршрутизатор.
3. Обработчик.
Из прочитаного сразу вопрос:
клиент отсылает запросы на сервер и каждый запрос должен уникальным образом однозначно идентифицироваться
Кем, идентифицироваться? Если клиентом — то для этого ему совсем не обязательно, посылать некий id серверу. Или не согласны? Даже в случае асинхронного взаимодействия — совсем, необязательно.
Так. Ладно... Пусть это нужно маршрутизатору... В этом случае (поскольку ему нужно будет с этим id работать) он должен знать его тип (или тип базового для типа id) класса. Согласны? В случаее, если знать тип id маршрутизатору не пологается... а пологается знать только базовый тип, то и работать он с ним смогЕт только как с базовым... Причем виртуальность в этом случае строго противопоказана... на стороне маршрутизатора нет кода типа id. Правильно? Т.е. клиент, в этом случае должен сериализовать свой id как базовый тип. Просто потому, что какой смысл посылать на сервер данные с которыми сервер работать все раавно не сможет?! Проблема в этом случае в том, что он и десериализовать его должен как базовый тип... А ему это нафиг не нужно. Т.е. если уж клиентский id так нужОн маршрутизатору (да... и при этом маршрутизатор совершенно не желает знать о типе клиентского id... ему для работы с этим id достаточно знать базовый тип id) то клиент сериализует свой id, приведя его к базовому... а в ответе от маршрутизатора его быть не должно. Клиент и сам "умный"... для того чтобы вести идентификацию своих же запросов (пусть и асинхронных) много ума не надо.
Тоже самое по отношению к цепочке маршрутизатор — обработчик. Зачем пересылать в обработчик id маршрутизатора!? Он там нужен только для того чтоб потом опять к нам вернуться? Весело, однако.
. А так же рекомендую, для общего развития, хотя бы бегло просмотреть книгу ASN.1 Complete by Prof John Larmouth -- знакомство с такой технологией, как ASN1 сильно расширяет кругозор.
E>>Ничего личного, но перечисленные тобой вопросы от непонимания того, какие проблемы бывают при эксплуатации и развитии прикладных протоколов.
G>%) Ок... Сами же напрашиваетесь
Вот это уже нормальный разговор пошел .
G>Давайте по порядку... с "Версий интерфейсов". Устроит?
G>Занчится так... Что у нас есть: G>1. Клиент. G>2. Маршрутизатор. G>3. Обработчик.
Ага, только во множественном числе.
G>Из прочитаного сразу вопрос:
G>
G>клиент отсылает запросы на сервер и каждый запрос должен уникальным образом однозначно идентифицироваться
G>Кем, идентифицироваться? Если клиентом — то для этого ему совсем не обязательно, посылать некий id серверу. Или не согласны? Даже в случае асинхронного взаимодействия — совсем, необязательно.
Если каждый запрос идет через свой канал (как http-запросы), то не нужен, в принципе. Хотя лучще все же идентификаторы со стороны клиента на сторону сервера передавать, если обработка запроса может занять длительное время.
А если все идет через один канал, да еще в асинхронном режиме, то идентификатор еще как нужен.
G>Так. Ладно... Пусть это нужно маршрутизатору... В этом случае (поскольку ему нужно будет с этим id работать) он должен знать его тип (или тип базового для типа id) класса. Согласны?
Согласен. Именно поэтому в моем примере используется общий базовый тип для всех идентификаторов.
G> В случаее, если знать тип id маршрутизатору не пологается... а пологается знать только базовый тип, то и работать он с ним смогЕт только как с базовым... Причем виртуальность в этом случае строго противопоказана... на стороне маршрутизатора нет кода типа id. Правильно?
А кто сказал, что нет. Есть Как и информация о том, что этот тип производен от базового типа.
G> Т.е. клиент, в этом случае должен сериализовать свой id как базовый тип. Просто потому, что какой смысл посылать на сервер данные с которыми сервер работать все раавно не сможет?!
Чтобы получить их в том же самом виде обратно.
G> Проблема в этом случае в том, что он и десериализовать его должен как базовый тип...
Нет, как раз клиент десериализует свой идентификатор в ответном сообщении именно как свой тип.
G> А ему это нафиг не нужно. Т.е. если уж клиентский id так нужОн маршрутизатору (да... и при этом маршрутизатор совершенно не желает знать о типе клиентского id... ему для работы с этим id достаточно знать базовый тип id) то клиент сериализует свой id, приведя его к базовому... а в ответе от маршрутизатора его быть не должно. Клиент и сам "умный"... для того чтобы вести идентификацию своих же запросов (пусть и асинхронных) много ума не надо.
Так в том-то и дело, что если использовать Async Completion Token ума нужно еще меньше Просто засовываешь все данные, которые тебе нужны для работы в trx_id и все! Когда получаешь trx_id обратно извлекаешь их оттуда и работаешь. А если прятать эти данные за каким-то GUID-ом, то придется поддерживать map между GUID-ом и остальной информацией. Вот от поддержки этого map-а async completion token избавляет.
G>Тоже самое по отношению к цепочке маршрутизатор — обработчик. Зачем пересылать в обработчик id маршрутизатора!? Он там нужен только для того чтоб потом опять к нам вернуться? Весело, однако.
Конечно весело. Маршрутизатор помещает в свой id имя клиента и id клиента и отсылает эту пару обработчику. Когда она возвращается, маршрутизатор знает, кому нужно отдать ответ. И получается stateless маршрутизатор, который у себе может вообще ничего не хранить.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Константин, я понимаю, что ты пока не в теме разговора, но я уже Владу устал объяснять, что бывают случаи, когда: E>- была исходная схема данных; E>- были клиенты A и В, которые сериализовали данные по этой схеме; E>- у клиента A схема данных расширилась и он стали сериализовать свои данные в новой схеме, про которую клиент B не знает; E>- когда клиент B получает от клиента A сериализованные данные, он должен беспрепятственно их десериализовать.
E>С XML-сериализацией все, в принципе понятно. Интереснее с двоичной сериализацией. E>Поддерживают ли стандартные средства двоичной сериализации .Net какой-нибудь механизм, который бы позволил клиенту B безболезненно десериализовать данные клиента A?
В 1.1 есть возможность либо ручками реализовать интерфейс ISerializable, либо сделать для такого объекта SerializationSurrogate. В 2.0 BinaryFormatter умеет обрабатывать простые ситуации вроде добавления/удаления полей.
А глобально такая проблема решается, как ты справедливо заметил, при помощи XmlSerializer, либо, в будущем, XmlFormatter.
Ну и наконец, еще один способ решения такой проблемы в однородной среде — передавать с сервера в том числе и сборки с клиентскими типами. Этот вариант хорош тем, что обновлять можно как угодно хитро, причем не только данные, но и прикладной код. Главное обеспечить совместимость публичного контракта.
Здравствуйте, AndrewVK, Вы писали:
AVK>В 1.1 есть возможность либо ручками реализовать интерфейс ISerializable, либо сделать для такого объекта SerializationSurrogate. В 2.0 BinaryFormatter умеет обрабатывать простые ситуации вроде добавления/удаления полей.
Спасибо. Вот этого ответа мне пришлось долго ждать.
Вероятно из-за неумения формировать правильные вопросы
AVK>А глобально такая проблема решается, как ты справедливо заметил, при помощи XmlSerializer, либо, в будущем, XmlFormatter. AVK>Ну и наконец, еще один способ решения такой проблемы в однородной среде — передавать с сервера в том числе и сборки с клиентскими типами. Этот вариант хорош тем, что обновлять можно как угодно хитро, причем не только данные, но и прикладной код. Главное обеспечить совместимость публичного контракта.
Как раз передача кода меня не интересует, т.к. не всегда возможна.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
C>>А зачем? Или вы будете ждать утверждения стандарта ISO на C# 2.0, прежде C>>чем начать использовать его?
VD>C# 1.0 уже ISO-стандарт. Делегаты были уже в нем. Да и используя даже не стандартизированный C# 2.0 я уверен, что никому и в голову не прийдет написать свой велосипед на тему делегата, а на С++ это в норме вещей. И это главное.
Не это главное. Главное в том, что делегат — это всего-лишь одна из очень многих концепций, и программистам на С++ необязательно ждать, когда же все модные концепции появятся в каком-то очередном языке.
Более того, понятие function object несомненно более широкое понятие, чем Delegate. Делегат — лишь частный случай, осуществляющий делегирование вызовов третьей стороне. А оно не всегда нужно, вот в чем дело-то (хотя, очень удобно для GUI).
Новоявленные анонимные делегаты как раз пытаются решить проблему избавления от "третей стороны", тогда как в С++ мы имеем эту возможность с самого начала, да еще и во многих вариациях — от глобальных и статических ф-ий, до функциональных объектов произвольной структуры, да и готовых биндеров в т.ч. (от STL и boost).
Здравствуйте, Cyberax, Вы писали:
>> E>и попытались десериализовать этот двоичный файл, что получится? >> Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает >> стандартный механизм... Реализуем данный интерфейс ручками... Так как >> нам это нужно/хочеться. BinaryFormatter, да и любой другой форматтер, >> тут, собственно, и не причем.
C>Во многих системах сериализации для классов можно указывать политику C>преобразований из предидущих версий этих классов.
Задача, то прочитать не данные предыдущих версий, а "будущих".
Здравствуйте, VladD2, Вы писали:
C>>В С++ были шаблоны еще в 80-х годах, как раз на 4-5 году жизни.
VD>В 90-ых скорее. Да и делать вещи подобные boost::bind на них точно было нельзя. Их еле еле стало можно делать в конце девяностых. Так что можно смело говорить о том, что 10 лет приходилось сосать лапу.
Да нет, именно в реализации буста есть ветки, предназначенные для компиляторов без поддержки частичной специализации.
Еще осталось только попытаться представить себе статистику случаям применений делегатов и ответить себе на вопрос — а оно надо было раньше 95-97-го года?
Скажу ответ сразу — делегаты в чистом виде наиболее востребованы в ГУИ. В большинстве остальных случаев мы легко обходимся либо самим указателями на ф-ии, либо функциональными объектами.
VD>Сейчас у него перед глазами есть и С++, и Ада, и Шарп с Явой, и черт лысый. Но выводов он делать не торопится и выводы все какие-то странные.
От него лично сейчас уже мало что зависит. Страуструп дал прекрасный язык вначала, а его адаптация к актуальным задачам — это уже дело, скорее, С++ сообщества. Именно их предложения двигают сам процесс пересмотра стандартов комитетом. Так что, высказывайся, плиз, по адресу.
VD>Блин, примитивного указателя на методы который не был бы ограничен методами одного класса, а инициализировался бы любыми методами с совпадающей сигнатурой. Это же так просто! Ни языка, ни концепций эта вещь не нарушит. Об этом Страуструпу долдонили целых 10 лет. Но у него свой путь.
Этот примитивный указатель примитивно получается и сейчас с помощью буста или любой другой реализации этой концепции.
Если бы в С++ было возможно только одиночное наследование, то не было бы проблем. А так, именно в компайл-тайм компилятор выполняют необходимую адресную арифметику в случае множественного наследования и использования this некоей базы, стоящей не первой в цепочке наследования. Перенести это в run-time не представляется возможным, т.к. С++ компилятор генерит только лишь предназначенный для непосредственного исполнения бинарный код.
Andrei N.Sobchuck wrote:
> C>Во многих системах сериализации для классов можно указывать политику > C>преобразований из предидущих версий этих классов. > Задача, то прочитать не данные предыдущих версий, а "будущих".
Можно и так при желании — если в будущих версиях сохранена совместимость
со старыми.
Здравствуйте, VladD2, Вы писали:
VD>А долго в каком веке был создан C#? Если ты забыл, то я напомню. C# появился на свет в 2002 году. Так что это функционального типа с кучей ограничений пришлось здать 20 лет. А дженериков пришлось ждать 3 года. И не нужно приплетать сюда красивые даты вроде веков.
А я до сих пор не понимаю, почему они сразу не выпустили свой C# с генериками? Тем более в 2002-м?
VD>Ерунда какя-то. Просто "мама купит мне казу я тебе не паказу". VD>Речь идет о том, что такую базовую сущьность как ссылка на метод нужно было вводить в язык. И заниматься ею должны те кто создают языки и компиляторы, а не гуру-прораммисты в поте лица обходящие ограничения компилятора.
Э нет, это не ссылка на метод. Это ссылка на объект, который хранит в себе указатель на экземпляр класса и выполняет делегирование вызова определенного метода класса.
Указатели на ф-ии в С++ есть, и этого достаточно для произвольного оперирования ими. Да и нам не всегда нужно делегирование вызова третей стороне. Здесь ответил:
E>>Я это к тому, что всем должны заниматься профессионалы в своей области. Ведь boost в C++ пишут очень продвинутые люди.
VD>И почему проффесионалы в области программирования занимаются работой компиляторо-строителей и дизайнеров языков? Почему нужно было ждать 20 лет пока прийдут эти самородки и наежжут тех кто делал компиляторы их же компилятором? Что мешало сделать аналог сигнала или бинда еще в 85-ом?
Ничто. В QT слоты и сигналы очень давно. QT, кстати, тоже графическая приблуда. Вот тебе и ответ, насчет 85-х.
VD>Так вот я тебе скажу. Сначала это была ошибка дизайнера языка. А теперь неумение ее признать и гордыня.
Сначала это было элементарно невостребовано, а теперь это уже есть, да еще и в гораздо более мощном виде, чем в C#. Предоставляемые возможности просто несравнимы.
Здравствуйте, vdimas, Вы писали:
V>Более того, понятие function object несомненно более широкое понятие, чем Delegate. Делегат — лишь частный случай, осуществляющий делегирование вызовов третьей стороне. А оно не всегда нужно, вот в чем дело-то (хотя, очень удобно для GUI).
V>Новоявленные анонимные делегаты как раз пытаются решить проблему избавления от "третей стороны",
Насколько мне известно, анонимные делегаты — это просто синтаксический сахарок. Никаких новых концепций в язык они не привносят.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Заметь, это весь пользовательский код.
Слово "пользовательский" — ключевое. Аттрибуты сами по себе ничего не делают, кто должен что-то сделать для их использования. Ничем не хуже мини-велосипедов для С++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Мне интересно, возможно ли с делегатами C# то, что выделено жирным? И если не возможно, то как тогда твое возражение понимать?
VD>Ты пример приведи где я делегатами не смогу реализовать твои изыски. Пойми, это просто более универсальная и гибкая сущьность.
Наоборот — это ограниченная сущность. Делегат умеет лишь передавать управление тратьей стороне. Более общая сущность — это callback. В С++ у тебя есть куча производных от нее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Так как же в C# сделать делегат, который должен вызывать нестатический метод объекта, но при этом не связан с конкретным объектом?
VD>А зачем?
Чтобы подменять этот объект. (Behaviour — паттерны)
Например, этот делегат используется уже очень многими объектами, и огранизовывать подписывание-отписывание может быть делом накладным или даже невозможным, ибо экземпляр нашего делегата мог быть передан "еще неизвестно куда", в какой-нить плагин.
Здравствуйте, eao197, Вы писали:
E>Это достаточно грубая и неумелая попытка уйти от конкретного вопроса.
Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн. И объяснили, что все что можно сделать с помощью указатели на методы классов С++ можно сделать с помощью делегатов. Делегат это вообще очень гибкая вещь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Это уже, как говорится, второй вопрос. E>Т.е., я был прав, говоря, что в C++ мы можем иметь указатель на нестатический метод без объекта, а в C# -- вряд ли.
Ага. Только это ровным счетом ничего не значит. Так как использовать указатель без сслки на объект все равно не удастся, а делегат прекрасно может создаваться динамически что позволяет делать все что угодно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Ага. Предположим у тебя есть объект типа TextFormatter и объект типа DiskFormatter. У обоих есть метод void format(). Захотел бы ты получить делегат...
Вот так же рассуждал Страуструп. Результат — куча программистов заняты обходом придуманного им ограничения.
Посмотри в глаза фактам. Ну, нельзя полноценно использовать эту дурь.
А что до случайного подсовавания нетого метода с той же сигнатурой, то — это просто софистика. Метод с той же сигнатурой но совсем неподходящим поведением может попасться и в том же классе (имя ведь не влияет на указатель), так что же никто не кричит, что это грабли и что нужно бояться использовать эти указатели на методы? Ответ прост, потому что на прктике такие ошибки раритетная редкость и отлавливаются они на раз. Это просто нормальная логическая ошибка. Никаких проблем связанных с типами тут быть не может. А страховать от логических ошибок язык не должен. Я ведь могу банально вызвать не тот метод или не у того объекта и без указателей. Было бы очень смешго если бы язык не давал бы вызвать "не тот метод". Не находишь?
E>, который вызывает метод format у неизвестно какого объекта? Прямо как русская рулетка -- либо текст отфоматирует, либо диск, на котором этот текст должен лежать.
Самому то не смешно? Высосал апакалипсис из пустого места.
VD>>Делегат — это ссылочный тип. Переменная типа делегат может указывать на любыее методы любых объектов. Так что функционально ты ничем не связан. Делегат же можно рассматривать как указатель на метод. Причем не только на метод эеземпляра. Он точно так же может указывать и на статический метод.
E>Влад, я уже устал спрашивать: может ли быть делегат, который нужно связать с нестатическим методом объекта, без самого объекта?
Переменная может. Сам делегат (на который ссылается переменная) неизменяемый объект. Он может тольк создаваться и комбинироваться с другими. Естественно он может указывать только на конкретный метод конкретного экземпляра. Только искать в этом фатальный недостаток бессмысленно. В конце концов всегда можно динамически создать делегат из ссылки на обхект и идентификатора метода.
В общем, чем искать недостатки там где их нет просто попробуй придумать простой пример который по-твоему нельзя будет решить с помощью делегатов, но можно с помощью указателей на мтеоды.
VD>> То есть делегат.
E>Пристрелите меня.
Не, мы люди добрые. Мы быстро не убиваем.
E> В беседах с тобой у меня и так возникали сомнения в своей способности логично мыслить.
Я тоже это заметил. (шучу)
E> Сейчас вообще наступил какой-то клинический случай -- я просто уже не верю, что логика существует.
Сушествует. И если не сопротивляться ей пытаясь найти какие-то притянутые за уши вещи в оправдение не верных теорий, то она даже работает.
E>Я использую. И я приводил примеры тебе и AndrewVK.
Еще один пример сможешь привести? Ну, вещь то такая универсальная. Неужели 2-3 применений не найдется?
Между тем я тебе продемонстрировал как твой случай легко решается на делегатах. Тебе не кажется странным, что делегат решает и эту проблему, и тысячи других, но при этом ты называешь его менее универсальным?
Поробую объяснить еще раз. Ты вбил себе в голову ошибочную догму, что мол указатель в котором нет (назавем его так) this более универсален нежели указатель который содержит в себе этот самый this. Но на практике люди думают объектами и им просто нет необходимости делать ссылку со сменным объектом.
С другой стороны ты не хочешь принимать аргументы связанные с тем, что привязка указателя к методам конкретного класса резко сужает область применения этой фичи. Другими словами это частное решение. Я был бы не против если бы такое частное решение существовало бы, при условии, что есть более универсальное решение позволяющее ссылаться на любой метод с нужной сигнатурой.
Вот и получается, ты цепляешся за эфимерную возможность фичи которая тебе кажется приемуществом при этом на отрез не хочешь воспринимать аргументы об ограниченности фичи и к тому же утрверждаешь, что эта фича более универсальна нежели другая (делегат). И даже практические примеры тебя не переубеждают. Как ты думашь как это называется и что происходит с твоей логикой?
VD>>Языком если только. Не уверен, что лично ты справишся если не заглядывал в тот же сигнал.
E>См. выше.
(к сожалению статья пока не доступна целиком, но уверяю наваротов там...)
VD>>Забавно. Ты только что смотрел пример где не только динамически привязывался экземпляр объекта, но и динамически же привязывался метод. Хрена два ты такое на современном С++ сделашь. Но тем не менее пыташся делать выводы об ущербности делегатов.
E>No comments.
+1
VD>>Так же. Не позволяют ссылаться на метод по сигнатуре тем самым ограничивая тебя экземплярами одного объекта.
E>См. выше. В классе format_method_binder_t легко сделать замену как указателя на объект, так и указателя на метод.
Ты породил два разных типа (две специализации), а не создал один универсальный указатель. Попробуй подсунуть в один указатель ссылку на другой метод.
К тому же ты нагородил целую кучу кода создав при этом не универсальную реализацию. Для следующей ссылки тебе прийдется наколбасить новую горку кода. И все это только чтобы обойти ограничение на ссылку.
Какой в этом смысл? Почему просто не ввести в язык указатель на метод (без класса)? Код сократился бы до декларации переменной.
E>Это я тебе хочу сказать: читай то, что тебе отвечают опоненты.
Читаю, с ужасом. Я им про Фому, а они мне про Ерему.
E>А я сказал, что если это декларативное программирование добавляет мне лишние неудобства -- по пусть оно идет лесом.
Где ты взял неудобства? Придумываешь на ходу себе проблемы и ударно с ними борешся. Забуть что это сообщения видовс. Оцени прсто саму идею. Тебе тут уже АВК привел пример с декларативным описанием действия в Янусе. Но ты и его умудрился не понять.
E> Лично мне, когда я стал использовать макросы из windowsx.h программировать стало проще.
Ну, так попрограммируй на том же ВинФормс и поймешь, что тратил последние несколько лет зря. Там макросы не нужны.
E> И более того, избавило от проблем при переходе на 32-х битовый Windows, когда упаковка параметров в некоторых сообщениях изменилась. А приведенный код мне не понравился тем, что из-за декларативности все обработчики оконных событий имели одинаковую сигнатуру, хотя давно было доказано, что это неудобно.
Это тут не причем! Нельзя из пальца высасать описание конкретного сообщения. Вот и одинаковы сгнатуры.
В общем, ты в очередной раз начав понимать, что оппонент прав привязался к стороннему факту и всячески переводишь обсудение на него. Напомню, что мы осбудали делегаты.
E>Так что все эти рюшечки и фишечки хороши только для самолюбования. А когда начинается реальная эксплуатация, столько оврагов обнаруживается, которых на бумаге не было, что мама не горюй.
Ясно. Это я видел уже не раз. Счасливо остоваться со своими догмами.
E>Я тебе могу сразу сказать результат. Решение на плюсах будет объемнее. Поскольку вручную придется делать то, что в C# уже сделано.
Оно бедет не просто объемнее. Оно будет кривым. Потому что прийдется заниматься закатом солнца вручную. Генерировать метаданные и вручную связывать все между собой. У меня добавление обработчика будет внесением записи в ХМЛ-файл, а у тебя танцем с бубнами.
E>Но я пытаюсь объяснить тебе простую вещь, основанную на опыте: любое удачное решение будет требовать развития. И во многих случаях оказывается, что доработка специализированного решения бывает проще, чем отказ от стандартного решения в пользу специализированного.
Спосибо, объяснил. У меня опыта то нет. Вот лабаю все без равития...
E> Вот сейчас ты воспользовался возможностями C# и тебе их хватило.
Мне их не хватило. Я их умею использовать. Причем использовать для решения достаточно большого круга задачь. Не нужно делать вид, что C# оказался заточен на пару задачь вроде сериализации или конфигов. Это универсальное средство. И что на нем не пиши всегда получается "несколько более короткий код и несколько более красивые решения". И это при таких то ограничениях!
E> Но ты так и не ответил мне, что ты будешь делать, если в конфиге нужно будет указать имя CaretVirtualLineUp, а в программе, в зависимости от других настроек, нужно будет использовать другие имена.
Мне это не нужно. Если будет нужно, я введу атрибут в который буду помещать публичное имя метода которое и буду использовать в ХМЛ-описани шорткатов.
E> Не придется ли тебе тогда программу латать?
Нет. Придется изменить класс обработчик клавиатуры и сделать контекстную замену вынимающую имя метода и помещающую его в атрибут. Далее пользоваться атрибутами.
E>Ключевой момент! Круто будет выглядеть продукт, выход новой версии которой сопровождается необходимостью править конфиги просто из-за того, что разработчик продукта произвел рефакторинг!
Бред каокой-то. Не меня названия или пиши скрпт модифицирующий конфиги. Ну, или сразу используй атрибуты. Какое это отношение имеет к гибкости и т.п.?
E>Я же не про парсинг, а про чтение значений из XML. Мне так сразу статью про якобы кульный способ автоматической сериализации/десериализации C#-ких объектов. А себе что-то применить такой способ слабо оказалось? Это что, двойные стандарты или "сапожник без сапог"?
Ты дальше то прочел мое сообщение? Или снова занимашся развитем провалившегося наступления? Там 6 строк кода. Я сделал выбор между сокращением их до трех и ускорением считывания в 10 раз. Что тебе не ясно то?
E>Она как оказывается! XML это еще и тормоза, о которых даже при небольших размерах конфига нужно думать. Да уж, доморощенные велосипеды нервно курят в сторонке.
XML — это текст. Чем более высокоуровнево ты работаешь с данными тем медленее. Дальшее баланс между производительностью, трудозатратами на кодирование и сервисом получаемым от того или иного решения. Я выбрал в пользу скорости. Но заметь для этого я не написал свой парсер, а воспользовался самым быстрым доступным стандартным.
E>Это я и так понял. Мне интересно, такая запись по-твоему нормальна? То, что твой код ее проглотит еще не означает, что пользователю нужно разрешать так писать. Может он ошибся, а мы ему об этом ничего не скажем.
Добавить проверку на совпадение модификаторов — это одна строка кода. Только в данной задачи это лишнее. Там и так не ошибешся. Да и настраивать вручную такой конфиг будут очень не многие. И уж точно очень редко.
E>Полный код класса KeyboadShortcatsMap делать, естественно, не буду.
Естествено. Иначе была бы сразу видна вся мощь С++.
E> А вот парсинг конфига: E>
И вообще я тебе даю работающий код, а ты мне псевдокод которыый еще не ясно что делает.
E>Чтобы нельзя было размазывать привязывание keymap-ов к одному action-у в разных концах конфига.
Ясно. Это очередное переусложнеие. Из сери чтобы было.
E>Влад, здесь прослеживается попытка обвинить мой код в неработоспособности.
Это просто констатация факта. Я не могу ни запустить его, ни сравнить. А сравнивать псевдакод и рельно работающй не очень хорошая идея. Вроде мой код даже длинее, но на поврку то все не совсем так. Эти фрагменты в 30 строк заменяют мои 6. А аналогов для всего остального увидеть не удается.
E>Если хочешь доказать неработоспособность чего-либо, то приводи примеры.
Я хочу "помацать". А "мацать" нечего. А доказывать неработоспособность мне не нужно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Ok. Давайте будем для четкости использовать "тип делегата" и "экземпляр делегата" (равно как "тип указателя на метод" и "экземпляр указателя на метод").
Еще, для четкости, нужно понять, что есть переменная "типа делегата" ссылающаяся на "экземпляр делегата". Вот тогда все встанет на свои места.
Переменная может содержать ссылки на любое количество разных экземпляров делегатов указывающих на разные методы разных объектов. При этом нет проблем изменить переменную делегата так чтобы она ссылалась на другой(ие) методы.
E>Так вот я прекрасно понимаю, что "тип делегата" никак не связан к конкретным экземпляром объекта (так же, как и тип указателя на метод). Но вот экземпляр делегата (как мне уже объяснил AndrewVK) может быть либо связан со статическим методом, либо с нестатическим методом конкретного объекта (т.е., экземпляр делегата связан с конкретным объектом). Но не может быть экземпляра делегата, связанного с нестатическим методом, но не имеющего объекта. А это означает, что если в твоем примере мы создали экземпляр делегата для t.Format(), то связать этот же делегат с c.Format() мы уже не сможем.
Попробуй отразить сказанное тобой на примере. Что мы не сможем сделать?
E>Так же мы не сможем сделать делегат для вызова метода Format у любого неизвестного пока объекта типа Text.
Класс! Я тебе привел 3 примера именно это и делающих. Причем в рантайме (тип может быть не известен до запуска) и динамически.
E>А вот в C++ мы можем создать экземпляр указателя на метод Format объектов типа Text, не имея самого объекта этого типа.
И что с ним делать дальше?
E> И затем использовать этот указатель для вызова метода Format у любого объекта типа Text без пересоздания самого экземпляра указателя на метод.
И что мешает просто сделать нужное количество ссылок на методы объекта?
Ты вообще хорошо представляшь как в рантайме инициализируется делегат?
E>И именно поэтому я считаю, что механизм указателей на методы в C++ является более общим, т.к. он:
Примеры, в студию, что можно сделать этим "более общим" механизмом. И пример в студию как этим общим механизмом положить в один массив указатели на методы разных классов.
E>1) позволяет как связать указатель с конкретным объектом (посредством дополнительных оберток, как в моем примере или средствами boost-а),
А зачем тут шаблоны то? Тип метода не изменяется ведь.
E>2) создавать экземпляр указателя на конкретный нестатический метод без наличия самого объекта.
Зачем?!!!
E>В C# п.1 получается автоматом, т.к. для этого есть поддержка со стороны компилятора. В C++, можно сказать, такая поддержка так же есть со стороны boost.
Заплатка это а не поддержка.
E>А вот как получить реализацию п.2 в C#?
Блин. Зачем? Еще раз, опиши задачу не решаемую "более узко специализированными делегатами".
E>PS
E>Просьба не апелировать к тому, что экземпляры указателей на методы без объектов не нужны. Я их использую, значит мне нужны. И, имхо, их использую не только я.
Чущь, именно к этому и нужно апеллировать, так как ты использушь их исключительно в связке с конкретными указателями на объекты. И никогда без них.
Ты втемяшил в свою голову, что это дает какую-то универсальность. А на самом деле это ничего не дает.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Извини, я уже начинаю злиться разговария с тобой. Наверно я не прав, но я всегда злюсь когда меня не понимают.
Видимо проблема твоего не понимания заключается в том, что тебе прийдется переломить себя и выбросить из своего сознания те готове решения которые ты так долго в него закладывал.
Все мы мыслим паттернами, но если их не сравнивать с чужими, то они превращаются в догму.
Мы просто говорим на разных языках. Причем я понимаю твой язык, так как сам прошел через все о чем ты говоришь, но к сожалению этого не достаточно чтобы объяснить тебе то мировозрение которое есть в мире управляемого кода.
По сему мне кажутся бесполезны все эти рассуждения и споры. Если ты действительно хочешь понять мою позицию (я и не заикаюсь о принять) — это попытаться самому поработать с тем о чем ты ведешь речь. Я готов помочь советом в этом процессе, но продолжать объяснение не хочу, так как не по-моему конструктива в нем уже не будет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
