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

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

E>>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.

IT>Для плюсов и всего остального есть msxml.dll.

Под Lunix-ом, *BSD и Solaris-ом

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

E>>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.

IT>Для плюсов и всего остального есть msxml.dll.

На Mac OS X не работает.

Здравствуйте, Павел Кузнецов, Вы писали:

IT>>Для плюсов и всего остального есть msxml.dll.

ПК>На Mac OS X не работает.

Значит там должно быть что-то другое.

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

IT>>Для плюсов и всего остального есть msxml.dll.

E>Под Lunix-ом, *BSD и Solaris-ом

Ты подо всё под это пишешь софт?

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

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

IT>>>Для плюсов и всего остального есть msxml.dll.

E>>Под Lunix-ом, *BSD и Solaris-ом

IT>Ты подо всё под это пишешь софт?

Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).

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

IT>>Ты подо всё под это пишешь софт?

E>Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).

И как ты обеспечиваешь совместимость для UI, DB, системных вызовов?

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

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

IT>>>Ты подо всё под это пишешь софт?

E>>Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).

IT>И как ты обеспечиваешь совместимость для UI, DB, системных вызовов?

К счастью, UI в наших решения особенно и не требуется, это в основном, server-side системы. Но для работы с GUI на C++ мы используем Qt.
Для работы с DB применяем otl. Некоторые из наших систем вообще не нуждаются в БД.
Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.

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

E>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.

О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров не будет на много сложнее.

Hello, IT!
You wrote on Fri, 24 Jun 2005 15:20:01 GMT:

E>> Для системных вызовов (сокеты, мультипоточность, работа с dll) пока
E>> используем свои обертки, которые унаследовали еще из OS/2. Но сейчас,
E>> потихоньку, переползаем под
E>> ACE.

I> О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров
I> не будет на много сложнее.

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

With best regards, Sergey.

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

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

E>>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.

IT>О! Это как раз оно

А о чем это ты?

IT>Думаю, что сделать свою обёртку для XML парсеров не будет на много сложнее.

Может быть, а есть ли смысл?
Исходя из моего скромного опыта работы с libxml2 и xerces получается, что нет единого C++ API для работы с XML парсерами. В таких условиях обертка должна не только содержать какие-то прикладные возможности (скажем преобразования unsigned int из строкового представления в двоичное), но и иметь адаптацию к конкретной XML-подложке (libxml2, xerces, expat, tinyxml, gsoap, ...). Довольно нехилый кусок работы. А если такой прозрачной адаптацией не заниматься, то зачем вообще подобная обертка нужна?

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

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

Расскажи это нашим почётным велосипедистам

Здравствуйте, Павел Кузнецов, Вы писали:


Да уж, сравнил слона и козу. Интерфейс с реализацией, притом реализация с комментариями.
И вообще, если не нравится код, то его следует рефакторить. А вот если не нравится функциональность, то можно и переписать. И причина Влада переписать редактор (как он утверждал сначала за 2 дня ) отнюдь не лежит в этой плоскости.
И вообще, можно прочитать пару книжек а ля Гамма или Фаулер и писать на каждом столбе что классы обязаны быть маленькими. А можно творить и попадаться на том, что не всегда это верно.
Если нам не нравятся большие интерфейсы предлагаю переписать gdi32.dll, user32.dll и kernel32.dll. Кто за?

С уважением, Gleb.

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

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

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

IT>Расскажи это нашим почётным велосипедистам

А что, уже такие звания раздают? Хочу!

AndrewVK,

> Если ты про <if>, то такие конструкции есть и в чисто функциональных языках.

Что является подтверждением наличия в большинстве "чисто" функциональных языков императивных конструкций.

<foreach item="Folder" property="foldername">
     <in>
         <items>
             <include name="**" />
         </items>
     </in>
     <do>
         <echo message="${foldername}" />
     </do>
</foreach>

<project default="build">
     <property name="debug" value="false" />
     <target name="init" unless="${target::has-executed('init')}">
         <echo message="initializing" />
     </target>
     <target name="compile" depends="init">
         <echo message="compiling with debug = ${debug}" />
     </target>
     <target name="build">
         <property name="debug" value="false" />
         <call target="compile" />
         <property name="debug" value="true" />
         <call target="compile" />
     </target>
</project>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>AndrewVK,

>> Если ты про <if>, то такие конструкции есть и в чисто функциональных языках.

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

<...>

Я бы даже сказал, что здесь есть присутствие двойного языка: первый, XML, отвечает за внешнее описание. А второй, за конструкции вида:

<echo message="${foldername}" />
<target name="init" unless="${target::has-executed('init')}">
         <echo message="initializing" />
</target>

Т.е. кто-то, после извлечения атрибута message из тега echo должен проверить, что в нем содержится. И если там есть имя переменной, то нужно выполнить какое-то действие. Причем провека выполняется уже без использования возможностей XML.

IT,

> IT>> Для плюсов и всего остального есть msxml.dll.
>
> ПК> На Mac OS X не работает.
>
> Значит там должно быть что-то другое.

Есть, конечно. Куча библиотек, из которых остаются кросс-платформенные, т.к. есть еще и Windows. Теперь доходим до дела: никакой готовой интеграции, подобной сериализации C# в XML там обычно нет, нужно делать. Иначе получится "красота" в таком духе: http://rsdn.ru/forum/Message.aspx?mid=1237916

Автор:
Дата: 23.06.05

. Часто может оказаться, что собственно формат при оценке затрат на сериализацию уже играет малую роль, т.к. "обвязка", не зависящая от формата, "съедает" большую часть усилий, и представляет наибольшую сложность в реализации. В свете чего вопрос: зачем в этом случае мучиться с XML, если можно сделать более удобный формат, лучше подходящий для нужд конкретного проекта?..

IT wrote:

> E>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока
> используем свои обертки, которые унаследовали еще из OS/2. Но сейчас,
> потихоньку, переползаем под ACE
> <http://www.cs.wustl.edu/%7Eschmidt/ACE.html&gt;.
> О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров не
> будет на много сложнее.

А зачем? libxml есть везде — сам лично компилировал его для PocketPC

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

GlebZ,

> Да уж, сравнил слона и козу. Интерфейс с реализацией, притом реализация с комментариями. И вообще, если не нравится код, то его следует рефакторить.

Я сначала хотел выкинуть реализацию, оставив от методов и свойств только сигнатуры, но оставил ради того, чтоб более наглядно было, что именно делает та или иная функция. Особенно позабавило "Открываем диалог выбора фйла проекта" в классе с названием Compiler. В данном случае для меня было существенно качество проектирования на уровне классов, а не качество реализации.

> И вообще, можно прочитать пару книжек а ля Гамма или Фаулер и писать на каждом столбе что классы обязаны быть маленькими.

Здесь "прокол" не в объеме класса, а в неоднородности его обязанностей и в нарушении множества самых базовых принципов OOP: класс и диалоги открывает, и в "потроха" ассоциированных классов "лазит", и знания о формате файлов Visual Studio содержит, и т.п.

> А можно творить и попадаться на том, что не всегда это верно.

Правильно, по коду сразу виден подход: "что тут думать, тут прыгать надо".

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

C>А зачем? libxml есть везде — сам лично компилировал его для PocketPC

Среди вариантов предложенных eao197 такого варианта не было

Здравствуйте, Павел Кузнецов, Вы писали:

Сейчас взглянул на код повнимательней. Конечно в отсутсвие автора разбирать его как-то нехорошо, однако рискну (поскольку мое мнение его по-моему не обидет).
ПК>Я сначала хотел выкинуть реализацию, оставив от методов и свойств только сигнатуры, но оставил ради того, чтоб более наглядно было, что именно делает та или иная функция. Особенно позабавило "Открываем диалог выбора фйла проекта" в классе с названием Compiler.
Меня позабавило название метода MakePathLoverCase. Я не эксперт в английском за пределами технических текстов, но что-то в названии этого методе есть.


ПК>Здесь "прокол" не в объеме класса, а в неоднородности его обязанностей и в нарушении множества самых базовых принципов OOP:
По порядку.
ПК>класс и диалоги открывает,
Ты в MFC для вызова COpenSaveDialog делаешь свой класс? Открытие файлов это уже самодостаточные классы. Или ты кроешь людей которые придумали DOMDocument с его методом Load?
ПК>и в "потроха" ассоциированных классов "лазит",
Че-то не нашел где? Намекни?
ПК>и знания о формате файлов Visual Studio содержит, и т.п.
Может быть действительно два метода типа ReadVs80Format и ReadVs71Format следует выделить в классы. Но что-то сильно криминального в этом я не вижу. Когда следует ожидать 3 формат? И стоит это того?

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

С уважением, Gleb.