Pull to refresh

Comments 7

Зачем вы наврали про КОМ? Есть per-user registration. Есть вообще standalone com.
Да, Вы правы, уточнил в статье.
UFO just landed and posted this here
Все новое — это хорошо забытое старое :)
>Но если Вы не можете скомпилировать Ваш C++ код с ключем /CLI, то потребуется вводить дополнительную промежуточную C++/CLI библиотеку и прописывать в ней обертки для каждого вызова

Нет, достаточно компилировать с /clr только те файлы, которые предоставляют интерфейсную часть.
•В C++ код целесообразно выносить алгоритмы, критичные к производительности

Такие алгоритмы лучше всего распаралеливать… ибо только распарареливанием алгоритма можно получить хоть какоето значимое улучшение производительности в наше время. Задумайтесь… накой процесоры делалают многопроцессорными.

•В C++ код целесообразно выносить части, связанные с защитой приложения

Ой… уже страшно от одной этой фразы. «C++» и «защита» в одном предложении… Как вы думаете почему код скомпилированный С++ называют «неуправляемый код». И еще про замечательные стредства защиты .Net'a только я слышал? о_О

•Много старого кода написано на C++, и переписывать его весь — не лучшее решение

Старый код потому и называют старым… что его лучше лишний раз не стоить использовать… Хотя изобретать велосипеды, тоже не стоит…
Прошу прощения, тогда я почему-то пропустил Ваш комментарий. Т.к. сейчас я опубликовал новую статью по теме, думаю будет уместным ответить на возникшие вопросы:

> Такие алгоритмы лучше всего распаралеливать… ибо только распарареливанием алгоритма можно получить хоть какоето значимое улучшение производительности

Разница в производительности алгоритма написанного на C# и С++ весьма существенна, позже я планирую написать об этом. Распараллеливание может быть плюсом но не исключает требования к производительности каждого потока.

> Ой… уже страшно от одной этой фразы. «C++» и «защита» в одном предложении

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

>Старый код потому и называют старым… что его лучше лишний раз не стоить использовать

Разумеется это идеал, всегда использовать свежие технологии и свежий код, но т.к. проекты развиваются в течении многих лет, отказываться от всех наработок и начинать все каждый раз заново — неразумный ход. Разумеется есть и исключения, после набора проектом какой-то критической массы сложности сопровождения, может возникнуть необходимость переписать все полностью. Но это все же крайний случай а не типовая ситуация.
Sign up to leave a comment.

Articles