Здравствуйте, Павел Кузнецов, Вы писали:
A>> Есть вещи которых не хватает в обоих языках. ПК>А именно?..
Например сериализация.
В Си++ её просто нету. Каждый в меру своих способнойстей что-то пишет или использует, но ничего универсального просто нет. Каждый подход подразумевает те или иные ограничения либо на формат хранения данных, либо на сериализуемые структуры.
В C# всё несколько сложнее. Там аж две независимые сериализации System.Runtime.Serialization и System.Xml.Serialization. Казалось бы хорошо — я тоже когда-то радовался. На самом деле всё плохо.
Xml-сериализация как нетрудно догадатся умеет писать только в XML. Весьма негибка по своей структуре для чтения большинства внешних форматов она не подходит (я её не смог использовать даже для внутреннего, придуманного мной же).
Что касается System.Runtime.Serialization, то тут начинаются подводные камни. Во-первых, класс непомеченный аттрибутом [Serializable] использовать нельзя. Я это воспринимаю как недостаток, тем более что Xml-сериализация без него работает, значит в принципе без специального аттрибута можно обойтись. Дальнейшее ИМХО просто архитектурная ошибка, которую легко обойти, то менее ошибкой она от этого не становится. Дело было так. У меня был контейнер для некоторых элементов, которые надо было не только хранить, но и отображать. Ну я реализовал некоторые необходимые интерфейсы и подключил мой контейнер как DataSource для DevExpress.TreeList. Всё замечательно отображалось, TreeList как и положено подписался на событие ListChanged и реагировал на все изменения. Дальше самое интересное — я хочу записать свой контейнер в файл, а мне говорят, что DevExpress.TreeList is not serializable. Оно мне надо было? Пришлось создавать ещё одну копию списка на события которой никто не подписан) только для того, чтобы записать её в файл, так как помечать событие аттрибутом NonSerialized нельзя. Ладно лишний расход памяти, но что если мне надо сериализовать вместе со структурой некоторые из подписчиков? Система показывает себя в этом случае не гибкой. ИМХО, если уж ввели атрибут Serializable, то надо было классы без этого аттрибута просто пропускать, а не генерировать ошибки.
adontz wrote:
> A>> Есть вещи которых не хватает в обоих языках. > ПК>А именно?.. > Например сериализация.
Мимо.
> В Си++ её просто нету. Каждый в меру своих способнойстей что-то пишет > или использует, но ничего универсального просто нет. Каждый подход > подразумевает те или иные ограничения либо на формат хранения данных, > либо на сериализуемые структуры.
1. Code portability — depend only on ANSI C++ facilities.
2. Code economy — exploit features of C++ such as RTTI, templates,
and multiple inheritance, etc. where appropriate to make code
shorter and simpler to use.
3. Independent versioning for each class definition. That is, when a
class definition changed, older files can still be imported to the
new version of the class.
4. Deep pointer save and restore. That is, save and restore of
pointers saves and restores the data pointed to.
5. Proper restoration of pointers to shared data.
6. Serialization of STL containers and other commonly used templates.
7. Data Portability — Streams of bytes created on one platform should
be readable on any other.
8. Orthogonal specification of class serialization and archive
format. That is, any file format should be able to store
serialization of any arbitrary set of C++ data structures without
having to alter the serialization of any class.
9. Non-intrusive. Permit serialization to be applied to unaltered
classes. That is, don't require that classes to be serialized be
derived from a specific base class or implement specified member
functions. This is necessary to easily permit serialization to be
applied to classes from class libraries that we cannot or don't
want to have to alter.
10. The *archive* interface must be simple enough to easily permit
creation of a new type of archive.
11. The *archive* interface must be rich enough to permit the creation
of an *archive* that presents serialized data as XML in a useful
manner.
При этом ее реально удобно использовать _и_ расширять. Единственное чем
бы помог кодогенератор — это для перечисления полей структуры и для
разворачивания атрибутов.
> Ладно лишний расход памяти, но что если мне надо сериализовать вместе > со структурой *некоторые* из подписчиков? Система показывает себя в > этом случае не гибкой. ИМХО, если уж ввели атрибут Serializable, то > надо было классы без этого аттрибута просто пропускать, а не > генерировать ошибки.
В Java есть ключевое слово transient, означающее, что данное поле
сериализовать не надо.
Угу. Явная сериализация базового класса, ручная версионность это всё пол-беды.
Беда это, например, потеря контроля целостности данных. Вот как с помошью boost.serialization делается такое:
Есть параллелипипед заданный тремя векторами с началами в одной точке (4 точки, 12 координат). В процессе его использования нужны координаты всех 8 вершин и объём. Считать их каждый раз накладно,, значит они тоже хранятся и вычисляются по мере изменения исходных данных, но в файл не записываются. Как мне их пересчитать после сериализации? В методе
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
?
Но он не только для считывания, но и для записи. Значит в методе
template<class Archive>
void load(Archive & ar, const unsigned int version)
?
Но это значит, что мало того что надо объявить ещё метод save, так надо потом ещё и постоянно держать методы в save и load в синхронном состоянии. На тех примерах что в Tutorial всё выглядит замечательно, стоит подсунуть чуть более сложный класс и опять всё надо делать руками и все эти способы сокращения объёма кодирования перестают работать.
C>При этом ее реально удобно использовать _и_ расширять. Единственное чем бы помог кодогенератор — это для перечисления полей структуры и для разворачивания атрибутов.
Нет, ты не прав. Кодогенератор может не только перечислять поля, но и вызывать методы. Мне например кажется более разумным считать вычисляемые поля не в методе load, а в методе on_after_load который бы вызывался если он есть. Более того, я хочу ещё и on_before_save чтобы привести данные к каноническому виду (например отсортировать или сдвинуть идентификаторы, чтобы использовались от 0 до N без просветов или перегенерировать GUIDы, да мало ли что) перед записью. Отдельный метод уместнее, тем более уместно чтобы не я его явно вызывал, а это делали за меня.
C>В Java есть ключевое слово transient, означающее, что данное поле сериализовать не надо.
А в .Net есть атрибут NonSerialized, но в событиям его применять нельзя.
Здравствуйте, Cyberax, Вы писали:
C>Павел Кузнецов wrote:
>> C>static_cast не поможет — прелбразование идет из void*. >> static_cast замечательно работает при преобразованиях из void* в T*.
C>Я имею в виду, что он не поможет избавиться от ошибок, и выбор типа C>каста — просто вопрос стиля.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
В данном случае это не стиль.
static_cast -- легальный каст в языке, в данном случае для получения типизированоого указателя из нетипизированного.
reinterpret_cast -- платформенно-зависимый хак.
Это вопрос о выражении характера операции в коде.
static_cast указываает при чтении кода, что всё нормально.
Условно говоря -- желтый маркер.
reinterpret_cast -- осторожно, платформенно-зависимый хак.
Красный маркер.
Здравствуйте, Cyberax, Вы писали:
C>Шахтер wrote:
>> Во-вторых, что бы сделать что-то лучше не обязательно начинать всё с >> нуля. Можно взять уже существующее решение и улучшить его в одном или >> другом направлении.
C>Даже это достаточно сложно — тот же Hoard почти полностью переписывали C>(кажется) дважды, чтобы добавить новые оптимизации. И это учитывая, что C>исследования по стрегиям реализации динамического распределения уже лет C>50 идут.
>> Это не требует нескольких человеко-лет.
C>Запросто может потребовать, особенно для того, чтобы обогнать тщательно C>оптимизированные реализации.
>> По поводу horad а. НЕ могу ничего сказать по поводу алгоритмов -- это >> требует углублённого исследования, но вот по поводу качества >> програмной реализации -- вот один из фрагментов. Мне он не внушает >> энтузиазма. Явный abuse наследования.
C>С наследованием тут все OK — используется трюк с EBO (Empty Base C>Optimization) для организации политик.
При чем здесь empty base optimization?
У нас получается два класса, производный и базовый. Публичное наследование.
Оба класса содержат методы с одинаковой сигнатурой, но с разной семантикой.
Для чего, спрашивается? Правильный ответ -- нафиг не нужно и даже вредно.
Базовый класс надо сделать членом.
>> Здесь нужно было агреггировать. Вместо reinterpret_cast нужен >> static_cast. Нет защиты от неверного размера. Ну и т.д. Код явно >> нуждается в некотором улучшении.
C>C защитой от неправильного размера: C> * @warning This is for one "size class" only. (хотя assert все равно C>бы не помешал)
Здесь не assert нужен. Вместо того, чтобы отлавливать ошибки в run-time е, их надо не допускать в compile-time.
В данном случае -- раз аллокируемый размер предопределён, не нужно его вообще как параметр передавать.
Сделай его параметром шаблона. Кроме того, нужна проверка, что этот размер не меньше, чем sizeof (freeObject).
C>static_cast не поможет — прелбразование идет из void*.
Кстати говоря, в данном примере каст вообще не нужен -- placement new будет в самый раз.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Шахтер, Вы писали:
Ш>>Делись. Я заинтересован в точном знании как реализована поддержка обработки исключений в VC++. У меня есть некоторые планы подкрутить это дело.
A>Давно уже поделился http://www.rsdn.ru/Forum/Message.aspx?mid=1206489&only=1
По-другому не получается красиво, это у них проскакивало в списке
рассылки. Да и не такая уж это большая проблема — добавить одну строчку
в метод serialize.
> ручная версионность это всё пол-беды.
К сожалению, автоматическое версирование (как в архивах MFC, например)
на практике выливается только в то, что версируются только добавления
полей. Для более других случаев приходится писать код руками.
> Беда это, например, потеря контроля целостности данных. Вот как с > помошью boost.serialization делается такое: > Есть параллелипипед заданный тремя векторами с началами в одной точке > (4 точки, 12 координат). В процессе его использования нужны координаты > всех 8 вершин и объём.
> Считать их каждый раз накладно,, значит они тоже хранятся и > вычисляются по мере изменения исходных данных, но в файл не > записываются. Как мне их пересчитать после сериализации? В методе > >template<class Archive> >void serialize(Archive & ar, const unsigned int version) > > ?
Можно и в нем, у архивов есть метод bool is_loading(). Кроме того, для
классов можно сделать serialization hook'и, которые будут вызываться при
загрузке/сохранении объектов (удобно для валидации загружаемых данных,
например).
> C>При этом ее реально удобно использовать _и_ расширять. Единственное > чем бы помог кодогенератор — это для перечисления полей структуры и > для разворачивания атрибутов. > Нет, ты не прав. Кодогенератор может не только перечислять поля, но и > вызывать методы. Мне например кажется более разумным считать > вычисляемые поля не в методе load, а в методе on_after_load который бы > вызывался если он есть.
Кто мешает добавить его в boost.serialization? Тем более, что это уже
сделано.
Все равно не вижу целей, которые оправдывали бы замену CRT.
Здравствуйте, Cyberax, Вы писали:
C>Все равно не вижу целей, которые оправдывали бы замену CRT.
А это раздельные проекты. Одно с другим не связано. Вполне возможно, что кодогенератор будет генерировать вполне портируемый код никак не завязанный на какие-либо библиотеки.
А ты думал я CRT меняю, что кодогенератор использовать? Ты ещё раз ошибся
Шахтер wrote:
> C>С наследованием тут все OK — используется трюк с EBO (Empty Base > C>Optimization) для организации политик. > При чем здесь empty base optimization?
При том, что базовый класс может быть stateless, а включение его членом
потребует 1 байта памяти (минимум). Кроме того, базовый класс может быть
некопируемым, тогда его надо было бы хранить как ссылку, а это будет
оверхед.
> У нас получается два класса, производный и базовый. Публичное > наследование. > Оба класса содержат методы с одинаковой сигнатурой, но с разной > семантикой. > Для чего, спрашивается?
Чтобы сделать прозрачные политики. Смотри у Александреску в flex_string,
например.
> Правильный ответ -- нафиг не нужно и даже вредно. > Базовый класс надо сделать членом.
В данном случае — нет.
> C>C защитой от неправильного размера: > C> * @warning This is for one "size class" only. (хотя assert все равно > C>бы не помешал) > Здесь не assert нужен. Вместо того, чтобы отлавливать ошибки в > run-time е, их надо не допускать в compile-time. > В данном случае -- раз аллокируемый размер предопределён, не нужно его > вообще как параметр передавать. > Сделай его параметром шаблона. Кроме того, нужна проверка, что этот > размер не меньше, чем sizeof (freeObject).
Да, об этом они не подумали.
> C>static_cast не поможет — прелбразование идет из void*. > Кстати говоря, в данном примере каст вообще не нужен -- placement new > будет в самый раз.
Кстати да, в своей библиотеке контейнеров я его использую, а тут как-то
об этом не подумал.
Здравствуйте, Cyberax, Вы писали:
C>Шахтер wrote:
>> C>С наследованием тут все OK — используется трюк с EBO (Empty Base >> C>Optimization) для организации политик. >> При чем здесь empty base optimization?
C>При том, что базовый класс может быть stateless, а включение его членом C>потребует 1 байта памяти (минимум).
Оптимизировать размер данного класса не имеет смысла -- объектов этого класса будет несколько штук в программе.
C>Кроме того, базовый класс может быть C>некопируемым,
Кстати -- копирование для даного класса должно быть запрещено. Это просто баг в этом коде.
С> тогда его надо было бы хранить как ссылку,
Зачем? Не нужно. Кстати, подобъекты базового класса не хранятся как ссылки.
С> а это будет C>оверхед.
>> У нас получается два класса, производный и базовый. Публичное >> наследование. >> Оба класса содержат методы с одинаковой сигнатурой, но с разной >> семантикой. >> Для чего, спрашивается?
C>Чтобы сделать прозрачные политики.
???
С>Смотри у Александреску в flex_string, C>например.
>> Правильный ответ -- нафиг не нужно и даже вредно. >> Базовый класс надо сделать членом.
C>В данном случае — нет.
>> C>C защитой от неправильного размера: >> C> * @warning This is for one "size class" only. (хотя assert все равно >> C>бы не помешал) >> Здесь не assert нужен. Вместо того, чтобы отлавливать ошибки в >> run-time е, их надо не допускать в compile-time. >> В данном случае -- раз аллокируемый размер предопределён, не нужно его >> вообще как параметр передавать. >> Сделай его параметром шаблона. Кроме того, нужна проверка, что этот >> размер не меньше, чем sizeof (freeObject).
C>Да, об этом они не подумали.
>> C>static_cast не поможет — прелбразование идет из void*. >> Кстати говоря, в данном примере каст вообще не нужен -- placement new >> будет в самый раз.
C>Кстати да, в своей библиотеке контейнеров я его использую, а тут как-то C>об этом не подумал.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, adontz, Вы писали:
A>Что касается System.Runtime.Serialization, то тут начинаются подводные камни. Во-первых, класс непомеченный аттрибутом [Serializable] использовать нельзя. Я это воспринимаю как недостаток, тем более что Xml-сериализация без него работает, значит в принципе без специального аттрибута можно обойтись. Дальнейшее ИМХО просто архитектурная ошибка, которую легко обойти, то менее ошибкой она от этого не становится. Дело было так. У меня был контейнер для некоторых элементов, которые надо было не только хранить, но и отображать. Ну я реализовал некоторые необходимые интерфейсы и подключил мой контейнер как DataSource для DevExpress.TreeList. Всё замечательно отображалось, TreeList как и положено подписался на событие ListChanged и реагировал на все изменения. Дальше самое интересное — я хочу записать свой контейнер в файл, а мне говорят, что DevExpress.TreeList is not serializable. Оно мне надо было? Пришлось создавать ещё одну копию списка на события которой никто не подписан) только для того, чтобы записать её в файл, так как помечать событие аттрибутом NonSerialized нельзя. Ладно лишний расход памяти, но что если мне надо сериализовать вместе со структурой некоторые из подписчиков? Система показывает себя в этом случае не гибкой. ИМХО, если уж ввели атрибут Serializable, то надо было классы без этого аттрибута просто пропускать, а не генерировать ошибки.
Как это нельзя? — это делать нужно и делается сплошь и рядом — только несколько другим путем
[Serializable]
public class OperandCollection : CollectionBase, IBindingList
{
[NonSerialized]private ListChangedEventHandler listChangedHandler;
public event ListChangedEventHandler ListChanged
{
add { listChangedHandler += value; }
remove { listChangedHandler -= value; }
}
Гуевых подписчиков серилизовать — идея вредная — отдашь ты например коллекцию по ремотингу — придется тащить и все потроха девекса? (или чего там юзается) Это ж никуда не годится.
error CS0592: Attribute 'NonSerialized' is not valid on this declaration type. It is valid on 'field' declarations only.
ЮБ>Гуевых подписчиков серилизовать — идея вредная — отдашь ты например коллекцию по ремотингу — придется тащить и все потроха девекса? (или чего там юзается) Это ж никуда не годится.
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Можешь — это просто другой способ реализации.
Я попытался, он мне посыпал Not Implemented. Я завтра MSDN почитаю на эту тему. Как это event можно на delegate заменить, так чтобы event считался реализованным.
Здравствуйте, adontz, Вы писали:
A>Я попытался, он мне посыпал Not Implemented. Я завтра MSDN почитаю на эту тему. Как это event можно на delegate заменить, так чтобы event считался реализованным.
Я заинтересован в точном знании как реализована поддержка обработки исключений в VC++. У меня есть некоторые планы подкрутить это дело.
