Как совместить Python для быстрой разработки "обертки" и С++ для "вычислительного ядра"?

В свое время у Страуструпа прочитал, что надо обязательно делать прототип будущей программы, который выполняет роль каркаса без наполнения конкретным функционалом. Подобный прототип:
1. Сразу показывает основные несостыковки проекта (без всяких uml).
2. Позволяет при наполнении подсистем более точно чувствовать их смысл и содержание.
3. Упрощает проектирование всей системы (не сваливаясь в детали задается структура проекта).

Появилась идея писать прототип на языке быстрой разработки, и только поняв узкие места производительности применять эффективный С++. Это позволит львиную долю кода написать значительно быстрее (и опять же упростит систему, внеся дополнительное разделение проекта).

Но! Нужно чтобы отладка происходила "бесшовно", т.е. я начинаю использовать отладчик Python, а по мере спуска по стеку вызовов автоматически (без лишних движений с моей стороны) стартует отладчик для С++, а потом при поднятии по стеку- опять отладчик Python.....

Как такое организовать?

AlekseySQL,
что делать то хочешь?

для начала нужно выбрать:

либо расширяешь питон

либо встраиваешь его

kealon(Ruslan)
AlekseySQL, что делать то хочешь? для начала нужно выбрать: либо расширяешь питон либо встраиваешь его

Вы не поняли мою мысль: я ничего никуда встраивать не хочу и такими категориями вообще не мыслю. Я хочу разделить проект на кусок занимающий 90% времени выполнения (вычислительное ядро) и вспомогательный код (обертка). Первое пишется на С++, второе- на Python.

AlekseySQL,

поясню

пишешь модуль для питона

встраиваешь интерпретатор питона в своё приложение

соответственно, в каждом случае стратегия будет отличаться

AlekseySQL,

разъясню вторую ситуацию на примере

я встраивал в своё приложение VBScript (язык не суть важен, попутно оно и JScript и со своим движком работало)

соответственно саму программу я спокойно отлаживал в IDE - тут делать ничего не нужно
для скриптого безобразия я делал фактически IDE (редактирование, отладка и пр.).
Фактически я мог сесть за любой ПК и отладить скриптовое безобразие, но естественно не нативный код

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

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

kealon(Ruslan)
AlekseySQL, поясню пишешь модуль для питона встраиваешь интерпретатор питона в своё приложение соответственно, в каждом случае стратегия будет отличаться

Это проект, в котором часть файлов написано на Python, а часть на С++.

Возможен такой стек вызовов:
С++
Python
C++
Python

Что здесь во что вложено?

AlekseySQL
Возможен такой стек вызовов: С++ Python C++ Python Что здесь во что вложено?

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

kealon(Ruslan)
AlekseySQL Возможен такой стек вызовов: С++ Python C++ Python Что здесь во что вложено? если вы не можете хотя бы для себя решить, что у вас первым запускаться будет, то наверное вам рано до таких проектов

Всегда считал, что задача определяет инструменты, а не наоборот. Например, тот набор стека, который я привел может выполнять следующие действия:
С++ - интерфейс, написанный на Qt.
Python - макрологика приложения (код который в программе выполнится 1 раз).
C++ - конкретная вычислительная задача.
Python - любые обслуживающие действия для основных вычислений, например, запись промежуточных результатов вычислений в файл.

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

AlekseySQL,

пока расклад такой: каждый пилит что может, готовое врят ли кто даст

запуск скрипта - десяток строчек,
нужна отладка - пиши IDE или минимум расширение-отладчика для студии

можно конечно закостылить типа CGI, но кажется вам такой вариант не понравится по скорости

AlekseySQL,

Насчет быстрого прототипирования - идея верная.

А обоснование использования отладчика слабое.

Есть 2 серъезных кейса когда отладчик нужен.
1) фиксится баг. Но логгирования недостаточно чтобы понять что происходит в prod или QA environment.

2) изучение или исследование чужого кода в динамике.

В вашем случае - не первое и не второе.

Так что там у вас?