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

I>>>Прелесть XML не в том, что требуется меньше закорючек для описания структуры, и не в том, что его проще редактировать вручную, а в том, что он — СТАНДАРТ.

E>>Стандарт чего?

I>Стандарт описания структурированной информации.

Тогда бы я сказал, что это один из стандартов описания структурированной информации. Со своими недостатками.

I>>> С самопальными примочками типа Вашей можете разобраться только Вы. Для неё не сущесвует таких полезных и удобных технологий, как XML Schema (проверка), XSLT (преобразование), XPATH (запросы). Пользователи не смогут воспользоваться внешними высокоуровневыми редакторами этих файлов (а могли бы, если бы была XML схема).

E>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.

I>XML Schema — для проверки корректности структуры.

I>XSLT в HTML может быть удобен для визуального отображения config-файла.

I>XPath можеь быть использован для быстрого получения конкретных настроек в config-файле в сторонних приложениях.

I>Как видите, всё логично, и, САМОЕ ГЛАВНОЕ, стандартизованно. Проще разрабатывать СЕЙЧАС, легче (дешевле, быстрее) поддерживать в будущем.

Из всего перечисленного тобой самое важное, имхо, это возможность чтения конфигов сторонними приложениями. Но вот есть два вопроса:
— что, если это не нужно? Конфиги только для C++. В таких случаях проще таскать за собой самописную библиотеку разбора конфигов, чем какой-нибудь Xerces или libxml2;
— что, если в других языках (скажем Python или Ruby) принято использовать другие форматы конфигов, скажем YAML?

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

E>С такими выражениями стоило бы быть поосторожнее. VS2003 -- это C++, C#, VB (или что-то еще)? IDEA -- это Java.

Тем не менее и та и другая IDE позволяют редактировать XML.

E>Но под понятие "любой" подойдут так же языки Perl, Python, Ruby, Smalltalk, Oberon, Ada, Modula-2, Eiffel, Prolog, Lisp (все, что сразу удалось вспомнить) и еще куча языков.

Возможно и в их средах встречается приличный редактор XML.

E>Так что-же я должен увидеть?

Редактор XML.

VladD2 wrote:

> Да, хорошая демонстрация очередного заката солнца вручную. Ради хохмы
> приведу аналог вот этого:
>
>class gps_position
>{
>private:
> friend class boost::serialization::access;
> // When the class Archive corresponds to an output archive, the
> // & operator is defined similar to <<. Likewise, when the class Archive
> // is a type of input archive the & operator is defined similar to >>.
> template<class Archive>
> void serialize(Archive & ar, const unsigned int version)
> {
> ar & degrees;
> ar & minutes;
> ar & seconds;
> }
> int degrees;
> int minutes;
> float seconds;
>public:
> gps_position(){};
> gps_position(int d, int m, float s) :
> degrees(d), minutes(m), seconds(s)
> {}
>};
>
>
> на Шарпе:
>
>[Serializable]
>class gps_position
>{
> private int degrees;
> private int minutes;
> private float seconds;
>};
>
>
Не забудь еще конструторы.

Между этими примерами вся разница в методе serialize, на самом деле. При
наличии compile-time reflection он делается автоматом.

> C>Был бы в С++ нормальный compile-time reflection — все стало бы еще
> C>намного проще.
> Был бы у бабушки хрен...

Будет

>>> Все это конечно можно написать на С++, но это будет не один
>>> человекогод. И так почти в каждой области. Именно по этому мы
>>> (разработчики Януса) смело заявляем, что повторить Янус на С++ на
>>> объщественных началах практически невозможно.
> C>Берем Thunderbird и пишем к ней расширение для RSDN. На С++
> Ага... языком.

Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило
абсолютно. Понятно, что если переизобретать ньюсридер, то потребуется
куча кода. Для того же Thunderbird'а я оцениваю требуемый объем кода
расширений примерно в 200Кбайт на С++ и JavaScript.

Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и
читаю про использование custom-форм в нем, так что в будущем (в конце
лета во время отпуска) возможно будет Janus for Outlook

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AVK>Возможно и в их средах встречается приличный редактор XML.

E>>Так что-же я должен увидеть?

AVK>Редактор XML.

Блин, а я уж думал, что должен увидеть прозрачное отображение структур данных на XML в любом языке программирования

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

AVK>>Редактор XML.

E>Блин, а я уж думал, что должен увидеть прозрачное отображение структур данных на XML в любом языке программирования

Ты еще помнишь, что я отвечал на твой вопрос о нужности XML Schema для конфигурационных файлов?

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

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

AVK>>>Редактор XML.

E>>Блин, а я уж думал, что должен увидеть прозрачное отображение структур данных на XML в любом языке программирования

AVK>Ты еще помнишь, что я отвечал на твой вопрос о нужности XML Schema для конфигурационных файлов?

Уже нет . Вот если бы ты сразу об этом сказал, тогда помнил бы. А так фантазия разыгралась, уже не знал о чем и думать.

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

E>Уже нет . Вот если бы ты сразу об этом сказал, тогда помнил бы.

А я сразу и сказал. Я, в отличие от некоторых, цитирую только по делу.

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

E>А зачем? Ответ я от Павла Кузнецова получил. Воспринял и поставил соответствующую оценку.

Паша в шарпе сам не на много больше твоего знает. К тому же он ярый приверженец С++ и к шарпу пока что относится предвзято.

E>>> Здорово (еще бы, это не C# c Python-ом в разработке игр применять). Только проблема в том, что я и так привел минимальный реальный код. В дейсвительности там еще больше навороты на более высоких уровнях есть. И на C++ это все работает и является сопровождаемым.

E>Стройность и простота -- очень относительные понятия.

Да нет. Они очень даже конкретны. Просто иногда люди привыкают к непросым и громоздким решениями считая их в норме вещей.

E> И во многом зависят от квалификации разработчика. Для продвинутого C++ программиста использование boost::bind гораздо проще и понятнее, чем для начинающего (либо даже для C++ программиста с многолетним опытом, но не работавшем с шаблонами). Поэтому они могут дать совершенно разные оценки одному и тому же коду.

Вот, вот. boost::bind — это заплатка языка. В том же шарпе ты просто имешь превокласную сущность — делегат. Ее одинаково хорошо понимаю и используют и продвинутый программист, и неофит.

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

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

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

Опять же никаких проблем. Автоматизированный рефакторинг легко править все связи. Даже вне проекта.

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

Исключительно для С++. Буквально вчера я отрефакторил кучу кода где-то за час. Все скомпилировалось и заработало без ошибок с первого раза.

E>Да, это я уже понял. Точно так же, как то, что C++ пытаются оценивать, используя тараканов из C#.

Ты забывашь, что для многих (в том числе и для меня) Шарп был даже не вторы языком. С++ я знаю не намного хуже шарпа и использовал его очень долго. Так что я более чем знаком с обоими языками и могу смело сказать, что после изучения других языков начинашь лучше писть и на том же С++. Это я просек еще когда два года провозился с Дельфи.

E>А можно подробнее об этой куче (можно вот в эту ветку: [ANN] ObjESSty &mdash; еще один проект сериализации

Автор: eao197
Дата: 24.01.05

)?

Откровенна говоря с некоторых пор проблемы трехколенных вывертов на С++ для решения примитивных задач меня перестали интересовать. Эта как раз такая. Тратить время не нее мен не хочется.

E> Ты, кстати, прочитал, для демонстрации чего был создан этот пример?

Дошел до фразы "как средства сериализации в организации межпроцессовых взаимодействий" и потирял всякий интерес читать дальше, так как это поять же тараканы С++ на которые мне смотреть не интересно. Мне проще писать на языках не имеющих таких проблем, или на худой конце воспользоваться КОМ-ом или Корбой.

VD>> Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.

E>Что-то я там с ходу не увидел, как с помощью BinaryFormatter можно десериализовать объекты, про которые принимающая сторона даже понятия не имеет? Или BinaryFormatter содержит в себе больше возможностей чем ASN1?

Незнаю как такое можно не заметить...

BinaryFormatter formatter = new BinaryFormatter();
object obj = formatter.Deserialize(mySream);

Вопрос только что дальше делать с этим самым obj.

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

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

E>>Уже нет . Вот если бы ты сразу об этом сказал, тогда помнил бы.

AVK>А я сразу и сказал. Я, в отличие от некоторых, цитирую только по делу.

Поскольку под некоторыми понимаюсь я, то для расстановки точек над i я хотел бы привести исходную цитату:

E>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.

Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.

Так вот в русле предыдущего обсуждения, когда Влад дал ссылку на статью с описанием автоматической сериализации C# в XML-конфигурационные файлы, ничто не мешало мне проинтерпритировать твою фразу как намек на то, что любая современная IDE позволяет делать такое прозрачное отображение структур на XML с помощью XML Schema.

А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат), чем таскать за собой монстрообразные XML-парсеры и использовать их в угоду тому, что XML считается стандартом. ASN1 так же является стандартом. И что из того?

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

VD>Вот, вот. boost::bind — это заплатка языка. В том же шарпе ты просто имешь превокласную сущность — делегат. Ее одинаково хорошо понимаю и используют и продвинутый программист, и неофит.

Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.

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

VD>Исключительно для С++. Буквально вчера я отрефакторил кучу кода где-то за час. Все скомпилировалось и заработало без ошибок с первого раза.

Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.

VD>>> Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.

E>>Что-то я там с ходу не увидел, как с помощью BinaryFormatter можно десериализовать объекты, про которые принимающая сторона даже понятия не имеет? Или BinaryFormatter содержит в себе больше возможностей чем ASN1?

VD>Незнаю как такое можно не заметить...
VD>

VD>BinaryFormatter formatter = new BinaryFormatter();
VD>object obj = formatter.Deserialize(mySream);
VD>

VD>Вопрос только что дальше делать с этим самым obj.

Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?

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


AVK>>А я сразу и сказал. Я, в отличие от некоторых, цитирую только по делу.

E>Поскольку под некоторыми понимаюсь я

Не угадал.

E>Так вот в русле предыдущего обсуждения, когда Влад дал ссылку на статью с описанием автоматической сериализации C# в XML-конфигурационные файлы, ничто не мешало мне проинтерпритировать твою фразу как намек на то, что любая современная IDE позволяет делать такое прозрачное отображение структур на XML с помощью XML Schema.

Ну вот не надо читать между строк и все будет впорядке.

E>А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат),

В каких?

E> чем таскать за собой монстрообразные XML-парсеры

Парсер XML входит в состав фреймворка, специально таскать его не нужно. Кроме того, парсеры xml для конфигурационных файлов можно уложить в 5-10Кб кода, прецеденты есть.

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

C>Не забудь еще конструторы.

Не забыл. Они не нужны.

C>Между этими примерами вся разница в методе serialize, на самом деле. При
C>наличии compile-time reflection он делается автоматом.

Ага. Все разнца в том, что нужно писать код. Причем чем сложнее случай, тем больше будет кода. В дотнете же в 99% случаев код писать попросту не прийдется.

C>Будет

Хрен или дедушка?


Ну, да когда будет тогда и поговорим. Пока что новый стандарт ожидаетя не ранее 2008 года, до тех пор еще много воды утечет.

C>Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило
C>абсолютно.

Самом собой. Найди лучше.

C> Понятно, что если переизобретать ньюсридер, то потребуется
C>куча кода. Для того же Thunderbird'а я оцениваю требуемый объем кода
C>расширений примерно в 200Кбайт на С++ и JavaScript.

Безумству храбрых поем мы песню. (с)

C>Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и
C>читаю про использование custom-форм в нем, так что в будущем (в конце
C>лета во время отпуска) возможно будет Janus for Outlook

Опоздал. У нас уже 100 лет как есть NNTP. Просто подпишись на него любой читалкой новостей и мучаться не прийдется.

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

E>Если серьезно, то я признаю, что в C# удобно делать сериализацию в XML.

Дело в том, что в нем оОоочень многое делать оОооочень удобно.

E> Так ведь для языка, который появился в расцвет XML-я это и не удивительно, не так ли?

Открою тебе сикрет. Шарп неимеет ни одной запятой рассчитанной на ХМЛ. Это такой же универсальный язык как и С++. Вся поддержка ХМЛ в дотнете реализо на Шарпе. Более того этот код досупен в Роторе (ну, или декомпилятором).

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

E>Ой-ли?

Еще как ой.

E> Не убедительно. Лично я останусь при своем мнении.

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

Я же просто хотел объснить тебе, что примеры того как на С++ можно замазать проблему этого языка ничто по сравнению с птимерами использования возможностей дотнета. В купе получается что писать программы на Шарпе под дотнетом значительно проще и результат получается куда надежнее.

E>Это дело вкуса.

Это не дело вкуса. Это дело стандартизации и дизайна.

E> По мне, так гораздо страшнее было бы работать с конфигом вида:...

Дык не создавай избыточных конструкций. А работать один фиг будет проще, так как есть такие мощьные вещи как: DOM, XSLT, XPath, XQuery. Боюсь ты даже представить себе не можешь как они могут облегчить жизнь.

E>Неужели это выглядит более читабельными и понятным?

Примерно как твой. Все равно сахивает на Лисп.

E>...Неужели бы он выиграл бы от XML-формата?

Не особо хуже. За-то изучать его было бы проще.

E>Ну я в свое время насмотрелся (на Java и C++), как хранят конфиги в XML а затем извлекают из них значения. Если используется DOM-модель, то после нескольких строчек обращения к парсингу шла масса строк с поиском и извлечением значений из DOM-элементов.

Видимо те кто это делали не знали про XPath.

E> А если использовалась SAX-модель, то код все равно получался таким же, как у меня, только нужно было еще корректно из строк в int-ы преобразовывать.

Как у тебя не получится, так как ты полностю парсер вручную написал. Я кажется тебе уже говорил, что для таких вещей нужно построители парсеров использовать.

VD>>Как я понимаю твой код не умеет впихивать информацию в объекты и читать ее из них. Попробуй ради хохмы добавить такую возможность.

E>Вот именно -- ради хохмы. А в реальности мне такая фишка пока не потребовалась.

Ага. "А нам и не надо". Не думаю, что кто-то по своей воле отказался бы просто работать с объектами и сохранять или загружать их состояние с помощью одной строчки кода. Ну, разве что "на зло". Типа выбью себе глаз, чтобы у тещи зять кривой был.

E>Там нет зачатков языка программирования. Просто похожие конструкции.
E>Кроме того, у граматик и парсеров есть большие проблемы с раширяемостью.

Не замечал.

E> Вот потребуется в тег {pixmap} еще один подтег добавить, и придется граматику править.

Да, уж проблема страшная. То ли дело отыскать в горе код нужную функцию и приписать еще горку кода.

E> И еще не понятно, насколько проще это окажется, особенно если граматика получится сильно контекстно-чувствительная.

У тебя примитивнейшая граматика описываемая в LL(1). В любом случае ручной парсинг более менее сложного формата всегда сложнее создания аналога вручную.

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

Возможно. Но попробовать стоит. Иначе зачем вообще пытаться что-то сравнивать?

E>Имхо, тебе пора перестать использовать в качестве доказательства крутости C# тот факт, что на C++ нет аналога Януса.

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

E> На C# нет аналога GNOME или KDE,

На C# есть винформс который полносью перекрыват возможности их как библиотек ГУИ. Если ты об оболчке, то в Лонгхорне большая ее часть писана на том же шарпе. Ну, и к шарпу есть GTK .

E>почему бы не сказать, что на C# эти проекты нереализуемы?

Ты где-нибудь слышал о том, что их нужно переписывать на Шарпе и тем более что это как пару байт переслать? То-то же, а про янус это уже стало местным приколов. Раз в неделю-другую появлется очередной орел и предлагает переписать Янус на шарпе. Все как один случае кончаются на пустопорожних обещаниях. Вот тут рядом еще одно обещание дали.

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

E>Хотя бы для какого языка программирования эта IDE должна быть?

IDE все больше и больше к языкам не относятся. Та же VS 2003-2005 отлично редактирует ХМЛ на основе схемы.

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

AVK>Ну вот не надо читать между строк и все будет впорядке.

Ok. Наследие советского прошлого

E>>А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат),

AVK>В каких?

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

E>> чем таскать за собой монстрообразные XML-парсеры

AVK>Парсер XML входит в состав фреймворка, специально таскать его не нужно. Кроме того, парсеры xml для конфигурационных файлов можно уложить в 5-10Кб кода, прецеденты есть.

Да, но если речь идет об C++, то такие парсеры не чуть не лучше собственных поделок.
Кроме того, если речь идет именно о конфигах, а не об интероперабельности на уровне документов, то XML здесь, имхо, не стандарт. Особенно на Unix-ах.

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

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

E>>Если серьезно, то я признаю, что в C# удобно делать сериализацию в XML.

VD>Дело в том, что в нем оОоочень многое делать оОооочень удобно.

В частности, создавать в generic-ах объекты заданных в параметре шаблона типов с передачей аргументов в конструкторе

E>> По мне, так гораздо страшнее было бы работать с конфигом вида:...

VD>Дык не создавай избыточных конструкций. А работать один фиг будет проще, так как есть такие мощьные вещи как: DOM, XSLT, XPath, XQuery. Боюсь ты даже представить себе не можешь как они могут облегчить жизнь.

Правда? Столько жутких слов для обработки какого-то конфигурационного файла.

E>>...Неужели бы он выиграл бы от XML-формата?

VD>Не особо хуже. За-то изучать его было бы проще.

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

E>>Ну я в свое время насмотрелся (на Java и C++), как хранят конфиги в XML а затем извлекают из них значения. Если используется DOM-модель, то после нескольких строчек обращения к парсингу шла масса строк с поиском и извлечением значений из DOM-элементов.

VD>Видимо те кто это делали не знали про XPath.

Я думаю, что тогда его еще не было (2001 год). А затем унаследованный код нужно было рефакторить на перехода на XPath? А затем на что-то после XPath?

E>> А если использовалась SAX-модель, то код все равно получался таким же, как у меня, только нужно было еще корректно из строк в int-ы преобразовывать.

VD>Как у тебя не получится, так как ты полностю парсер вручную написал. Я кажется тебе уже говорил, что для таких вещей нужно построители парсеров использовать.

И где ты в моем коде увидел вручную написанный парсер? Ткни носом, плз. А то ведь библиотека cls_2, которая парсингом занимается, для программиста выглядит такой же готовой штукой, как Xerces или libxml2.

VD>Ага. "А нам и не надо". Не думаю, что кто-то по своей воле отказался бы просто работать с объектами и сохранять или загружать их состояние с помощью одной строчки кода. Ну, разве что "на зло". Типа выбью себе глаз, чтобы у тещи зять кривой был.

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

E>>Там нет зачатков языка программирования. Просто похожие конструкции.
E>>Кроме того, у граматик и парсеров есть большие проблемы с раширяемостью.

VD>Не замечал.

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

E>> Вот потребуется в тег {pixmap} еще один подтег добавить, и придется граматику править.

VD>Да, уж проблема страшная. То ли дело отыскать в горе код нужную функцию и приписать еще горку кода.

E>> На C# нет аналога GNOME или KDE,

VD>На C# есть винформс который полносью перекрыват возможности их как библиотек ГУИ. Если ты об оболчке, то в Лонгхорне большая ее часть писана на том же шарпе. Ну, и к шарпу есть GTK .

Ба, да мы, вероятно, об KDE и понятия не имеем? Может выберешь время, зайдешь на http://www.kde.org как нибудь?

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

E>Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.

Не беспокойся — не станет. Я тут прочел твою ссылку на очередное откровение Страуструпа и понял, что основные вещи он уеж решил (ну, классы есть же?) а мелочи вроде делегатов или процедурных типов он делать не желает. Это мелкие частности. Ну, что поделать если человек настолко образован, что ему плевать на целую парадигму функционального программирования? В общем, орлам вроде Степанова и дальше прийдется извращаться, чтобы написать примитивную фичу вроде boost::bind. Причем компилироваться это будет часами. В общем, маразм крепчал...

E>Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.

А ты рафактри сам. Нечего сваливать на молодежь.

E>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?

Именно по этому я тебе и говорил, что тебе прийдется потратить год, чтобы изучить дотнет в той мере, чтобы не удивляться таким примитивным вещам.

Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон.

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

E>В частности, создавать в generic-ах объекты заданных в параметре шаблона типов с передачей аргументов в конструкторе

Когда все вокруг объект и ты о всем можешь прочепсть описание, невозможного просто нет.

E>Правда? Столько жутких слов для обработки какого-то конфигурационного файла.

Это унивесальные заклинания.

E>Да уж. Зачем же тогда различные DSL придумывают?


Не боись. Их все чаще на ХМЛ лабают.

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

А ты точно уверен, что не путаешь синтаксис с семантикой?

E>Я думаю, что тогда его еще не было (2001 год).


Вроде был.

E>И где ты в моем коде увидел вручную написанный парсер? Ткни носом, плз. А то ведь библиотека cls_2, которая парсингом занимается, для программиста выглядит такой же готовой штукой, как Xerces или libxml2.

Ну, не знаю. Выглядит это жутко. Бизон был бы куда проще.

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

Дык зак этим морем кода заметить было что либо не просто.

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

Ну, я как-то парсер C# создал который такой финей страдет постоянно. Прадва не на яке, ана КокоР, но это не так важно.

E>Ба, да мы, вероятно, об KDE и понятия не имеем? Может выберешь время, зайдешь на http://www.kde.org как нибудь?

И что виликого мы там узреем?

VladD2 wrote:

> C>Не забудь еще конструторы.
> Не забыл. Они не нужны.

Тогда бы хоть property поставил. Как ты эти поля читать/писать
собираешься, если они приватные.

В С++ном варианте конструкторы, кстати, тоже можно убрать — для
сериализации они не важны.

> C>Между этими примерами вся разница в методе serialize, на самом деле.
> При
> C>наличии compile-time reflection он делается автоматом.
> Ага. Все разнца в том, что нужно писать код. Причем чем сложнее
> случай, тем больше будет кода. В дотнете же в 99% случаев код писать
> попросту не прийдется.

У себя я сделал такой костыль для этого:

struct restriction_compareprops
{
    mapitag_t left,right;
    boost::value_initialized<relation_op> operation;

    #define restriction_compareprops_MEMBERS 
BOOST_PP_TUPLE_TO_LIST(3,(left,right,operation))
};
ORDERED_OBJECT(restriction_compareprops);
SERIALIZABLE_OBJECT(restriction_compareprops);

struct restriction_bitmask
{
    mapitag_t tag;
    boost::value_initialized<logic_op> operation;
    Placeholder<unsigned int> mask;

    #define restriction_bitmask_MEMBERS 
BOOST_PP_TUPLE_TO_LIST(3,(tag,operation,mask))
};
ORDERED_OBJECT(restriction_bitmask);
SERIALIZABLE_OBJECT(restriction_bitmask);

Макрос ORDERED_OBJECT развертывается в реализацию лексиографического
оператора сравнения (попробуй то же самое сделать в С#) и прочие
производные операторы (>,==, !=, <=, >=), а SERIALIZABLE_OBJECT — в
сериализатор.

Если бы можно было перечислить члены класса, то даже этого бы не
понадобилось.

> C>Будет
> Хрен или дедушка?

И то, и другое Вот сейчас с GCCXML играюсь, возможно получится
сделать что-то типа атрибутов для С++.

> Ну, да когда будет тогда и поговорим. Пока что новый стандарт ожидаетя
> не ранее 2008 года, до тех пор еще много воды утечет.

Как раз к выходу Longhorn, где будет Net 2.0 и всеобщее счастье...

> C>Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило
> C>абсолютно.
> Самом собой. Найди лучше.

Сейчас NNTP пользуюсь, оно лучше.

> C>Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и
> C>читаю про использование custom-форм в нем, так что в будущем (в конце
> C>лета во время отпуска) возможно будет Janus for Outlook
> Опоздал. У нас уже 100 лет как есть NNTP. Просто подпишись на него
> любой читалкой новостей и мучаться не прийдется.

Он кривоват, нет некоторых важных фич Януса.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AVK>>В каких?

E>Когда решение на разные платформы нужно перетаскивать и вместе с исходниками заказчику передавать.

С парсером XML на разных платформах вроде как проблем нет. Да и несильно сложно написать свой вариант парсера. Наконец есть готовые, к примеру TinyXML — бесплатный, маленький, переносимый.

E>Да, но если речь идет об C++, то такие парсеры не чуть не лучше собственных поделок.

Лучше, поскольку как минимум уже есть и имеют историю использования не в одном проекте.

E>Кроме того, если речь идет именно о конфигах, а не об интероперабельности на уровне документов, то XML здесь, имхо, не стандарт. Особенно на Unix-ах.

XML это стандарт вне зависимости от его применения.