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

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

S>>WFrag wrote:

>>> P.S. Сэкономив пару дней своих ресурсов, ты мог бы их потратить на какие-нибудь осмысленные оптимизации. Или на
S>>исправление ошибок — пользователи тебе спасибо скажут.
S>>М... А зачем свои ресурсы экономить? Лучше будет и туда и туда выделить не по паре дней а по неделе.

_>А кто оплатит эти пару дней?

Недель конечно же.

>>>> Ты уже почти слил, напиши код чтобы это всем понятно было. Тебе ведь нужно явное указание типа
>>>> при десериализации, чтобы вызвать нужный load.
>> S>Я просто не буду писать так, чтобы было непонятно что куда как откуда читать.
>> Не надо жопой играть, код покажи.
S>И не подумаю. Раз сам не понимаешь, о чем речь, то тебе и код не поможет.

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


>>>> Кстати, как твой код отработает при циклических ссылках,
>> S>Встретится такое — придумаю что прикрутить.
>> Не надо так откровенно сливать.
>> Ты ведь показываешь свое непонимание проблемы.
S>Я то проблему прекрасно понимаю. Это ты не понимаеш что проблема в том, что дохрена мусора после сериализации вашим методом.

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

>>>> как будут сериализовываться строки?
>> S>Ты действительно не знаешь или притворяешся?
>> Код в студию.
S>Ох уж эти дотнетчики... Пишешь количество символов, следом строку. Читаешь количество символов, читаешь строку.

Расскажи, что такое символ, применительно к ASCII, UTF-8, UTF-16, UTF-8 с различными формами нормализации.


>> Так покажи что это мусор в общем случае.
S>Мда... Почитай то что мамут давал http://wiki.shelek.ru/index.php/C%2B%2B_сериализация_данных и обрати внимание что там в файл
S>сохраняется.


А ты почитай, почему это там сохраняеся. Твой пример обладает следующими недостатками:

- Допустимо использовать только для POD-структур (POD — Plain Old Data) и встроенных типов. Почему, будет понятно из следующих пунктов.
— Если программистом описан конструктор, то компилятор вправе в класс добавить какие-то свои вспомогательные переменные, что превращает класс в не POD-структуру, на самом деле это не так страшно, но формально это так.
— При сохранении указателей членов класса будут скопированы только адреса, хранимые указателями и, естественно, класс с указателями это не POD-тип
— Если в классе объявленные виртуальные функции (или он унаследован от класса содержащего виртуальные функции), это приводит к тому, что класс будет дополнен указателем на таблицу виртуальных функций, и с этим указателем та же проблема, что и со всеми другими. Опять же не POD-тип.
— Если ваш класс содержит внутри себя не POD типы или унаследован от не POD-типа, то ваш класс тоже не под тип, т.е. нет никакой гарантии, что копирование куска памяти позволит постановить состояние класса.
— Различное выравнивание данных внутри класса может сделать невозможным перенос сохранённого класса на другую платформу или даже в программу, скомпилированную с другими параметрами компиляции.
— Различный порядок байт не позволит переносить данные между такими платформами, как: x86 и PowerPC

WFrag wrote:

> S>М... А зачем свои ресурсы экономить? Лучше будет и туда и туда выделить не по паре дней а по неделе.
> Тогда чем-то ещё придётся жертвовать.
С чего это?

Mamut wrote:

> С экономической точки зрения:
> — две недели * на зарплату на ветер... Ты уволен
Ой, как мне страааашно.

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

anton_t wrote:

> А кто оплатит эти пару дней?
Как кто? Работодатель.

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

S>gandjustas wrote:

>>>> Ты уже почти слил, напиши код чтобы это всем понятно было. Тебе ведь нужно явное указание типа
>>>> при десериализации, чтобы вызвать нужный load.
>> S>Я просто не буду писать так, чтобы было непонятно что куда как откуда читать.
>> Не надо жопой играть, код покажи.
S>И не подумаю. Раз сам не понимаешь, о чем речь, то тебе и код не поможет.
Ок. Слив засчитан.

>>>> Кстати, как твой код отработает при циклических ссылках,
>> S>Встретится такое — придумаю что прикрутить.
>> Не надо так откровенно сливать.
>> Ты ведь показываешь свое непонимание проблемы.
S>Я то проблему прекрасно понимаю. Это ты не понимаеш что проблема в том, что дохрена мусора после сериализации вашим методом.
Так докажи что это мусор. Тебе ведь как раз не удается это сделать.

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

>> Хотя даже в частном случае ты не можешь десериализацию написать.
S>Я написал по минимуму. Да не бойся, писал я такое лет 7 назад, когда делал для себя каталогизатор CD.
Так покажи код, просто десериализация полиморфного объекта с получением ссылки на базовый класс.

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

>> А кто оплатит эти пару дней?
S>Как кто? Работодатель.

А деньги он откуда возьмёт? Из тумбочки.

Mamut wrote:

> Шеридан, ты все же ответь на вопрос, как ты будешь сохранять данные с циклическими ссылками,
Не знаю, думаю — флаги какие нибудь прикручу, а что?

> а также как ты будешь сохранять указатели.
Надо сохранять не указатели, а данные, хранящиеся там.

> Нет. Это ты не понимаешь, какие проблемы возникают при сохранении сложных структур данных, а не
> простых чисел
Это какие? Сложно уследить за порядком сохранения-чтения? Ну да, ну да...

> Расскажи, что такое символ, применительно к ASCII, UTF-8, UTF-16, UTF-8 с различными формами нормализации.
Тоесть ты хочешь сказать что вообще никак, тоесть абсолютно невозможно никаким образом, ну ввобще никак и никогда не получится
сохранить и прочитать строку в любой кодировке?
Ах, можно? Правда? Ну значит так и сделаем.

> А ты почитай, почему это там сохраняеся. Твой пример обладает следующими недостатками:
Мамут, там все красиво конечно описано. Только это не мой случай там описан. Там описана сериализация — тоесть сохранение данных
с мусором, а у меня — сохранение только данных. Так что не надо мне всякий раз эту вики подсовывать.

S> > С экономической точки зрения:
S> > — две недели * на зарплату на ветер... Ты уволен

S> Ой, как мне страааашно.

Это факт. Дедланы никто не отменял



S> > С программистской точки зрения:
S> > — две недели на то, чтобы сделать достаточно общую библиотеку, покрывающую приемлемый объем
S> > пограничных случаев, задача достаточно нереальная.

S> Хорошо, месяц. Ибо в первую очередь должна присутствовать забота о потребителях.

Именно поэтому нормальный программист не будет клепать велосипед, а возьмет проверенную, устоявшуюся библиотеку.

anton_t wrote:

>>> a *c2 = new a(); // соответственно и при загрузке не знаем реальный тип c2.
> S>Напомни, я чтото говорил про чисто виртуальные функции или нет?
>
> Как связаны чисто виртуальные функции с этим примером, сдесь же ни одного абстрактного класса
> нет? И как они тебе помогут, даже если будут?
Так, что у тебя просто не получится не то что добиться неоднозначности вызовов, но даже создать такой класс.

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

>> S>М... А зачем свои ресурсы экономить? Лучше будет и туда и туда выделить не по паре дней а по неделе.
>> Тогда чем-то ещё придётся жертвовать.
S>С чего это?

Потому что время — это тоже ресурс, который довольно-таки ограничен. В том числе и из экономических соображений. Если ничем не жертвовать, то разработка легко раздуется на пару порядков и по времени и по деньгам. Кому нужен продукт через 10 лет? Тем более, что тогда он уже скорее всего потеряет всякую актуальность.

gandjustas wrote:

>>> Хотя даже в частном случае ты не можешь десериализацию написать.
> S>Я написал по минимуму. Да не бойся, писал я такое лет 7 назад, когда делал для себя
> каталогизатор CD. Так покажи код, просто десериализация полиморфного объекта с получением ссылки
> на базовый класс.
У меня там такого не было. Обычные структуры были, да. А вот полиморфного ничего

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

S>WFrag wrote:

>> S>М... А зачем свои ресурсы экономить? Лучше будет и туда и туда выделить не по паре дней а по неделе.
>> Тогда чем-то ещё придётся жертвовать.
S>С чего это?

Неделю на сериализацию. Месяц на создани собственного сетевого протокола. Месяц на написание собственного хранилища данных. Неделю еще на что-то. Ведь мы люим велосипеды, не?

В итоге прошел год — куча велосипедов, из них половина не протестирована, а проект не сдивнулся с мертвой точки ни на шаг

S> > Шеридан, ты все же ответь на вопрос, как ты будешь сохранять данные с циклическими ссылками,
S> Не знаю, думаю — флаги какие нибудь прикручу, а что?

Ключевой момен выделен

S> > а также как ты будешь сохранять указатели.
S> Надо сохранять не указатели, а данные, хранящиеся там.

Верно, но не до конца. Потому что, восстанавливая, ты должен получить структуру с указателями на эти данные. Не говоря уже о том, что эти данные сами могут быть достаточно сложными структурами, да еще и зацикленными друг на друга.

В итоге твой код, способный созранить и восстановить такую структуру, разрастется неимоверно и на определенном этапе тебе все равно придется вносить «мусор» — те же флаги.

S> > Нет. Это ты не понимаешь, какие проблемы возникают при сохранении сложных структур данных, а не
S> > простых чисел

S> Это какие? Сложно уследить за порядком сохранения-чтения? Ну да, ну да...

Сохрани мне std::list<my_class *>

Порядок чтения у него, ага

S> > Расскажи, что такое символ, применительно к ASCII, UTF-8, UTF-16, UTF-8 с различными формами нормализации.

S> Тоесть ты хочешь сказать что вообще никак, тоесть абсолютно невозможно никаким образом, ну ввобще никак и никогда не получится
S> сохранить и прочитать строку в любой кодировке?
S> Ах, можно? Правда? Ну значит так и сделаем.


Нет. Ты гвооришь:

Ох уж эти дотнетчики... Пишешь количество символов, следом строку. Читаешь количество символов, читаешь строку.

Так вот, тем способом, что ты сохраняешь данные ты не сможешь прочитать UTF-16 строку. Ты даже не сможешь гарантированно прочитать UTF-8 строку. Ты будешь обязан сохранить с этой строкой как минимум следующие данные:
— тип строки
— кодировка
— тип нормализации (для UTF-8)

И только потом — саму строку. Именно поэтому сохранение данных aka сериализация — то не просто «записал—считал»

S> > А ты почитай, почему это там сохраняеся. Твой пример обладает следующими недостатками:

S> Мамут, там все красиво конечно описано. Только это не мой случай там описан.

Там описан именно твой случай. Проблемы, что я процитировал, относятся именно к твоему случаю.


S> Там описана сериализация — тоесть сохранение данных
S> с мусором, а у меня — сохранение только данных.

Ты — все-таки клинический идиот, да простят меня модераторы. Сериализация — это сохранение данных. С «мусором» или без него — это способ реализации такого сохранения. Твой способ «без мусора» работает только для простейших типов данных и встроенных типов. Для всего отсального он н работает

WFrag wrote:

> Кому нужен продукт через 10 лет?
Лучше потратить 10 лет и выпустить действительно отлаженый и оптимизированный продукт.

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

я понимаю, что все это пустой идеализм, но помечтать то хочется

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

H>Ты мне пытаешься нарисовать картину идеального мира, чтоли? Пожалуйста, не нужно. Ну правда, смешно читать такие вещи на фоне существующих веток, где говорят, что бета 2010 студии тормозит на современном железе (согласен, это всего лишь бета).
А она не на чистом .net, там как-раз большинство кода на C++, так что следуя твоей логике это c++-код в тормозит.

H>На фоне сливающегося Paint.NET, на фоне монстра по имени Creative Docs. NET. Я уже писал о симптоматичности, вот она то и проглядывается...
Судить о всем дотнете по нескольким приложениям...

H>Ты правда думаешь, что менторы из МС (читаем About от Paint.NET), позволили так накорявить в алгоритме, что его даже параллельность не спасает?
А ты думаешь они там все алгоритмы до блеска вылизывали?

H>>>>>Ну так в чем проблема? Исходники доступны, сравни.
J>>>>Зачем мне заниматься такой ерундой? Это удел местных обиженных дотнетом.
H>>>Раз ты сомнение имеешь, тебе и карты в руки
J>>Ятут сравнением не занимался. Или это по Шеридановскому учению "вот вам кое-какие аргументы, не нравится — опровергайте"?
H>Это и небыло сравнением Один горячий финский хлопец учудил сравнив Paint.NET с Photoshop, на что в ответ получл сей пример (по типу, разберись ка с моим младшим братом сперва). Если ты в этом увидел сравнение .NET с нативом, ну...
Да, а это что?

Предлагаю объективный тест Выбери картинку побольше и наложи на нее фильтр Gaussian Blur с радиусом в 200 (побольше и 200 это для того, чтоб было что посмотреть). Теперь запусти GIMP и проделай то же самое (к слову, в GIMP'е настроек фильтра больше, можешь попробовать со всякими -- картины это не меняет). Уверяю тебя, приставка .Net будет порвана на твоих глазах раз десять точно (чем больше картинка тем ощутимее).

H>>>>>Ты вправду думаешь, что реализацию одного алгоритма можно осуществить с такими девиациями от генеральной линии, что оно будет сливаться чуть не на порядок?
J>>>>Запросто. Посмотри все эти приведенные здесь сравнения "C++ vs .Net", чаще всего там не учтены какие-то особенности или приведен неидентичный код.
H>>>Тут ты прав, чтоб сравнивать скорость работы wstring и StringBuilder'а, нужно иметь непоколебимую веру в светлую идеи отстаивания своих взлядов/убеждений/веры любой ценой
J>>И чем же отличается скорость работы wstring и StringBuilder'а, а то я не в теме?
H>Можешь ознакомиться

Автор: criosray
Дата: 07.06.09

.
Да уж, опять сравнение шила с мылом...

Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder. Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.

H>>>(а сравнений алгоритмов тут небыло вообще, насколько я помню)
J>>В этом и заключается ущербность данного сравнения. Люди сравнивают скорость работы программы даже не заглядывая в реализацию .
H>Как я уже написал выше, это небыло сравнением натива с .NET. Было сравнение продуктов.
Там это сравнение было именно в контексте "тормознутости .net"

MxKazan>На моем домашнем компе, который и 3 года назад то был средний и с тех пор не видел ничего нового, кроме винтов, Paint.Net просто летает. Так что, всё больше убеждаюсь, что приставка ".Net" действует на некоторых как красная тряпка для быка, хочется искать тормоза даже когда их нет.

S> > Кому нужен продукт через 10 лет?
S> Лучше потратить 10 лет и выпустить действительно отлаженый и оптимизированный продукт.


10 лет * ((кол-во програмистов) * зарплата + содержание) = фирма уходит из бизнеса на второй месяц.


ЗЫ. Ты гмылом пользуешься? Доволен? Фигня, то он до их пор не отлажен и не оптимизирован?

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

S>anton_t wrote:

>> А кто оплатит эти пару дней?
S>Как кто? Работодатель.

— А деньги где берёшь?
— В тумбочке.

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

S>anton_t wrote:

>>>> a *c2 = new a(); // соответственно и при загрузке не знаем реальный тип c2.
>> S>Напомни, я чтото говорил про чисто виртуальные функции или нет?
>>
>> Как связаны чисто виртуальные функции с этим примером, сдесь же ни одного абстрактного класса
>> нет? И как они тебе помогут, даже если будут?
S>Так, что у тебя просто не получится не то что добиться неоднозначности вызовов, но даже создать такой класс.

Ну хорошо, в корне иерархии у нас абстрактный класс:

class a
{
public:
  virtual void load(const string& path) = 0;
  virtual void save(const string& path) = 0;
}

class b : public a
{
  int q;
public:
  virtual void load(const string& path)
  {
    //что-то.
  }
  virtual void save(const string& path)
  {
    //что-то.
  }
}

class c : public a
{
  double q;
public:
  virtual void load(const string& path)
  {
    //что-то.
  }
  virtual void save(const string& path)
  {
    //что-то.
  }
}

int main()
{
  a* a1 = GetA(); // или b или с.
  a1->save("file.dat");

  a* a2 = ... //<- сдесь живут драконы
  a2->load("file.dat");

  return 0;
}

А теперь сделай этот код работающим, если конечно можешь.

Mamut wrote:

> 10 лет * ((кол-во програмистов) * зарплата + содержание) = фирма уходит из бизнеса на второй
> месяц.
Значит недостойна.

> ЗЫ. Ты гмылом пользуешься? Доволен? Фигня, то он до их пор не отлажен и не оптимизирован?
Нет, n\a, нет.