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

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

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

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

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

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

Хоть бы ключик отключающий ввели в массовые компиляторы.
Хотя лучше конечно как в D http://www.d-programming-language.org/safed.html выделить безопасное подмножество языка.

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

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

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

"Если лепить смартпоинтеры везде, не думая, то легко можно получить всё тот же говнокод." (С)

S>>>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
BBI>>Operator new может быть перекрыт глобально.
S>Не смешите мои тапочки.
А что смешного. Ты утверждаешь что раз используется new то значит нету никакого кастомного аллокатора. Что неверно.

S>Мы обсуждаем гипотетический аллокатор, который может порвать дотнетный GC на задачах с короткоживущими объектами.
Такой аллокатор уже порвал .NET GC где то в недрах КСВ.

S> Этот аллокатор не может себе позволить иметь нетривиальный delete.
Может. Почему нет.
Самый простой пример:

void ThreadPoolAlloc::Free (const void* ptr)
{
    if (!ptr)
        return;

    BlockHeader* hdr = (BlockHeader*)ptr - 1;
    if (hdr->m_poolNum != ~0)
    {
        Context *context = m_context;

        if ((context) && (hdr->m_context == context))
            context->AttachBlock (hdr, hdr->m_poolNum);
        else hdr->m_context->DeferredFree (hdr);
    }
    else HeapFree (GetProcessHeap(), 0, hdr);
}

...

    void AttachBlock (void* ptr, uint poolNum)
    {
        BlockHeader* newBlock = (BlockHeader*)ptr;
        BlockHeader* freeListHead = m_freeBlocks[poolNum];

        newBlock->m_next = freeListHead;
        m_freeBlocks[poolNum] = newBlock;
    }

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

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

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

Микротесты ничего не доказывают так как по их результатам нельзя судить о более сложном коде.

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

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

Ошибаешься, если генерить только Program database (что достаточно для этого сценария), то оно не ограничивает возможность полной оптимизации. Ну пропадут у тебя некоторые локальные переменные, ну будут пропуски в стек-трейсе... Дык, в дотнете аналогично, при инлайне методов, как бы "скипается" частично исходный стек-трейс. Все равно видно, куда копать, т.е. область поиска резко сужается.


V>>А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек. Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
G>Да, только наведенных ошибок в managed коде почти нет или легко отлавливаются при тестировании, а в unmanaged их полно.

Заблуждение. Если бы отлавливались при тестировании, их бы не было. А по факту на сегодня я не видел еще ни одной достаточно большой дотнетной неглюкавой программы. Хреново в дотнете со статикой-то, а в динамике не всё поймаешь, бесконечным и дейтсвительно всеобъемлющим тестирование не бывает, это миф, бо такое тестирование на пару порядков обойдется дороже собственно разработки.

T>>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме.
V>>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
G>Стектрейс, хотя для nre в продакшене надо сильно постараться

Не льсти себе. Тебя послушать как в дотнете, то "надо просто контрактами обложить", а как в С++, то "обязательно нарушат контракт". Эдак можно много до чего договориться.

По моим наблюдениям за глюкавостью дотнетных программ, они ловятся на совершенно детских тестах: например часто при попытке сохранить файл в директорию, защищенную от записи или почти в 100% случаев, при исчерпании какого-нить ресурса (кол-ва сокетов, поверхностей для рисования, свободного места на диске). Такое ощущение, что дотнетчики поголовно пишут код из расчета "всё будет хорошо", проверяя максимум контракты на входные параметры методов, во всех остальных случаях тупо плюя эксепшен, который (удивительно!) никто нигде не ждет. Понятие безопасного к исключениям кода — это нечто из другой реальности, отсюда дотнет — просто рассадник наведенных ошибок (по опыту своей помощи в ловле ошибок коллег), бо после первой же обработанной (якобы обработанной) ошибочной ситуации, отваливается работоспособность в другом месте, потому как один или несколько объектов остаются в некоем промежуточном невалидном состоянии. И хоть подобные ошибки от платформы не зависят, но почему-то дотнетные программы болеют ими чаще, по моим сугубо личным наблюдениям. Да, "вы" правы, на плюсах в среднем приходится быть малость внимательней, чем на дотнете, но зато типичных детских ошибок вижу всяко поменьше. ИМХО, от рабочего настроя тоже кое-что зависит. А в дотнет диктует некий расслабон (даже по собственным ощущениям, в сравнении с писаниной на плюсах).


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

Не только.

V>>Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что...
G>Вот только по-умолчанию C# рождает safe код, а unsafe без необходимости даже не ошибка, а вредительство. С++ имеет тяжелое наследие C и не наказывает за попытки писать в стиле С, то есть любой код по умолчанию — unsafe.

А как меня наказвают за исопльзование unsafe в дотнете, не пояснишь? И почему хак типов в стиле C есть на твой взгляд "нормально"?


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

Стоило бы просить обосновать, но вряд ли справишься. По моим наблюдениям — ровно наоборот, чем больше типизированной информации у компилятора, тем агрессивнее оптимизация. И да, safe С++ не означает только библиотеки STL. Это просто типизированный подход, например, набивший оскомину выход за пределы массива на стеке, стиле С это так:

void doSomething(char * array, size_t size);

char array[N];
doSomething(array, sizeof(array)); // вот здесь могут подать не тот sizeof в результате многих актов рефакторинга

В С++ стиле это будет так:

<size_t size>
void doSomething(char (&array)[size]);

char array[N];
doSomething(array); // теперь типобезопасно

V>>Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки
G>Ага, только они очень часто встречаются в unmanaged.

В сравнении с остальными ошибками, в т.ч. логическими — не видно и под микроскопом. Какая разница, падает программа или неверно работает? Лажа в обоих случаях.


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

Ну я же говорил.
Рассуждая так, и контракты в C# мало кто проверяет, это же прямо такое "хакерство" (С).


V>>и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии
G>Ну это когда размер известен на этапе компиляции.

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


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

Это если мы по всему массиву итерируем, а если нет, то лишней проверки не избежать. Уже обсуждали 4 года назад.


V>>Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак.
G>v.end()++ не?

Не. Кто мешает мне компилируемую бредятину и на C# писать с тем же успехом?
Чем не коровья лепешка?

int SomeProp { 
  get { return _someProp; } 
  
  set {
    _somePtrop = value;

    if((new Random()).Next() < 0.5)
      onSomePropChanged(this, EmptryArgs.Value);
  }
}

Ничуть не хуже твоей.

V>>Это надо С++ использовать как голый С, для получения наиболее обсуждаемого здесь эффекта, ну так давай и сравнивать голый С с дотнетом, при чем здесь С++?
G>Весь прикол в том что С++ унаследовал все проблемы C и никто тебе не запрещает использовать небезопасный код. А если использовать только безопасный, то C++ начинает сосать.

Дважды повторился, жду обоснований с примерами. В общем, в таком стиле это натуральный flame, так что за качество ответов на твои посты не обессудь.

G>Кроме того даже если ты напишешь safe код, то менее грамотный коллега напишет unsafe, который заставит твой код работать неправильно.

Менее грамотный, это год работы. Кто ж ему даст весь код трогать? В любом проекте при хоть какой-то организации полно изолированных мест, где могут разгуляться разработчики любого уровня. Ну и code review определенно рулит.

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

G>Микротесты ничего не доказывают так как по их результатам нельзя судить о более сложном коде.
Как раз в тестах с генерацией кода fail в микротесте достаточно наглядно показывает что оптимизация не работает.

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

V>В С++ стиле это будет так:
V>

V><size_t size>
V>void doSomething(char (&array)[size]);

V>char array[N];
V>doSomething(array); // теперь типобезопасно
V>

А как с массивами, чей размер определяется в процессе выполнения? switch

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


V>>И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему.
T>А кто тебя заставляет это делать?

Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы.


V>>А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого. И какая разница, почему программа упала, из-за изолированной ошибки или нет? Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range.
T>Ну если ты согласился, то и спорить не о чем

Дык, это не тот класс ошибок, который действительно напрягает.


T>Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие!

Если не пользовать механизмы исключений как способ организации логики программы, то до фени быстродействие абсолютно, если уж произошла исключительная ситуация. Не зря C++ потоки не бросают исключений при открытии файла, это нормальная логика, по которой надо всегда делать if, бо там вероятность этой т.н. "исключительной ситуации" чуть ли не 50%. Как раз тут упомянул про эти детские ошибки, наблюдаемые в дотнетных программах: http://www.rsdn.ru/forum/philosophy/4505981.1.aspx

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

T>А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?

На этапе беты — да, а что?
В клинических случаях даже для релизных продуктов шлем клиентам PDB, просим положить рядом и воспроизвести.


V>>Помогает только для примитивных ошибок, и доступно для С++ тоже.
T>Примитивных ошибок большинство и суммарное время, потраченное на их исправление довольно большое.

Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки". И как-то всегда забываете, что далеко не всё может быть поймано во время тестирования, т.е. у клиентов все-равно программы выкидывают ошибку на дотнете аж бегом. А теперь, внимание, что на дотнете мы заплатку слали на следующий день, после баг-репорта (с учетом всех процедур и повторного тестирования), что на С++ аналогично. С т.з. клиента пох глубоко. В общих процедурах по обслуживанию бага, собвственно его поиск и исправление — это капля в море. Ну не 1 мин это заняло, а пол-часа, и что? У клиента баг уже произошел, осадочек остался...

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

T>Совсем необязательно что-то там хачить. Достаточно воспользоваться указателем на удаленный блок памяти.

Тю, блин, а я то думал... Для этого надо следить за ресурсами в стиле голого С. Начинаем шарманку сначала, или остановимся?

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

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

V>>В С++ стиле это будет так:
...
S>А как с массивами, чей размер определяется в процессе выполнения? switch

Там же:

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

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

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

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

S>>А как с массивами, чей размер определяется в процессе выполнения? switch

V>Там же:
V>

V>Дык, а в других случаях самописанина ничего не дает в сравнении со стандартными контейнерами. Да и эскалацию привилегий ты при проходе по куче не получишь (по стеку надо идти, чтобы передать куда надо управление в текущем кольце), т.е. не получится той самой дырки в безопасности и обсуждать сразу нечего.

V>На всяк случай расшифровываю: для случая динамических массивов, т.е. хранящих свое тело на куче, самописные контейнеры будут не лучше уже имеющихся безопасных реализаций из стандартной библиотеки, которые, в свою очередь, безопаснее всего использовать через предоставляемые ими же итераторы.
Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.

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

FR>Хоть бы ключик отключающий ввели в массовые компиляторы.
FR>Хотя лучше конечно как в D http://www.d-programming-language.org/safed.html выделить безопасное подмножество языка.

А че-то D совсем притих... Никто там его покупать не собирается, случайно?

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


S>Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.

А кто мешает сделать "точку входа" для любого типа-контейнера, отвечающего стандартам STL?

template<TContainer>
inline void doSomething(TContainer & container)
{
  if(size_t size = container.size())
    doSomething(&container.at(0), size);
}

Это один из примеров насчет того, что типобезопасность времени компиляции дается относительно дешево на шаблонах. Т.е. вместо повторения каждый раз одного и того же критичного кода (в данном случае, проверка размера перед вызовом at(0)), можно сделать самотипизируемую точку входа однократно.

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

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


S>>Все же непонятно, почему DoSomething для массива статического размера надо писать этак, а для динамического — с помощью стандартных контейнеров? На всякий, я не предлагаю писать самописный контейнер. Речь все еще идет о неком функционале DoSomething.

V>А кто мешает сделать "точку входа" для любого типа-контейнера, отвечающего стандартам STL?
V>

V>template<TContainer>
V>inline void doSomething(TContainer & container)
V>{
V>  if(size_t size = container.size())
V>    doSomething(&container.at(0), size);
V>}
V>

V>Это один из примеров насчет того, что типобезопасность времени компиляции дается относительно дешево на шаблонах. Т.е. вместо повторения каждый раз одного и того же критичного кода (в данном случае, проверка размера перед вызовом at(0)), можно сделать самотипизируемую точку входа однократно.

Отлично, но ведь такую точку входа не подружить с

<size_t size>
void doSomething(char (&array)[size]);

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

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

T>>А кто тебя заставляет это делать?
V>Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы.
Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.

V>Дык, это не тот класс ошибок, который действительно напрягает.
Ну это кого как. Меня уже достало искать подобные ошибки в С++ коде.

T>>Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие!

V>Если не пользовать механизмы исключений как способ организации логики программы, то до фени быстродействие абсолютно, если уж произошла исключительная ситуация.
Это отдельная флеймовая тема: и что такое исключительная ситуация, и как отличить исключительную ситуацию от неисключительной и про то, что исключительная ситуация с точки зрения одного кода может быть неисключительной с точки зрения другого, и, наконец, про то, что по мнению многих плюсовиков коды возврата — это прошлый век и тонны ифов.

Но в любом случае ваше решение очень ограниченно по следующим причинам:
1) Надо распространять pdb
2) Надо модифицировать код, бросающий исключения, а это не всегда возможно.
3) Можно получить очень сильную просадку производительности на ровном месте.

T>>А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?

V>На этапе беты — да, а что?
V>В клинических случаях даже для релизных продуктов шлем клиентам PDB, просим положить рядом и воспроизвести.

А в чем смысл? Если уж клиент согласен и в состоянии воспроизвести (что далеко не всегда так), то почему бы тогда полный дамп не сгенерировать?

V>>>Помогает только для примитивных ошибок, и доступно для С++ тоже.
T>>Примитивных ошибок большинство и суммарное время, потраченное на их исправление довольно большое.

V>Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки".
Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов. Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!


V>И я опять утверждаю, что дотнетные программы чаще плюют баги у клиентов, чем плюсовые, по итогам наблюдений за 8 лет.
Я этого почему-то не наблюдаю.

V>И как общую картину исправит тот факт, что на стороне разработчика этот баг потом проще найти?
Повлияет тем, что можно набрать больше тестировщиков благодаря тому, что программисты быстрее исправляют ошибки. В результате больше ошибок будет найдено и исправлено во время тестирования. У нас, например, тестировщиков больше, чем программистов. Если бы не С++ код, то пропорцию можно было бы еще увеличить.

V>Не принципиально абсолютно. Да и не помню я, чтобы сложные в поиске баги, т.е. занявшие хотя бы пол-дня на поиски, выскакивали чаще, чем раз в несколько лет.

Да, кстати. Мы тут недавно Critical Fix выпускали. Buffer overrun в одном из umanaged компонентов. Но, как мне тут объяснили, таких ошибок в реальной жизни не бывает. Значит мне это все приснилось

T>>Совсем необязательно что-то там хачить. Достаточно воспользоваться указателем на удаленный блок памяти.
V>Тю, блин, а я то думал... Для этого надо следить за ресурсами в стиле голого С. Начинаем шарманку сначала, или остановимся?
Совсем не обязательно. Достаточно сделать грамотную и продуманную политику управления времени жизни объектов и в соответствии с этой политикой для обеспечения энергоэффективности передать куда-нибудь объект по константной ссылке (одетый С++, между прочим). Там эту константную ссылку бережно сохранят и нагадят в нее потом.
Или, например, удалить популярный в этом топике кастомный аллокатор (вместе с кучей) до того, как забыты все ссылки на объекты из этой кучи.

Вариантов граблей, как обычно в С++ очень много.

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

S>А как с массивами, чей размер определяется в процессе выполнения? switch
Контейнеры есть для создания таких массивов.

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

T>>>А кто тебя заставляет это делать?
V>>Отличный вопрос, который можно задавать любому, кто утверждает, что на С++ можно писать небезопасные с т.з. типов программы.
T>Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.
Меняй круг общения

V>>Это в дотнете, ввиду низкой типизированности времени компиляции. Чем больше затащишь в статику типов целевой логики, тем меньше самих мест, где надо будет искать потом "примитивные ошибки".
T>Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов.
Что за продукт то?

T>Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!
И как она называется?

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

S>Отлично, но ведь такую точку входа не подружить с

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

Например, у меня стоит такая ловушка для самого общего случая:

    // A trap for unknown types to help in operator<< overriding diagnostics
    template<typename UNKNOWN_TYPE>
    TextBuilder& operator<<(const UNKNOWN_TYPE & value) {
        struct can_not_format_unknown_type {};

        //
        // Note: you must define an external operator<< like:
        // TextBuilder& operator<<(TextBuilder& f, const YourConcreteType& value)
        // or TextBuilder& operator<<(TextBuilder& f, YourConcreteType value)
        // defined in ****::**** namespace or in YourConcreteType declaration namespace
        // 
        can_not_format_unknown_type error = value;
    }

Которая генерит следующую ошибку при отсутствии специализации:

cannot convert from 'const SomeType' to '****::****::TextBuilder::<<::can_not_format_unknown_type'

Для аналогичного показанному в пред.посте случаю есть специализация:

    template<size_t N>
    inline TextBuilder& operator<<(const char(& data)[N]);

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

Да, в первых компиляторах С++ происходил именно взрыв размера бинарника. А потом оптимизатор link-time научился "склеивать" одинаковые куски кода. Что характерно, эта техника работает даже для нешаблонных и даже для виртуальных ф-ий, например:

class SomeIntBox 
{
  int i;

public:
  virtual int getI() { return i; }
};

class SomeFloatBox : public ISomeContract<float>
{
  float f;

public:
  virtual float getF() { return f; }
};

Признаюсь, я был сильно в 2002-м году удивлен, когда в релизном коде обнаружил, что getI и getF имеют один и тот же адрес, т.е. вместо двух ф-ий в бинарнике осталась только одна.

Для случая doSomething наиболее вероятным будет несколько сгенеренных точек входа (настоящих точек входа, без call и дополнительного фрейма стека, а просто jump потом на общее тело) с инициализацией какого-нить регистра или push в стек разных значений. Достоверно обещать не могу, это уж как оптимизатор выкрутится для конкретного кода, но использование нескольких легковесных точек входа, без создания лишних фреймов, наблюдаю постоянно. Особенно это неплохо смотрится если помнить, что в современных процах (со времен 2-го пня) безусловный jump занимает ровно 0 тактов.

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

AVK>Здравствуйте, Don Reba, Вы писали:

DR>>Был Evernote 3.5 написанный на WPF

AVK>С WPF разговор отдельный.

WPF/SL- единственная прогрессивная технология под зонтиком .NET (+ Mono конечно же). Все остальное- унылый веб к БД и обертки над доисторическим WinAPI, обертки над SQL, обертки над обертками над обертками

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

T>Не встречал еще в живую ни одного С++ программиста, который умеет это делать. Пока только на форумах.

Работаешь не там, значит.

V>>Дык, это не тот класс ошибок, который действительно напрягает.
T>Ну это кого как. Меня уже достало искать подобные ошибки в С++ коде.

Могу повторить.

T>2) Надо модифицировать код, бросающий исключения, а это не всегда возможно.

Бред сивой кобылы

T>3) Можно получить очень сильную просадку производительности на ровном месте.

Могу повторить.

T>А в чем смысл? Если уж клиент согласен и в состоянии воспроизвести (что далеко не всегда так), то почему бы тогда полный дамп не сгенерировать?

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

T>Блин, ну вот не надо сказки рассказывать, это у меня больная тема! Абсолютно все продуктовые баги проходят через меня и такого количества багов, как от С++ кода в .NET части нашего продукта нет и близко. Доходило до того, что некоторые компоненты было дешевле полностью переписать на .NETе, чем вылавливать все баги в С++. И не надо рассказывать про плохих программистов. Я работаю в конторе, у которой наверное самые высокие в России требования к С++никам и соответствующие зарплаты. Если уж тут плохие С++ программисты, то где тогда хорошие? Покажите мне их!

Ну... местные конторы "с самыми высокими ЗП на Украине" настойчиво многократно приглашают... Только предложить ничего не могут ни в плане интересной работы, ни по перспективам. У нас ведь в больших конторах рост может быть исключительно в менеджера, напр., по линии ПМ. Ну вот есть такая поголовная инвалидность в карьерных линиях наших контор. И не рассказывай мне сказки (С), что у вас это не так, я бы знал тогда, о какой конторе речь. Ты не обратил внимание, что плюсовики, достигнув некоторого уровня, поголовно уходят из наших "больших" контор в пользу буржуинских или своих собственных, небольших, если не видят себя по линии откровенного менеджерства? Или вообще съезжают "туда". Поэтому дефицит их, опытных, однако. Да только Intel с MS всех молодых талантливых плюсовиков стараются как корова языком подчистую слизывать, и еще куча контор поменьше. К дотнетникам, прямо скажем, отношение попроще. Ну т.е. висит в и-нете резюме, где и по плюсам и под дотнету неплохо, дык предложения относительно плюсов совсем не те приходят, что по дотнету, небо и земля.


V>>И я опять утверждаю, что дотнетные программы чаще плюют баги у клиентов, чем плюсовые, по итогам наблюдений за 8 лет.
T>Я этого почему-то не наблюдаю.

Т.е. открыть ваш баг-трекер и там совсем мало багов по дотнетным продуктам? Не поленись пройтись интереса ради.

T>Повлияет тем, что можно набрать больше тестировщиков благодаря тому, что программисты быстрее исправляют ошибки.

Не понял, у вас баги найти не могут что ле? Это ты точно сказки изволишь рассказывать или кто-то кого-то водит за нос (со стороны разработчиков). Есть еще вариант, что ты не в теме, что у вас там происходит.


T>В результате больше ошибок будет найдено и исправлено во время тестирования. У нас, например, тестировщиков больше, чем программистов. Если бы не С++ код, то пропорцию можно было бы еще увеличить.

Бред сивой кобылы. А кто юнит-тесты пишут, и как они интегрируются с регрессионными? А с интеграционными? Что насчет тестопригодности компонент? Какие техники для этого используются в плюсах? А дотнете? Какова доля сугубо UI-кода в общей массе? И что же именно и как именно ищут толпы тестеров, если UI-кода не подавляющее большинство? Какие инструменты автоматизации тестирования применяются? Какая доля тестеров пишет автоматические интеграционные сценарии, а какая "тупо клацает по кнопкам"? Какую долю из них ты бы увеличил?


V>>Не принципиально абсолютно. Да и не помню я, чтобы сложные в поиске баги, т.е. занявшие хотя бы пол-дня на поиски, выскакивали чаще, чем раз в несколько лет.

T>Да, кстати. Мы тут недавно Critical Fix выпускали. Buffer overrun в одном из umanaged компонентов. Но, как мне тут объяснили, таких ошибок в реальной жизни не бывает. Значит мне это все приснилось

Ну так и у меня в прошлом году по осени "чиста плюсовый" баг был, который я почти рабочий день искал, а до этого аналогичный за 3 года до, искал с коллегой его двойной delete. Я не настаиваю, что таких багов нет, но на одной чаше весов проблемы длиной в день раз в несколько лет, на другой куча компромиссов и допущений, чтобы юзать дотнет... и как-то картинка очень обсуждаемая в итоге. Чем я тут и занимаюсь.


T>Там эту константную ссылку бережно сохранят и нагадят в нее потом.

Таки предлагаешь в С++ обязательно гадить, а в дотнете исключительно всё делать правильно? Я уже пытался привести в чувство, что таким макаром можно много до чего договориться.

T>Или, например, удалить популярный в этом топике кастомный аллокатор (вместе с кучей) до того, как забыты все ссылки на объекты из этой кучи.

Т.е. применен некий grow-only аллокатор (коль можно "просто забывать" все ссылки by design), но который в итоге обслуживает не только локальные данные. Т.е. опять предлагаешь преднамеренно гадить в С++, и далее по тексту...


T>Вариантов граблей, как обычно в С++ очень много.

Немногим больше, не спорю. Но интересно не кол-во граблей, а распределение ошибок по граблям. По моим наблюдениям, основная доля граблей, вычищаемых и исправляемых, никак не связана ни с языком, ни с платформой. Т.е. "обычных" ошибок во многие разы больше, чем ошибок, специфичных для технологий, вот в чем цимус.