Здравствуйте, Ikemefula, Вы писали:
I>По уму, надо бы положить BinaryFormatter в неймспейс Debug и назвать ObjectGraphDump. Тогда многие вопросы снялись бы сами собой.
Он и так назван Formatter, а не Serializer. Но, как видишь, не останавливает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Два раза обходить граф рефлекшеном?
Зачем два раза обходить? Раз обойти, второй — по сохраненному списку.
А по хорошему, надо было просто генерить код для обхода. Но ручки то не дотягиваются, видимо.
Здравствуйте, pilgrim_, Вы писали:
_>На объект может быть ссылка? может, соотв. чтобы кто-то на кого-то мог ссылаться, этот "кого-то" должен иметь идентификатор, а тот кто ссылается должен хранить ссылку на этого "кого-то".
На самом деле, конечно, не должен. Адрес объекта — это и есть его идентификатор. Да и для списка хранить ссылку на каждый элемент — странно как-то.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Ikemefula, Вы писали:
I>>По уму, надо бы положить BinaryFormatter в неймспейс Debug и назвать ObjectGraphDump. Тогда многие вопросы снялись бы сами собой.
НС>Он и так назван Formatter, а не Serializer. Но, как видишь, не останавливает.
Здравствуйте, Ikemefula, Вы писали:
НС>>Он и так назван Formatter, а не Serializer. Но, как видишь, не останавливает. I> I>formatter это слишком общее слово.
О да, главная проблема в том что слово не такое, а не в том что некоторые документацию не читают.
Здравствуйте, CoderMonkey, Вы писали:
НС>>Два раза обходить граф рефлекшеном? CM>Зачем два раза обходить? Раз обойти, второй — по сохраненному списку.
Это всер равно замедлит и сильно.
CM>А по хорошему, надо было просто генерить код для обхода.
JIT не даст работать коду, который обращается к приватным полям извне. Это во-первых. А во-вторых в случае BinaryFormatter заранее неизвестен список типов, в отличие от того же XmlSerializer.
CM> Но ручки то не дотягиваются, видимо.
BinaryFormatter это легаси, его никто существенно переделывать не будет. Ты какую задачу вообще решаешь? Зачем тебе BF понадобился?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Он и так назван Formatter, а не Serializer. Но, как видишь, не останавливает. I>> I>>formatter это слишком общее слово.
НС>О да, главная проблема в том что слово не такое, а не в том что некоторые документацию не читают.
Именно потому, что документацию не читают и надо подбирать правильные имена и неймспеймы, открывать или закрывать доступ.
Здравствуйте, Ikemefula, Вы писали:
НС>>О да, главная проблема в том что слово не такое, а не в том что некоторые документацию не читают. I>Именно потому, что документацию не читают и надо подбирать правильные имена и неймспеймы, открывать или закрывать доступ.
Увы, мир не идеален. Правильными названиями вообще мало кто заморачивается, за редким исключением типа такого.
Здравствуйте, CoderMonkey, Вы писали:
CM>Здравствуйте, pilgrim_, Вы писали:
_>>На объект может быть ссылка? может, соотв. чтобы кто-то на кого-то мог ссылаться, этот "кого-то" должен иметь идентификатор, а тот кто ссылается должен хранить ссылку на этого "кого-то".
CM>На самом деле, конечно, не должен. Адрес объекта — это и есть его идентификатор.
Сюр какой-то, какой адрес объекта в сериализованном представлении, в файле например?
CM>Да и для списка хранить ссылку на каждый элемент — странно как-то.
А что он должен хранить? Как ссылаться на произвольный сериализуемый объект (в файле напр.)?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это всер равно замедлит и сильно.
С фига ли, позвольте узнать? И наколько сильно?
НС>JIT не даст работать коду, который обращается к приватным полям извне. Это во-первых. А во-вторых в случае BinaryFormatter заранее неизвестен список типов, в отличие от того же XmlSerializer.
1. Есть unsafe, или его уже отменили?
2. Это нисколько не мешает сгенерить код для известных типов
НС>BinaryFormatter это легаси, его никто существенно переделывать не будет. Ты какую задачу вообще решаешь? Зачем тебе BF понадобился?
Какую решаю — уже решил. Просто решил поиграться и удивился, насколько он феноменально крив.
А ты, кстати, какую задачу здесь решаешь?
Здравствуйте, CoderMonkey, Вы писали:
НС>>JIT не даст работать коду, который обращается к приватным полям извне. Это во-первых. А во-вторых в случае BinaryFormatter заранее неизвестен список типов, в отличие от того же XmlSerializer.
CM>1. Есть unsafe, или его уже отменили?
Работает только для full trust
CM>2. Это нисколько не мешает сгенерить код для известных типов
Нк попробуй, сгенери код чтения или записи приватного поля, а потом попробуй выполнить. И да, для BF никаких известных типов кроме примитивов не существует в принципе.
НС>>BinaryFormatter это легаси, его никто существенно переделывать не будет. Ты какую задачу вообще решаешь? Зачем тебе BF понадобился? CM>Какую решаю — уже решил. Просто решил поиграться и удивился, насколько он феноменально крив.
Он не крив, просто ты явно применил его не по назначению.
CM>А ты, кстати, какую задачу здесь решаешь?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А если в графе циклы? Как смещение предвычислить?
1. Делаем обход графа возможных типов, генерим код для обхода объектов. Если какие типы заранее неизвестны — там уж придется использовать рефлекшен.
2. Обходим граф объектов, складываем объекты в список в порядке обнаружения
3. Идем по списку, пишем объекты
Здравствуйте, CoderMonkey, Вы писали:
CM>Можно подумать, он и так не требует full trust
Не требует. Иначе бы междоменное взаимодействие без full trust не работало.
НС>>И да, для BF никаких известных типов кроме примитивов не существует в принципе. CM>С чего бы?
Здравствуйте, CoderMonkey, Вы писали:
CM>Здравствуйте, pilgrim_, Вы писали:
_>>Сюр какой-то, какой адрес объекта в сериализованном представлении, в файле например?
CM>И в чем заключается "сюр"?
Так не делают
— адреса объектов (в памяти), их размер, зависят от архитектуры проца (x86/x64)
— в случае CLR, в процессе сериализации адрес объекта может быть изменен (при дефрагментации кучи, в которой на данный момент "живет" объект)
_>>А что он должен хранить? Как ссылаться на произвольный сериализуемый объект (в файле напр.)?
CM>Достаточно хранить просто тела объектов.
— BinaryFormatter спецом сделан, и тебе уже сказали об этом, для возможности передать полный граф объектов по ремотингу, AppDomain/сеть, с возможностью полностью воссоздать (десериализовать) оригинальный граф
— в общем случае это дороже в плане объема, чем хранить ссылку (конечно возможны и оптимизации — если объем хранения id+ссылки > тела объекта, тело сохранять выгоднее, т.е. можно хранение сделать вариативным), но это не про BinaryFormatter, см. п.1
-при циклических ссылках (напр. parent/child+parent) сохранение "сырого" тела невозможно, попробуй это сделать с пом. XmlSerializer
CM>А нафига тебе понадобилось ссылаться на произвольный сериализуемый объект?
произвольный здесь в смысле любой (в товем примере List ссылается на объекты TestClass)
Раз обойти, второй — по сохраненному списку.
