Против грамотных людей вообще мало что поможет.
А я предлагал не решение, а вариант в виде антиутопии:
TPC повсеместно, софт запускается только подписанный персональными ключами,
ключи имеют срок действия + можно их отзывать.
В такой ситуации количество зловредного кода будем меньше, мне кажется.
Проще сделать программирование лицензированной деятельностью:
Есть лицензия — есть ключ, без подписи программа не запускается.
Нет лицензии, значит не запустится.
Да.
Есть книга Malicious Cryptography, где в качестве примера указывали применение для автора вируса:
Каждый экземпляр перед размножением увеличивает счётчик на единицу и только автор потом может анализировать результаты.
Как я понимаю, у них есть понятие действия по защите ТМ, и если их не предпринимать, то ТМ попадёт в общественный доступ.
Поэтому такие иски выставляются на автомате.
Для нас COM в первую очередь — компонентная архитектура. Она позволяет достичь модульности и независимости компонентов друг от друга.
COM на самом деле тяжеловесен и громоздок, но при работе над крупным многокомпонентным проектом открывается, что это всё нужно.
Я думаю, что если бы у нас не было COM, то мы бы придумали какой-нибудь его недоработанный аналог.
CORBA в принципе тоже подошла, но тогда бы был отдельный геморрой интеграции с .NET.
Немного поддержу автора:
мы также использовали такой подход (каскадированные автоматы), но совсем не потому, что не знали преимуществ RTOS, или боялись мутексов и потоков.
Причиной явилось то, что нам достаточно легко удалось доказать временные характеристики реакции системы.
Позже плюсом оказалось то, что при анализе остановов по логам, знание циклограммы позволяло достаточно точно восстановить состояние в эти моменты и сделать выводы (например, однажды, наш анализ помог нам перейти из состояния виновные в состояние свидетели).
Минусы этого подхода также очевидны: повышенная сложность разработки, которая требует определённого склада ума. Также плюсы и ограничения этого подхода обычно новому разработчику сразу не очевидны и требуется определённая работа при обучении.
If you have a scenario where this data structure is more optimal than a string builder, I would be curious to know what it is. It has been my experience that rope data structures are almost never a win over the raw speed of native string or string builder operations in typical cases, so I am very interested to see realistic scenarios where its a win.
My experience is admittedly limited; I've tried to add rope-style string representations to languages like VBScript and JScript. The number of cases in which we must aggressively reify internal strings into «real» buffer-based strings was so large, and the number of cases where runtime string manipulations actually grew large, complex strings was so small, that the net perf impact was negative. When we built the string logic in JScript.NET we simply used a stringbuilder rather than attempting ropes again.
Вы постоянно переключаетесь между студией и Vim, или MyClassImpl.cpp редактируете в Vim, а остальные в студии 0_o?
Я нажимаю горячие клавиши и у меня открывается gVim в том же месте, где я находился.
Что подразумевается под сложным редактированием?
Например, чтобы разобраться в сложном неизвестном мне коде нужно было залогировать вызовы методов (а там их были многие десятки), для этого я записал два макроса:
один на переход на определение следующего метода, второй вставку кода логирования.
Всего это заняло около 10 минут в полуавтоматическом режиме и то только из-за того, что поленился поточнее сформулировать признак следующего метода, но если не попадал, то @@.
В ручную я бы потратил гораздо больше времени.
Другой пример, иногда требуется переколбасить громоздкий код, тогда просто удобней то, что много регистров копирования и то, что VIM понимает объекты типа внутри фигурных/круглых скобок, можно накопировать нужных участков и расставить их как надо.
Больше трёх регистров я использую только для макросов.
Для статистики:
из-под windows, C++, целевая платформа: Embedded.
Сейчас использую VIM совместно со студией, вызываю по горячей клавише для быстрого сложного редактирования.
Для меня основные преимущества именно в качестве редактирования: когда в редакторе VS делаешь что-то большое, очень не хватает команд VIM, прямо раздражение какое-то испытываешь.
А как IDE VS+VisualAssist меня больше устраивают в плане навигации по большому проекту.
А я предлагал не решение, а вариант в виде антиутопии:
TPC повсеместно, софт запускается только подписанный персональными ключами,
ключи имеют срок действия + можно их отзывать.
В такой ситуации количество зловредного кода будем меньше, мне кажется.
Есть лицензия — есть ключ, без подписи программа не запускается.
Нет лицензии, значит не запустится.
Просто, доступно и интересно, почти как книга Еськова.
Есть книга Malicious Cryptography, где в качестве примера указывали применение для автора вируса:
Каждый экземпляр перед размножением увеличивает счётчик на единицу и только автор потом может анализировать результаты.
1989й год, но содержит всё, чтобы помочь человеку, обдумывающему архитектуру своего стекового процессора.
Поэтому такие иски выставляются на автомате.
COM на самом деле тяжеловесен и громоздок, но при работе над крупным многокомпонентным проектом открывается, что это всё нужно.
Я думаю, что если бы у нас не было COM, то мы бы придумали какой-нибудь его недоработанный аналог.
CORBA в принципе тоже подошла, но тогда бы был отдельный геморрой интеграции с .NET.
мы также использовали такой подход (каскадированные автоматы), но совсем не потому, что не знали преимуществ RTOS, или боялись мутексов и потоков.
Причиной явилось то, что нам достаточно легко удалось доказать временные характеристики реакции системы.
Позже плюсом оказалось то, что при анализе остановов по логам, знание циклограммы позволяло достаточно точно восстановить состояние в эти моменты и сделать выводы (например, однажды, наш анализ помог нам перейти из состояния виновные в состояние свидетели).
Минусы этого подхода также очевидны: повышенная сложность разработки, которая требует определённого склада ума. Также плюсы и ограничения этого подхода обычно новому разработчику сразу не очевидны и требуется определённая работа при обучении.
1:
2:
Тут мне кажется, что порядок их описания будет уже случайным (в смысле зависить от чего-то ещё).
Я нажимаю горячие клавиши и у меня открывается gVim в том же месте, где я находился.
Например, чтобы разобраться в сложном неизвестном мне коде нужно было залогировать вызовы методов (а там их были многие десятки), для этого я записал два макроса:
один на переход на определение следующего метода, второй вставку кода логирования.
Всего это заняло около 10 минут в полуавтоматическом режиме и то только из-за того, что поленился поточнее сформулировать признак следующего метода, но если не попадал, то @@.
В ручную я бы потратил гораздо больше времени.
Другой пример, иногда требуется переколбасить громоздкий код, тогда просто удобней то, что много регистров копирования и то, что VIM понимает объекты типа внутри фигурных/круглых скобок, можно накопировать нужных участков и расставить их как надо.
Больше трёх регистров я использую только для макросов.
из-под windows, C++, целевая платформа: Embedded.
Сейчас использую VIM совместно со студией, вызываю по горячей клавише для быстрого сложного редактирования.
Для меня основные преимущества именно в качестве редактирования: когда в редакторе VS делаешь что-то большое, очень не хватает команд VIM, прямо раздражение какое-то испытываешь.
А как IDE VS+VisualAssist меня больше устраивают в плане навигации по большому проекту.