В течении последних двух лет я занимался собственным проектом для сериализации и долговременного хранения сложных C++ объектов: Object Entity Serialization & Stability (ObjESSty). Наконец сейчас он достиг уровня, при котором его не стыдно показать общественности. Что я и делаю при помощи этого сообщения.
Страничка проекта: http://eao197.narod.ru/objessty
Страничка, как и последняя версия проекта находится в состоянии работоспособной beta-версии. Могут наблюдаться различные кривости/ошибки/описки/опечатки, но при наличии интереса и предложений все может быть доведено до ума.
Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
С наилучшими пожеланиями
Евгений Охотников.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
Основная идея в ObjESSty -- это необходимость описания схемы данных на специальном языке и объявление сериализуемых типов производными от специального класса oess_1::stdsn::serializable_t
Вот после этого я уже даже скачивать не стал. Эсть такое понятие как гибкость (flexibility). Данная система уже при прочтении первых строк документации показывает себя не как гибкая (если класс (например std::vector) не производен от oess_1::stdsn::serializable_t то может быть сериализован).
Вообще идея производности от класса очень очень плохая.
Читаем далее
ObjESSty реализован на языке C++ и предназначен для использования в C++ приложениях. Поэтому в ObjESSty встроена поддержка атрибутов-указателей и атрибутов-контейнеров STL.
О! std::vector таки может быть сериализован, зато все другие классы (не std, например boost::shared_ptr) идут лесом
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
ObjESSty разрабатывается с расчетом на максимальную переносимость. Для достижения этого используется библиотека ACE и кросс-платформенный инструмент для компиляции C++ проектов mxx_ru.
Про mxx_ru уже сказали. Так еще и ACE нужно тянуть за собой. То еще сокровище, в нем, если я ничего не путаю, свои контейнеры, не STL-евские.
ACE вроде для писания всяких распределенных систем главным образом предназначена. Зачем тут-то она нужна?
Ощущения некой монстроузности
Re[2]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, adontz, Вы писали:
E>>Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
A>
A>Основная идея в ObjESSty -- это необходимость описания схемы данных на специальном языке и объявление сериализуемых типов производными от специального класса oess_1::stdsn::serializable_t
A>Вот после этого я уже даже скачивать не стал. Эсть такое понятие как гибкость (flexibility). Данная система уже при прочтении первых строк документации показывает себя не как гибкая (если класс (например std::vector) не производен от oess_1::stdsn::serializable_t то может быть сериализован).
ObjESSty ведет свою историю не от средств сериализации, а от объектно-ориентированных баз данных. А там подход, когда схема данных имеет одно описание на специальном языке, а представление в языке программирование имеет другое (аналогичное, но другое) описание -- в порядке вещей. Причин тому может быть масса. Например:
— описание на DDL (Data Definition Language) позволяет осуществлять эволюцию схемы данных с автоматическим преобразованием уже сохраненных в БД данных;
— описание на DDL позволяет строить отображение данных в несколько языков программирования. Аналогичный пример -- Corba IDL, из которого можно получить код хоть для C++, хотя для Java;
— описание на DDL позволяет строить инструменты, которые делают "читабельный" дамп сохраненных данных без необходимости ручного программирования. Более того, они позволяют строить инструменты, которые изменяют данные в БД без программирования на C++;
— схема данных в БД и в приложении может различаться. Например, в приложении может использоваться более старая схема данных, чем в БД и БД по DDL описанию умеет обрабатывать это на лету;
— сериализации и сохранению могут подвергаться не все атрибуты объекта, а только часть из них.
A>Вообще идея производности от класса очень очень плохая.
На вкус и цвет...
В объектных базах данных обычной практикой является произведение persistent классов от специального базового класса. В этом есть как идеологический момент (ведь это нормально, когда сериализуемый объект удовлетворяет какому-то интерфейсу, т.е. наследуется от общего предка), так и чисто практический. В базовом классе сосредотачивается функциональность, которая нужна всем производным сериализуемым классам, но которая не должна дублироваться в производных классах. Поэтому я вполне сознательно пошел на то, чтобы в ObjESSty был общий корень иерархии сериализуемых типов.
Вот, например, какую функциональность реализует oess_1::stdsn::serializable_t: Опциональные поля, Расширяемые типы, subclassing by extension.
Для поддержки этих возможностей все равно в сериализуемый класс пришлось бы добавлять какие-то данные (пусть и спрятанные за хитрым макросом). Но в общем базовом классе эти поля уже есть и они не требуют для себя места в производных классах. А если их добавлять в каждый производный класс, то при нескольких уровнях наследования это начнет выливаться в накладные расходы.
Кроме того, oess_1::stdsn::serializable_t не обязательно должен быть единственным базовым. Он вполне может быть примесью.
A>Читаем далее A>
A>ObjESSty реализован на языке C++ и предназначен для использования в C++ приложениях. Поэтому в ObjESSty встроена поддержка атрибутов-указателей и атрибутов-контейнеров STL.
A>О! std::vector таки может быть сериализован, зато все другие классы (не std, например boost::shared_ptr) идут лесом
Не знаю, куда должны идти все остальные типы, но в сериализацию должны идти типы, которые явно для этого расчитаны (имхо). Особенно если объекты этих типов содержат указатели. Ведь C++ не smalltalk, где можно часть памяти виртуальной машины сохранить, а затем восстановить.
Здесь так же есть аналогия с Corba IDL -- ведь в Corba не любой объект может быть использован для Corba-взаимодействия, а только тот, который описан на IDL.
Практика показала, что в сложных программах существуют сотни, если не тысячи C++ типов, но сериализуется только малая часть из них. Поэтому даже накладные расходы на описание этих типов в DDL можно считать несущественными.
A>
A>Я не буду скачивать ни mmx_ru ни ruby чтоб поглядеть на библиотеку которая мне уже не нравиться. Неужели нельзя было сделать vcproj/make файл?
Кросс-платформенный инструмент для компиляции C++ проектов -- это вообще больной вопрос. Кроме mxx_ru я знаком только с двумя такими инструментами: Boost.Jam и SCons. Но первый, по своему удобству использования, не сильно далеко ушел от обычного make (кто не верит, пусть попробует адаптировать Boost.Jam под какой-нибудь новый компилятор). SCons более удобен для меня, но он требует Python, который не меньше Ruby. К тому же мне проще программировать на Ruby, чем на Python.
А vcproj и makefile я не делаю из-за того, что сейчас в ObjESSty 39 проектных файлов. С помощью mxx_ru это поддается управлению. Но во что выльется адаптация проектных файлов хотя бы для трех компиляторов на трех платформах? А сопровождать это как? Ведь многоплатформенность ObjESSty -- это одно из самых главных требований.
Кроме того, если вам таки не нравится весь инструмент, то зачем хаить его систему компиляции? Вы ведь все равно использовать его не будете
Наличие же в Boost-е собственной системы компиляции никого не смущает?
A>По идее вообще не должно компилироваться.
Так и не компилиться
Вот, что было:
class app_data_t :
public oess_1::stdsn::serializable_t
{
OESS_SERIALIZER( app_data_t )
Исправляем:
class app_data_t :
public oess_1::stdsn::serializable_t
{
OESS_SERIALIZER( my_app_data_t )
Получаем:
sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(6) : error C2511: 'void app_data_t::oess_serializer_t::unpack_self(oess_1::stdsn::ient_t &,app_data_t &,oess_1::stdsn::isubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(17) : error C2511: 'void app_data_t::oess_serializer_t::unpack(oess_1::stdsn::ient_t &,app_data_t &,oess_1::stdsn::isubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(29) : error C2511: 'void app_data_t::oess_serializer_t::unpack_complete(oess_1::stdsn::ient_t &,app_data_t &)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(37) : error C2511: 'void app_data_t::oess_serializer_t::pack_self(oess_1::stdsn::oent_t &,const app_data_t &,oess_1::stdsn::osubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(48) : error C2511: 'void app_data_t::oess_serializer_t::pack(oess_1::stdsn::oent_t &,const app_data_t &,oess_1::stdsn::osubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(60) : error C2511: 'void app_data_t::oess_serializer_t::pack_complete(oess_1::stdsn::oent_t &,const app_data_t &)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(67) : error C2511: 'void *app_data_t::oess_serializer_t::cast(const std::string &,app_data_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(106) : error C2660: 'app_data_t::oess_serializer_t::unpack' : function does not take 3 arguments
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(107) : error C2660: 'app_data_t::oess_serializer_t::unpack_complete' : function does not take 2 arguments
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(114) : error C2660: 'app_data_t::oess_serializer_t::pack' : function does not take 3 arguments
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(115) : error C2664: 'app_data_t::oess_serializer_t::pack_complete' : cannot convert parameter 2 from 'const app_data_t' to 'const int'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(121) : error C2660: 'app_data_t::oess_serializer_t::cast' : function does not take 2 arguments
A>И отсутсвие поддержки XML окончательно поставило крест на всём проекте
Ну, на проекте это точно крест не поставит Максимум, на его распространении
Сейчас XML является мэйнстримом и есть куча попыток писать в него и читать из него. Зачем же еще одна попытка?
Моей задачей изначально было создание компактного двоичного представления и быстрых средств его формирования/разбора. Ведь есть же еще предметные области, в которых XML просто по определению не подходит из-за своих объемов/скорости. Вот там бы ObjESSty и мог найти свое применение.
A>Вот такие пироги
Спасибо за ваше мнение.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, alsemm, Вы писали:
A>Про mxx_ru уже сказали. Так еще и ACE нужно тянуть за собой. То еще сокровище, в нем, если я ничего не путаю, свои контейнеры, не STL-евские.
Хорошей стороной ACE является то, что из него можно брать только то, что тебе необходимо. Никого не заставляют использовать средства ACE, если они не нужны. ObjESSty, например, все берет из STL, а из ACE только платформенно-зависимые средства. Да и в скомпилированном виде ace.dll всего-то 900Kb в release-режиме.
A>ACE вроде для писания всяких распределенных систем главным образом предназначена. Зачем тут-то она нужна?
Изначально я взялся использовать ACE из-за того, что мне потребовались кросс-платформенные средства работы с файловой системой. Свои писать не хотелось, т.к. собственный опыт был и повторять его с учетом различных тонких несовпадений на разных платформах не хотелось. Выбирал между STLsoft, Boost и ACE. STLsoft отпал сразу. Нынешний Boost потяжелее ACE будет, а из реально системных средств в нем filesystem и многопоточность. А в ACE, кроме этого, еще и различные виды IPC. Поэтому остановился на ACE с учетом того, что со временем хотелось бы сделать в ObjESSty возможность работы в клиент-серверном режиме (как BerkeleyDB это делает для предоставления нескольким процессам работать с одной БД).
A>Ощущения некой монстроузности
Да, после подключения ACE так оно и стало. До ACE архив был где-то 200Kb, зато все самому приходилось переписывать на каждой из платформ.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: [ANN] ObjESSty - еще один проект сериализации
Я следил за этими ветками. Только ситуация немного иная: у меня есть проект, который я начал разрабатывать под свои нужды. И под свои нужды использовал, постепенно развивая его. Теперь этот проект достиг момента, когда им можно воспользоваться не только мне. О чем я и сказал.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, eao197, Вы писали:
E>ObjESSty ведет свою историю не от средств сериализации, а от объектно-ориентированных баз данных. А там подход, когда схема данных имеет одно описание на специальном языке, а представление в языке программирование имеет другое (аналогичное, но другое) описание -- в порядке вещей. Причин тому может быть масса.
А как тебе вот такой сценарий. Программист пишет программу и ему вдруг (а иначе и не бывает) понадобилась сериализация. Он будет скачивать монстра на пару мегабайт к которому прилагается 2 (ACE, mxx_ru) средства разрабтки и 2 (DDL, Ruby) языка или возьмёт удобную систему, которая работает после простого копирования и сама генерирует большую часть нужного уме кода?
A>>Вообще идея производности от класса очень очень плохая. E>На вкус и цвет...
Это вопрос расширяемости и гибкости.
E>В объектных базах данных обычной практикой является произведение persistent классов от специального базового класса. В этом есть как идеологический момент (ведь это нормально, когда сериализуемый объект удовлетворяет какому-то интерфейсу, т.е. наследуется от общего предка),
Это как раз НЕ нормально. Должен быть принцип plug-and-play. Никаких изменений в уже существующих класса. Я же не должен переписывать весь Boost только чтобы возспользоваться чудо-сериализацией.
E>так и чисто практический. В базовом классе сосредотачивается функциональность, которая нужна всем производным сериализуемым классам, но которая не должна дублироваться в производных классах.
По вышеуказанным причинам функциональность надо сосредотачивать в глобальных функциях, а не в методах классов.
E>Не знаю, куда должны идти все остальные типы, но в сериализацию должны идти типы, которые явно для этого расчитаны (имхо). Особенно если объекты этих типов содержат указатели. Ведь C++ не smalltalk, где можно часть памяти виртуальной машины сохранить, а затем восстановить.
Вот это-то и есть расширяемость, когда тип изначально не расчитывался на сериализацию, но сделать это всётаки можно.
E>Практика показала, что в сложных программах существуют сотни, если не тысячи C++ типов, но сериализуется только малая часть из них. Поэтому даже накладные расходы на описание этих типов в DDL можно считать несущественными.
Имеет проблемы с синхронизацией DDL и C++ определения.
E>Кросс-платформенный инструмент для компиляции C++ проектов -- это вообще больной вопрос. Кроме mxx_ru я знаком только с двумя такими инструментами: Boost.Jam и SCons. Но первый, по своему удобству использования, не сильно далеко ушел от обычного make (кто не верит, пусть попробует адаптировать Boost.Jam под какой-нибудь новый компилятор). SCons более удобен для меня, но он требует Python, который не меньше Ruby. К тому же мне проще программировать на Ruby, чем на Python.
Странный подход. Обычно делают так: пишут под одну платформу то что надо, а под другие портируют создавая новые файлы либо пользуясь препроцессором.
E>А vcproj и makefile я не делаю из-за того, что сейчас в ObjESSty 39 проектных файлов. С помощью mxx_ru это поддается управлению. Но во что выльется адаптация проектных файлов хотя бы для трех компиляторов на трех платформах? А сопровождать это как? Ведь многоплатформенность ObjESSty -- это одно из самых главных требований.
Делаешь для одной платформы. Если это кому-то нужно, то найдётся смельчак и портирует код под другую платформу.
E>Кроме того, если вам таки не нравится весь инструмент, то зачем храить его систему компиляции? Вы ведь все равно использовать его не будете
Я не видел ни одного человека, который бы пользовался MSVC++ из коммандной строки.
E>Наличие же в Boost-е собственной системы компиляции никого не смущает?
Бост пишет не один человек.
E>Получаем: E>
E>sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
E>sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
E>sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
E>sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
E>sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
E>sample\app_recovery\main.cpp(62) : error C2143: syntax error : missing ',' before '&'
E>sample\app_recovery\main.cpp(62) : error C2061: syntax error : identifier 'my_app_data_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(6) : error C2511: 'void app_data_t::oess_serializer_t::unpack_self(oess_1::stdsn::ient_t &,app_data_t &,oess_1::stdsn::isubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(17) : error C2511: 'void app_data_t::oess_serializer_t::unpack(oess_1::stdsn::ient_t &,app_data_t &,oess_1::stdsn::isubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(29) : error C2511: 'void app_data_t::oess_serializer_t::unpack_complete(oess_1::stdsn::ient_t &,app_data_t &)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(37) : error C2511: 'void app_data_t::oess_serializer_t::pack_self(oess_1::stdsn::oent_t &,const app_data_t &,oess_1::stdsn::osubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(48) : error C2511: 'void app_data_t::oess_serializer_t::pack(oess_1::stdsn::oent_t &,const app_data_t &,oess_1::stdsn::osubclass_extension_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(60) : error C2511: 'void app_data_t::oess_serializer_t::pack_complete(oess_1::stdsn::oent_t &,const app_data_t &)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(67) : error C2511: 'void *app_data_t::oess_serializer_t::cast(const std::string &,app_data_t *)' : overloaded member function not found in 'app_data_t::oess_serializer_t'
E> sample\app_recovery\main.cpp(62) : see declaration of 'app_data_t::oess_serializer_t'
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(106) : error C2660: 'app_data_t::oess_serializer_t::unpack' : function does not take 3 arguments
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(107) : error C2660: 'app_data_t::oess_serializer_t::unpack_complete' : function does not take 2 arguments
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(114) : error C2660: 'app_data_t::oess_serializer_t::pack' : function does not take 3 arguments
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(115) : error C2664: 'app_data_t::oess_serializer_t::pack_complete' : cannot convert parameter 2 from 'const app_data_t' to 'const int'
E> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
E>d:\home\eao\sandboxes\oess_1\tags\1.4.0-b1\dev\sample\app_recovery\main.ddl.cpp(121) : error C2660: 'app_data_t::oess_serializer_t::cast' : function does not take 2 arguments
19 ошибок и ни из одной не ясно чтоже произошло Но то что не компилируется это несомненно плюс.
A>>И отсутсвие поддержки XML окончательно поставило крест на всём проекте E>Ну, на проекте это точно крест не поставит Максимум, на его распространении E>Сейчас XML является мэйнстримом и есть куча попыток писать в него и читать из него. Зачем же еще одна попытка?
Писать и читать может каждый дурак. Вопрос в том как это делать удобно.
E>Моей задачей изначально было создание компактного двоичного представления и быстрых средств его формирования/разбора. Ведь есть же еще предметные области, в которых XML просто по определению не подходит из-за своих объемов/скорости. Вот там бы ObjESSty и мог найти свое применение.
Версионность? Очевидно такая вешь нацелена на крупные проекты, а в них backward compability важное условие.
Здравствуйте, adontz, Вы писали:
A>А как тебе вот такой сценарий. Программист пишет программу и ему вдруг (а иначе и не бывает) понадобилась сериализация. Он будет скачивать монстра на пару мегабайт к которому прилагается 2 (ACE, mxx_ru) средства разрабтки и 2 (DDL, Ruby) языка или возьмёт удобную систему, которая работает после простого копирования и сама генерирует большую часть нужного уме кода?
Если бы такие универсальные системы были, то жизнь была бы прекрасна. Но на практике оказывается, что продукт, который хорошо работает в одной предметной области, будет не приспособлен к другой продметной области. Поэтому инструементов должно быть много, хороших и разных.
На счет больших объемов...
Ну вот мне потребовались средства, которые я не смог написать сам -- взял ACE и все завелось. Кому-то потребуется сериализация, возмет ObjESSty, увидит, что там ACE. А в ACE еще и многопоточность, и синхронизация, и сокеты, и SSL, и memory-mapped files, и pipes, и все это работает практически везде. Лепота
Если серьезно, то использование boost сейчас не вызывает особых вопросов, хотя boost и поболее будет. ACE -- это аналог boost по мощности, но в другой области. И не такой ракрученный бренд, к сожалению, как boost.
Насчет Ruby+mxx_ru это действительно вопрос. Пока он другого решения не имеет.
A>>>Вообще идея производности от класса очень очень плохая. E>>На вкус и цвет...
A>Это вопрос расширяемости и гибкости.
Я думаю, что это вопрос некоей принципиальной позиции. Если человеку кажется, что опроизводность от специального класса -- это зло, то вопрос можно закрывать -- ObjESSty однозначно не подойдет.
Я же стаю на другой позиции. Если у меня есть класс Window, то я не ожидаю, что его можно сериализовать. Поэтому могу запихивать в него все что хочу. Более того, я знаю, что никто не сможет его сериализовать. Поэтому не ожидаю никаких проблем. Но вот приходит кто-то с каким-то мега-тулом и сериализует мое окно, вместе с указателем на огромное дерево или граф вспомогательных объектов. И как мне это запретить? Явно указывать, что атрибут такой-то класса Window сериализации не подлежит? Тогда чем это отличается от того, чтобы заранее говорить, что вот только эти типы и вот эти их атрибуты должны сериализоваться и все?
E>>В объектных базах данных обычной практикой является произведение persistent классов от специального базового класса. В этом есть как идеологический момент (ведь это нормально, когда сериализуемый объект удовлетворяет какому-то интерфейсу, т.е. наследуется от общего предка),
A>Это как раз НЕ нормально. Должен быть принцип plug-and-play. Никаких изменений в уже существующих класса. Я же не должен переписывать весь Boost только чтобы возспользоваться чудо-сериализацией.
Не очень понимаю о чем речь. Сериализуют в приложении как раз органиченое число прикладных типов. Которые, как правило, к boost или другим объектным библиотекам не имеют отношения. Эти типы объявляются сериализуемыми. Опять же, я привел факт того, что в объектных базах было распространенной практикой использовать специальный базовый класс. Я просто пошел в том же направлении.
E>>так и чисто практический. В базовом классе сосредотачивается функциональность, которая нужна всем производным сериализуемым классам, но которая не должна дублироваться в производных классах.
A>По вышеуказанным причинам функциональность надо сосредотачивать в глобальных функциях, а не в методах классов.
Здесь нужно дать еще одну ссылку, про которую я забыл: Неизвестные расширения. Вот для хранения этих неизвестных расширений и нужны атрибуты в базовом классе, от которого наследуются остальные сериализуемые классы.
A>Вот это-то и есть расширяемость, когда тип изначально не расчитывался на сериализацию, но сделать это всётаки можно.
Выше я уже привел свое мнение по этому поводу. Добавлю, что наличие специального базового класса есть важная характеристика ObjESSty. Если из-за нее ObjESSty где-то не найдет применения -- значит судьба такая, это следствие осознано принятого проектного решения.
E>>Практика показала, что в сложных программах существуют сотни, если не тысячи C++ типов, но сериализуется только малая часть из них. Поэтому даже накладные расходы на описание этих типов в DDL можно считать несущественными.
A>Имеет проблемы с синхронизацией DDL и C++ определения.
Пока да, имеет. Руки еще не дошли до инструмента, который бы по DDL генерировал C++ класс с getter-ами/setter-ами.
E>>Кросс-платформенный инструмент для компиляции C++ проектов -- это вообще больной вопрос. Кроме mxx_ru я знаком только с двумя такими инструментами: Boost.Jam и SCons. Но первый, по своему удобству использования, не сильно далеко ушел от обычного make (кто не верит, пусть попробует адаптировать Boost.Jam под какой-нибудь новый компилятор). SCons более удобен для меня, но он требует Python, который не меньше Ruby. К тому же мне проще программировать на Ruby, чем на Python.
A>Странный подход. Обычно делают так: пишут под одну платформу то что надо, а под другие портируют создавая новые файлы либо пользуясь препроцессором.
Извините, adontz, но тут у меня большой печальный опыт. Я уже десять лет занимаюсь кросс-платформенной разработкой. Довелось поработать (не считая MS-DOS в университете) и в Win3.11 параллельно с WinNT, и под OS/2, и под различными версиями Linux-а, под FreeBSD и Solaris чуть-чуть, под OS/9000, теперь и под HPNonStop. Наилучший результат достигается тогда, когда разработка изначально идет сразу под несколько платформ. Вносится изменение в проект, тут же тестируется под всем, чем можно. Если оставлять на потом, то это плохо заканчивается. Вплоть до обнаружения того, что из-за особенностей OS выбранное проектное решение оказывается нежизнеспособным.
E>>А vcproj и makefile я не делаю из-за того, что сейчас в ObjESSty 39 проектных файлов. С помощью mxx_ru это поддается управлению. Но во что выльется адаптация проектных файлов хотя бы для трех компиляторов на трех платформах? А сопровождать это как? Ведь многоплатформенность ObjESSty -- это одно из самых главных требований.
A>Делаешь для одной платформы. Если это кому-то нужно, то найдётся смельчак и портирует код под другую платформу.
А если смельчака не найдется, а самому потребуется? Пока оказывается, что проще настроить mxx_ru на новый компилятор/OS, чем править десятки проектных файлов. Ведь во что выливается изъятие одного файла из проекта и добавление вместо него новых двух? В правку всех проектных файлов. А если проектный файл не текстовый, а среды разработки для него под рукой нет?
Товарищи из ACE решили подобную проблему тем, что у них есть своя система описания проектов, из которой через Perl скрипты генерируются родные vcproj/makefile/etc для разных компиляторов.
A>Я не видел ни одного человека, который бы пользовался MSVC++ из коммандной строки.
Не сромно так говорить, но можешь посмотреть на одного -- меня. Работаю 90% под WinXP. Из инструемнтов -- vim, sh (портированные unix-utils), mxx_ru, MSDN. Нет проблем. Правда GUI я не пишу уже, года полтора назад писал на Qt, там Visual Studio так же не нужен был.
A>Бост пишет не один человек.
SCons начинал писать и продолжает развивать один человек.
E>>Сейчас XML является мэйнстримом и есть куча попыток писать в него и читать из него. Зачем же еще одна попытка? A>Писать и читать может каждый дурак. Вопрос в том как это делать удобно.
Под попытками читать и писать я подразумевал проекты сериализации, которые пытаются это делать (adontz -- это не камень в твой огород).
Применительно к ObjESSty, в теории, можно сделать и сериализацию в XML, т.к. реально сериализацией занимаются классы, производные от oess_1::stdsn::ient_t/oent_t. Но на практике я не вижу в этом практического интереса. По моему, ObjESSty должно двигаться куда-то в сторону Asn1 (PER в частности), а не в XML.
A>Версионность? Очевидно такая вешь нацелена на крупные проекты, а в них backward compability важное условие.
Чистой версионности, как в некоторых объектных БД, у меня в ObjESSty нет. Сейчас есть Расширяемые типы, subclassing by extension и Неизвестные расширения. В планах есть создание утилиты, которая бы сравнивала две схемы данных и автоматически преобразовывала сериализованные значения из одной схемы (версии) в другу. В своей первой СУБД я такое уже делал. В ObjESSty еще не успел.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, eao197, Вы писали:
E>Если бы такие универсальные системы были, то жизнь была бы прекрасна.
Вот я и разрабатываю такую Осталось только добавить в список поддерживаемых компиляторов GCC и всё будет ОК.
A>>Это вопрос расширяемости и гибкости. E>Я думаю, что это вопрос некоей принципиальной позиции. Если человеку кажется, что опроизводность от специального класса -- это зло, то вопрос можно закрывать -- ObjESSty однозначно не подойдет.
Если прочесть те два топика ссылки на которые я дал, то станет видно, что такую позицию занимает довольно много людей.
E>Я же стаю на другой позиции. Если у меня есть класс Window, то я не ожидаю, что его можно сериализовать. Поэтому могу запихивать в него все что хочу. Более того, я знаю, что никто не сможет его сериализовать. Поэтому не ожидаю никаких проблем. Но вот приходит кто-то с каким-то мега-тулом и сериализует мое окно, вместе с указателем на огромное дерево или граф вспомогательных объектов. И как мне это запретить?
Вопрос в том зачем это запрещать если человеку действительно надо?
E>Не очень понимаю о чем речь. Сериализуют в приложении как раз органиченое число прикладных типов.
Но некоторые из них определены в сторонних библиотеках, как например std::string. А если я использую другой класс строки?
A>>Вот это-то и есть расширяемость, когда тип изначально не расчитывался на сериализацию, но сделать это всётаки можно.
E>Выше я уже привел свое мнение по этому поводу. Добавлю, что наличие специального базового класса есть важная характеристика ObjESSty. Если из-за нее ObjESSty где-то не найдет применения -- значит судьба такая, это следствие осознано принятого проектного решения.
ОК, просто это большой минус в глазах многих потенциальных потребителей.
A>>Делаешь для одной платформы. Если это кому-то нужно, то найдётся смельчак и портирует код под другую платформу. E>А если смельчака не найдется, а самому потребуется?
Если смельчака не найдёться, значит проект никому не нужен
E>Не сромно так говорить, но можешь посмотреть на одного -- меня. Работаю 90% под WinXP. Из инструемнтов -- vim, sh (портированные unix-utils), mxx_ru, MSDN. Нет проблем. Правда GUI я не пишу уже, года полтора назад писал на Qt, там Visual Studio так же не нужен был.
И mainstream компилятор VC++? Думаю всё-таки gcc.
E>Под попытками читать и писать я подразумевал проекты сериализации, которые пытаются это делать (adontz -- это не камень в твой огород).
Моя пока ничего не пишет. Я временно погряз в написании сопуствующих вещей.
Здравствуйте, adontz, Вы писали:
E>>Если бы такие универсальные системы были, то жизнь была бы прекрасна.
A>Вот я и разрабатываю такую Осталось только добавить в список поддерживаемых компиляторов GCC и всё будет ОК.
Раз за вас, у вас еще есть оптимизм
Только GCC -- это еще не все компиляторы. Даже на Windows есть еще пара-тройка. Borland C++, MetaWare, например. А есть платформы, на которые GCC еще и не портирован -- HPNonStop.
A>Если прочесть те два топика ссылки на которые я дал, то станет видно, что такую позицию занимает довольно много людей.
Но это аргумент к чему? К тому, чтобы переделать ObjESSty? Это уже не реально.
E>>Я же стаю на другой позиции. Если у меня есть класс Window, то я не ожидаю, что его можно сериализовать. Поэтому могу запихивать в него все что хочу. Более того, я знаю, что никто не сможет его сериализовать. Поэтому не ожидаю никаких проблем. Но вот приходит кто-то с каким-то мега-тулом и сериализует мое окно, вместе с указателем на огромное дерево или граф вспомогательных объектов. И как мне это запретить?
A>Вопрос в том зачем это запрещать если человеку действительно надо?
Потому, что с моей точки зрения, разработчик класса должен определять разрешать ли классу сериализоваться или нет. А если кому-то нужно сериализовать несериализуемый класс -- нет проблем, напиши объект-хранилище нужных атрибутов и сохраняй его вместо исходного объекта. Да, трудоемко. Зато гибко: один и тот же класс можно сериализовать разными инструментами, а он ничего и не знает
E>>Не очень понимаю о чем речь. Сериализуют в приложении как раз органиченое число прикладных типов.
A>Но некоторые из них определены в сторонних библиотеках, как например std::string. А если я использую другой класс строки?
Как раз std::string ObjESSty сериализует
На счет остальных классов -- см. выше.
A>ОК, просто это большой минус в глазах многих потенциальных потребителей.
Так ведь я и не продавец
A>Если смельчака не найдёться, значит проект никому не нужен
А я как же
E>>Не сромно так говорить, но можешь посмотреть на одного -- меня. Работаю 90% под WinXP. Из инструемнтов -- vim, sh (портированные unix-utils), mxx_ru, MSDN. Нет проблем. Правда GUI я не пишу уже, года полтора назад писал на Qt, там Visual Studio так же не нужен был.
A>И mainstream компилятор VC++? Думаю всё-таки gcc.
Как раз под Windows -- mainstream компилятор это VC++ 7.1. А Borland C++, MinGW и cygwin я использую для проверки.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, eao197, Вы писали:
E>Рад за вас, у вас еще есть оптимизм E>Только GCC -- это еще не все компиляторы. Даже на Windows есть еще пара-тройка. Borland C++, MetaWare, например. А есть платформы, на которые GCC еще и не портирован -- HPNonStop.
Ну положим Intel'овский весьма сильно совместим с MSVC, так что я думаю даже переделывать особо ничего не придёться, а Microsoft Visual C++, Intel C++ Compiler и GNU C++ Compiler это уже весьма большая аудитория. Не побось сказать, что более половины всех разработчиков.
A>>Если прочесть те два топика ссылки на которые я дал, то станет видно, что такую позицию занимает довольно много людей. E>Но это аргумент к чему? К тому, чтобы переделать ObjESSty? Это уже не реально.
A>>Вопрос в том зачем это запрещать если человеку действительно надо? E>Потому, что с моей точки зрения, разработчик класса должен определять разрешать ли классу сериализоваться или нет.
Ну вот разработчики std::vector ничего такого не думали, однако всериализовать вектор надо ОК, сдесь сделали заплатку, а дальше?
E>А если кому-то нужно сериализовать несериализуемый класс -- нет проблем, напиши объект-хранилище нужных атрибутов и сохраняй его вместо исходного объекта. Да, трудоемко.
Я так как возиться будет лень (это главный двигатель прогресса), то библиотеку спишут. Удобство использования в конечном итоге важнейший критерий. Но если делается велосипед на любителя, но и вопросов нет.
Здравствуйте, adontz, Вы писали:
A>Ну положим Intel'овский весьма сильно совместим с MSVC, так что я думаю даже переделывать особо ничего не придёться, а Microsoft Visual C++, Intel C++ Compiler и GNU C++ Compiler это уже весьма большая аудитория. Не побось сказать, что более половины всех разработчиков.
Ну что здесь сказать? Закон потребления пива 20/80: 20% компиляторов покрывают 80 процентов потребностей.
Если вы расчитываете, что сделаете продукт заточенный на 20% наиболее распространенных компиляторов и создадите себе достаточную аудиторию за счет того, что пользователей этих компиляторов гораздо больше, то вы, определенно, правы. Вполне надежный маркетинговый ход. Надеюсь, что в вашем случае он сработает. Но вам придется здесь столкнуться с серьезными конкурентами вроде boost, s11n.net и даже большим объемом унаследованного кода, который использует MFC сериализацию. Поэтому искрене желаю вам успеха на этом поприще.
Но кроме mainstream существуют еще и менее известные, менее раскрученные, но не менее перспективные направления. Например, кроме ОС общего назначения (Win, Linux, BSD, Solaris), есть еще экзотические ОС общего назначения (HP-UX, AIX), ОС реального времени (QNX, VxWoks) и встраиваемые системы (PalmOS, SymbianOS). Кроме задач "офисного программирования", "автоматизации" и "web-программирования" есть еще и другие предметные области. Например системы АСУТП, CAD/CAM приложения, приложения для проведения on-line банковских транзакций, приложения для систем реального времени, для встраиваемых устройств, для ресуроемких научных вычислений и т.д. Большая часть этих задач нуждается в специализированных инструментах.
Например, в обсуждениях вашего проекта McSeem2 приводил примеры того, как правильно подобранный формат хранения данных мог уменьшить объем их представления в разы. Для многих проектов это критически важно. Например, в CAD приложениях. Если для представления средненького чертежа потребуется сохранить 10000 объектов, то вопрос, как их сохранять, встанет очень остро. Например, если двоичный образ объекта занимает 16 байт, а XML-образ 32 байта (оптимистическое предположение), то вместо 160000Kb один чертеж будет занимать 320000Kb. А если в проекте используется не один чертеж, а 5000? Здесь и архивирование не поможет. Я когда-то читал, что при проектировании одного из Боингов использвался CAD пакет, который сохранял информацию в объектную БД (то ли Versant, то ли ObjectivityDB, точно не помню). И это была единственная(!) БД, которая могла удовлетворить нужды проектировщиков, т.к. объемы некоторых чертежей превышали 4Gb.
Мне как раз интереснее такие, не mainstream, проекты и задачи -- в них простора больше, требования выше, а проторенных тропинок меньше. Поэтому не думаю, что ObjESSty будет конкурировать с вашей системой. Поэтому не нужно подводить меня (или себя) к мысли, что ваш продукт более правильный, чем мой. Он -- иной А места всем хватит.
A>>>Вопрос в том зачем это запрещать если человеку действительно надо? E>>Потому, что с моей точки зрения, разработчик класса должен определять разрешать ли классу сериализоваться или нет.
A>Ну вот разработчики std::vector ничего такого не думали, однако всериализовать вектор надо ОК, сдесь сделали заплатку, а дальше?
В отличии от boost, ACE и других объектных библиотек с собственными контейнерами, std::vector является стандартным типом C++. ObjESSty позволяет сериализовать атрибуты стандартных типов C++: char, short, int, float, double, std::string, std::vector, std::list, std::deque, std::set, std::multiset, std::map, std::multimap и обычный одномерный вектор. Только элементами контейнеров должны быть либо объекты стандартных типов, либо сериализуемые объекты. Вполне логичная, и стройная система. Никаких заплаток.
Станут какие-то типы boost-а стандартом, тогда можно будет и о них поговорить.
E>>А если кому-то нужно сериализовать несериализуемый класс -- нет проблем, напиши объект-хранилище нужных атрибутов и сохраняй его вместо исходного объекта. Да, трудоемко.
A>Я так как возиться будет лень (это главный двигатель прогресса), то библиотеку спишут. Удобство использования в конечном итоге важнейший критерий. Но если делается велосипед на любителя, но и вопросов нет.
adontz, ИМХО, вы излишне оптимистично относитесь к вопросам сериализации. Почему-то во главу угла ставите то, что сериализация происходит легко, гладко и незаметно. Достаточно спроектировать нужную для предметной области модель данных, описать C++ типы, применить к парочке объектов супер-мега-тул и все! Все довольны, все смеются! Боюсь, что это не так. Можно рассмотреть несколько аспектов:
1. Объем занимаемых данных. Если объем данных в сериализованном виде критичен для задачи, то здесь будут оцениваться не только возможности инструмента сериализации. Предположим, что кроме XML представления, инструмент может очень эффективно строить двоичное представление (что само по себе уже не просто, попробуйте хотя бы приблизиться к эффективности Asn1 PER). Но, может оказаться, что наибольшая эффективность достигается изменением модели данных на предметном уровне. Скажем в ОП какую-то ломаную линию на чертеже выгодно представлять в виде std::list< pointer * >. А вот сериализовать ее лучше в виде обычного вектора pointer-ов. И окажется, что уже на предметном уровне придется выбирать, что и как будет сериализовано. Т.е. все равно придется выделять сериализуемые типы и явно с ними работать, как с сериализуемыми.
2. Транзактность. Почему-то об этом при обсуждении средств сериализации ничего не говорят, но это важно. Пусть при заполнении пустого архива (хранилища) транзактность не важна, не запишется -- перепишем архив и все. Но при модификации архива? Жалко же терять 20Mb данных из-за того, что произошел сбой при добавлении в архив 5Kb новых объектов. Но, если хранилище поддерживает транзакции, то в приложении, которое занимается сериализацией, нужно будет добавлять код по управлению транзакциями (begin/commit/rollback), диагностику того, что последняя транзакция не была зафиксирована, инициированием восстановления архива и т.д. Окажется, что код сериализации/десериализации уже не так прост.
3. Конкурентный доступ к архивам. Например, несколько приложений работают в связке (типичный unix way). Одно приложение пишет что-то в архив, а другие по ходу дела извлекают из него данные и обрабатывают. Пример: subversion, которая хранит все в хитром сериализованном представлении в BerkeleyDB (до версии 1.1 это был единственный back-end). Тут окажется, что инструмент должен предоставлять средства многопользовательского доступа к хранилищу. А приложения, которые используют этот инструмент, должны учитывать, то, что их могут заблокировать или отказать в проведении операции из-за чужой блокировки. И опять, обращение к сериализации/десериализации уже не будет простым.
4. Формат сериализованного представления. Возьмем XML, здесь извращений побольше. Хорошо, когда инструмент сериализации может использовать собственный DTD для сериализуемых данных. Но тогда, фактически, получается "полузакрытый" формат данных. С одной стороны, он базируется на открытых инструментах, но с другой -- DTD диктуете вы. Хорошо, если все согласны его использовать (имеется в виду, что кроме C++ приложения с автоматической сериализацией, есть еще и другие приложения, на других языках, которые таких инструментов не имеют). А если вам скажут -- что это за proprietary формат? Ах, вам так удобнее данные сохранять? Ну это ваши проблемы. У нас есть отраслевой стандарт, для него уже определены стандартные DTD и у нас уже код для него написан. И будут в ваше приложение передавать XML-и, которые на автоматический парсинг не очень-то и расчитаны. Либо парсить его автоматически нельзя, т.к. нужно делать специфическую обработку ошибок. Пример: спецификация Visa 3D Secure. Набор XML-документов с определенной структурой. Но на парсинг которых накладываются очень жесткие ограничения, проверяемые при сертификации продукта. И если в каком-то проекте есть вручную написанный код для сериализации/десериализации таких XML-документов, то этот код и будет использоваться даже для промежуточного сохранения документов в БД. И сериализации/десериализации в этом приложении будет отводиться одна из самых главных ролей.
Я это все к тому, что необходимость сериализации и требования к ней нужно определять в проекте с самого начала. Иначе могут придти бОльшие неприятности. А раз так, то и типы, подлежащие сериализации могут быть специальным образом выделены (вплоть до размещения в отдельных пространствах имен). И на этом фоне я не считаю, что необходимость производить сериализуемые типы от специального базового типа является драконовским условием.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если вы расчитываете, что сделаете продукт заточенный на 20% наиболее распространенных компиляторов и создадите себе достаточную аудиторию за счет того, что пользователей этих компиляторов гораздо больше, то вы, определенно, правы. Вполне надежный маркетинговый ход.
Стараюсь
E>Надеюсь, что в вашем случае он сработает. Но вам придется здесь столкнуться с серьезными конкурентами вроде boost, s11n.net и даже большим объемом унаследованного кода, который использует MFC сериализацию. Поэтому искрене желаю вам успеха на этом поприще.
Конкурентов я не боюсь. Волков бояться в лес не ходить. А большой объём унаследованного кода не достанеться ни мне ни комубы-то ни было ещё из конкурентов. Его просто когда-нибудь перепишут.
E>Но кроме mainstream существуют еще и менее известные, менее раскрученные, но не менее перспективные направления. Например, кроме ОС общего назначения (Win, Linux, BSD, Solaris), есть еще экзотические ОС общего назначения (HP-UX, AIX), ОС реального времени (QNX, VxWoks) и встраиваемые системы (PalmOS, SymbianOS). Кроме задач "офисного программирования", "автоматизации" и "web-программирования" есть еще и другие предметные области. Например системы АСУТП, CAD/CAM приложения, приложения для проведения on-line банковских транзакций, приложения для систем реального времени, для встраиваемых устройств, для ресуроемких научных вычислений и т.д. Большая часть этих задач нуждается в специализированных инструментах.
Вопрос в том одно ли это и то же делать ширпотреб и специнструмент? ИМХО второе делается только на заказ и за серьёзные деньги. Конечно надёться какое-нибудь исключение, но суть именно такова.
E>А места всем хватит.
E>В отличии от boost, ACE и других объектных библиотек с собственными контейнерами, std::vector является стандартным типом C++. ObjESSty позволяет сериализовать атрибуты стандартных типов C++: char, short, int, float, double, std::string, std::vector, std::list, std::deque, std::set, std::multiset, std::map, std::multimap и обычный одномерный вектор. Только элементами контейнеров должны быть либо объекты стандартных типов, либо сериализуемые объекты. Вполне логичная, и стройная система. Никаких заплаток.
Проблема в том, что MFC::CArray и ATL::CString для многих не менее стандартны, но системе уже чужды.
Вот это-то я и называю не гибкостью, когда все типы невольно деляться на build-in и user-defined.
Представьте себе Си++ без перегрузки операторов и поймёте о чём речь.
E>Станут какие-то типы boost-а стандартом, тогда можно будет и о них поговорить.
Я не хочу зависеть от производителя библиотеки в плане выбора типов данных
E>adontz, ИМХО, вы излишне оптимистично относитесь к вопросам сериализации. Почему-то во главу угла ставите то, что сериализация происходит легко, гладко и незаметно. Достаточно спроектировать нужную для предметной области модель данных, описать C++ типы, применить к парочке объектов супер-мега-тул и все! Все довольны, все смеются!
В начале прошлого века люди по 30 минут неподвижно сидели перед дагеротипами, кто тогда думал, что можно будет нажать кнопку и уже через 15 секунд получить фотографию?
Если что-то кажеться сейчас неосуществимым это не значит, что это что-то действительно неосуществимо.
Описаное вами выше это именно то к чему я стремлюсь. А когда добьюсь, то наверное поставлю себе новую, ещё более крутую цель.
E>1. Объем занимаемых данных. Если объем данных в сериализованном виде критичен для задачи, то здесь будут оцениваться не только возможности инструмента сериализации. Предположим, что кроме XML представления, инструмент может очень эффективно строить двоичное представление (что само по себе уже не просто, попробуйте хотя бы приблизиться к эффективности Asn1 PER). Но, может оказаться, что наибольшая эффективность достигается изменением модели данных на предметном уровне. Скажем в ОП какую-то ломаную линию на чертеже выгодно представлять в виде std::list< pointer * >. А вот сериализовать ее лучше в виде обычного вектора pointer-ов. И окажется, что уже на предметном уровне придется выбирать, что и как будет сериализовано. Т.е. все равно придется выделять сериализуемые типы и явно с ними работать, как с сериализуемыми.
В этом проявляется гибкость. Автоматически нагенерированная сериализация и не должна быть оптимальной по всем параметрам. Она должна удовлетворять всего одному требованию — безглючность.
Если что-то сильно не устраивает отключаем автомат и пишем руками.
E>2. Транзактность. Почему-то об этом при обсуждении средств сериализации ничего не говорят, но это важно. Пусть при заполнении пустого архива (хранилища) транзактность не важна, не запишется -- перепишем архив и все. Но при модификации архива? Жалко же терять 20Mb данных из-за того, что произошел сбой при добавлении в архив 5Kb новых объектов. Но, если хранилище поддерживает транзакции, то в приложении, которое занимается сериализацией, нужно будет добавлять код по управлению транзакциями (begin/commit/rollback), диагностику того, что последняя транзакция не была зафиксирована, инициированием восстановления архива и т.д. Окажется, что код сериализации/десериализации уже не так прост.
Это не есть проблема сериализации как таковой. Я выделял три объекта: сериализуемый объект, архив отвечающий за формат хранения данных и последовательный поток байт. Вот поддержка транзакций это функциональность потока байт, но не сериализуемого объекта или архива.
Когда вы пишете в файл, то транзакции отрываются и закрываются не вызовом функций, а неявно, драйвером NTFS или вовсе не используются на FAT32. Так и с сериализацией. Транзакциями неявно управляет поток байт.
E>3. Конкурентный доступ к архивам. Например, несколько приложений работают в связке (типичный unix way). Одно приложение пишет что-то в архив, а другие по ходу дела извлекают из него данные и обрабатывают. Пример: subversion, которая хранит все в хитром сериализованном представлении в BerkeleyDB (до версии 1.1 это был единственный back-end). Тут окажется, что инструмент должен предоставлять средства многопользовательского доступа к хранилищу. А приложения, которые используют этот инструмент, должны учитывать, то, что их могут заблокировать или отказать в проведении операции из-за чужой блокировки. И опять, обращение к сериализации/десериализации уже не будет простым.
Опять таки проблемы потока, но не архива или сериализуемого объекта.
E>4. Формат сериализованного представления. Возьмем XML, здесь извращений побольше. Хорошо, когда инструмент сериализации может использовать собственный DTD для сериализуемых данных. Но тогда, фактически, получается "полузакрытый" формат данных. С одной стороны, он базируется на открытых инструментах, но с другой -- DTD диктуете вы. Хорошо, если все согласны его использовать (имеется в виду, что кроме C++ приложения с автоматической сериализацией, есть еще и другие приложения, на других языках, которые таких инструментов не имеют). А если вам скажут -- что это за proprietary формат? Ах, вам так удобнее данные сохранять? Ну это ваши проблемы. У нас есть отраслевой стандарт, для него уже определены стандартные DTD и у нас уже код для него написан. И будут в ваше приложение передавать XML-и, которые на автоматический парсинг не очень-то и расчитаны. Либо парсить его автоматически нельзя, т.к. нужно делать специфическую обработку ошибок. Пример: спецификация Visa 3D Secure. Набор XML-документов с определенной структурой. Но на парсинг которых накладываются очень жесткие ограничения, проверяемые при сертификации продукта. И если в каком-то проекте есть вручную написанный код для сериализации/десериализации таких XML-документов, то этот код и будет использоваться даже для промежуточного сохранения документов в БД. И сериализации/десериализации в этом приложении будет отводиться одна из самых главных ролей.
Опять таки вот она гибкость. Не нравиться автоматически сгенерированный код — пиши свой. Просто случаев когда надо писать свой, по сравнению со случаями когда надо написать по принципу "лишь бы работало" достаточно мало. Поэтому автоматическая генерация кода сериализации с возможностью вкраплений сериализации написаной ручками это ИМХО весьма перспективное направление.
Здравствуйте, adontz, Вы писали:
A>Вопрос в том одно ли это и то же делать ширпотреб и специнструмент? ИМХО второе делается только на заказ и за серьёзные деньги. Конечно надёться какое-нибудь исключение, но суть именно такова.
Я не делаю ни того, ни другого -- я делаю то, что мне интересно.
Только при попытке объективно оценить ситуацию я понимаю, что вряд ли смогу сделать mainstream-овый инструмент. Но вот инструемент для каких то специфических целей -- это вполне возможно.
A>Проблема в том, что MFC::CArray и ATL::CString для многих не менее стандартны, но системе уже чужды. A>Вот это-то я и называю не гибкостью, когда все типы невольно деляться на build-in и user-defined. A>Представьте себе Си++ без перегрузки операторов и поймёте о чём речь.
Повторю еще раз, я считаю, что сериализация -- это серьезный вопрос. Для успешного решения которого вполне допустимо делить типы на свои и чужие. Ведь когда речь идет о РСУБД, вполне нормальной считается ситуация, что СУБД поддерживает только ограниченное количество типов, а все остальное требует делать на их основе.
A>Я не хочу зависеть от производителя библиотеки в плане выбора типов данных
Ok. Кто же вам мешает. Вы делаете продукт, который позволит сериализовать все, что угодно. Пусть именно этим он и привлекает к себе стороников.
A>Если что-то кажеться сейчас неосуществимым это не значит, что это что-то действительно неосуществимо. A>Описаное вами выше это именно то к чему я стремлюсь. А когда добьюсь, то наверное поставлю себе новую, ещё более крутую цель.
Успехов!
E>>1. Объем занимаемых данных. Если объем данных в сериализованном виде критичен для задачи, то здесь будут оцениваться не только возможности инструмента сериализации. Предположим, что кроме XML представления, инструмент может очень эффективно строить двоичное представление (что само по себе уже не просто, попробуйте хотя бы приблизиться к эффективности Asn1 PER). Но, может оказаться, что наибольшая эффективность достигается изменением модели данных на предметном уровне. Скажем в ОП какую-то ломаную линию на чертеже выгодно представлять в виде std::list< pointer * >. А вот сериализовать ее лучше в виде обычного вектора pointer-ов. И окажется, что уже на предметном уровне придется выбирать, что и как будет сериализовано. Т.е. все равно придется выделять сериализуемые типы и явно с ними работать, как с сериализуемыми.
A>В этом проявляется гибкость. Автоматически нагенерированная сериализация и не должна быть оптимальной по всем параметрам. Она должна удовлетворять всего одному требованию — безглючность. A>Если что-то сильно не устраивает отключаем автомат и пишем руками.
Если вы возьмете стандартную ASN1 PER сериализацию и нормальный инструмент, который ее полностью поддерживает, то вы увидите, что есть автоматическая сериализация, которая эффективна, как минимум: по объему результирующего образа и по скорости сериализации/десериализации. Но даже ASN1 PER можно сделать еще эффективнее, если сериализовать "правильные" для сериализации типы, а не те типы, которыми удобно оперировать в программе.
E>>2. Транзактность. Почему-то об этом при обсуждении средств сериализации ничего не говорят, но это важно. Пусть при заполнении пустого архива (хранилища) транзактность не важна, не запишется -- перепишем архив и все. Но при модификации архива? Жалко же терять 20Mb данных из-за того, что произошел сбой при добавлении в архив 5Kb новых объектов. Но, если хранилище поддерживает транзакции, то в приложении, которое занимается сериализацией, нужно будет добавлять код по управлению транзакциями (begin/commit/rollback), диагностику того, что последняя транзакция не была зафиксирована, инициированием восстановления архива и т.д. Окажется, что код сериализации/десериализации уже не так прост.
A>Это не есть проблема сериализации как таковой. Я выделял три объекта: сериализуемый объект, архив отвечающий за формат хранения данных и последовательный поток байт. Вот поддержка транзакций это функциональность потока байт, но не сериализуемого объекта или архива.
Я и не говорил, что это проблема сериализации. Это проблема использования инструемента сериализации, который, в идеальном случае, транзактность должен обеспечивать. А прикладной код должен учитывать транзактность (см. выше).
A>Когда вы пишете в файл, то транзакции отрываются и закрываются не вызовом функций, а неявно, драйвером NTFS или вовсе не используются на FAT32. Так и с сериализацией. Транзакциями неявно управляет поток байт.
Плохая аналогия. Файловая система еще не в состоянии обеспечить логическую целостность файла. Хотя бы потому, что сбой может произойти между двумя последующими write в программе. Т.е. файловая система корректно зафиксирует результат первого write и физически файл будет неповрежденным, но вот логической целостностью он обладать уже не будет.
E>>3. Конкурентный доступ к архивам. Например, несколько приложений работают в связке (типичный unix way). Одно приложение пишет что-то в архив, а другие по ходу дела извлекают из него данные и обрабатывают. Пример: subversion, которая хранит все в хитром сериализованном представлении в BerkeleyDB (до версии 1.1 это был единственный back-end). Тут окажется, что инструмент должен предоставлять средства многопользовательского доступа к хранилищу. А приложения, которые используют этот инструмент, должны учитывать, то, что их могут заблокировать или отказать в проведении операции из-за чужой блокировки. И опять, обращение к сериализации/десериализации уже не будет простым.
A>Опять таки проблемы потока, но не архива или сериализуемого объекта.
Это не проблемы потока, это проблемы приложения. Что должно делать приложение, если ему говорят, что поток сейчас заблокирован другим приложением? Повторять попытку сразу? После тайм-аута? Сколько попыток делать? Или вообще не делать? Или сам поток не вернет управление пока не разблокируется? А если есть deadlock-и?
E>>4. Формат сериализованного представления. Возьмем XML, здесь извращений побольше. Хорошо, когда инструмент сериализации может использовать собственный DTD для сериализуемых данных. Но тогда, фактически, получается "полузакрытый" формат данных. С одной стороны, он базируется на открытых инструментах, но с другой -- DTD диктуете вы. Хорошо, если все согласны его использовать (имеется в виду, что кроме C++ приложения с автоматической сериализацией, есть еще и другие приложения, на других языках, которые таких инструментов не имеют). А если вам скажут -- что это за proprietary формат? Ах, вам так удобнее данные сохранять? Ну это ваши проблемы. У нас есть отраслевой стандарт, для него уже определены стандартные DTD и у нас уже код для него написан. И будут в ваше приложение передавать XML-и, которые на автоматический парсинг не очень-то и расчитаны. Либо парсить его автоматически нельзя, т.к. нужно делать специфическую обработку ошибок. Пример: спецификация Visa 3D Secure. Набор XML-документов с определенной структурой. Но на парсинг которых накладываются очень жесткие ограничения, проверяемые при сертификации продукта. И если в каком-то проекте есть вручную написанный код для сериализации/десериализации таких XML-документов, то этот код и будет использоваться даже для промежуточного сохранения документов в БД. И сериализации/десериализации в этом приложении будет отводиться одна из самых главных ролей.
A>Опять таки вот она гибкость. Не нравиться автоматически сгенерированный код — пиши свой. Просто случаев когда надо писать свой, по сравнению со случаями когда надо написать по принципу "лишь бы работало" достаточно мало. Поэтому автоматическая генерация кода сериализации с возможностью вкраплений сериализации написаной ручками это ИМХО весьма перспективное направление.
Принцип "лишь бы работало" приводит к тому, что неудачные решения уходят в эксплуатацию, а потом их невозможно заменить на удачные из-за соображений обратной совместимости.
adontz, а есть еще притензии к ObjESSty, кроме:
— наличия специального базового типа, от которого все должны наследоваться;
— поддержки ограниченного количества типов;
— использования собственного средства компиляции проектов;
— отсутствия поддержки XML
?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, 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
Я бы сказал шире — плохая расширяемость. Насколько легко подключить новое хранилище или формат хранения данных?
Здравствуйте, adontz, Вы писали:
A>>>В этом проявляется гибкость. Автоматически нагенерированная сериализация и не должна быть оптимальной по всем параметрам. Она должна удовлетворять всего одному требованию — безглючность. A>>>Если что-то сильно не устраивает отключаем автомат и пишем руками.
E>>Если вы возьмете стандартную ASN1 PER сериализацию и нормальный инструмент, который ее полностью поддерживает, то вы увидите, что есть автоматическая сериализация, которая эффективна, как минимум: по объему результирующего образа и по скорости сериализации/десериализации. Но даже ASN1 PER можно сделать еще эффективнее, если сериализовать "правильные" для сериализации типы, а не те типы, которыми удобно оперировать в программе.
A>ОК, вот ещё одна умопомрачительная задача: сделать множества "правильных" для сериализации типов и типов удобных для использования в программе идентичными.
Не реальная. Но вечный двигатель до сих пор изобретают.
E>>Плохая аналогия. Файловая система еще не в состоянии обеспечить логическую целостность файла. Хотя бы потому, что сбой может произойти между двумя последующими write в программе. Т.е. файловая система корректно зафиксирует результат первого write и физически файл будет неповрежденным, но вот логической целостностью он обладать уже не будет.
A>Поэтому я и ввёл методы scope_begin/scope_end.
E>>adontz, а есть еще притензии к ObjESSty, кроме: E>>- наличия специального базового типа, от которого все должны наследоваться; A>+
Понятно. E>>- поддержки ограниченного количества типов; A>+
Понятно. E>>- использования собственного средства компиляции проектов; A>дело не в том собственное оно или нет. Если вместе с проектом будут идти vbs и pl файл то всё ок. А так качать много чего надо.
pl -- это Perl? А если у меня на машине Perl-а нет? Вот принципиально не люблю Perl-а и не ставлю себе, пока сильно не прижмет.
E>>- отсутствия поддержки XML A>Я бы сказал шире — плохая расширяемость. Насколько легко подключить новое хранилище или формат хранения данных?
А насколько просто подключить к SQLite или MetaKit, или BerkeleyDB новое хранилище или формат хранения данных? Ведь ObjESSty изначально создавалась как восстановочная БД, а возможность сериализации (я считаю не слабая), явилась побочным продуктом. Который сейчас используется и независимо от восстановочной БД.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Вы ведь все равно использовать его не будете 
Думаю всё-таки gcc.
