ну как же неправда... вы возразили "если вам есть что возразить по всем пунктам, то сделайте это культурно", из чего я заключаю вывод, что вам непонятно... далее я пытаюсь разложить свою точку зрения по пунтам, отвечая на ваши тезисы:
"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..." ты сам по понимаешь что написал? не совсем культурная форма, конечно, но тут я попытался объяснить, что то, что кто-то считает чью-то ссылки вовсе не означает, что гадят память, ибо с таким же успехом можно предположить что память гадят CStringT, _bstr_t, shared_ptr, shared_array, auto_ptr и так далее... они тоже считают ссылки... inproc COM сервер мало чем отличается от dll, которая экспортирует функции.
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
тут я попытался объснить, что следуя этой идее, т.е. запрещать чужому коду лазить в собственное пространство, нужно вообще не использовать сторонних библиотек (dll), да и обычных типа MFC тоже (по хорошему). а это является полностью impossible
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы" да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее тут я попытался объяснить, что идиома RAII (shared_ptr, auto_ptr и так далее) позволяет для небольших проектов избежать вообще проблем с указателями... для больших неудается, так как чем больше проект тем больше людей которые только думают, что знают цепп... а в очень больших проектах - такие ошибки просто есть... но они уже лежат на другом логическом уровне, чем просто неверная работа с указателями
ну и так далее... если вам все еще было непонятно о чем речь = не понятны отдельные тезисы или их связь с вашим комментом, то можно было задать вопрос
no subject
"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..."
ты сам по понимаешь что написал?
не совсем культурная форма, конечно, но тут я попытался объяснить, что то, что кто-то считает чью-то ссылки вовсе не означает, что гадят память, ибо с таким же успехом можно предположить что память гадят CStringT, _bstr_t, shared_ptr, shared_array, auto_ptr и так далее... они тоже считают ссылки... inproc COM сервер мало чем отличается от dll, которая экспортирует функции.
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
тут я попытался объснить, что следуя этой идее, т.е. запрещать чужому коду лазить в собственное пространство, нужно вообще не использовать сторонних библиотек (dll), да и обычных типа MFC тоже (по хорошему). а это является полностью impossible
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы"
да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее
тут я попытался объяснить, что идиома RAII (shared_ptr, auto_ptr и так далее) позволяет для небольших проектов избежать вообще проблем с указателями... для больших неудается, так как чем больше проект тем больше людей которые только думают, что знают цепп... а в очень больших проектах - такие ошибки просто есть... но они уже лежат на другом логическом уровне, чем просто неверная работа с указателями
ну и так далее...
если вам все еще было непонятно о чем речь = не понятны отдельные тезисы или их связь с вашим комментом, то можно было задать вопрос