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

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

E>>>Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию.
G>>Отличная идея. GC как раз позволяет не думать о выделении и освобождении памяти вообще.

E>Это не правда. Если бы GC позволял не думать о выделении и освобождении памяти, то какой смысл бы был сравнивать производительность GC и стандартного аллокатора С++? Или эти сравнения в топике были бессмысленными?
Сравнения в топике были чтобы показать что выделение и освобождения памяти в случае стандартного аллокатора — далеко не бесплатная операция, как многие думали.

E>Как можно не думать о выделении и освобождении объектов, если из-за этого может оказаться очень низкая производительность приложения?
Спокойно, и произовдительность нормальная будет.

G>>Если производительность окажется недостаточной то надо смотреть причны и бороться с ними.
G>>Причем чаще всего прчиной оказывается применение неподходчщего алогоритма. Очень редко приходится нарываться на ситуацию когда низкая производительность вызвана особенностями платформы.

E>А причём здесь алгоритмы, если речь идёт о декомпозиции на объекты? Если бы дело было только в алгоритмах, то тогда не применяли бы ООП, а так бы и писали эти алгоритмы на структурных языках. Алгоритм может быть одним и тем же, но по-разному представляться с помощью объектов, работать с разными объектами. По вашим словам один и тот же алгоритм может быть одновременно "подходящим" и "неподходящим" в зависимости от используемой объектной модели задачи. А если Вы подразумеваете под разными алгоритмами использование разных объектных декомпозиций, то тогда Вы просто ограничиваете доступный набор этих декомпозиций, с помощью которых можно решить задачу, просто называя такие декомпозиции неподходящими из-за скорости выделения памяти.
Я не об объектах говорил, а о производительности вообще.

E>А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?
Неправ. Слабые выразительне способности C++ не позволяют мере проводить объектую декомпозицию так как хочется.

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

E>>Как можно не думать о выделении и освобождении объектов, если из-за этого может оказаться очень низкая производительность приложения?
G>Спокойно, и произовдительность нормальная будет.

Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?

E>>А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?
G>Неправ. Слабые выразительне способности C++ не позволяют мере проводить объектую декомпозицию так как хочется.

Примеры?

>> с чего начать: С++ или С#?

А ты подумай Сейчас вузы выпускают примерно 9 разработчиков тяготеющих к какому нить С#, к 1 толковому на С++, при примерно равном кол-ве вакансий, чтобы не быть голословным:

http://hh.ru/applicant/searchvacancyresult.xml?text=программист+С%2B%2B&professionalAreaId=0&desireableCompensation=&compensationCurrencyId=1

http://hh.ru/applicant/searchvacancyresult.xml?text=программист+С%23&professionalAreaId=0&desireableCompensation=&compensationCurrencyId=1

Да и ниши это разные совсем, о чём тут вообще спор то идёт. Приложения то языков разные совсем, давайте ещё поспорим на тему, что лучше LISP или PHP.

Тут ответ простой и ясный на вопрос, хочешь дёшево лепить корпоративные вэб сайты/сервисы и формоклёпить со скоростью света бери С#. Хочешь в перспективе работать в Apple, Google, Microsoft, в России в к примеру в Yandex ну или ещё в одном вот из этих ( http://www.research.att.com/~bs/applications.html ) "скромных" мест, в которых как известно работают одни идиоты, которые не читают RSDN и не знают, что с использованием .Net они бы сделали всё быстрее и лучше, учи С++. Только в С++ мало приятного, что в разработке, что в изучении, которое в лучшем случае продлится лет 5, а в худшем не закончится никогда. По уровню зарплат опять же в целом C++/Unix разработчики обычно получают значительно выше, при том же уровне квалификации.

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

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

E>>>Как можно не думать о выделении и освобождении объектов, если из-за этого может оказаться очень низкая производительность приложения?
G>>Спокойно, и произовдительность нормальная будет.

E>Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?
Для систем с GC — да. Это и позволяет концентрироваться на алгоритме.
Для C++ — нет. Там надо думать о том как распределяется память под объекты.

E>>>А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?
G>>Неправ. Слабые выразительне способности C++ не позволяют мере проводить объектую декомпозицию так как хочется.
E>Примеры?
1)Как минимум нельзя просто вернуть динамический объект из метода, потому что неизвестно освободят ли его.
2)Осутствуют многие языковые конструкции как yield, ФВП, делегаты, события.
3)Отсуствие метаинформации о типах не позволяет создавать решения вроде IoC контейнеров, OR-мапперов, связывания данных (binding) и других полезных фишек.

Я знаю что некоторые недостатки исправляются бустом, но обычно это порождает сложночитемый код.

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

E>>Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?
G>Для систем с GC — да. Это и позволяет концентрироваться на алгоритме.

Представьте, что надо сделать текстовый редактор типа WYSIWYG. Ваша вера настолько сильна, что Вы рискнёте для представления одного символа использовать отдельный объект некоторого класса?

Представьте, что надо реализовать какую-нибудь числодробилку. Ваша вера настолько сильна, что Вы рискнёте для представления числа использовать класс?

G>Для C++ — нет. Там надо думать о том как распределяется память под объекты.

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

E>>>>А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?
G>>>Неправ. Слабые выразительне способности C++ не позволяют мере проводить объектую декомпозицию так как хочется.
E>>Примеры?
G>1)Как минимум нельзя просто вернуть динамический объект из метода, потому что неизвестно освободят ли его.
G>2)Осутствуют многие языковые конструкции как yield, ФВП, делегаты, события.
G>3)Отсуствие метаинформации о типах не позволяет создавать решения вроде IoC контейнеров, OR-мапперов, связывания данных (binding) и других полезных фишек.

G>Я знаю что некоторые недостатки исправляются бустом, но обычно это порождает сложночитемый код.

Ок, в общем позиция понятна. Странно правда, что использование std::auto_ptr/boost::shared_ptr для возвращаемого объекта представляется сложночитаемым.

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

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

E>>>Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?
G>>Для систем с GC — да. Это и позволяет концентрироваться на алгоритме.

E>Представьте, что надо сделать текстовый редактор типа WYSIWYG. Ваша вера настолько сильна, что Вы рискнёте для представления одного символа использовать отдельный объект некоторого класса?
А такое вообще может быть нужно? Я что-то не представляю сценарий, где для одного символа требуется объект класса.
Если что есть паттерн flyweight, который как раз позволяет не создавать кучу однотипных объектов.

E>Представьте, что надо реализовать какую-нибудь числодробилку. Ваша вера настолько сильна, что Вы рискнёте для представления числа использовать класс?
А что значит класс?
Например в C# сами числа являются наследниками Object, имеют методы и реализуют интерфейсы.

Я надеюсь вы сами понимаете, что выдумываете что-то нереальное. не нужно создавать классы для символов и чисел, они уже есть и отлично работают.
А если каких-то абстракций нету в стандартной библиотеке, то я буду создавать классы.
Очень надеюсь что все программисты так поступют.

G>>Для C++ — нет. Там надо думать о том как распределяется память под объекты.
E>В каком смысле надо думать? Думать о том, когда и как память освободить? Ну тогда это утверждение выглядит бредово, с учётом предыдущего. "Производительность будет отличаться на порядки, потому что надо думать". Память выделяется и освобождается в обоих вариантах, но во втором варианте надо думать, чтобы её освободить, поэтому производительность будет хуже.

Ниче не не понял.

E>>>>>А если я пишу программу на С++, то выбор доступных декомпозиций расширяется. Разве я не прав?
G>>>>Неправ. Слабые выразительне способности C++ не позволяют мере проводить объектую декомпозицию так как хочется.
E>>>Примеры?
G>>1)Как минимум нельзя просто вернуть динамический объект из метода, потому что неизвестно освободят ли его.
G>>2)Осутствуют многие языковые конструкции как yield, ФВП, делегаты, события.
G>>3)Отсуствие метаинформации о типах не позволяет создавать решения вроде IoC контейнеров, OR-мапперов, связывания данных (binding) и других полезных фишек.
G>>Я знаю что некоторые недостатки исправляются бустом, но обычно это порождает сложночитемый код.

E>Ок, в общем позиция понятна. Странно правда, что использование std::auto_ptr/boost::shared_ptr для возвращаемого объекта представляется сложночитаемым.
Это как раз самое простое.
Вот сложночитаемомое становится при активном использовании ФВП.

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

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

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

E>>>>Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?
G>>>Для систем с GC — да. Это и позволяет концентрироваться на алгоритме.

E>>Представьте, что надо сделать текстовый редактор типа WYSIWYG. Ваша вера настолько сильна, что Вы рискнёте для представления одного символа использовать отдельный объект некоторого класса?
G>А такое вообще может быть нужно? Я что-то не представляю сценарий, где для одного символа требуется объект класса.
G>Если что есть паттерн flyweight, который как раз позволяет не создавать кучу однотипных объектов.

Вот WYSIWYG-редактор -- это как раз и есть сценарий, где для одного символа хотелось бы отдельный объект.
Наша беседа становится предсказуемой. Я знал, что сейчас Вы скажите про flyweight, а я скопирую описание сего паттерна из той известной книги.

Таки вот, копирую:

Например, в большинстве редакторов документов имеются средства форма-
тирования и редактирования текстов, в той или иной степени модульные. Объект-
но-ориентированные редакторы обычно применяют объекты для представления
таких встроенных элементов, как таблицы и рисунки. Но они не используют
объекты для представления каждого символа, несмотря на то что это увеличило
бы гибкость на самых нижних уровнях приложения. Ведь тогда к рисованию и фор-
матированию символов и встроенных элементов можно былб бы применить еди-
нообразный подход. И для поддержки новых наборов символов не пришлось бы
как-либо затрагивать остальные функции редактора. Да и общая структура прило-
жения отражала бы физическую структуру документа. На следующей диаграмме
показано, как редактор документов мог бы воспользоваться объектами для пред-
ставления символов.

У такого дизайна есть один недостаток — стоимость. Даже в документе скром-
ных размеров было бы несколько сотен тысяч объектов-символов, а это привело
бы к расходованию огромного объема памяти и неприемлемым затратам во время
выполнения. Паттерн приспособленец показывает, как разделять очень мелкие
объекты без недопустимо высоких издержек.

А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?

Вот это Ваше утверждение "Я что-то не представляю сценарий, где для одного символа требуется объект класса" исходит не из того, что такого никогда не хотелось бы, а из того, что такое не применяется. Не Вам не требуется или не хочется, а это скорее всего будет просто недопустимо. Вы считаете, что этот самый flyweight выглядит не более сложным и не менее хуже читаемым и спопровождаемым, чем отдельный объект для каждого символа?

E>>Представьте, что надо реализовать какую-нибудь числодробилку. Ваша вера настолько сильна, что Вы рискнёте для представления числа использовать класс?
G>А что значит класс?
G>Например в C# сами числа являются наследниками Object, имеют методы и реализуют интерфейсы.

Класс — это значит уж точно не то, что представляют из себя примитивные типы с автоматическим боксингом в C#.
Кстати, это не с Вами мы разбирали тот пример с обходом plain-массива по индексам и обхода через интерфейс? Или я путаю?

G>Я надеюсь вы сами понимаете, что выдумываете что-то нереальное. не нужно создавать классы для символов и чисел, они уже есть и отлично работают.
G>А если каких-то абстракций нету в стандартной библиотеке, то я буду создавать классы.
G>Очень надеюсь что все программисты так поступют.

В каком смысле нереальное? Нереальное в плане затрат на реализацию? Так оно о том и речь. С тем, что скорее всего можно найти объектную декомпозицию, которая будет менее затратной по производительности, и более-менее "красивой", никто и не спорит. Но это никак не противоречит неверености вашего исходного утверждения о том, что все объектные декомпозиции имеют производительность одного порядка.

G>>>Для C++ — нет. Там надо думать о том как распределяется память под объекты.
E>>В каком смысле надо думать? Думать о том, когда и как память освободить? Ну тогда это утверждение выглядит бредово, с учётом предыдущего. "Производительность будет отличаться на порядки, потому что надо думать". Память выделяется и освобождается в обоих вариантах, но во втором варианте надо думать, чтобы её освободить, поэтому производительность будет хуже.
G>
G>Ниче не не понял.

Имелось в виду, что здесь очередной плевок в сторону С++ и unmanaged-языков был абсолютно не уместен, потому что здесь либо для обоих вариантов ответ да, либо для обоих нет.

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

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

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

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

E>>>>>Т. е. Вы утверждаете, что при правильно выбранном алгоритме независимо от объектной декомпозиции производительность будет одного порядка?
G>>>>Для систем с GC — да. Это и позволяет концентрироваться на алгоритме.

E>>>Представьте, что надо сделать текстовый редактор типа WYSIWYG. Ваша вера настолько сильна, что Вы рискнёте для представления одного символа использовать отдельный объект некоторого класса?
G>>А такое вообще может быть нужно? Я что-то не представляю сценарий, где для одного символа требуется объект класса.
G>>Если что есть паттерн flyweight, который как раз позволяет не создавать кучу однотипных объектов.

E>Вот WYSIWYG-редактор -- это как раз и есть сценарий, где для одного символа хотелось бы отдельный объект.
Я к сожалению или к счастью визивиги не писал, но не очень понимаю зачем иметь объекты на каждый символ.
Может вы объясните?

E>Наша беседа становится предсказуемой. Я знал, что сейчас Вы скажите про flyweight, а я скопирую описание сего паттерна из той известной книги.
E>Таки вот, копирую:
E>

поскипано

E>А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?
Какое отношение это имеет к теме разговора?

E>Вот это Ваше утверждение "Я что-то не представляю сценарий, где для одного символа требуется объект класса" исходит не из того, что такого никогда не хотелось бы, а из того, что такое не применяется. Не Вам не требуется или не хочется, а это скорее всего будет просто недопустимо. Вы считаете, что этот самый flyweight выглядит не более сложным и не менее хуже читаемым и спопровождаемым, чем отдельный объект для каждого символа?
Не понял что вы этим хотели сказать.
Давайте так: объясните зачем создавать какой-то класс, если уже существует подходящий тип в базовой библиотеке.

E>>>Представьте, что надо реализовать какую-нибудь числодробилку. Ваша вера настолько сильна, что Вы рискнёте для представления числа использовать класс?
G>>А что значит класс?
G>>Например в C# сами числа являются наследниками Object, имеют методы и реализуют интерфейсы.

E>Класс — это значит уж точно не то, что представляют из себя примитивные типы с автоматическим боксингом в C#.
Так что представляют из себя классы? Причем тут боксинг вообще?

E>Кстати, это не с Вами мы разбирали тот пример с обходом plain-массива по индексам и обхода через интерфейс? Или я путаю?
Не припоминаю, наверное не со мной.

G>>Я надеюсь вы сами понимаете, что выдумываете что-то нереальное. не нужно создавать классы для символов и чисел, они уже есть и отлично работают.
G>>А если каких-то абстракций нету в стандартной библиотеке, то я буду создавать классы.
G>>Очень надеюсь что все программисты так поступют.

E>В каком смысле нереальное? Нереальное в плане затрат на реализацию? Так оно о том и речь. С тем, что скорее всего можно найти объектную декомпозицию, которая будет менее затратной по производительности, и более-менее "красивой", никто и не спорит. Но это никак не противоречит неверености вашего исходного утверждения о том, что все объектные декомпозиции имеют производительность одного порядка.
Нет, вы придумываете ситуации, которые не встечаются в нормальных приложениях.
На выдуманых примерах можно вообще показать что угодно.

G>>>>Для C++ — нет. Там надо думать о том как распределяется память под объекты.
E>>>В каком смысле надо думать? Думать о том, когда и как память освободить? Ну тогда это утверждение выглядит бредово, с учётом предыдущего. "Производительность будет отличаться на порядки, потому что надо думать". Память выделяется и освобождается в обоих вариантах, но во втором варианте надо думать, чтобы её освободить, поэтому производительность будет хуже.
G>>
G>>Ниче не не понял.

E>Имелось в виду, что здесь очередной плевок в сторону С++ и unmanaged-языков был абсолютно не уместен, потому что здесь либо для обоих вариантов ответ да, либо для обоих нет.
Это надо еще доказать. Ваш пример с визивигом доказательство не является, потому что он явно надуманный и нифига не обощается. Далеко не во всех программах есть очень много одинаковых объектов.

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

NBN>Я когда пишу на С++ — просто выделяю память, и не занимаюсь её освобожденим — пока в этом нет необходимости.

Тут бы любителям GC и спросить, дескать, как это — "не занимаюсь её освобождением" (и памяти, и других ресурсов, и вообще не ресурсов) и без GC. И, получив ответ, обратиться в веру С++. Увы Вам.

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

E>>Вот WYSIWYG-редактор -- это как раз и есть сценарий, где для одного символа хотелось бы отдельный объект.
G>Я к сожалению или к счастью визивиги не писал, но не очень понимаю зачем иметь объекты на каждый символ.
G>Может вы объясните?

Документ состоит из абзацев. Абзац из "символов". Пока он состоит только из символов, всё просто. Когда в качестве "символа" может быть таблица, рисунок, формула, спецсимвол, объект OLE, что угодно, то сразу напрашивается сделать этот символ классом, а все вышеуказанные объекты сделать наследником этого класса, чтобы с ними можно было единообразно работать. Как уже было сказано тут возникают проблемы с накладными расходами, если представлять каждый символ в виде объекта. В качестве решения предлагается паттерн flyweight, в котором для одинаковых символов используется один и тот же объект. Но у разных одних и тех же символов могут быть разные атрибуты форматирования (шрифт, цвет). В предлагаемом паттерне эти атрибуты хранятся отдельно, и передаются при рисовании в качестве параметров методов. Но эти параметры нужны в основном только символам, таблицам и картинкам они уже не нужны! В результате получается, что такому объекту как картинка при рисовании требуется зачем-то передать шрифт и цвет, которые никак не используются. Разве Вам уже не кажется, что дизайн так себе? Лично мне уже кажется.

Вообще, у нас есть структура, в которой символ является минимальной единицей форматирования, т. е. форматирование может быть назначено каждому символу отдельно. Не логично ли при этом для каждого символа хранить форматирование, а так как оно используется только для символов, то перенести его в класс символа? Мне кажется это логичным. Да, это потребует больше памяти, потому что форматирование будет храниться посимвольно, а не интервалами. Лет 10 назад возможно это и не было бы приемлимо, но сейчас дополнительные 4 байта на символ мне не кажутся слишком большими расходами, если уж даже flyweight предполагает 4 байта на него. Т. е. с издержками на память можно как-то согласиться. Но ешё есть издержки на выделение/освобождение объекта для каждого символа, с которыми, по моему мнению (да и по Вашему как я понял) могут быть большие проблемы.

E>>Наша беседа становится предсказуемой. Я знал, что сейчас Вы скажите про flyweight, а я скопирую описание сего паттерна из той известной книги.
E>>Таки вот, копирую:
E>>

G>поскипано

E>>А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?
G>Какое отношение это имеет к теме разговора?

К какой из тем? Про независимость производительности от декомпозиции на объекты? Имеет такое, что есть декомпозиции, в которых издержки на выделение/освобождение объектов становятся недопустимыми. Какое отношение эта тема имеет к C#/C++? Ну давайте Вы уже скорее согласитесь с тем, что не все декомпозиции равноценны по производительности, и пойдём дальше?

E>>Вот это Ваше утверждение "Я что-то не представляю сценарий, где для одного символа требуется объект класса" исходит не из того, что такого никогда не хотелось бы, а из того, что такое не применяется. Не Вам не требуется или не хочется, а это скорее всего будет просто недопустимо. Вы считаете, что этот самый flyweight выглядит не более сложным и не менее хуже читаемым и спопровождаемым, чем отдельный объект для каждого символа?
G>Не понял что вы этим хотели сказать.
G>Давайте так: объясните зачем создавать какой-то класс, если уже существует подходящий тип в базовой библиотеке.

Чтобы сделать в нём виртуальный метод.

E>>Класс — это значит уж точно не то, что представляют из себя примитивные типы с автоматическим боксингом в C#.
G>Так что представляют из себя классы? Причем тут боксинг вообще?
E>>Кстати, это не с Вами мы разбирали тот пример с обходом plain-массива по индексам и обхода через интерфейс? Или я путаю?
G>Не припоминаю, наверное не со мной.

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

E>>В каком смысле нереальное? Нереальное в плане затрат на реализацию? Так оно о том и речь. С тем, что скорее всего можно найти объектную декомпозицию, которая будет менее затратной по производительности, и более-менее "красивой", никто и не спорит. Но это никак не противоречит неверености вашего исходного утверждения о том, что все объектные декомпозиции имеют производительность одного порядка.
G>Нет, вы придумываете ситуации, которые не встечаются в нормальных приложениях.
G>На выдуманых примерах можно вообще показать что угодно.

Выше написал про редактор.

G>>>>>Для C++ — нет. Там надо думать о том как распределяется память под объекты.
E>>>>В каком смысле надо думать? Думать о том, когда и как память освободить? Ну тогда это утверждение выглядит бредово, с учётом предыдущего. "Производительность будет отличаться на порядки, потому что надо думать". Память выделяется и освобождается в обоих вариантах, но во втором варианте надо думать, чтобы её освободить, поэтому производительность будет хуже.
G>>>
G>>>Ниче не не понял.

E>>Имелось в виду, что здесь очередной плевок в сторону С++ и unmanaged-языков был абсолютно не уместен, потому что здесь либо для обоих вариантов ответ да, либо для обоих нет.
G>Это надо еще доказать. Ваш пример с визивигом доказательство не является, потому что он явно надуманный и нифига не обощается. Далеко не во всех программах есть очень много одинаковых объектов.

Причём здесь пример с WYSIWYG? Причём здесь то, что "Далеко не во всех программах есть очень много одинаковых объектов"?
Что доказать? Что выделение/освобождение памяти является и там и там операцией довольно тяжеловесной примерно одного порядка? Вы издеваетесь что ли? Вы правда думаете, что выделение объекта в .net настолько быстрое, что на него можно не обращать внимание, а в С++ оно настолько медленнее, что там уже надо обращать внимание? Вы правда считаете, что при одинаковой объектной декомпозиции в C# и C++ затраты на работу с памятью в C# будут на порядок меньше?

Знаете, складывается такое ощущение, что Вы читаете текст моих постов только для того, чтобы хоть как-то аргументированно возразить, независимо от того, что я напишу, потому-что Вам кажется, что если Вы хоть с чем-то согласитесь, то это будет сразу же автоматически и неминуемо означать, что C# дерьмо, а С++ рулит.

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

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

E>>>Вот WYSIWYG-редактор -- это как раз и есть сценарий, где для одного символа хотелось бы отдельный объект.
G>>Я к сожалению или к счастью визивиги не писал, но не очень понимаю зачем иметь объекты на каждый символ.
G>>Может вы объясните?

E>Документ состоит из абзацев. Абзац из "символов". Пока он состоит только из символов, всё просто. Когда в качестве "символа" может быть таблица, рисунок, формула, спецсимвол, объект OLE, что угодно, то сразу напрашивается сделать этот символ классом, а все вышеуказанные объекты сделать наследником этого класса, чтобы с ними можно было единообразно работать. Как уже было сказано тут возникают проблемы с накладными расходами, если представлять каждый символ в виде объекта. В качестве решения предлагается паттерн flyweight, в котором для одинаковых символов используется один и тот же объект. Но у разных одних и тех же символов могут быть разные атрибуты форматирования (шрифт, цвет). В предлагаемом паттерне эти атрибуты хранятся отдельно, и передаются при рисовании в качестве параметров методов. Но эти параметры нужны в основном только символам, таблицам и картинкам они уже не нужны! В результате получается, что такому объекту как картинка при рисовании требуется зачем-то передать шрифт и цвет, которые никак не используются. Разве Вам уже не кажется, что дизайн так себе? Лично мне уже кажется.
И мне кажется.
Нафиг не нужны символы текста как отдельные объекты. Строк достаточно.
В таком случае сразу отпадает необходимость использовать flyweight.

E>Вообще, у нас есть структура, в которой символ является минимальной единицей форматирования, т. е. форматирование может быть назначено каждому символу отдельно. Не логично ли при этом для каждого символа хранить форматирование, а так как оно используется только для символов, то перенести его в класс символа? Мне кажется это логичным. Да, это потребует больше памяти, потому что форматирование будет храниться посимвольно, а не интервалами.
Если нужно форматирование посимвольно, то это правильно.
Но например в HTML такое не нужно, тем не менее работает.

E>Лет 10 назад возможно это и не было бы приемлимо, но сейчас дополнительные 4 байта на символ мне не кажутся слишком большими расходами, если уж даже flyweight предполагает 4 байта на него. Т. е. с издержками на память можно как-то согласиться. Но ешё есть издержки на выделение/освобождение объекта для каждого символа, с которыми, по моему мнению (да и по Вашему как я понял) могут быть большие проблемы.
Ну даже если вынести символы отдельно и использовать flyweight, то это никак не решит проблемы создания кучи мелких объектов для аттрибутов символа.

При создании объектов надо определиться с равенством объектов.
Паттерн flyweigth говорит нам что если создается много объектов, но при этом разных (в смысле равентсва) объектов не так много, то лучше не создавать объекты, а использовать идентичные (одни и теже) объекты, созданные заранее.

E>>>Имелось в виду, что здесь очередной плевок в сторону С++ и unmanaged-языков был абсолютно не уместен, потому что здесь либо для обоих вариантов ответ да, либо для обоих нет.
G>>Это надо еще доказать. Ваш пример с визивигом доказательство не является, потому что он явно надуманный и нифига не обощается. Далеко не во всех программах есть очень много одинаковых объектов.
E>
E>Причём здесь пример с WYSIWYG? Причём здесь то, что "Далеко не во всех программах есть очень много одинаковых объектов"?
E>Что доказать? Что выделение/освобождение памяти является и там и там операцией довольно тяжеловесной примерно одного порядка?
Это не так.

E>Вы издеваетесь что ли?
Нет

E>Вы правда думаете, что выделение объекта в .net настолько быстрое, что на него можно не обращать внимание,
Да, сдвиг указателя и все.

E>а в С++ оно настолько медленнее, что там уже надо обращать внимание?
С++ медленнее, но обращать внимание все равно не надо.

В C++ надо обращать внимание на сам факт освобождения или использовать что-то типа auto_ptr или shared_ptr, которые создают свой оверхед.

E>Вы правда считаете, что при одинаковой объектной декомпозиции в C# и C++ затраты на работу с памятью в C# будут на порядок меньше?
Она одинаковой не будет.

E>Знаете, складывается такое ощущение, что Вы читаете текст моих постов только для того, чтобы хоть как-то аргументированно возразить, независимо от того, что я напишу, потому-что Вам кажется, что если Вы хоть с чем-то согласитесь, то это будет сразу же автоматически и неминуемо означать, что C# дерьмо, а С++ рулит.
Мне кажется с точностью до наоборот.

e> Документ состоит из абзацев. Абзац из "символов".

все дальше поскипано. в тх ж GoF, если мне не изеняет память, описано как надо делать для сложного форатирования и т.п. Никому не нужно иметь на каждый символ по классу/экземпляру класса.

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

E>А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?
Меня всегда умиляла способность читать книгу и ничерта не понимать.
Ты не заметил, что паттерн позволяет заменить часть программы так, чтобы уменьшить накладные расходы до приемлемых?
При этом основным алгоритмам наплевать, один и тот же там объект или разные.
Это как раз пример того, что мы
а) сначала пишем систему так, как нам удобно — все алгоритмы (например, разбиения на строки и страницы) пишутся очевидным и красивым образом
б) при помощи профайлера выясняем источник проблемы
в) заменяем нехорошую часть алгоритма.
Например, для текстового редактора мы бы всего лишь изменили маленький фрагмент кода, тот, где фабрика Char-ов. Возможно, закомментировали бы метод Char.Equals (чтобы использовать дефолтный ReferenceEquals, который быстрее). И всё! Где тут "заранее проектировать с учетом быстродействия"?

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

CC>CPUID: Intel(R) Pentium(R) D CPU 2.66GHz
А вот на той же машине скорость аллокации через ThreadPoolAlloc, склепаный "по-быстрому, на коленке" интереса ради для проверки теории Тормозящей Синхронизации
Суть: отдельный пул на каждый поток с возможностью deferred delete из другого потока.

VS 2003 + ICC 11, C++ : 0 или 16 (видимо разрешения GetTickCount не хватает)

Заменил на вывод времени в секундах, замеренное через RDTSC

#include <CrayLib.h>
#include "threadpoolalloc.h"

int main()
{
    Duration timer;
    timer.Start();

    for(int i=0; i<1000000; i++)
    {        
        int* arr = (int*)ThreadPoolAlloc::Alloc (sizeof(int)*64);
        ThreadPoolAlloc::Free (arr);
    }

    timer.End();

    crprintf(L"%.15f\n", timer.GetSeconds());
    return 0;
}

В итоге:

ThreadPoolAlloc : 0.009060842642408 сек
new []/delete []: 0.198343848866225 сек

Exeшники для "побаловаться" брать тут: http://creatorcray.googlepages.com/testAlloc.rar (45Kb)

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

E>>А Вы считали зачем придумали этот паттерн? Чтобы было круто и все поняли, что авторы паттерна очень умные?
S>Меня всегда умиляла способность читать книгу и ничерта не понимать.
S>Ты не заметил, что паттерн позволяет заменить часть программы так, чтобы уменьшить накладные расходы до приемлемых?
S>При этом основным алгоритмам наплевать, один и тот же там объект или разные.
S>Это как раз пример того, что мы
S>а) сначала пишем систему так, как нам удобно — все алгоритмы (например, разбиения на строки и страницы) пишутся очевидным и красивым образом
S>б) при помощи профайлера выясняем источник проблемы
S>в) заменяем нехорошую часть алгоритма.
S>Например, для текстового редактора мы бы всего лишь изменили маленький фрагмент кода, тот, где фабрика Char-ов. Возможно, закомментировали бы метод Char.Equals (чтобы использовать дефолтный ReferenceEquals, который быстрее). И всё! Где тут "заранее проектировать с учетом быстродействия"?

Меня тоже много чего умиляет... Хочешь аналогию на примере парсинга XML-RPC пакетов (ну, оно мое родное и близкое)?

a) сначала пишем систему так, как нам удобно — все алгоритмы (например, парсинг XML, валидация и маппинг) пишутся очевидным и красивым образом. -- Используется XML ридер с DOM. По DOM делается валидация модели пакетов XML-RPC и маппинг на языковые типы.

б) при помощи профайлера выясняем источник проблемы. -- Им оказывается именно построение DOM (там и по памяти оверхед получаем и по перформансу).

в) заменяем нехорошую часть алгоритма. -- Выкидываем DOM и переписываем на SAX (при этом меняется весь алгоритм вообще)

S>И всё! Где тут "заранее проектировать с учетом быстродействия"?

И все! Приплыли. Выкинули весь парсинг, валидацию, маппинг и переписали. Лень было проектировать заранее.

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

G>Для C++ — нет. Там надо думать о том как распределяется память под объекты.
Только если профайлер тычет пальцем в распределение памяти под объекты. А такое обычно бывает если выделяется много мелких объектиков.

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

Посыпаю голову пеплом: забыл добавить еще один вызов (ThreadPoolAlloc::ExitThread()) в конце потока, чтоб грохнуло пул и уже точно всё было учтено

Теперь ThreadPoolAlloc : 0.009068380170764 сек

Exeшники обновил

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

H>И все! Приплыли. Выкинули весь парсинг, валидацию, маппинг и переписали. Лень было проектировать заранее.
Это оттого, что вы с самого начала писали маппинг плохим, неочевидным и неудобным способом.
Вы перемешали логику реализации с логикой задачи. Конечно вы в итоге огребли. Это стопроцентная гарантия.

А вот если бы у вас маппинг был описан декларативно (см. XmlRootAttribute, XmlElementAttribute, XmlAttributeAttribute и т.п.), то вы бы легко заменили DOM-based serializer на SAX-based serializer.

Аналогичные примеры приводят всякие умники про "изначальный выбор алгоритма сортировки" и прочую ботву. Их проблемы — ровно аналогичны. Зачем писать программы в настолько связанном стиле?
Все ведущие собаководы говорят: выражайте намерения, а не действия. Потому что действия изменчивы, а намерения стабильны.
Я приводил ссылку на блог Липперта. Один товарищ там Липперта обвинил в том, что тот дескать намеренно пессимизировал программу, чтобы легче было оптимизировать потом.
Нет, Липперт просто написал программу в максимально декларативном виде. Благодаря этому ему было легко подменить, к примеру, реализацию коллекции.

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

H>>И все! Приплыли. Выкинули весь парсинг, валидацию, маппинг и переписали. Лень было проектировать заранее.
S>Это оттого, что вы с самого начала писали маппинг плохим, неочевидным и неудобным способом.
S>Вы перемешали логику реализации с логикой задачи. Конечно вы в итоге огребли. Это стопроцентная гарантия.

S>А вот если бы у вас маппинг был описан декларативно (см. XmlRootAttribute, XmlElementAttribute, XmlAttributeAttribute и т.п.), то вы бы легко заменили DOM-based serializer на SAX-based serializer.

Слушай, ты по фотографии не лечишь? А то появляются у меня смутные подозрения... Ты понимаешь как отличается алгоритм при работе с DOM и SAX? Кардинально. Общности там вообще ни какой нет. Если в случае с DOM я могу делать маппинг с готовой модели, то используя SAX я вынужден маппинг и валидацию делать по ходу пьессы (кстати, речь идет о парсинге).

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

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

H>>>И все! Приплыли. Выкинули весь парсинг, валидацию, маппинг и переписали. Лень было проектировать заранее.
S>>Это оттого, что вы с самого начала писали маппинг плохим, неочевидным и неудобным способом.
S>>Вы перемешали логику реализации с логикой задачи. Конечно вы в итоге огребли. Это стопроцентная гарантия.

S>>А вот если бы у вас маппинг был описан декларативно (см. XmlRootAttribute, XmlElementAttribute, XmlAttributeAttribute и т.п.), то вы бы легко заменили DOM-based serializer на SAX-based serializer.

H>Слушай, ты по фотографии не лечишь? А то появляются у меня смутные подозрения... Ты понимаешь как отличается алгоритм при работе с DOM и SAX? Кардинально. Общности там вообще ни какой нет. Если в случае с DOM я могу делать маппинг с готовой модели, то используя SAX я вынужден маппинг и валидацию делать по ходу пьессы (кстати, речь идет о парсинге).

А с чего ты взял что DOM гораздо удобнее для этой задачи?
Традиционно входящими данными для парсера явяляется поток лексем. В вашем случае интерфейс, представляющий XML как поток лексем — StAX.