OberonCore

Аналог вот этого "по общей схеме" после еще некоторых размышлений я бы предложил такой:

Вместо ro_export<> можно просто геттер сделать (я бы так и предпочел), но если хочется макисмально повторить оригинал (например чтобы потом однозначно восстановить) - то так нагляднее. Да, писанины больше - это цена за "неродной" для C++ стиль инкапсуляции. Однако писанина чисто механическая, никаких проблем "перевода" она не создает.

P.S. Реализация ro_export тривиальна, что-то типа:

Не всех со всеми, а явно связываем конкретную запись с конкретным модулем. Ну нету в C++ ключевого слова "MODULE". Поэтому приходится ручками прописывать то же самое, но другими средствами.



Нет, все N сущностей прописываем в классе, который назван ModuleX. Каждому рекорду который принадлежит модулю - прописываем friend class Module. Вполне логично. Не так красиво, конечно, но и не сказать, что ужасно. А главное - идея не теряется, код однозначно преобразуюется. Чего никак нельзя сказать об обратном переводе.

Насколько я понимаю, известный транслятор с Оберон-2 на C Ofront более-менее механически транслирует код на Oberon-2 в C включая GC. Транслятор на C++ мог бы, видимо, выдавать код еще ближе к обероновскому оригиналу. Заодно решая проблему многоплатформенности:-)

Что Вы имеете в виду? Не преобразуется или преобразуется неоднозначно?

Преобразуется и вполне однозначно.

О чем первая цитата тогда?

Обратный перевод чрезвычайно трудоемок, если программа изначально написана на C++ и использует такие возможности языка, которые не имеюют прямого отражения в оберон: шаблоны, исключения, конструкторы/деструкторы и т.д.

Возможно. Может и не надо никому.

Не хорошо. В Python нет friend (или уже есть?) и оператор import -- транзитивный (т.е., как include в C).
"Модули" в Python скорее условно равны: namespace + include.

Проблема с Oberon-2/Component Pascal.
Связанные процедуры разных записей одного модуля имеют полный доступ ко всем полям (своих параметров).
В результате либо необходимо объявить гораздо больше фрэндов (думаю не сложно построить пример где потребуется порядка N*N фрэндов) либо отобразить вначале в Oberon (т.е., конвертировать связанные процедуры в указатели и процедуры модуля).

Гхм. А нафига нужен friend?



Ничего общего с сишным инклудом.




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

Тогда лучше использовать вот такой подход (без френдов вообще):

.h


.cpp

В том то и проблема, что квалифицированный импорт... тоже транзитивный.

Опишите конкретную проблему?

Суммируя: для отображения совершенно тривиальных вещей (readonly export, module), необходимо применить почти весь аппарат C++.
В одном решении: friend, const&, templates,
В другом: inheritance, dynamic_cast, const& и переход от автоматической памяти к динамической.

Да, автоматический преобразователь что-то там на генерирует (а что с garbage collector?), но руками это далеко не тривиально (и даже мучительно).
При всем при этом о безопасности можно забыть.

Так что...трудности скорее есть, чем нет.

Аналогично, как поднять из ассемблера, написанного вручную, до ЯВУ... Фобия Старуструпа не включить в язык какую-нибудь частность на какой-нибудь "авось понадобится" - просто... беспрецедентная. Это, знаете, как студент-троечник засовывал бы в базис дополнительный линейно зависимый вектор, просто потому, что боялся бы, что "вдруг не хватит".

modA.py:
modB.py:
modC.py:
модуль modC не импортировал modA, но он имеет доступ к его переменным и функциям.

Хе-хе Вы не представляете себе масштабы "аппарата" С++ То, что здесь было показано - это даже не цветочки Тривиальные вещи.



Не понял. Чем вам не нравится последнее решение? Там нет ни одного из "ужасов", о которых вы пишите



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



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

Все правильно, только наоборот C++ - это ЯВУ, и чтобы из него получить ассемблер в лице оберона - надо попариться (поработать компилятором).

И чего? Где проблема то? И импорт здесь вообще никаким боком. Просто модуль в питоне это не просто ключевое слово, но и рефлективная сущность, что вполне логично для динамического языка. Я уверен, что тоже самое вы и в BB сможете сделать, задействовав рефлекшин. То, что на питоне этого добится проще - скорее плюс, чем минус.