OberonCore

Некая программа написана на нативном (не CLI) C++ в среде Visual Studio 2005. К ней надо сделать плагин. Возможно ли такое, и если да, то как? Какой язык для этого лучше использовать? У меня есть пример плагина на C++, но перспектива дописывать его на этом языке вгоняет меня в депрессняк.

Я точно знаю, что один из плагинов для этой программы сделан на языке Ruby (для этого сначала реализовали промежуточную DLL на C++, которая вызывается и из основной программы, и из скрипта на Ruby). Понятно, что так можно и на VBA написать, но хотелось бы нативно скомпилировать.

Платформа Windows 7+ 32-bit. Особых требований к языку нет. Меня бы и FreePascal устроил, но он криво DLL генерирует. А мне надо надежно. Не хочу потом ловить гейзенбаги и думать, куда утекает память. Может, стоит Modula-2 использовать? Я где-то слышал, что DLL лучше писать на языках без GC.

viewtopic.php?f=30&t=1037
viewtopic.php?f=30&t=2205
viewtopic.php?f=30&t=2027

Те плагины, что попроще, сделаны без GC и даже без Runtime, а те, что посложнее, используют GC, так что примеры всего спектра возможностей есть в исходниках. См. также http://sourceforge.net/apps/mediawiki/n ... in_Central (поиск по строке "Alexander Iljin").

Целевая программа (для которой плагины) - Notepad++, написана на нативном C++ в Visual Studio.

Спасибо! Заодно решился вопрос, какой редактор лучше использовать.

Я посмотрел исходник Oberon-2 Lexer (пару файлов по диагонали) и заметил слово ASSERT. Это контрактное программирование? А юнит-тесты применяете?

См. blackbox15i21base/i21sys :

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

В моих плагинах, по-моему, нет юнит-тестов, но вообще на при работе на Oberon-2 я автоматические тесты внедрял и использовал довольно активно.

Юнит-тесты это в модульной системе понятие ... ну, избыточное.

Для каждого модуля пишутся тесты, и всё.

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

Контрактное программирование -- тоже некое избыточное понятие.

Неконтрактное программирование -- это не программирование, а так ... чмо.

Для каждой процедуры есть пред- и пост-условия.
На всё втыкаются АССЕРТы на уровне инстинкта.

Я детишкам в самом начале логики показываю фрагмент из "Леона":

-- Проверь. Убедись, что это именно то, что тебе нужно.
-- Я тебе доверяю.
-- Не путай одно с другим, Леон!

Это оно и есть.

Задачей ASSERT является проверка данных параметров во время исполнения программы, в то время как проверкой типов параметров занимается компилятор на этапе компиляции модуля КП.

ASSERT и есть проверка соответствия контракту, при нарушении которого программа завершается нештатным образом.

Правда?!