Здравствуйте, hattab, Вы писали:
H>Слушай, ты по фотографии не лечишь? А то появляются у меня смутные подозрения... Ты понимаешь как отличается алгоритм при работе с DOM и SAX? Кардинально.
Алгоритм, пардон, чего?
Я призываю всего лишь отделить конкретный маппинг от алгоритма маппинга. Ничего военного в этом нету.

H>Общности там вообще ни какой нет. Если в случае с DOM я могу делать маппинг с готовой модели, то используя SAX я вынужден маппинг и валидацию делать по ходу пьессы (кстати, речь идет о парсинге).
Ничего не понимаю. Модель у тебя в любом случае готова до начала десериализации — она статически размечена атрибутами на сериализуемых типах.
Единственное "радикальное отличие" — в том, чтобы делать один проход по потоку, а не два (один для валидации, другой для маппинга).
Нормально написанный код переделать с DOM-парсера на SAX-парсер — пара пустяков. По сравнению, естественно, с переделкой всего клиентского кода, который выполняет реальные вызовы реального ендпоинта.

Покажи мне фрагмент того кода, который вам запредельно сложно переводить в SAX-based. Может, я чего-то кардинально не понимаю?

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

G>А с чего ты взял что DOM гораздо удобнее для этой задачи?

С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.

G>Традиционно входящими данными для парсера явяляется поток лексем. В вашем случае интерфейс, представляющий XML как поток лексем — StAX.

Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг. К слову сказать, в XML-RPC.NET все сделано на основе DOM, так там алгоритм кристально чист и линеен. В случае с SAX, необходим конечный автомат со стеком (гемороя больше в разы, если не на порядок. но и профита море).

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

H>>Ты понимаешь как отличается алгоритм при работе с DOM и SAX? Кардинально.
S>Алгоритм, пардон, чего?
S>Я призываю всего лишь отделить конкретный маппинг от алгоритма маппинга. Ничего военного в этом нету.

Алгоритм валидации модели пакета XML-RPC + ее маппинг на языковые типы.

H>>Общности там вообще ни какой нет. Если в случае с DOM я могу делать маппинг с готовой модели, то используя SAX я вынужден маппинг и валидацию делать по ходу пьессы (кстати, речь идет о парсинге).
S>Ничего не понимаю. Модель у тебя в любом случае готова до начала десериализации — она статически размечена атрибутами на сериализуемых типах.

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

S>Единственное "радикальное отличие" — в том, чтобы делать один проход по потоку, а не два (один для валидации, другой для маппинга).

Различие в том, что в имея DOM ты можешь свалидировать и смапить все за раз, а в случае SAX ты будешь по кусочкам выполнять эти действия.

S>Нормально написанный код переделать с DOM-парсера на SAX-парсер — пара пустяков. По сравнению, естественно, с переделкой всего клиентского кода, который выполняет реальные вызовы реального ендпоинта.

Клиентский код мы не трогаем, его переделывать в случае смены DOM<->SAX вообще не придется.

S>Покажи мне фрагмент того кода, который вам запредельно сложно переводить в SAX-based. Может, я чего-то кардинально не понимаю?

У меня нет кода работающего с DOM, т.к. у меня решение на SAX (просто я знаю, как бы мне было легче все сделать используя DOM). Но на http://www.xml-rpc.net.com/ есть код работающий с DOM.

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

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

G>>А с чего ты взял что DOM гораздо удобнее для этой задачи?

H>С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.
Весь прикол в том что для этой задачи DOM и SAX одинаково хреново подходят.

G>>Традиционно входящими данными для парсера явяляется поток лексем. В вашем случае интерфейс, представляющий XML как поток лексем — StAX.

H>Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг. К слову сказать, в XML-RPC.NET все сделано на основе DOM, так там алгоритм кристально чист и линеен.

Там используется DOM, хотя вполне хватило бы того самого StAX (XMLReader) ибо вся сериализация-десериализация выполняется потоково.

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

G>>>А с чего ты взял что DOM гораздо удобнее для этой задачи?

H>>С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.
G>Весь прикол в том что для этой задачи DOM и SAX одинаково хреново подходят.

Реши ее по другому, и покажи тут свое решение. Тода и поговорим

G>>>Традиционно входящими данными для парсера явяляется поток лексем. В вашем случае интерфейс, представляющий XML как поток лексем — StAX.

H>>Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг. К слову сказать, в XML-RPC.NET все сделано на основе DOM, так там алгоритм кристально чист и линеен.
G>
G>Там используется DOM, хотя вполне хватило бы того самого StAX (XMLReader) ибо вся сериализация-десериализация выполняется потоково.

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

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

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

G>>>>А с чего ты взял что DOM гораздо удобнее для этой задачи?

H>>>С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.
G>>Весь прикол в том что для этой задачи DOM и SAX одинаково хреново подходят.
H>Реши ее по другому, и покажи тут свое решение. Тода и поговорим
Я уже подумал об этом.

G>>>>Традиционно входящими данными для парсера явяляется поток лексем. В вашем случае интерфейс, представляющий XML как поток лексем — StAX.
H>>>Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг. К слову сказать, в XML-RPC.NET все сделано на основе DOM, так там алгоритм кристально чист и линеен.
G>>
G>>Там используется DOM, хотя вполне хватило бы того самого StAX (XMLReader) ибо вся сериализация-десериализация выполняется потоково.
H>Ты рассуждаешь о задаче, которую, видимо, даже не представляешь.
О да, я ни разу не парсил XML и не строил по нему какие-то объекты...

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

S>Вы перемешали логику реализации с логикой задачи. Конечно вы в итоге огребли. Это стопроцентная гарантия.

Она частенько перемешивается.

S>А вот если бы у вас маппинг был описан декларативно (см. XmlRootAttribute, XmlElementAttribute, XmlAttributeAttribute и т.п.), то вы бы легко заменили DOM-based serializer на SAX-based serializer.

Давай будем честными сами с собой. Реализовать оторванный от API парсинг ХМЛ-я очень не просто.

Как, например, описать такое отображение (маппинг) на Шарпе и потом связать его с реализациями на основе DOM и MxlReader?

Не получится ли код интерпретации отображения больше основной задачи (в несколько раз)?
Ведь очень легко сказать, что для решения задачи Х "просто" нужно создать подходящий фрэймворк или библиотеку, а потом "просто" использовать его. Но создание таких фрэймворков само по себе не простая задача. Особенно когда язык для этого не предоставляет должных средств.

S>Аналогичные примеры приводят всякие умники про "изначальный выбор алгоритма сортировки" и прочую ботву. Их проблемы — ровно аналогичны.

Не. Разные алгоритмы могут сортировки могут иметь общий интерфейс. А вот разные АПИ — нет.

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

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

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

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

H>С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.

Не зарекайся. А то когда решить эту задачу с помощью ФВП и рекурсии, то окажется, что это удобнее чем САКсы, шамксы и другие дурДОМы.

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

H>Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг.

А зачем ты вообще это вручную делал? Создал бы по метаинформации подходящий XSD и выполнил бы проверк соответствия схеме твоих данных.

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

H>>С того, что я решил эту задачу используя SAX, и могу со знанием дела утверждать, что удобнее, а что нет в данном случае.

VD>Не зарекайся. А то когда решить эту задачу с помощью ФВП и рекурсии, то окажется, что это удобнее чем САКсы, шамксы и другие дурДОМы.

Ну, я же относительно DOM и SAX

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

H>>Это не просто парсинг XML, это еще и валидация модели XML-RPC + маппинг.

VD>А зачем ты вообще это вручную делал? Создал бы по метаинформации подходящий XSD и выполнил бы проверк соответствия схеме твоих данных.

Во-первых перформанс. Во-вторых у XML-RPC пакетов есть нюансы, которые схемой не описываются. Ну и в третьих, у меня есть некоторые особенности при работе с большим контентом в base64.

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

VD>>А зачем ты вообще это вручную делал? Создал бы по метаинформации подходящий XSD и выполнил бы проверк соответствия схеме твоих данных.

H>Во-первых перформанс.

А ты измерял разницу? Проверка схем вроде как была очень эффективно реализована. Или я ошибаюсь?

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

VD>>>А зачем ты вообще это вручную делал? Создал бы по метаинформации подходящий XSD и выполнил бы проверк соответствия схеме твоих данных.

H>>Во-первых перформанс.

VD>А ты измерял разницу? Проверка схем вроде как была очень эффективно реализована. Или я ошибаюсь?

Честно говоря нет. Но тут какое дело, схема мне только проверит валидность модели XML-RPC (хотя по приводимой ссылке сказано, что она этого не может, ну допустим), причем весь пакет у меня должен быть в памяти или доступен для второго прохода (собственно моего маппинга). При ручной валидации + маппинге я имею стек правил и модификаторов допустимости некоторых ситуаций, что позволяет эти операции проводить очень быстро (фактически несколько простых проверок). В общем, такой подход позволил мне получить перформанс парсинга "динамики" (пакетов заранее не известных) на уровне gSOAP с его статическим парсингом.

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

_>А самой CRT уже лет 40.

Это copy/paste из DUNUL.PRIDUMAL ?

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

O>А как вы напишете на C# что нить под мак?

Возьмет mono и запустит.

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

O>Ой насмешили Нету такого — Qt Software. Есть лишь библиотека Qt, написанная Trolltech.

И владеет ею теперь мобила всея матрицы — Nokia.

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

H>Алгоритм валидации модели пакета XML-RPC + ее маппинг на языковые типы.
Ок, я кажется понял. Я-то думал, у вас есть некая "система", и парсинг XML-RPC лишь некоторая ее часть.
А ты имеешь в виду именно разработку библиотеки парсинга XML-RPC. Про эту задачу я так сходу не могу сказать, какую часть кода можно сделать независимой от выбора SAX/DOM.
При написании "влоб", конечно же, придется выкинуть 100% кода. Ладно, будет время — выкачаю либу, на которую ты ссылался, и посмотрю, как там что устроено.

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

E>>Документ состоит из абзацев. Абзац из "символов". Пока он состоит только из символов, всё просто. Когда в качестве "символа" может быть таблица, рисунок, формула, спецсимвол, объект OLE, что угодно, то сразу напрашивается сделать этот символ классом, а все вышеуказанные объекты сделать наследником этого класса, чтобы с ними можно было единообразно работать. Как уже было сказано тут возникают проблемы с накладными расходами, если представлять каждый символ в виде объекта. В качестве решения предлагается паттерн flyweight, в котором для одинаковых символов используется один и тот же объект. Но у разных одних и тех же символов могут быть разные атрибуты форматирования (шрифт, цвет). В предлагаемом паттерне эти атрибуты хранятся отдельно, и передаются при рисовании в качестве параметров методов. Но эти параметры нужны в основном только символам, таблицам и картинкам они уже не нужны! В результате получается, что такому объекту как картинка при рисовании требуется зачем-то передать шрифт и цвет, которые никак не используются. Разве Вам уже не кажется, что дизайн так себе? Лично мне уже кажется.
G>И мне кажется.
G>Нафиг не нужны символы текста как отдельные объекты. Строк достаточно.
G>В таком случае сразу отпадает необходимость использовать flyweight.

Строк не достаточно. Как быть с таблицами и картинками? С ними хочется обращаться как с символами.

E>>Лет 10 назад возможно это и не было бы приемлимо, но сейчас дополнительные 4 байта на символ мне не кажутся слишком большими расходами, если уж даже flyweight предполагает 4 байта на него. Т. е. с издержками на память можно как-то согласиться. Но ешё есть издержки на выделение/освобождение объекта для каждого символа, с которыми, по моему мнению (да и по Вашему как я понял) могут быть большие проблемы.
G>Ну даже если вынести символы отдельно и использовать flyweight, то это никак не решит проблемы создания кучи мелких объектов для аттрибутов символа.

Вот для форматирования разных символов можно как раз использовать один и тот же объект "аттрибут". И можно попробовать хранить этот атрибут не для каждого символа, а для интервалов. Но тогда придётся это форматирование передавать каждому символу при рисовании, и картинкам/таблицам тоже.

E>>>>Имелось в виду, что здесь очередной плевок в сторону С++ и unmanaged-языков был абсолютно не уместен, потому что здесь либо для обоих вариантов ответ да, либо для обоих нет.
G>>>Это надо еще доказать. Ваш пример с визивигом доказательство не является, потому что он явно надуманный и нифига не обощается. Далеко не во всех программах есть очень много одинаковых объектов.
E>>
E>>Причём здесь пример с WYSIWYG? Причём здесь то, что "Далеко не во всех программах есть очень много одинаковых объектов"?
E>>Что доказать? Что выделение/освобождение памяти является и там и там операцией довольно тяжеловесной примерно одного порядка?
G>Это не так.

E>>Вы издеваетесь что ли?
G>Нет

E>>Вы правда думаете, что выделение объекта в .net настолько быстрое, что на него можно не обращать внимание,
G>Да, сдвиг указателя и все.

E>>а в С++ оно настолько медленнее, что там уже надо обращать внимание?
G>С++ медленнее, но обращать внимание все равно не надо.

G>В C++ надо обращать внимание на сам факт освобождения или использовать что-то типа auto_ptr или shared_ptr, которые создают свой оверхед.

E>>Вы правда считаете, что при одинаковой объектной декомпозиции в C# и C++ затраты на работу с памятью в C# будут на порядок меньше?
G>Она одинаковой не будет.

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

Ну а как же тогда пример с WYSIWYG? Вы считаете, что архитектура с паттерном flyweight ничуть не хуже, чем использование отдельных объектов для символов?

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

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

E>>А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?
S>Меня всегда умиляла способность читать книгу и ничерта не понимать.

Меня всегда умиляла способность людей умиляться своим способностям.

S>Ты не заметил, что паттерн позволяет заменить часть программы так, чтобы уменьшить накладные расходы до приемлемых?
S>При этом основным алгоритмам наплевать, один и тот же там объект или разные.
Если бы Вы хотя бы потрудились прочитать пример кода из указанной книги, то Вам бы стало понятно, что алгоритмам не наплевать. В случае с flyweight им необходимо знать текущее форматирование, которое применяется к рисуемому объекту. Последствия этого Вы понять можете, или тоже нет?

S>Это как раз пример того, что мы
S>а) сначала пишем систему так, как нам удобно — все алгоритмы (например, разбиения на строки и страницы) пишутся очевидным и красивым образом
S>б) при помощи профайлера выясняем источник проблемы
S>в) заменяем нехорошую часть алгоритма.
S>Например, для текстового редактора мы бы всего лишь изменили маленький фрагмент кода, тот, где фабрика Char-ов. Возможно, закомментировали бы метод Char.Equals (чтобы использовать дефолтный ReferenceEquals, который быстрее). И всё! Где тут "заранее проектировать с учетом быстродействия"?

Конечно, конечно, всё так просто. А про добавление дополнительного параметра в метод рисования символа вы не забыли? И в методы рисования картинок тоже не забыли? А теперь скажите мне, если у вас этот же класс картинки помимо непосредственно окна редактирования используется в каком-либо сложном элементе UI, то откуда вы там возьмёте "текущее форматирование", которое нужно предать при рисовании картинки? И с какого перепуга компонент UI, который отображает картинку, должен знать о каком-то форматировании?

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

e>> Документ состоит из абзацев. Абзац из "символов".

M>все дальше поскипано. в тх ж GoF, если мне не изеняет память, описано как надо делать для сложного форатирования и т.п.
Там написано не как надо делать, а как можно делать, чтобы избежать больших изжержек.

M>Никому не нужно иметь на каждый символ по классу/экземпляру класса.
Кому не нужно? Вам не нужно. Ну пожалуйста, я не против. А вот те же авторы GoF пишут, что хотелось бы работать с символами как с объектами, но просто так это сделать не позволяют накладные расходы, поэтому они предлагают использовать flyweight в качестве альтернативы. Цитата, которую я привёл, как раз оттуда.