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

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

L>>Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.
WH>Какой процент времени у тебя уходит на то чтобы набить код в комментариях? Что-то мне подстказывает что 0.1% максимум.
В vim даже меньше. Только вот не стоит недооценивать важность таких комментариев не следует, особенно в коллективной разработке.
WH>Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?
Ну, если это для тебя сфероконь...
WH>Кстати кстати ты так и не ответил где логическая связь между D и C?
А нету ее. А каково логическое значение Ctrl-V и чем оно лучше "p"?
WH>В большинстве виндовых редакторов вобще и в студии в частности есть комманды для навигации по тексту.
Команды?
WH>Если держать shift то они превращаются в комманды выделения текста.
WH>А с выделенным текстом можно сделать кучу всяких разных действий.
Какие, например? Кроме скопировать/удалить/отформатировать?

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

R>Можно рассчитывать только на 1 вещь
R>-при полностью корректных данных на входе, скорее всего все работает
Эээ..
R>на что рассчитывать нельзя
R>-для многопоточных приложений никаких гарантий нет
Почему?
R>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
R>-при некорректных данных на входе никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по анализу данных
А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?
R>-в нештатных ситуациях никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке нештатных ситуаций
Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?
R>-написать юнит-тесты на отказ оборудования чисто физически проблематично, т.к. требует работы с железом\системными функциями через интерфейс(здравствуй куча врапперов). не говоря уж о том что код должен быть строго транзакционным (прощай vector\deque)
Отказ оборудования разный бывает. Если это горелая память, то тут нечего и тестировать, как оно упадет, даже ЕМУ не известно. Если это отказ периферии, то это должна быть штатная ситуация для софта, но в любом случае это уже далеко не юнит-тест, если тестируется работа с реальным железом.

R>Если тов WolfHound действительно имеет дело с кластерами (я имел с ними дело всего пару лет и в довольно скромных масштабах) то он имеет полный объем гемора с последними пунктами.
R>И я с ним согласен т.к. на моей памяти был случай когда мы огребли больше всего проблемм из-за покртыой тестами маленькой либы которая страдала всеми описанными недостатками (кроме работы с оборудованием)
Ну неправильно написанные тесты (скорее всего сделанные по принципу "нате и отвяжитесь"). Ну что с того? Мало ли вокруг софта, сделанного по тому же принципу?

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

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


L>>А Вы предпочитаете оставить утечку памяти?
WH>Я предпочитаю найти ошибку, пропатчить либу и отправить патч автору.
WH>Ибо мне нужна система которая работает, а не стоять и крчать "Я тут не причем! Это все Вася!".
Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
L>>Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.
WH>Иногда не код такой. А задача такая.
Задачу нужно дробить на части. Мы ведь тут решаем задачи, а не бросаемся с валенком на танки?
WH>Например у тебя на входе есть огромное дерево. И на выходе дерево но еще больше.
И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде

while (i=SOME_MAX_VALUE)  // "=" вместо "=="
{
}

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

WH>Писать код который сравнивает результат с тем что ожидалось?
Да. Еще можно, к примеру, написать генератор.
WH>Но это десятки если не сотни килобайт кода на каждый тест.
И что? Ручками сравнишь быстрее?
L>>Я тебе сейчас одну обидную вещь скажу, но советую над ней подумать. Если ты не понимаешь, как протестировать свой собственный код, ты не понимаешь как он работает.
WH>Я просто не хочу писать метры кода на ровном месте.
Погоди, пятью строчками у тебя алгоритм обработки дерева, который ты не знаешь, как тестировать, а тут вдруг "не хочу писать метры кода?" Вот уж правда, говорят "не могу", подразумевают "не хочу".
WH>Ибо в них тоже может быть ошибка.
Может. Не ошибается вообще только тот, кто ничего не делает.
L>>Подобные вещи покрываются автоматическими тестами на раз.
L>>Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.

WH>Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
Кстати, что он там такое проверяет?
WH>Это я тебе говорю как человек у которого в тз одним из первых пунктов идет: "Кластер должен работать если чать кластера физически выдет из строя."
WH>И мои кластеры работают.
Бум пиписьками меряться?
WH>Так чем же плох вариант: Написать, отладить, сделать кучу дампов, отсмотреть их на предмет совпадения с тем что ожидали. После чего засунуть эти дампы в svn и автоматически находить регрессии.

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


WH>Кстати еще одна задача которую не понятно как тестировать: Автоматическое улучшение изображений.
Вы точно уверены, что знаете, что такое юнит тест?
Юнит-тесты тестируют не систему целиком, а ее минимальные части для уверенности, что вы не положили в фундамент плохих кирпичей. Тестировать алгоритмы в общем случае — не их задача.
WH>Результат совершенно субъективен.
WH>Объективные метрики полностью отсутствуют.
Это не задача для юнит-тестирования. Это функциональное тестирование.

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

T>кстати, если ставить его версию под винду, то как он поможет мне в разработке?

Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.

T> его ж можно будет использовать только как редактор или отладка тоже будет работать?

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

T>он перекроет по возможностям VS 2005?

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

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

C>показал, который делает то же самое. Я бы свою поделку нафиг выбросил.
Приведи мальенькое ТЗ или лучше кусок кода, я попробую примерчик нарисовать, для перехода к полноценной дискусси.
В спорах истина рождается, однако.
>> Попробуйте изменить подход к "покрытию юнит-тестами".
C>Куда? В третий раз напомню — код библиотеки почти на 100% покрыт
C>тестами. Почему же мне не помогает эта магическая серебряная пуля?
Если в сердце дверь закрыта, можно в печень постучаться (где-то подслушал)
>> Бывает. Еще можно лог к программе приделать.
C>Приделан. Ничерта не помогает. Тем более, что писать в лог сложные
C>графовые стркутуры — это еще то занятие.
Ну... перегрузить операторы вывода для узла структуры не помогает?

R>>-для многопоточных приложений никаких гарантий нет
L>Почему?

Потому что неизвестно, где именно кернел переключит нитку. Искать race conditions юнит-тестами — это бред. Они ищутся только вычиткой кода, ну или ловятся на живой глюкнувшей системе . Лучше их вообще не допускать.

Юнит-тестируестя то, что внутри себя однонитево, например — будет использоваться только из-под лока.

L>А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?

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

L>Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?

Ошибка любого вызова, сделанного "вбок" в другие компоненты или "вниз" в платформу. Я понимаю, что есть технологии типа Low Resources Simulation в Driver Verifier, но они под эту симуляцию пол-ядра отпатчили

L>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.

Так вот, 80% кода — это просто если очень аккуратно его писать — грабли почти никогда не вылезают, разве что ну-очень-сильно-corner-cases.

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

L>Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
Такое что для того чтобы это исправить нужен отладчик.

То, что вы делаете в отладчике, легко автоматизируется юнит тестом...

Далеко не все автоматизируется юнит тестом...

L>И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде
L>банальных проблем выделения/освобождения памяти и прочих глупых, обидных, но трудноулавливаемых косяков.
1)Подобные опечатки у меня бывают пару раз в год. А когда у меня последный раз память текла или там проезд был я уже и не помню.
2)Для того чтобы протестировать некоторую функцию нужно подготовить для нее данные. Что далеко не всегда просто.
3)Не знаю как у тебя но у меня детали реализации по ходу дела часто и сильно меняются. И если тестировать их то придется постоянно переписывать тесты. И уж точно я не знаю как именно у меня будет выглядить код до того как я его напишу. До начала работы у меня есть только примерный план и (не всегда) внешние интерфейсы.
4)Я в данный момент пытаюсь допинать до рабочего состояния (устранив проблемы с крайними случаями на которые забили торетеки) очередной алгоритм обработки изображения. Подобных ошибок там нет. Но легче от этого не становится.

L>Да. Еще можно, к примеру, написать генератор.
А зачем мне два генератора?
У меня уже есть один. Сама программа...
Сделать печать результата тривиально. А вот получить сам результат...

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

WH>>Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
L>Кстати, что он там такое проверяет?
Проверяет он то что на выходе то что ожидалось.

L>В принципе, твой подход тоже применим, но нужно как-то показать стабильность алгоритма (иначе твой тест будет доказывать лишь то, что алгоритм работает для отдельной конечной области значений на входе)
Любой. Те абсолютно любой тест. Доказывает это и только это.
Болие сильные гарантии может дать только формальное доказательство. Но это очень дорого и не всегда возможно (например если у результата есть субъективные характеристики).

L>и обязательно организовать проверку поведения при некорректных данных на входе.
Тут все просто. В этом случае вылетит исключение...

L>Вы точно уверены, что знаете, что такое юнит тест?
Я знаю.
Но тут кто-то утверждал что дебагер ваще не нужен...

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

R>>-для многопоточных приложений никаких гарантий нет
L>Почему?
Юнит тесты для недетерминированных систем... это что-то новое...
Проверить работу даже двух потоков во всех возможных сочетаниях практически не реально. Почему объяснять надо?

R>>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
L>Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
Я бы сказал что проверить на всем диапозоне входных данных можно исчезающи малое колличество алгоритмов.
Уже при паре Int32 проверить на всех входных значениях почти не реально.
А если на входе картинка Думаю всю чудовищьность числа 2 ^ (1024 * 768 * 32) сможешь предствавить сам...

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

WH>>В том что тут было высказано мнение что Linux это что-то особенное... меж тем изучение линукса ничем не отличатся от изучения MFC или какой либо иной библиотеки.
MSS>Т.е. нет разницы между платформой и библиотекой?
MSS>Совершенно неверно.
Мой опыт перехода под линукс говорит что очень даже верно...

MSS>Библиотеку можно учить _не всю_. Я от MFC брал то, что мне нужно, и не пользовался ничем другим.
MSS>С платформой так не выйдет. Делаешь вроде то же самое, что под виндами, а работает иначе.
Гм. Чтение доков перед использованием уже отменили?

MSS>Я уж не говорю про билд-платформу, ее поддержка тоже есть немалый труд.
Гм. ИМХО вобще не проблема.
Один раз туториал прочитал и дальше только иногда в маны поглядываешь...

MSS>Под линуксом можно сделать в принципе практически все, что под виндами, и наоборот. Но конкретные тулы для этого сделать — сильно разные.
И? Чем это отличается от перехода на не знакомую библиотеку?

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

L>В vim даже меньше. Только вот не стоит недооценивать важность таких комментариев не следует, особенно в коллективной разработке.
Я не про ценность данных комментариев. А про ценность автоматизаци операции которая занимет меьше 0.1% времени.

WH>>Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?
L>Ну, если это для тебя сфероконь...
Ну тогда просвети зачем тебе нужно скопировать ровно 100 строк и при этом ты точно знаешь это число зарание.
Учитывая что тебе это нужно регулярно (инче ты бы на этом не настаивал) у тебя не возникнет проблем с парой примеров.

Вот я никогда не знаю сколько строк мне нужно скопировать. Я знаю что мне нужно скопировать от и до. Но сколько там строк

WH>>Кстати кстати ты так и не ответил где логическая связь между D и C?
L>А нету ее. А каково логическое значение Ctrl-V и чем оно лучше "p"?
Причем тут Ctrl-V?
Я говорю про конкретные операции в студии и виме.
В студии есть перемещение к концу строки end.
Есть режим выделения shift.
Их сочетание дает выделение до конца строки.
Если добавить сюда del то получим удаление текста до конца строки.
А если Ctrl-V то получим замену текста до конца строки на то что было в буфере.

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

А вот зная про то что есть D догадаться до того что есть C не реально.

L>Какие, например? Кроме скопировать/удалить/отформатировать?
Например можно провести замену в том числе по регулярному выражению в приделах выделения.

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

KP>Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.
А зачем? Если можно взять студию и получить очень хороший редактор без допиливания?

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

WH>Здравствуйте, kaa.python, Вы писали:

KP>>Исключительно как редактор. Как очень хороший редактор. После того как вы потратите довольно много времени на его допиливание.
WH>А зачем? Если можно взять студию и получить очень хороший редактор без допиливания?

а если мне не нравится, как она работает, тогда как?
а если я дома нет-нет люблю что-то написать, в рамках самообразования, а на покупку Windows мне денег жалко, а пиратским пользоваться принципиально не хочется?
а что если по работе приходило писать под обе платформы, и были случаи когда работа происходила исключительно на Linux?

как быть во всех этих случаях?

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


L>Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

Угу вот только и современные интегрированные отладчики и юнит тесты имеют один общий корень — Smalltalk

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

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

Кстати, я вспомнил. Основная проблема при написании кроссплатформенного кода для симбиана — вовсе не в исключениях, а системе callback. Эти калбеки иногда сильно меняют архитектуру программы.
Правда мне очень нравится программировать с использованием их парадигмы, за это я прощаю симбе их жуткий С++.

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

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

L>>Что-то Вы тут сравниваете мягкое с теплым. Какое это имеет отношение к юнит-тестированию?
WH>Такое что для того чтобы это исправить нужен отладчик.
WH>

То, что вы делаете в отладчике, легко автоматизируется юнит тестом...

WH>Далеко не все автоматизируется юнит тестом...
Тестирование всего, кроме GUI, можно автоматизировать. Уровней можно придумать сколько угодно — проверка кода на корректность поведения в юнит тестах, функциональные тесты, основанные на юнит-тестах и т.д. Если нечто, что не имеет никаких ручек, торчащих навстречу пользователю, "не автоматизируется", то надо сделать так, чтобы автоматизировалось. Особенно в случае коллективной разработки.
L>>И код обработки дерева засунут в одну функцию, надо полагать? Или состоит из множества сущностей поменьше? Вот их-то и надо протестировать на предмет ошибок вроде
L>>банальных проблем выделения/освобождения памяти и прочих глупых, обидных, но трудноулавливаемых косяков.
WH>1)Подобные опечатки у меня бывают пару раз в год. А когда у меня последный раз память текла или там проезд был я уже и не помню.
А ты один код пишешь или есть еще Х, нет Y девелоперов?

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

M>кто без VS как без рук?

Нет.

Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>>-для многопоточных приложений никаких гарантий нет
L>>Почему?

MSS>Потому что неизвестно, где именно кернел переключит нитку. Искать race conditions юнит-тестами — это бред. Они ищутся только вычиткой кода, ну или ловятся на живой глюкнувшей системе . Лучше их вообще не допускать.
Можно симулировать ситуацию, провоцирующую возникновение гонок и/или дедлоков. Естественно, характерную для конкретного кода. Сам делал, делаю и буду делать. Только это уже не юнит тест в обычном его понимании, хотя очень удобно включается в состав юнит-тестов.

MSS>Юнит-тестируестя то, что внутри себя однонитево, например — будет использоваться только из-под лока.
L>>А кто запрещает написать юнит тест, который тестирует работу алгоритма, подавая ему мусор на вход?
MSS>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой? Если данные не валидны — поведение одно, если валидны — другое.
L>>Нештатная ситуация это что? Computer on fire? Ошибка ввода-вывода? Крах ОС?
MSS>Ошибка любого вызова, сделанного "вбок" в другие компоненты или "вниз" в платформу. Я понимаю, что есть технологии типа Low Resources Simulation в Driver Verifier, но они под эту симуляцию пол-ядра отпатчили

L>>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.
MSS>Так вот, 80% кода — это просто если очень аккуратно его писать — грабли почти никогда не вылезают, разве что ну-очень-сильно-corner-cases.
Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard и т.д?

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

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

R>>>-для многопоточных приложений никаких гарантий нет
L>>Почему?
WH>Юнит тесты для недетерминированных систем... это что-то новое...
WH>Проверить работу даже двух потоков во всех возможных сочетаниях практически не реально. Почему объяснять надо?
Опять непонимание того, кто такой юнит тест. Нет смысла тестировать всю систему, если нет уверенности в том, что она не собрана из гнилых кирпичей. Более того, у двух потоков могут быть лишь два интересных взаимных состояния — когда они обращаются к разделяемым данным и когда не обращаются.
R>>>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
L>>Это вопрос о программировании юнит-теста и стабильности алгоритма. Иногда есть смысл проверить на всем диапазоне значений, иногда это невозможно.
WH>Я бы сказал что проверить на всем диапозоне входных данных можно исчезающи малое колличество алгоритмов.
WH>Уже при паре Int32 проверить на всех входных значениях почти не реально.
2^64
WH>А если на входе картинка Думаю всю чудовищьность числа 2 ^ (1024 * 768 * 32) сможешь предствавить сам...
Еще раз, по буквам — можно и нужно тестировать составные части того, что на вход принимает картинку, даже если проверку работы всего принимающего картинки автомата автоматизировать не удается.
L>>У меня опыт сугубо противоположный — стоит что-нибудь не покрыть юнит тестом (ну, надо быстро сделать, это просто и т.п.), как моментально из этого кода отрастают трудноуловимые грабли.
WH>А у меня все серьезные проблемы отрастают исключительно на этапе интеграции нескольких систем которые псали разные люди.
А у меня таких проблем не было уже давно, благодаря подходу к архитектуре и наличию простых правил тестирования модулей.

MSS>>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
L>Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой?

Баг может возникнуть только в случае _неких специальных видов мусора_, часто неизвестных тестеру.

L>Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard

Мне scope guards не нужны — у меня и так ни разу забытого лока не было за 8 лет ковыряния в ядре виндов.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Перебрать все возможные виды мусора — это крайне сложно, зачастую — невозможно.
L>>Хм.. что это за алгоритм такой, который выбирает, хороший мусор ему дали или плохой?

MSS>Баг может возникнуть только в случае _неких специальных видов мусора_, часто неизвестных тестеру.

Хм.. это такой мусор, замаскированный под корректные данные, что ли?

L>>Очень аккуратно вот ты можешь писать очень аккуратно, я тоже могу писать очень аккуратно. Гарантирует ли это, что остальные 10 девелоперов пишут так же аккуратно и не забывают освобождать память, не используют EnterCriticalSection явно вместо Scope guard

MSS>Мне scope guards не нужны — у меня и так ни разу забытого лока не было за 8 лет ковыряния в ядре виндов.

А остальные 10 девелоперов в команде такие же гении?