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

ГВ>За время работы в индустрии у меня сложилось устойчивое убеждение, что "корпоративный сайт" (а чуть раньше — "корпоративная база данных") — это такая штука, написать которую просто дело чести для каждого программиста и тем более — для разработчика инструментальных средств. Почти уверен, что можно найти корпоративные [что-то] на шелле.

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

ГВ>Собственно, корпоративный софт не релевантен популярности в данном случае, поскольку пишется под требования определённого, достаточно узкого круга лиц, под более или менее определённую аппаратуру, системное ПО и т.п. Ну вот возьму я, напишу для себя нечто на batch-файлах, ну и что?

Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций. Вот размер кодовой базы или трудозатрат это более подходящий критерий для отделения софта от не-cофта. Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.

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

I>>>>Нативный софт начали писать еще в 80х [...]
ГВ>>>Щито???
I>>Офис, вындоус и куча всякой всячины тянется ажно оттуда.

ГВ>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман?

У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?

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

I>Расклад по тому, что нынче пишется в каких объемах можно сделать тупо по количеству вакансий. Как то я не вижу значительного кол.ва вакансий на с++ и не вижу, что бы ЗП в с++ отражали спрос на с++

Дык, я же говорю, дефицит. Как ни посмотришь требования к С++-программисту, от года, или типа таких:

Требования к кандидату
• Понимание ООП проектирования и программирования
• Практический опыт разработки программ на С++ (MS Windows)
• Знания и практический опыт использование библиотек MFC, STL, Boost
• Практический опыт разработки многопоточных приложений (синхронизация, разделяемые данные, обмен сообщениями)
• Опыт командной работы

Последние годы требования к плюсовикам настолько деградировали в объявлениях, что эти объявления можно читать как "ну придите же хоть кто-то". И предлагают там же ЗП, сопоставимую с разработчиками ASP.Net, для которых нехилый конкретный список требований, технологий, практик и т.д.

Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место. Лучше посмотреть на каком-нить http://nyjobsource.com/ , бо у нас 99% спецов-плюсистов тупо уехало и не вернулось. Когда я последний раз внимательно смотрел, то ЗП С++ разработчиков легко были 140-170к, аналогичных по опыту дотнетчиков 100-120к.

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

V>Ты показал, что не в курсе о чем речь.
Я не в курсе о чем ты говоришь. В твоем тексте постоянно взаимоисключающие параграфы встречаются.

V>Не поинтересуешься у тестовой команды, какова доля негативных тестов в общей доле тестов? Если меньше 70%-80% (грубо), то при игнорировании устойчивости к исключениям в вашей дисциплине кода, мы обсуждаем сейчас стандартный дотнетный говнокод, с детскими ошибками внутри.
Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?


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

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

ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.

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

ГВ>>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман?
I>У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?

Unix.

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

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

ГВ>>>>>Это как раз очень простая ситуация. Врубись: я держу ссылку на объект, предполагая, что он кому-то нужен. Но этот кто-то этот самый объект сейчас "выкидывает". В unmanaged произойдёт "ой" из-за внезапного delete, а в managed — будет тишина и я буду продолжать работать с никому не нужным объектом.
G>>>>Да, и managed программа будет работать и работать корректно.
ГВ>>>Разницу между "корректно" и "без выбрасывания исключений" надо объяснять?

G>>Да, опиши что такое "корректно". Почему ты считаешь некорректным держать ссылку на объект? Это как-то повлияет на результат?

ГВ>Вход: число N.
ГВ>Выход: N x 2.

ГВ>Пример неправильного выхода без выбрасывания исключения: N x 2 + 1.

Причем тут ссылка на объект? Не уходи от вопроса, ты же сказал что ссылку на объект держать "неправильно".

G>>>>В unmanaged в лучшем случае упадет. Разницу понимаешь?
ГВ>>>Естественно, понимаю.
G>>Похоже что нет. Хотя это зависит от твоего понимания корректности.

ГВ>Ну похоже, так похоже. Мне-то что?

А то что ты продолжаешь вести разговор не понимая проблем.

ГВ>Очевидно, затем, чтобы показать, как терялся объект данных, сгенерированный unmanaged-кодом. Только для этого. Поверь, советов по проектированию я спрашивать не собирался.
Ты написал не-threadsafe код, причем тут unmanaged непонятно. Причем этот пример больше на говнокод смахивает. Говнокод — не проблема языка.

ГВ>>>В реальности и сам код был сложней, и ещё довольно сложная логика перезапуска потоков, из-за которой, в общем, всё и случилось. Но к тому, на что я хотел обратить внимание, это не относится. А про однопоточность unmanaged всем и так было известно.

G>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое.
ГВ>Ты правда, прочёл то сообщение, которое обсуждаешь?
Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.

G>>А то получается что ты низкую квалификацию писавшего код на C# выставляешь за недостаток языка.
ГВ>Мой тебе добрый совет: не надо рассуждать о чужой квалификации с через третьи руки.
Мой тебе совет, не лезь со своими советами. Толку от них ноль.
Давай посмотри правде в глаза: 90% посчитают за говнокод то что ты привел, неважно был ли он написан так или ты упросил его до такого состояния.

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

ГВ>>За время работы в индустрии у меня сложилось устойчивое убеждение, что "корпоративный сайт" (а чуть раньше — "корпоративная база данных") — это такая штука, написать которую просто дело чести для каждого программиста и тем более — для разработчика инструментальных средств. Почти уверен, что можно найти корпоративные [что-то] на шелле.

I>Корпоративные сайты включают достаточно много функционала, часто это часть большей системы управления предприятием(чтото вроде), которая нынче редко пишется в нативном виде. В любом случае веб это вагоны проектов самых разных масштабов. А Офисов, к слову, хорошо если десяток наберется.

Ну и что?

ГВ>>Собственно, корпоративный софт не релевантен популярности в данном случае, поскольку пишется под требования определённого, достаточно узкого круга лиц, под более или менее определённую аппаратуру, системное ПО и т.п. Ну вот возьму я, напишу для себя нечто на batch-файлах, ну и что?

I>Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций.

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

I>Вот размер кодовой базы или трудозатрат это более подходящий критерий для отделения софта от не-cофта.

Размер кодовой базы — это просто размер кодовой базы. Максимум, о чём он может сказать, так это о том, какой язык популярен у разработчиков. Ну и что такое "не-софт" я не очень представляю. Автомобили, что ли?

I>Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.

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

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

G>>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое.
ГВ>>Ты правда, прочёл то сообщение, которое обсуждаешь?
G>Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.

В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности.

"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило.

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

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

G>>>>В таких случаях надо делать вокруг unmanaged кода wrapper, который будет проверять предусловия. Вообще стоит почитать гайдлайны перед тем как писать такое.
ГВ>>>Ты правда, прочёл то сообщение, которое обсуждаешь?
G>>Да, я его прочел, но абсолютно не вижу в чем проблема managed в данном случае. Просто говнокод, который с тем же успехом можно было в любой среде написать.

ГВ>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности.
Ну ты же начал про managed-unmanaged, а привел говнокод, который на любом языке мог бы так работать.

ГВ>"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило.
А это еще один интересный вопрос. Видимо помимо проблем в managed были еще и в unmanaged проблемы, которые приводили к ave. Тоже что-то вроде разделяемых данных без синхронизации.

ГВ>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.

Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно". Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь". В случае managed-кода всё это было аккуратно и тихо проглочено либо "гарантирующей" средой, либо GC.

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

ГВ>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного. То есть само по себе создание двух потоков было заведомой ошибкой, к несчастью, не обложенной тестами. Так что, твои метания молний относительно thread-safety сейчас не по адресу. Я просто не хочу вдаваться в лишние подробности.
G>Ну ты же начал про managed-unmanaged, а привел говнокод, который на любом языке мог бы так работать.

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

ГВ>>"Диагностика" такой ситуации проявилась в виде AVE, возникающем, естественно, в unmanaged. Поскольку как ни крути, а строго одновременно обращения происходили далеко не всегда, то и ошибка была "плавающей". Повторю ещё раз: в самом managed-коде ничего необычного при этом не происходило.
G>А это еще один интересный вопрос. Видимо помимо проблем в managed были еще и в unmanaged проблемы, которые приводили к ave. Тоже что-то вроде разделяемых данных без синхронизации.

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

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

ГВ>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.

ГВ>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно".

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

ГВ>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь".
Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.

Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем.

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

ГВ>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.
ГВ>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно".
G>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.

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

ГВ>>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь".
G>Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.

Естественно. Только для этого надо приложить специальные усилия. Например — добавить защиту от многопоточности там, где многопоточность ни разу не планируется.

G>Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем.

Как оказалось, очень даже при чём.

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

G>Говнокод он и в африке говнокод [...]

Всё хочу у тебя спросить: тебе слово "говнокод" нравится, что ли? Прям в каждом сообщении — говнокод, говнокод, говнокод. Ты не отличаешь иллюстративные примеры от реального кода? Или я как-то непонятно ситуацию описываю?

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

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

G>>Говнокод он и в африке говнокод [...]

ГВ>Всё хочу у тебя спросить: тебе слово "говнокод" нравится, что ли? Прям в каждом сообщении — говнокод, говнокод, говнокод. Ты не отличаешь иллюстративные примеры от реального кода? Или я как-то непонятно ситуацию описываю?

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

Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?

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

G>Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?

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

G>Ты уже перешел в демагогию. Вместо описания каких-то проблем ты пишешь общие слова, которые все по разному понимают.
G>Давай пиши конкретнее что ты имеешь ввиду.

Это общеупотребительные термины и мемы.


G>ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.

Ну, ок, по серверам я говорил, что это ниша дотнета, по многим пунктам. И даже особенности работы GC как раз хорошо ложатся на массовое обслуживание. Касательно подробностей модели, в 99% случаев веба там stateless, т.е. состояние просто умирает в этом сценарии, а не переходит в невалидное. К тому же сценарий обработки ошибки ровно один — передать текст ошибки клиенту. Ну и транзакционность и независимость подключений/запросов обеспечивается протоколом и низлежащей инфраструкторой, к которой к тебе торчит "конец", дергаемый в нужное время, не тобой определыемое. И вот во всей этой массе серьезных технологий вы делаете прикладную верхушку айсберга.

Совсем другое дело десктоп.

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

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

ГВ>>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.
ГВ>>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно".
G>>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.

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

Да ну? Ты же начал говорить что проблема была в managed коде, но показать её не можешь. Приводишь только кусок кода к делу и не относящийся (судя по твои словам).

ГВ>>>Unmanaged при аналогичных условиях повёл бы себя одним из трёх возможных вариантов: либо вылетел, либо устроил внезапные светошумовые эффекты, либо хотя бы начал "течь".
G>>Unmanaged мог бы себя точно также повести. Более того можно написать полностью эквивалентный (в том числе в плане багов) код на C++.

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

Нет, чтобы написать такой же бажный код не потребовалось бы ничего.

G>>Так что хз что ты пытаешься показать. Говнокод он и в африке говнокод, языки тут не при чем.
ГВ>Как оказалось, очень даже при чём.
Где оказалось? Выйди из сумрака.

Меня всегда прикалывали мнения вроде: вот Вася писал прогу на C#, она получилась глючной и медленной, он решил переписать её на C++. Знаете что обычно получается у таких вась и их программ?
Хороший кодер сможет на любом языке написать хорошую программу, плохой кодер на любом языке напишет плохую. Глупо приписывать эти свойства языку.

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

G>Если же в реальном коде нет таких проблем как в указанном тобой примере, то зачем ты вообще писал пример?

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

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

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

G>>Это какие тесты ты имеешь ввиду? Те которые проверяют поведение при неверных входных данных? Ты утверждаешь что их должно быть 70%-80%, а на проверку нужных сценариев предлагаешь отводить 20%-30% усилий?

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

Не спорю. Но ты на вопрос ответь. Ты предлагаешь тестировать негативные сценарии, которые по сути не нужны пользователю. Зачем это делать?

G>>Ты уже перешел в демагогию. Вместо описания каких-то проблем ты пишешь общие слова, которые все по разному понимают.
G>>Давай пиши конкретнее что ты имеешь ввиду.
V>Это общеупотребительные термины и мемы.
Как обычно за "общеупотребительными терминами" у каждого свое понимание. Дай ссылку на какие-нить источники, хоть википедию чтоли.


G>>ЗЫ. Если что я веб разрабатываю, там 99% exception перехватываются глобальным перехватчиком, а пользователю отдается сообщение что что-то пошло не так.


V>Совсем другое дело десктоп.

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

Стейт как всегда присутствует в двух местах: интерфейс и хранилище данных. Первый нормально изолируется с помощью паттернов mv*, второй с помощью грамотно проработанных интерфейсов.
Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее. А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.

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

ГВ>>>>>В том-то и дело, что у managed никаких проблем чисто внешне не было. Просто иногда, при некоторых условиях ошибочно создавались два потока чтения/обработки данных вместо одного.
ГВ>>>>Важно здесь не то, в чём именно заключалась ошибка managed (т.е. — в каком именно коде или алгоритме она была допущена), а то, что при её наличии managed-код молча "работал правильно".
G>>>Вообще-то нет. Очевидно что приведенный выше код будет демонстрировать разное поведение при разном количестве потоков. К сожалению оно будет не фиксировано, поэтому тесты могут и не отловить.
ГВ>>Правильно. Но принципиально тут планировался ровно один поток. Поэтому ошибка была вовсе не в отсутствии примитивов синхронизации, а в коде управления потоками (создание-пуск-остановка). В чём конкретно она состояла — сейчас совершенно не важно.

G>Да ну? Ты же начал говорить что проблема была в managed коде, но показать её не можешь. Приводишь только кусок кода к делу и не относящийся (судя по твои словам).

Именно. Я ж не алгоритмы управления потоками обсуждать собираюсь, а показываю именно кусок, прямо не относящийся к проблеме, который в unmanaged-варианте стал бы работать чёрт-те как, а в managed-исполнении работал вполне гладко (кроме иногда возникавших конфликтов в unmanaged-части).

Повторяю в ...-й раз: код, который вызывал unmanaged-часть, планировался, проектировался, разрабатывался и тестировался, как однопоточный.

G>Меня всегда прикалывали мнения вроде: вот Вася писал прогу на C#, она получилась глючной и медленной, он решил переписать её на C++. Знаете что обычно получается у таких вась и их программ?
G>Хороший кодер сможет на любом языке написать хорошую программу, плохой кодер на любом языке напишет плохую. Глупо приписывать эти свойства языку.

А я ничего никому не приписываю.