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

V>>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти.
K>>ну это просто вранье или полная некомпетентность

ГВ>Слушай, найди какой-нибудь другой аргумент, а?

Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил, и непонятно кто — это, пардон, п-ц. Писать в таком стиле, что это становится типичной ошибкой — полнейшая некомпетентность. Метлу в руки — и на улицу.

ГВ>Давай уж начистоту: "вы все [плохое слово по выбору], а я в белом!" Так хоть честно будет.

Не все. Только те, кто слишком завирается.

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

V>>>>Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти.
K>>>ну это просто вранье или полная некомпетентность
ГВ>>Слушай, найди какой-нибудь другой аргумент, а?
K>Ну а что поделаешь. Прога, которая сломалась потому что (очевидно, глобальное/статическое) поле кто-то обнулил [...]

На этом варианты закончились? Только глобальное/статическое?

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

S>Здравствуйте, Banned by IT, Вы писали:
BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
S>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои. Голые указатели, если верить форумам, вообще никто уже десять лет не применяет.

Пользовал и пользую; писал и пишу; применяю, где имеет смысл и не применяю, где не имеет смысла.

S>И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.

Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++. А то, всё время получается:

- У дотнет есть некоторые недостатки...
— А вы ошибки делаете, память теряете, ужас-ужас-ужас, уши отваливаются при стрельбе в ногу! Нет-нет-нет, мы обратно ни ногой!

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

S>Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.

Во-во, оно и есть.

S>Добро пожаловать в реальный мир, Нео.

Угу, загляни в топикстарт.

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

I>>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что

FR>Прикол в том что точно также падают и глючат и программы на шарпе и яве.

Не точно так же. Если сиплюсники утверждают что RAII и тд и тд спасает, то это все сказки.

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

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

G>>>в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью.
BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?

I>Средний C# не знает и не умеет указателей. Как то так выходит, что заказчики предлагают проектов примерно на порядок больше, чем могут реализовать умелые сиплюсники, так что unmanaged это вынужденая мера.

Печально это, не спорю.

I>C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.

Мрак. У меня последний раз "не взлетал" код (именно совсем не взлетал, не от скуки, из любви к искусству или стремления к совершенству), примерно, в 1990-м, если не ошибаюсь, это была лаба на ассемблере КР580ИК80А. А всё остальное как-то либо летало, либо не доводилось до "взлётной полосы" по каким-то отвлечённым соображениям. Так что, блин, всё сильнее чувствую себя в башне из бивней мамонта.

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

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

А можно узнать возрастные характеристики этого среднего программиста?

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

ГВ>Печально это, не спорю.

I>>C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.

ГВ>Мрак. У меня последний раз "не взлетал" код (именно совсем не взлетал, не от скуки, из любви к искусству или стремления к совершенству), примерно, в 1990-м, если не ошибаюсь, это была лаба на ассемблере КР580ИК80А. А всё остальное как-то либо летало, либо не доводилось до "взлётной полосы" по каким-то отвлечённым соображениям. Так что, блин, всё сильнее чувствую себя в башне из бивней мамонта.

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

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

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

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

ГВ>А можно узнать возрастные характеристики этого среднего программиста?
Рекомендую сналчала поинтересоваться об источнике этой информации

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

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

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

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

Ну, посмотрим. C++, конечно, далеко не идеал языка программирования, но пока что ничего лучше для native не придумали (по сумме факторов, конечно).

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

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

ГВ>А можно узнать возрастные характеристики этого среднего программиста?

28-30 лет.

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

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

T>>Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.

V>И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему. А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого.
Ты путаешь возможность специально уронить или случайно. Можешь вообще с помощью класса Marshal AV получить. Но find all references сразу скажет где это происходит еще до запуска.

V>И какая разница, почему программа упала, из-за изолированной ошибки или нет?
В этом нет разницы. Но есть разница в том что ошибка создавалась специально (то есть не ошибка, а вредительство) или возникла случайно.
Причем именно апологеты unmanaged имеют стремления делать такие вещи в managed среде.

V>Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range. Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна.
outofrange вывалится даже у клиента с полным stacktrace резко сузив область поиска. Если же неуправляемая программа упадет с ошибкой в оптимизированном коде, то придется очень долго её воспроизводить.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

ГВ>Сама по себе управляемость, может быть, не при чём. А вот гарантирование корректности ссылок — очень даже при чём.
Ты бы предпочел UB?

ГВ>Нет, комната стала тёмной по другим причинам. Пафосно выражаясь, C++ — это были те искры, которые позволили найти выход из этой комнаты.
Предпочитаю фонарик в виде assert искрам из глаз в виде AV

ГВ>Без исходного кода я ничего посоветовать не могу. Если хочешь, свяжись по мылу, может быть, что-нибудь придумаем.
А исходный код тебе ничего не даст. Тот код, что упал вполне себе невинен. Проблема в том, что кто-то испортил общий хип. По дампу понять, кто испортил общий хип невозможно. Под app verifier ошибка не воспроизводится. Общая кодовая база — сотни мегабайт исходников. Понятно, что не надо использовать общий хип, надо делать кастомные хипы для каждого компонента, а еще лучше разносить компоненты по процессам. Но это все костыли, вызванные "особенностями" С++ и из-за которых приходится существенно усложнять архитектуру.

ГВ>А... Я подумал про design contracts из FW 4. Ну так assert-ом по сути и спаслись.
Ну вот видишь. Ассерт — мощная штука, но его не повесишь на порчу памяти.

ГВ>Во-во, знакомо. Ошибка — это только если exception, всё остальное — "так и надо".
Не совсем. Ошибка — это несоответствие требованиям. Все остальное — "так и надо".

ГВ>>>Да и дамп объектов бы не помог... Если я непонятно написал, то уточню: ключом к решению стало добавление защиты от параллельного доступа. Всё остальное было поисками чёрной кошки из-за приключившегося у меня приступа паранойи.
T>>В дампе ты бы увидел, что было создано два объекта вместо одного. Дальше все тривиально.

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

ГВ>Тоже справедливо. А исходников этого самого чужого кода у меня нет?
Исходники есть. Но править ты их не можешь.

T>>Это говорит о том, что в С++ проблемы можно получить в любом месте и фраза, что неверная интерпретация памяти бывает только [подставить что-то одно] ложная. Неверная интерпретация памяти может произойти по миллиону причин. И для каждой такой причины можно ответить: "надо делать то-то".

ГВ>Так и надо делать "то-то".
Совершенно верно. То есть другими словами, не надо делать ошибок. Но люди их все равно делают, это данность. В случае с С++ многие такие ошибки оборачиваются большими потерями времени.

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

ГВ>Пользовал и пользую; писал и пишу; применяю, где имеет смысл и не применяю, где не имеет смысла.
Верю. Всем остальным — тоже верю. Я же говорю: на форумах — все гуру. А в реальности закрытый С++ код, который я видел, в среднем намного хуже того Open-source, который вроде написан непонятно кем.

ГВ>Никто никого никуда не зовёт. Нравится дотнет — пиши для дотнет, кто мешает-то? Только не надо при этом плеваться в сторону С++.
ГВ>Ни ногой, так ни ногой, только зачем шуметь, если кто-то констатирует объективные недостатки того же дотнета, не зависящие от программистов?
Да вроде никто не плюётся. Средний дотнетчик редко затевает топики типа "оппа, плюсам-то капец!". Всё как раз наоборот: начинаются какие-то наезды на управляемый код (без малейшего желания хотя бы выяснить, что вообще такое управляемый код. Признайся честно — ведь не читал определение из ECMA-335, да?), вопросы типа "а как вы будете писать драйвер" и прочее, навязшее уже в зубах.
Работаете вы на С++ — так и работайте, кто ж вам не даёт?
ГВ>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев. А если их нет, этих преимуществ по каким-то критериям?
Это у вас комплекс такой. Вот, к примеру, в этом топике никто ни разу не высказался про "возможных и невозможных случаев".
Зато с другой стороны идут какие-то постоянные намёки на некомпетентность С#-девелоперов. Недостатки дотнета от программистов, может быть, и не зависят. Зато вот достоинства С++, на которые вы тут ссылаетесь, почему-то очень сильно зависят от программистов.
А нам, дотнетчикам, хочется, чтобы от программистов зависело поменьше. Потому что программисты — компонент самый ненадёжный.

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

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

I>28-30 лет.

Это ты про пост-СССР? Или про Бахрейн, который у тебя в профиле?

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

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

T>>Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ!

V>Ну ты не приводи слова без указания контекста, або даже я упомяну неприятное слово "демагогия".

T>>Куча тактов процессора и байтов памяти зазря тратятся.

V>-1
V>Достаточно самому написать програму из 3-х строк, с использованием std::auto_ptr, и убедиться на сгенеренном бинарном коде, что использование этого умного указателя ничего не стоит, в сравнении с ручным вариантом, безопасным к исключениям.

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

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

S>Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей.
У тебя что, отсутствие указателей это признак качества кода?

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

S>Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
Operator new может быть перекрыт глобально.
И опять таки, кастомный аллокатор как правило применяется там, где он реально нужен.

S>Итого: кастомные аллокаторы и умные поинтеры в реальной жизни не встречаются.

Скажи, а кенгуру ты вживую видел? Или они тоже в реальной жизни не встречаются?

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

I>Может и ничего не стоит. А кто её умеет и где посмотреть продукты, где бы эта безопасность что ничего ен стоит была использована ? Я чет как ни залезу в чей нибудь С++ код, так вечно хаос с указателями. Такое ощущение что RAII еще не изобрели или изобрели но не рассказали, как правильно им пользоваться

Ну извини. То, что тебя окружают индусокодеры означает совсем не это.

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

K>Я пока что не встречал более пафосных говнокодеров, чем на С++. Вот это — точно медицинский факт. Каждое нубло, которое накропало пару примитивных программок на С++ — уже считает себя гуру
Брысь зелёный, еды не будет. Тоньше надо троллить, тоньше!

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

I>По трудоёмкости может и не стояли рядом, но глядя на обилие ошибок с указателями в сиплюсных программах, как то возникает сомнение что люди в общей массе вообще способны освоить эти указатели
Встречал людей которые в принципе не могли понять как работает указатель и как им пользоваться. Т.е. в принципе не понимали. Как работает индекс по массиву — понятно, а как работает BYTE* по flat оперативке — полный ступор и пустота в глазах.

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

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

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

V>Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна. И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек.
Вы что, для каждого исключения вытаскиваете его коллстек через DbgHelp? Это же тормоза дикие! А если в коллстеке много модулей, тащите пачку pdb? Вы их всем клиентам поставляете "в нагрузку"?

V>Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
И при этом я не помню случая, когда при наличии на руках дампа процессе не смог бы найти ошибку в managed коде. При этом случаев, аналогичных вышеописанному, когда кто-то портит общий хип, а потом кто-то другой падает из-за чего дамп оказывается бесполезным — полным полно. Потому что хип может испортить кто угодно и в подозреваемых находится весь код на С++. В случае с .NET'ом T>>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме.

V>Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
Разница в том, что мы получим NRE не где попало, а только там, где мы работаем с общим испорченным состоянием. Такого кода, как правило мало и в результате ошибку проще локализовать.

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

V>Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
Совсем не факт, что проявит и повлиять на это я не могу. А вот ассертов понаставить — это влегкую. Только вот против порчи памяти толку от ассертов мало.

T>>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
T>>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого

V>Легко в тех же ошибках в многопоточном коде.
Выше ответил.

T>>2) Наличие коллстеков у всех исключений.

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

T>>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.

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

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