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

S>>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои.
BBI>Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"?
Что именно? Да хоть вот этот топик прочитать.
BBI>Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры.
То есть в четырёх из четырёх проектов, рассмотренных в этом топике? М-м.

BBI>Жуткий говнокод есть и на дотнете, не волнуйся.
BBI>Особенно когда пишут индусы и проект в финансовой сфере.
Не волнуюсь. Я про код на дотнете ничего особенного не говорю.
Я говорю о том, что все рассказы про легкодостижимость высокого качества на С++ являются, мягко говоря, преувеличением.
BBI>Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша.
Если хотите ужасов, откройте исходники любого проекта, разработанного в институте. Ну там — анализ сейсмограмм, или общёт экспериментов. Только не забудьте взять тазик и резиновые сапоги.
BBI>Что говорит о том, что это не С++ а С с классами.
Ну так куда ни плюнь — везде С++ с классами.
Надо полагать, остальные фичи плюсов требуют недоступной на рынке квалификации.
BBI>К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API.
Я не в курсе. Я честно гуглил в поиске проектов.

BBI>Не знаю кто тебе рассказывал. Я сам reinterpret_cast и ему подобные не люблю — громоздко а бонусов никаких.
Не будем показывать пальцем, но это был Геннадий Васильев.

BBI>Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ".
Я об этом и говорю.

BBI>Нормально написанных Opensource проектов — единицы.
Давайте в студию хотя бы один этот опенсорс проект.
BBI>В основном вот такая вот жуть.
А знаете, почему? Потому, что опенсорс-проекты представляют срез комьюнити. Там точно так же, как и в любом другом проекте, есть несколько сильных программистов (иначе проект вообще не взлетит). А средний уровень в индустрии — именно такой, какой вы видите в опен-соурсе.

BBI>Ты ищешь нормальный код там, где его отродясь не было.
Вы имеете в виду — в С++?
BBI>Реальный мир не состоит из одного опенсурса.
Я в курсе. По моему опыту, в среднем всё ещё хуже.

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

T>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно! На каждую аллокацию для объекта получаем еще одну аллокацию для счетчика. В результате нагрузка на и так тормозной менеджер памяти увеличивается в два раза. А какой размер такого счетчика ссылок? 4 байта? Только для этих 4 байтов в стандартной виндосовой куче будет выделено 16. И спрашивается, на кой черт это надо, не проще ли сразу .NET использовать, а на С++ писать только куски, на которые и умного указателя жалко?

http://www.boost.org/doc/libs/1_42_0/libs/smart_ptr/make_shared.html

Здравствуйте, Banned by IT, Вы писали:
S>>Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей.
BBI>У тебя что, отсутствие указателей это признак качества кода?
Отсутствие голых указателей и храбрых вызовов strcpy — да.

BBI>Неужто вообще весь код просмотрел?
Нет, потыкался наугад. У меня ещё и работа есть, вообще-то.
BBI>Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод.
Можно, я буду это цитировать в будущих спорах с плюсистами?

S>>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
BBI>Operator new может быть перекрыт глобально.
Не смешите мои тапочки. Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами. Этот аллокатор не может себе позволить иметь нетривиальный delete.
А аллокатор с вырожденным delete не удастся использовать глобально.

BBI>И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен.

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

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

T>>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно! На каждую аллокацию для объекта получаем еще одну аллокацию для счетчика. В результате нагрузка на и так тормозной менеджер памяти увеличивается в два раза. А какой размер такого счетчика ссылок? 4 байта? Только для этих 4 байтов в стандартной виндосовой куче будет выделено 16. И спрашивается, на кой черт это надо, не проще ли сразу .NET использовать, а на С++ писать только куски, на которые и умного указателя жалко?

FR>http://www.boost.org/doc/libs/1_42_0/libs/smart_ptr/make_shared.html

Не всегда применимо.

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

V>>И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное.
G>Если не ошибаюсь то для этого нужна debug сборка, которая сводит на нет все преимущества C++.
Ошибаешься.

T>>>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
V>>Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
G>Прикол весь в том что AV возникает не там где находится ошибка, что значительно усложняет отладку. Кроме того пропустить на тестировании outofrange и nre довольно сложно.
В 99% случаях — именно там где накосячено.
Расстрелы памяти кстати тоже ловятся достаточно просто. Мест где пишется что то в память напрямую обычно немного.

T>>>2) Наличие коллстеков у всех исключений.
V>>Помогает только для примитивных ошибок, и доступно для С++ тоже.
G>Ага, но только в дебаг версии.
Что, в release стек не используется что ли?
Несколько сложнее его раскручивать но тем не менее оно есть.

G>Использование только safe части C++ делает программу не быстрее (а зачастую и медленнее) чем .NET
Facepalm.

V>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII
G>Которым далеко не все пользуются
Все вменяемые — пользуются.

V>>что совершенно невозможно в дотнете
G>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1.
Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный.

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

T>Давай лучше рассмотрим умный указатель со счетчиком ссылок.
T>Где этот счетчик надо хранить? В хипе?
Гы, неа
Не, ну можно конечно и в хипе, как тебе больше хочется.
Но вариантов на самом деле куда больше.
Домашнее задание: подумать самому о менее брутфорсных вариантах решения.

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

ГВ>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев.
Это синдром VladD2

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

S>А в реальности закрытый С++ код, который я видел, в среднем намного хуже того Open-source, который вроде написан непонятно кем.
Я в реальности видел C# код насколько кошмарный, что ни один говнокод на С или С++ что я видел с ним не сравнится.
И чо?

S>Всё как раз наоборот: начинаются какие-то наезды на управляемый код
Дааа. Канеееешна. Особенно два самых заядлых .net ненавистника стараются: икемфула и ганжустас.

S>Зато с другой стороны идут какие-то постоянные намёки на некомпетентность С#-девелоперов.
В общем то под подобными заявлениями есть некоторые реальные тенденции. Не в том плане что C# девелоперы тупеют, нет. Просто в силу того что на managed куда более тупорылые ошибки прощаются туда постепенно стекает всякий некондиционный кодер, ухудшая карму среднестатического managed прогера.

S>Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
С достоинствами оно всегда так. Это и для C# верно.
Одним и тем же инструментом один сделает из куска мрамора статую, другой — кучу мусора.

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

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

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

T>>Давай лучше рассмотрим умный указатель со счетчиком ссылок.
T>>Где этот счетчик надо хранить? В хипе?
BBI>Гы, неа
BBI>Не, ну можно конечно и в хипе, как тебе больше хочется.
BBI>Но вариантов на самом деле куда больше.
BBI>Домашнее задание: подумать самому о менее брутфорсных вариантах решения.

То есть мне надо еще самому смартпоинтеры себе писать?

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


BBI>>Operator new может быть перекрыт глобально.
S>Не смешите мои тапочки. Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами. Этот аллокатор не может себе позволить иметь нетривиальный delete.
S>А аллокатор с вырожденным delete не удастся использовать глобально.

Вопрос а нужен ли в большинстве случаев (учитывая RAII) такой аллокатор в C++?

BBI>>И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен.
S>

Ну на примере того же хрома тут http://src.chromium.org/viewvc/chrome/trunk/src/base/memory/
видно что применяется вполне, пусть и не в виде std::allocator/

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

T>Тоже мне, умный указатель нашел std::auto_ptr

Самый что ни на есть умный, автоматизирующий реализацию технологии RAII.


T>Давай лучше рассмотрим умный указатель со счетчиком ссылок. Где этот счетчик надо хранить? В хипе? Прекрасно!

Есть так же intrusive хранение счетчика. Аналогично, как intrusive linked list всяко получше такого linked list, где целевые объекты дополнительно по ссылке из узлов хранятся, как в дотнете. В общем, поинт номер один в том, что оптимизировать всё подряд вовсе не надо, но если надо... то поинт номер два в том, что С++ дает всяко больше таких возможностей относительно дешево (из-за повторяемости решений через шаблоны и отсутствия ограничений value/ref типов), причем, абсолютно в типобезопасном виде, вовсе не надо жонглировать никакими битами и напрасной реинтепретацией памяти. Хотя, самые эффективные биржевые протоколы как раз описаны в терминах С (напр. NASDAQ OMX) и полностью сидят на реинтепретации памяти, экономя на десериализации байт, т.е. входящие пакеты можно просто приводить к некому типу данных, согласно фиксированного заголовка. Там, где время отклика должно составлять единицы микросекунд (десятки наносекунд на каждый элемент внутри сообщения, с учетом всей прикладной логики), это оправдано. Но ключевое опять же в том, что это С-АПИ, а не С++. Для С++ пишут типизированные и безопасные обертки над этим С-АПИ, которые, что характерно, ничего не стоят в рантайм.

Возвращаясь к бедному shred_ptr. Его можно использовать как первое приближение при реализации прототипа. Потом, когда собственная программа станет самому более понятна, и будут обкатаны все сценарии, будет хорошо видно в конечном наборе сущностей, кто кем и когда владеет, и в большей части кода shared_ptr может уйти совсем (как раз недавно занимался увеличением эффективности одного продукта, заменяя shared_ptr в т.ч.), или когда его можно переделать на intrusive, если уж критично в этом месте к быстродействию, но налицо именно совместное владение объектом из разных потоков с недетерминированным временем жизни самих этих потоков.

Если проводить аналогии с дотнетом, то shared_ptr хорош там, где объекты создаются относительно редко, и потом долго используются, т.е. те, которые в дотнете пойдут во 2-е поколение. А то, что в дотнете не переживает первой сборки, обычно в программе на С++ не требует памяти из кучи вообще, т.е. не требует никаких shared_ptr ввиду отсутствия ограничений на место расположения объектов. Т.е. можно на стеке создать временный объект, либо другой экземпляр того же типа на куче, если этот экземпляр будет долгоживущий. Есть выбор, вот что удобно.

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

T>То есть мне надо еще самому смартпоинтеры себе писать?

Всё уже давно есть: http://www.boost.org/doc/libs/1_48_0/libs/smart_ptr/intrusive_ptr.html

Объекты С++ собираются на подобных шаблонных хелперах как из кубиков LEGO, оставляя пространство разработчику для выбора кучи стратегий, прописывая текущие зависимости через typedef, давая возможность кардинально все менять, не трогая зависимый код. В C# иногда просто ломка, когда приходится разрабатывать что-то за рамками использования стандартной библиотеки, бо ручного труда навскидку в 2-3 раза больше. Из-за ограничений технологии генериков в т.ч. Хорошо понимаю немерлистов, когда они описывают похожий эффект.

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

V>>>всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII
G>>Которым далеко не все пользуются
BBI>Все вменяемые — пользуются.

Таких сильно меньше чем вменяемых программистов на .NET
Достаточно посмотреть opensource.

V>>>что совершенно невозможно в дотнете
G>>Поправочка: не нужно, там массив таскает с собой размер. А умный jit выкидывает проверки границ для циклов от нуля до length-1.
BBI>Тут уже приводили неподалёку замеры где оказалось что jit не такой уж и умный.


Микротесты на массивах чтоли? А толку от них?

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

S>>>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои.
BBI>>Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"?
S>Что именно? Да хоть вот этот топик прочитать.
Тут плюсистов по пальцам пересчитать можно.

BBI>>Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры.
S>То есть в четырёх из четырёх проектов, рассмотренных в этом топике? М-м.
Тебе уже привели тот же хром в пример.

BBI>>Жуткий говнокод есть и на дотнете, не волнуйся.
BBI>>Особенно когда пишут индусы и проект в финансовой сфере.
S>Не волнуюсь. Я про код на дотнете ничего особенного не говорю.
S>Я говорю о том, что все рассказы про легкодостижимость высокого качества на С++ являются, мягко говоря, преувеличением.
Где, где ты увидел что высокое качество легкодостижимо?

BBI>>Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша.
S>Если хотите ужасов, откройте исходники любого проекта, разработанного в институте. Ну там — анализ сейсмограмм, или общёт экспериментов. Только не забудьте взять тазик и резиновые сапоги.
Не, ну там вообще за пределами бобра и козла.

BBI>>Что говорит о том, что это не С++ а С с классами.
S>Ну так куда ни плюнь — везде С++ с классами.
Нухз, может ты плюёшь куда то не туда. У меня на расстоянии плевка есть проекты которые без поддержки C++0x просто не соберутся, т.к. используют фичи языка.

S>Надо полагать, остальные фичи плюсов требуют недоступной на рынке квалификации.
Ну берём же мы откуда то квалифицированных людей.

BBI>>К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API.
S>Я не в курсе. Я честно гуглил в поиске проектов.
Я просто код history почитал.

BBI>>Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ".
S>Я об этом и говорю.
Ты говорил "О да, последнее явно говорит о собственном аллокаторе.". Абы потроллить, не подумав зачем так было там сделано.

BBI>>Нормально написанных Opensource проектов — единицы.
S>Давайте в студию хотя бы один этот опенсорс проект.

BBI>>В основном вот такая вот жуть.
S>А знаете, почему? Потому, что опенсорс-проекты представляют срез комьюнити.
Какого именно комьюнити?
Из известных мне сильных разработчиков никто не тратит время на опенсурс.

S> Там точно так же, как и в любом другом проекте, есть несколько сильных программистов (иначе проект вообще не взлетит). А средний уровень в индустрии — именно такой, какой вы видите в опен-соурсе.
А средний уровень managed разработчиков тогда выходит это та самая масса говнокодеров, которые приползли туда с почившего вижуалбасика и прочего индусского стаффа, 5 копеек пучок?

BBI>>Ты ищешь нормальный код там, где его отродясь не было.
S>Вы имеете в виду — в С++?
Я имею в виду опенсурс.

BBI>>Реальный мир не состоит из одного опенсурса.
S>Я в курсе. По моему опыту, в среднем всё ещё хуже.
А средняя температура по больнице 36.6.
И чо?

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

S>Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.

Не вижу здесь чего-то удивительного. Разработчик с 3-х летним опытом всяко должен отличаться от разработчика с опытом в год. Как раз, по моим наблюдениям, в хорошей среде программист С++ за примерно 3 года овладевает всеми обсуждаемыми приемами на уровне мозжечка. А если учесть, что средний стаж программистов в наше время поболе 5-ти лет, я вообще не вижу проблем.

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

Ваньке на печке тоже много чего хотелось, но чудес не бывает. Уже есть неоднократные случаи, когда дотнетные приложения опять переписывали на нейтив. И не только из-за WPF. Примерные потери на такие "эксперименты" можешь прикинуть сам...

У дотнетных приложений есть своя ниша, где эффективность не важна. Утилиты какие-нить, всякие SOAP-сервисы, генерация HTML и прочее из той же оперы... ИМХО, споры возникают по причине неправильного позиционирования дотнета. Как только обсуждающие сходятся на том, что каждому инструменту своя ниша, так споры утихают сами собой.

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

I>Сейчас вдобавок ко всему сказывается сильный спад в образовании, так что сильно кажется точка невозврата в С++ уже давно пройдена. Нативная разработка может и будет набирать обороты, но это точно будет не олдскульный С++, а чтото более гуманное и безопасное.

Если убрать из стандарта C++ приведение в стиле С, то этого было бы достаточно. Никак не могут пойти на этот важный шаг, бо сломается туева хуча программ. Но результат, ИМХО, того стоит, бо всякие reinterpret_cast видны, т.е. не представляют из себя тех самых "незаметных мин" в коде... а во всех остальных местах код будет несильно уступать Хаскелю по типобезопасности.

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


I>Прикол в том, что средний программист уже не способен писать на С++. Вот это действительно прикол. А если учесть, что на менеджед пишется примерно 99% всех проектов, то это да, большой прикол.

Мде? А я вижу, что практически все популярные программы на нейтив, даже которые опенсорсные. Допускаю, что окружающие тебя 99% коллег пишут на дотнете, это лишь значит, что у тебя такая выборка. Попробуй на досуге набрать в гугле "новости софта", или зайти на любой пиратский торрент и посмотреть в топах, что народ качает. Дотнет там оч редко, только в утилитах каких-нить, администраторских.

Подозреваю, что дотнет цветет и пахнет на рынке заказных программ. Я тоже грешен, делал много подобных халявок, пока не надоело. (Вернее, пока окончательно не разочаровался дотнете, т.к. свою собственную задумку так и не смог на нем заставить работать с нужной отдачей, и рост производительности железа в пересчете на ядро, уже совсем не тот, что раньше). Но это же масштабы разработок не те, напр. такое для одной известной конторки: http://files.rsdn.ru/21096/ss1.PNG
Хотя в рамках проекта был писан полноценный дотнетный ActiveX-host для out of proc COM-серверов, типа офисных приложений (см на вкладки и кнопки на форме с объектом ворда), и всевозможные реализации IPersistentStorage к ним, но это всё-равно несравнимо с реальными проектами... просто на уровне хобби, "посчупать там", "подергать здесь", скуки ради...

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

S>Рекомендую сналчала поинтересоваться об источнике этой информации

Тьфу, блин! Так это Plutonia переименовался... В бытность плюсовиком его слог был дружелюбнее гораздо... вот до чего дотнет разработчиков доводит! Никакой антирекламы не надо.

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

CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap.
CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.
Мне требуется ликбез. Что в данном случае входит в понятие DOM? Я провел небольшой тест

Автор: MxMsk
Дата: 21.11.11

, по которому получается, что само чтение XAML-а, загрузка его контента, превращение стилей и шаблонов в описательные .Net объекты — вещь достаточно быстрая, плюс вовсю используется отоложенная загрузка по требованию. Однако, построение визуального дерева контролов уже затратная операция. Так вот, DOM — это загруженный описательный контент XAML или сформированное визуальное дерево контролов?

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

T>>>Давай лучше рассмотрим умный указатель со счетчиком ссылок.
T>>>Где этот счетчик надо хранить? В хипе?
BBI>>Гы, неа
BBI>>Не, ну можно конечно и в хипе, как тебе больше хочется.
BBI>>Но вариантов на самом деле куда больше.
BBI>>Домашнее задание: подумать самому о менее брутфорсных вариантах решения.

T>То есть мне надо еще самому смартпоинтеры себе писать?

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