Посоветуйте инструмантарий для группового проекта определённой архитектуры

Пролог

многообещающее начало...

отформатируйте сообщение по-нормальному.

уберите слово «папка». не принципиально, но если уж вдаётесь в какие-то тех. подробности, то негоже.

почему именно с++? может не зря боятся? надеюсь, под с++ подразумевается не #include iostream

если Qt, так это и будет кути, а не плюсы. и слава боГу.

Ну и что тебя останавливает? Делаешь Qt Plugin в виде динамической библиотеки. В интерфейсе плагина предусматриваешь метод, возвращающий QWidget*, который в итоге будет встраиваться куда-нибудь в окно основной программы (на вкладку в QTabWidget, в QStackedWidget и т.п.), либо отображаться вообще отдельным окном. За логику поведения этого виджета соответственно будет отвечать конкретный плагин. Главное - хорошо продумай программный интерфейс этого плагина или вообще реализуй несколько типов плагинов со своими интерфейсами.

Благодарю, отформатировал. Конечно, под C++ подразумевается использование любых библиотек на вкус студента, только бы они компилировались в независимый подключаемый модуль.

Это было бы идеально, я с вами полностью согласен. Если бы я писал проект сам или с несколькими людьми, знающими С++\Qt, вопросов бы не возникало, но нужно иметь возможность эти плагины писать на паскале.

Condor (который в RedHat MRG используется). Систему можно гетерогенной забацать, взаимодействие хоть через ftp.

• Обязательное ревью кода. На всех уровнях — компилируемость, стиль (можно просто соблюдать стиль Qt), минимальность. Если получиться делать ревью с помощью веб-интерфейса, это будет шикарно (известные не варианты — пулл-реквесты github, gerrit, phabricator).
• Учите их также обсуждать правки вежливо и конструктивно.

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

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

Но к сожалению университет не даёт адекватного знания С++, если точнее, студенты просто боятся этого слова. В основном все кодят на паскале (Delphi)

Используйте clang как компилятор, он находит опечатки и даёт хорошую диагностику.

Это было бы идеально, я с вами полностью согласен. Если бы я писал проект сам или с несколькими людьми, знающими С++\Qt, вопросов бы не возникало, но нужно иметь возможность эти плагины писать на паскале.

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

Должна иметься возможность написания модулей на разных языках (необходимый и достаточный минимум - С++, Pascal).

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

Это было бы идеально, я с вами полностью согласен. Если бы я писал проект сам или с несколькими людьми, знающими С++\Qt, вопросов бы не возникало, но нужно иметь возможность эти плагины писать на паскале.

Тогда два пути:
1. Создать собственную библиотеку-обертку над требуемыми функциями Qt, которую уже будут использовать студенты в своем коде.
2. Фактически все тоже самое, только использовать какой-либо механизм IPC, например сокеты. Преимуществом данного подхода будет являться возможность подключения как 32-разрядных, так и 64-разрядных модулей (мало ли у какого студента какие ограничения).

Процесс конечно крайне утомительный, но при должном старании и хорошем продумывании интерфейса можно получить приемлемый результат.

Переучить на плюсы, имхо, не так сложно. Паскаль все же немного мертв и, имхо, ненужен.
Из советов, могу точно утверждать, что необходимо использовать системы контроля версий. git, svn etc. А то мне приходилось видеть подобные проекты, правда меньшего маштаба, которые хранили просто так. Это ужасно.

и не забывайте про систему документирования кода

actics

Переучить на плюсы, имхо, не так сложно.

К сожалению, не вариант. C++ изучается 1 год, и за этот год даже некоторые способные студенты не выносят ничего. Увы, если оставить поддержку исключительно С++ мы потеряем 90% студентов. Это ведь не обязаловка а что-то вроде факультатива.

m0rph

1. Создать собственную библиотеку-обертку над требуемыми функциями Qt, которую уже будут использовать студенты в своем коде.

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

2. Фактически все тоже самое, только использовать какой-либо механизм IPC, например сокеты.

Думал над этим, ещё не копал глубоко, на сколько это возможно и правильно.

no-such-file

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

Всё таки, программа должны быть «Батарейки в комплекте»

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

Необязательно оборачивать каждую Qt'шную функцию. Можно попытаться сделать только необходимые высокоуровневые вещи, хотя даже тут работы немало.

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

В clang уложились в один заголовок (и только с версии 3.2 выделили утилиты в 3 отдельных маленьких заголовка).

typedef struct STWindowImpl *STWindow;
STWindow stars_createWindow();
void stars_disposeWindow(STWindow *window);

Нужно написать программу на C++( желательно Qt ) с возможностью подключения дополнительного функционала в виде модулей (динамических библиотек ).

ябы рассчитывал на языки где не так легко отстрелить ногу (студенты способные писать на С++ так чтобы valgrind потом не говорил чистым русским «бъ» мне не встречались), с учетом кроссплатформенности это питон, а лучше даже яву

или зайти с другой стороны - делать плагины отдельным процессом - чтобы не роняли основной софт

К системам контроля версий еще систему управления проектом, типа redmine.

По архитектуре - мы пишем на связке С++/питон. На питоне верхний слой и интерфейс, на плюсах то что должно работать быстро в виде динамических библиотек. Есть шаблон макефайла, который делают всю работу по сборке библиотеки, включая запуск SWIG (нужно только задать имя библиотеки, перечислить хидеры и модули), поэтому для зеленого студента такая технология проблемы не представляет, порог вхождения крайне низкий.

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

Насчет документации уже сказали - прежде чем что то делать, это должно быть описано как можно подробнее, с формулами числ схемами и пр.

В колледже нам преподавали C, никакого Pascal.

Pascal открыл уже потом, так как изучая C, полностью игнорировал Pascal и как все подтрунивал над теми кто говорил что Pascal лучший, искренне считал их несведущими.

Pascal более современный язык чем C или C++. Если не говорить о Pascal образца 70-х, то это язык абсолютно ничем не уступающий C и C++, но обладающий преимуществами. Быстрая компиляция, этому способствует не только продуманный синтаксис языка, но и модульность.

Да даже за одну только модульность Pascal можно предпочитать по сравнению с C/++. Юниты(units)...

Free Pascal Compiler, кроссплатформенный, стабильно развивается(с поправкой на то что нет корпораций покровителей).

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

Гцц делает гораздо более эффективный код. Шаблоны там вроде были, но всякой низкоуровневой работы с памятью ЕМНИП так и не появилось. В общем то я не знаю никого, кто серьезно что то считал на Паскале...

или зайти с другой стороны - делать плагины отдельным процессом - чтобы не роняли основной софт

Давайте уж сразу свой язык придумаем, напишем ему компилятор. Обязательно под свою ОС. Крутящуюся на своём процессоре. Про чистоту добываемого кремния для этого процессора тоже сразу думать начинайте.

Не, ну есть же Кондор, зачем плохой велосипед изобретать? Тоже студентота, кстати, писала.

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

Гцц делает гораздо более эффективный код. Шаблоны там вроде были, но всякой низкоуровневой работы с памятью ЕМНИП так и не появилось. В общем то я не знаю никого, кто серьезно что то считал на Паскале...

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

В Pascal другой подход - библиотека должна быть читаемой. А если нужна максимальная производительность какой-то функции, то есть встроенный стандартный inline assembler. Думаю такой подход более логичен особенно с точки зрения создателей игр.

Вообще, любому человеку пишущему C модули для Python смешно слышать про то что компиляторы Pascal генерируют в 2 раза менее эффективный машинный код по сравнению с C. Python в 100~150 раз медленнее чем C(исключая строковые операции, они медленнее в 5-20 раз).

Просто эти малопонятные оптимизации внутри компилятора почти никому не нужны В НАЧАЛЕ ПРОЕКТА. К тому же они мешают развитию компилятора. Думаю поэтому и считают стиль в котором написан GCC - макаронами. Каждая корпорация вносит свои макароны, лучше бы они это делали в своём коде а не на уровне оптимизаций компилятора, который должен легко переносится на все платформы без осложнений.

В Pascal другой подход - библиотека должна быть читаемой. А если нужна максимальная производительность какой-то функции, то есть встроенный стандартный inline assembler.

Взаимоисключающие параграфы.

Просто эти малопонятные оптимизации внутри компилятора почти никому не нужны В НАЧАЛЕ ПРОЕКТА

-O0

К тому же они мешают развитию компилятора.

man llvm

Думаю поэтому и считают стиль в котором написан GCC - макаронами.

Согласен, только вот GCC лишь полгода назад начали компилировать плюсовым компилятором.

Зыбкая почва...

Трудно понять что кому нужно, т.е. программистам и астрономам например. Так как множества их знаний пересекаются частично, а чаще вообще не пересекаются.

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

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

Free Pascal обратно совместим со многим известным Delphi. Проект может быть скомпилирован указав компилятору главный файл проекта, это модульность.

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

Задачи создавать динамические библиотеки подходят только для студентов программистов. Любая ошибка в подключаемой библиотеке - и программа не работает. Это может подавить студента и он уйдёт в запой.

Выделение таких задач в отдельные процессы - единственно правильное решение, и подходит для этого идеально Python, в стандартной библиотеке которого всё для высокоуровневой манипуляции процессами. И в огромной степени это соответствует принципу «батарейки в комплекте» - ничто другое не сравнится.

Задачи создавать динамические библиотеки подходят только для студентов программистов. Любая ошибка в подключаемой библиотеке - и программа не работает. Это может подавить студента и он уйдёт в запой.

Когда флеш у вас упадёт, тогда придёте и будете тут оверинжинирингом заниматься. А пока попробуйте объяснить младшему братишке суть сокетов. Поймёт — возвращайтесь.

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

Вовсе нет. GCC делает более эффективный код просто потому, что он умеет делать более эффективный код. Коллеги, когда то писавшие ассемблерные вставки давно перестали это делать, просто потому что GCC делает это не хуже человека (как правило лучше).

А если нужна максимальная производительность какой-то функции, то есть встроенный стандартный inline assembler. Думаю такой подход более логичен особенно с точки зрения создателей игр.

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

Вообще, любому человеку пишущему C модули для Python смешно слышать про то что компиляторы Pascal генерируют в 2 раза менее эффективный машинный код по сравнению с C. Python в 100~150 раз медленнее чем C

Для интерфйеса и верхнего слоя скорость вообще не важна, он даже на питоне занимает меньше 1% по времени. Можете переписать его на С и получить выигрыш на 0.99%. Или переписать С-шные либы на паскале и получить проигрышь вдвое. И правда смешно...

Просто эти малопонятные оптимизации внутри компилятора почти никому не нужны В НАЧАЛЕ ПРОЕКТА.

Ага. Давайте заложим вначале проекта заведомо тормознутое решение, что бы потом когда упремся в производительность рвать волосы по всему телу и искать транслятор паскаль -> С;-)

Хочу заметить, что слухи об аццкой сложности C++ для числодробилок сильно преувеличены.

me:

В Pascal другой подход - библиотека должна быть читаемой. А если нужна максимальная производительность какой-то функции, то есть встроенный стандартный inline assembler.

you:

Взаимоисключающие параграфы.

Отнюдь, скорее всего ваша дислексия.

Не я диктую стандарты, и всего лишь описал своё видение свободного проекта компилятора в котором это моё видение соблюдается в большей степени.

Inline assembler как стандарт скорее языка а не компилятора(хотя в обоих языках это не так чётко определенно) позволяет разработчикам создавать функции с максимально возможной проиводительностью доступной процессору, а продуманный синтаксис, модульность, и отсутствие ненужных оптимизаций в компиляторе предоставляют максимально возможную скорость компиляции.

В Pascal это всё лучше реализовано.

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

Ничего что я например вообще не программист?;-)

Задачи создавать динамические библиотеки подходят только для студентов программистов. Любая ошибка в подключаемой библиотеке - и программа не работает. Это может подавить студента и он уйдёт в запой.

Никто из наших студентов не является программистом (во всяком случае поначалу, некоторые потом скурвливаются и уходят в банки-шманки где из них делают кодеров;-)), но все пишут подключаемые библиотеки и почти никто не пьет (про запои вообще не слышал). ЧЯНТД? ;-)

Я понял ход ваших мыслей, но это никак не опровергает мои утверждения, и не заставляет меня отказаться от моего мнения.

Ага. Давайте заложим вначале проекта заведомо тормознутое решение, что бы потом когда упремся в производительность рвать волосы по всему телу и искать транслятор паскаль -> С;-) Хочу заметить, что слухи об аццкой сложности C++ для числодробилок сильно преувеличены.

Это предложение к сотрудничеству? Вынужден отказаться. ))

программист, кодер..

Это уже лингвистические анекдоты из курилки и желание создать нерациональную иерархию основываясь на обстоятельствах и на личных вредных интересах. А я не курю.

В армии подобное надо искоренять. А они картошку чистят в сапогах...

но это никак не опровергает мои утверждения

С частью из Ваших утверждений (про питон например) я согласен, другие Ваши утверждения не верны. Но убеждать Вас в чем либо не входит в мои интересы.

Это предложение к сотрудничеству? Вынужден отказаться. ))

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

Это уже лингвистические анекдоты из курилки

Б-г с Вами, какие анекдоты... суровая проза жизни.

Непонятно, что конкретно должны делать модули.

Можно разделить каждый модуль на 2 части:
1) Демон, реализующий обработку данных, которым можно управлять удаленно.
2) Плагин qt, реализующий виджет для управления модулем.

Один студент напишет демон на паскале, а второй морду к нему на qt. Как бонус становится сложнее перемешать логику и gui.

Для связи с демоном можно взять какой-нибудь RPC вроде SOAP.
Можно вместо RPC разработать свой протокол, одинаковый для всех модулей, и проектировать систему используя протокол как отправную точку.

Если модули чисто расчетные, я бы использовал MPI либо изучал предложенный выше Condor или аналоги.

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

Сейчас я пишу на PHP(Silex, Symfony), мне не грустно и не одиноко(в данном контексте).

Что бы выразить отношение к паре Pascal/C++, использую аллегорию.

C++ это танк Тигр.

Его трудно собирать, трудно эвакуировать подбитый от линии фронта, бензиновый двигатель, точная пушка, но броня под углом 90 градусов к попаданию, хорошая рация. Даже замена и установка гусеницы сложная операция. Тигр обуза с точки зрения логистики, не только в производстве. Он настолько сложен в производстве что даже наивный саботаж рабов остарбайтеров создаёт проблемы. Появляются усовершенстовования во время войны, которые ещё усложняют производство. Ограниченный запас хода, мощный удар, немного проехал дальше окопа и остановился. Далее работают другие, малые танки произведённые на заводах Чехии, средние немецкие танки. Но все тоже с бензиновыми двигателями.

Pascal это T-34.

Дизельный двигатель, большой запас хода, броня под углом 45 градусов, американская рация и тип подвески. Широкие траки гусениц, низкий профиль. Разрабатывался аж с 31 года, но в войне уже стал массовым и эффективным при меньших затратах и более продуманной конструкции.

Разрабатывался аж с 31 года, но в войне уже стал массовым и эффективным при меньших затратах и более продуманной конструкции.

К сожалению, вы глубоко заблуждаетесь в вопросе продуманности. Ну а если вы считаете паскаль имеющим более глубокую продуманность и потенциал, чем C++, то вы просто не знаете C++ — иначе объяснить это не могу. Проблемы у C++ со сложностями в создании полноценных, надёжно работающих инструментов и некоторым наследием от C, а батареек хоть отбавляй.

К слову: паскаль быстрее компилируется не из-за «продуманного синтаксиса», это частое заблуждение. Долгое время компиляции плюсов — это парсинг + оптимизации, и если оптимизации не замедляют компиляцию паскаля ввиду их отсутствия, то с парсингом немного сложнее. Долгий парсинг плюсов — это сочетание сразу трёх вещей: #include вместо импорта символов вкупе с препроцессором, необходимости описывать многие вещи в заголовках и собственно парсинга / семантических проверок.

Но я вас обнадёжу: ни одному хейтеру плюсов ещё не удалось правильно назвать недостатки плюсов, без детального изучения и опыта работы с ними.

К слову: паскаль быстрее компилируется не из-за «продуманного синтаксиса», это частое заблуждение.

Именно поэтому, и из-за модульности выражающей зависимости частей кода, пригодной для кэширования результатов компиляции, понятной самому компилятору а не только какому-то makefile.

Обозначение указателя знаком умножения никак не упрощает описание синтаксиса для парсеров(компиляторов и IDE). Знак «^»(префиксный и постфиксный) для указателя и более логичен и приятен для чтения и человеком и программой.

Инкремент и декремент в Pascal выглядящие как библиотечные функции inc() и dec() мне больше нравятся чем явные операторы ещё более вносящие неопределёность и нагрузку на инструменты.

Другие аналогии:

C++ <-> PHP, создавались из целесообразности, невзирая на то как достигать этих целей.

Pascal <-> Python.

Однажды Никлас Вирт приехал в Италию и спросил - «Нравится ли вам Паскаль?» - «Si!» сказали итальянцы. Вирт обиделся и больше в Италию не ездил...

Аллегория забавная, но далекая от. С++ ужасный ЯП, но его ужасность отчасти связана с присущей ему смесью всякой низкоуровневой лабуды и высокоуровневых абстракций. Паскаль все таки делался для обучения в первую очередь (ЕМНИП), да он куда строже и продуманней... но и возможности у него поскромнее.

Именно поэтому, и из-за модульности выражающей зависимости частей кода, пригодной для кэширования результатов компиляции, понятной самому компилятору а не только какому-то makefile.

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

Один студент напишет демон на паскале, а второй морду к нему на qt. Как бонус становится сложнее перемешать логику и gui

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

Программа должны быть в стиле «батарейки в комплекте» (то есть - исполняемый файл, каталог с модулями ).

Если я влезу в СОАП, то это ещё куча проблем с IDL, c интерфейсами передачи, и это не объяснишь студенту.
tp_for_my_bunghole, quiet_readonly, прошу вас - прекращайте холивар. Я не могу отказаться от Pascal вовсе не из любви к нему. На питон перейти не могу, так как питон люди начинают изучать на 4 курсе ( на мой взгляд, его надо давать на первом, как приложение к какой нибудь Теории Алгоритмов или Дискретной математике)
mv Condor - малопопулярная технология. На сколько я понял, это что-то на подобие SOAP и требует какого-то запущенного своего процесса. Увы, так низя.

К слову: паскаль быстрее компилируется не из-за «продуманного синтаксиса», это частое заблуждение.

Я не хейтер плюсов. Не изучал pascal ни в школе ни где либо ещё по программе которую составил кто-то другой.

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

Зато полно разочаровавшихся «иммигрантов», которые или в думах/печали, или приобретают синдром «подсознательного оправдания травмы иммиграции».

Ну там же документацию легко на сайти у них найти...

один из немногих , хоть корявеньких, но выходов.

Есть мнение, что разделение на процессы обычно лучше разделения на бибилотеки, если задача позволяет.

Программа должны быть в стиле «батарейки в комплекте» (то есть - исполняемый файл, каталог с модулями ).

Что это значит? Что запрещено запускать дочерние процессы?

На сколько я понял, это что-то на подобие SOAP

Нет :)

Если ваш проект не зависит от сторонних библиотек пишите на том, на чем готово писать большинство, иначе C/Cpp only. Как компромис по квалификации это Python но с производительнотью тут совсем тяжко.

Самое главное - Программа должна быть кроссплатформенна

Если нужно полноценный GUI без заморочек то Qt

Должна иметься возможность написания модулей на разных языках

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

Нельзя использовать технологию COM, так как писать модули будут совсем зеленые ребята.

Только из-за этого? А как же кросс-платформеность?

Программа должны быть в стиле «батарейки в комплекте»

Статическая сборка под nix

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

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

Я бы посоветовал ядро написать на чем угодно(C/C++/Pascal) а модули расширения через какуюнибудь встраиваемую Lua.

А зачем и правда динамические библиотеки? Нужна общая память? Если с плагинами нужно обмениваться небольшими данными - так и делайте плагины отдельными программами. Обмен данными через stdin/out/err пайпы. Договоритесь о протоколе (или там напишите маленькие библиотеки для C/C++/Pascal).

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

Тут видится некоторая сложность в отладке (вот конкретно для студентов с Дельфи), но тоже можно что-то придумать.

Долгое время компиляции плюсов — это парсинг + оптимизации

И разворачивание шаблонов. Для библиотек типа буста это занимает приличное время.

вы не о том думаете.

пример: Большая (и очень многолетняя) система мат.моделирования, отдельные расчётные части делались студентами и аспирантами в течении поколений. На С,C++,Фортране. В разработке отдельных модулей отмечались авторы будущего stl и другие не менее известные ныне личности. Отгадайте на чём был сделан «каркас» и какие части чаще переделывались и почему ?

Prolog!

Отгадайте на чём был сделан «каркас» и какие части чаще переделывались и почему ?

Сам каркас + интерфейс чаще всего и переделывались?

На чем написан угадать не берусь... на баше? Наверное каждый новый лидер переписывал его на своем любимом ЯП;-)

Отгадайте на чём был сделан «каркас»

На коленке

какие части чаще переделывались и почему ?

Системы инициализации, NIH-синдром.

Доктор, я угадал?

Есть проблема, если вы мне посоветуете более элегантное решение - буду очень вам благодарен.

постучись в гуглочат. адрес в профиле есть. проконсультирую по распределенным архитектурам на Qt4 C++

Ещё раз по пунктам.

1. Паскаль таки-можно собрать в разделяемую библиотеку, и можно вызывать функции паскаля из C++ и наоборот, если использовать extern «C». Вот, сделал прототипчик в виде проекта для QtCreator (сборка и запуск там настроены).

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

2. Раз уж имеете дело со студентами, рекомендую выбрать максимально облегчающие работу инструменты. Clang как компилятор я уже советовал, а если работы начнутся не раньше сентября — можно глянуть на плагин ClangCodeModel для QtCreator, у него гораздо более точное автодополнение и есть подчёркивание ошибок/предупреждений прямо по месту появления со всплывающей подсказкой. Git и какой-либо инструмент для ревью кода также помогут.