OberonCore

Модератор: выделена тема. Инициирующее сообщение - viewtopic.php?p=31833#p31833

Какие трудности? Оно один в один транслируется. Вот наоборот - это да... Или у вас каждая программа на обероне жить не может без динамической загрузки модулей и рефлекшина?

Частично экспортируемые записи в C++ будут выглядеть как полностью открытые структуры или у Вас есть другое решение?

Они буду выглядеть как private...

И как их юзать "вне модуля"?
Если предложите аксессоры, так это тот же public.
Короче, как всегда, вам бы поспорить.

В смысле как? Если они неэкспортируемые, то зачем их юзать вне модуля? Все экспортируемые сущности прописываете в .h-файле, некспортируемые поля прописываете private, все методы кладете в одноименный .cpp. Вот вам прямое отображение обероновского модуля в плюсовый "модуль". Где "острые" ощущения?



Это вам - лишь бы пнуть C++ Надо быть хоть чуть-чуть объективнее.

В кавычках вокруг слова модуль.

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

А. Значит шашечки. Так бы сразу и сказали

Это значит, что у народа закончилось терпение с Вами дискуссировать.
Один я еще на что то надеюсь.

Поля должны быть скрытыми для всех сущностей вне модуля, но открытыми для всех сущностей внутри модуля.
В С++ Вам этого не отобразить.

Ада -- "да". Ява с ее пакетами, хоть как то "да". С++ -- "нет", Питон (насколько я знаю) -- тоже "нет".

Ну, понятно. Для плюсников безопасность -- шашечки.

Еще раз - вам шашечки или ехать? Я говорю - что все конструкции оберона замечательно перекладываются в C++ "один в один" без потери смысла и без напряжения мозга. С точностью до синтаксиса. Конкретные возражения будут?
.h


.cpp


Тут что-то не понятно? Но ладно, допустим вам позарез надо иметь доступ к Record1::y из функции f2, причем функция f2 должна быть внутренней функцией модуля (никто извне не может ее вызвать). Тогда можно более общий случай расписать:

.h


.cpp


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



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

На самом деле можно и без классов.

Вот вам cpp'шник. Попробуйте ка откуда-нибудь ещё получить доступ к переменной var:



По моему, народ просто довольно плохо знает С++

Так и скажите, что будете френдить всех со всеми.
Имеем N сущностей в одном модуле, прописываем в каждом классе всех N френдов.
Думаю о красоте такого кода спорить не будем.

Вы о чем?

Ну, давайте лучше на примере. Дайте модель на обероне который перевести на c++. Посмотрим что выйдет.

Я абсолютно согласен с Владом: с Оберона на С++ перевести достаточно легко. Обратно - значительно сложнее из-за управления памятью.
А механизмов инкапсуляции в С++ больше и с их помощью моделируется какой угодно доступ. И пространства имен, и классы с тремя видами доступа, и файлы (можно в файле сделать локальной как функцию, так и любую переменную. И френдить всех со всеми не требуется. Герб Саттер приводит в своей книжке простой прием, в котором дружественность выборочная - одной функции открыто, другой - закрыто.
А доступ только по чтению, который так часто приводят оберонщики в качестве плюса Оберонам - это просто свойства. Которые в каждой интегрированной С++ среде реализованы. И еще на РСДН могу статью показать "Свойства в С++". А в Додиез своства уже как конструкции языка входят.
С++ значительно более гибок в смысле инкапсуляции. Но эта гибкость - для экспертов, а не для простых прикладных программеров. Как говориться, палка - о двух концах.

Ну, во-первых при чем тут IDE? Эти самые проперти (ака свойства) не фича IDE, а нестандартное расширение языка некоторыми компиляторами. Пользоваться ими -- моветон. Тем более что они легко реализуются через шаблоны, т.е. расширение языка ни чем не обосновано (разве что т.н. "историческими причинами").

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

Теперь хм.. Полное решение. Итак, хотим чтобы:
1) Структура/класс/запись имела поля только для чтения, имела поля доступные только внутри модуля и имела поля доступные всем.
2) Хотим иметь доступ ко всем полям структуры внутри модуля.

Хедер (спецификация модуля):


cpp'шник (ака тело модуля)


Пример использования:

Это "аналог" чего, вот этого?

Нет. Читайте внимательней.