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

E>Я не делаю ни того, ни другого -- я делаю то, что мне интересно.

То есть проект — для души? Сам таким болел. Закончится тем, что всё перепишешь ещё лучше, чем советовали

E>Повторю еще раз, я считаю, что сериализация -- это серьезный вопрос.

ОК, только лично меня твой подход не избавляет от этой серьёзности, а подавляет ею.

A>>В этом проявляется гибкость. Автоматически нагенерированная сериализация и не должна быть оптимальной по всем параметрам. Она должна удовлетворять всего одному требованию — безглючность.
A>>Если что-то сильно не устраивает отключаем автомат и пишем руками.

E>Если вы возьмете стандартную ASN1 PER сериализацию и нормальный инструмент, который ее полностью поддерживает, то вы увидите, что есть автоматическая сериализация, которая эффективна, как минимум: по объему результирующего образа и по скорости сериализации/десериализации. Но даже ASN1 PER можно сделать еще эффективнее, если сериализовать "правильные" для сериализации типы, а не те типы, которыми удобно оперировать в программе.

ОК, вот ещё одна умопомрачительная задача: сделать множества "правильных" для сериализации типов и типов удобных для использования в программе идентичными.

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

Поэтому я и ввёл методы scope_begin/scope_end.

E>Это не проблемы потока, это проблемы приложения. Что должно делать приложение, если ему говорят, что поток сейчас заблокирован другим приложением? Повторять попытку сразу? После тайм-аута? Сколько попыток делать? Или вообще не делать? Или сам поток не вернет управление пока не разблокируется? А если есть deadlock-и?

Поток кинет исключение с кодом ошибки. Программа сама решит что делать: повторить попытку или выдать сообщение об ошибке. Более того политика обработки ошибок вполне может задаваться потоку каким-нибуд set_flags(int) до использованияи тогда можно будет указать правило типа "попытайсятри раза ожидая не более 3 секунд а потом киньб исключение". Вобщем технических проблем с обработкой ошибок нет.

A>>Опять таки вот она гибкость. Не нравиться автоматически сгенерированный код — пиши свой. Просто случаев когда надо писать свой, по сравнению со случаями когда надо написать по принципу "лишь бы работало" достаточно мало. Поэтому автоматическая генерация кода сериализации с возможностью вкраплений сериализации написаной ручками это ИМХО весьма перспективное направление.

E>Принцип "лишь бы работало" приводит к тому, что неудачные решения уходят в эксплуатацию, а потом их невозможно заменить на удачные из-за соображений обратной совместимости.

Есть такое дело. Но сразу хорошая вешь не появляеться. Любой проект проходит некоторую эволюцию начиная с весьма посредственных результатов.

E>adontz, а есть еще притензии к ObjESSty, кроме:
E>- наличия специального базового типа, от которого все должны наследоваться;
+
E>- поддержки ограниченного количества типов;
+
E>- использования собственного средства компиляции проектов;
дело не в том собственное оно или нет. Если вместе с проектом будут идти vbs и pl файл то всё ок. А так качать много чего надо.
E>- отсутствия поддержки XML
Я бы сказал шире — плохая расширяемость. Насколько легко подключить новое хранилище или формат хранения данных?