OberonCore https://forum.oberoncore.ru/ |
|
Проблемы трансляции Оберон на Си++ https://forum.oberoncore.ru/viewtopic.php?f=30&t=1713 |
Страница 2 из 3 |
Автор: | Vlad [ Вторник, 14 Июль, 2009 18:33 ] |
Заголовок сообщения: | Re: Проблемы трансляции Оберон на Си++ |
slava писал(а): Это "аналог" чего, вот этого? Код: MODULE A; VAR rwField*: INTEGER; roField-: INTEGER; privateField: INTEGER; PROCEDURE setRo*(val: INTEGER); END A. Аналог вот этого "по общей схеме" после еще некоторых размышлений я бы предложил такой: Код: class A { public: static int rwField; static ro_export<int,A> roField; private: static int privateField; public: static void setRo(int val); }; Вместо ro_export<> можно просто геттер сделать (я бы так и предпочел), но если хочется макисмально повторить оригинал (например чтобы потом однозначно восстановить) - то так нагляднее. Да, писанины больше - это цена за "неродной" для C++ стиль инкапсуляции. Однако писанина чисто механическая, никаких проблем "перевода" она не создает. P.S. Реализация ro_export тривиальна, что-то типа: Код: template <typename Module, typename T>
class ro_export { friend class Module; private: ro_export(T const& t) : t(t) {} ro_export(ro_export const& o) : t(o.t) {} void operator = (T const& t) {this->t = t;} ro_export& operator = (ro_export const& o) {this->t = o.t; return *this;} public: operator T const& () {return this->t;} private: T t; }; |
Автор: | Vlad [ Вторник, 14 Июль, 2009 18:46 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
slava писал(а): Так и скажите, что будете френдить всех со всеми. Не всех со всеми, а явно связываем конкретную запись с конкретным модулем. Ну нету в C++ ключевого слова "MODULE". Поэтому приходится ручками прописывать то же самое, но другими средствами. slava писал(а): Имеем N сущностей в одном модуле, прописываем в каждом классе всех N френдов. Думаю о красоте такого кода спорить не будем. Нет, все N сущностей прописываем в классе, который назван ModuleX. Каждому рекорду который принадлежит модулю - прописываем friend class Module. Вполне логично. Не так красиво, конечно, но и не сказать, что ужасно. А главное - идея не теряется, код однозначно преобразуюется. Чего никак нельзя сказать об обратном переводе. |
Автор: | QWERTYProgrammer [ Вторник, 14 Июль, 2009 22:33 ] |
Заголовок сообщения: | Re: Проблемы трансляции Оберон на Си++ |
Насколько я понимаю, известный транслятор с Оберон-2 на C Ofront более-менее механически транслирует код на Oberon-2 в C включая GC. Транслятор на C++ мог бы, видимо, выдавать код еще ближе к обероновскому оригиналу. Заодно решая проблему многоплатформенности:-) |
Автор: | Сергей Оборотов [ Среда, 15 Июль, 2009 01:10 ] |
Заголовок сообщения: | Проблемы трансляции С++ на Оберон. |
Vlad писал(а): А главное - идея не теряется, код однозначно преобразуется. Чего никак нельзя сказать об обратном переводе. Что Вы имеете в виду? Не преобразуется или преобразуется неоднозначно? |
Автор: | Vlad [ Среда, 15 Июль, 2009 01:33 ] |
Заголовок сообщения: | Re: Проблемы трансляции С++ на Оберон. |
GUEST писал(а): Vlad писал(а): А главное - идея не теряется, код однозначно преобразуется. Чего никак нельзя сказать об обратном переводе. Что Вы имеете в виду? Не преобразуется или преобразуется неоднозначно? Преобразуется и вполне однозначно. |
Автор: | Сергей Оборотов [ Среда, 15 Июль, 2009 17:41 ] |
Заголовок сообщения: | Re: Проблемы трансляции С++ на Оберон. |
Vlad писал(а): Re: Проблемы трансляции С++ на Оберон. О чем первая цитата тогда?
...Чего никак нельзя сказать об обратном переводе... GUEST писал(а): Что Вы имеете в виду? Не преобразуется или преобразуется неоднозначно? Преобразуется и вполне однозначно. |
Автор: | Vlad [ Среда, 15 Июль, 2009 20:18 ] |
Заголовок сообщения: | Re: Проблемы трансляции С++ на Оберон. |
GUEST писал(а): Vlad писал(а): ...Чего никак нельзя сказать об обратном переводе... О чем первая цитата тогда?GUEST писал(а): Что Вы имеете в виду? Не преобразуется или преобразуется неоднозначно? Преобразуется и вполне однозначно. Обратный перевод чрезвычайно трудоемок, если программа изначально написана на C++ и использует такие возможности языка, которые не имеюют прямого отражения в оберон: шаблоны, исключения, конструкторы/деструкторы и т.д. |
Автор: | Сергей Оборотов [ Среда, 15 Июль, 2009 21:32 ] |
Заголовок сообщения: | Re: Проблемы трансляции Си++ на Оберон |
Vlad писал(а): Обратный перевод чрезвычайно трудоемок, если программа изначально написана на C++ и использует такие возможности языка, которые не имеют прямого отражения в Оберон: шаблоны, исключения, конструкторы/деструкторы и т.д. Возможно. Может и не надо никому. |
Автор: | slava [ Среда, 15 Июль, 2009 21:40 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
Vlad писал(а): В питоне с модулями почти все хорошо, особенно если использовать явный импорт. Не хорошо. В Python нет friend (или уже есть?) и оператор import -- транзитивный (т.е., как include в C)."Модули" в Python скорее условно равны: namespace + include. |
Автор: | slava [ Среда, 15 Июль, 2009 22:03 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
Vlad писал(а): slava писал(а): Имеем N сущностей в одном модуле, прописываем в каждом классе всех N френдов. Думаю о красоте такого кода спорить не будем. Нет, все N сущностей прописываем в классе, который назван ModuleX. Каждому рекорду который принадлежит модулю - прописываем friend class Module. Вполне логично. Не так красиво, конечно, но и не сказать, что ужасно. А главное - идея не теряется, код однозначно преобразуюется. Связанные процедуры разных записей одного модуля имеют полный доступ ко всем полям (своих параметров). В результате либо необходимо объявить гораздо больше фрэндов (думаю не сложно построить пример где потребуется порядка N*N фрэндов) либо отобразить вначале в Oberon (т.е., конвертировать связанные процедуры в указатели и процедуры модуля). |
Автор: | Vlad [ Среда, 15 Июль, 2009 22:22 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
slava писал(а): Vlad писал(а): В питоне с модулями почти все хорошо, особенно если использовать явный импорт. Не хорошо. В Python нет friend (или уже есть?) Гхм. А нафига нужен friend? slava писал(а): и оператор import -- транзитивный (т.е., как include в C). Ничего общего с сишным инклудом. Код: import os print os.name # явная спецификация модуля print name # ошибка slava писал(а): "Модули" в Python скорее условно равны: namespace + include. В питоне можно сделать из модулей бардак, так что будет не разобраться что откуда импортнулось. Но можно не делать |
Автор: | Vlad [ Среда, 15 Июль, 2009 22:43 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
slava писал(а): Проблема с Oberon-2/Component Pascal. Связанные процедуры разных записей одного модуля имеют полный доступ ко всем полям (своих параметров). Тогда лучше использовать вот такой подход (без френдов вообще): .h Код: class ModuleA; class X { public: int field1; // поле, доступное всем public: int& field2(ModuleA); // поле, доступное только внутри модуля, "обозначаем" этот факт с помощью аргумента private: int m_field2; }; class Y { void f(); }; .cpp Код: class ModuleA {};
... Y::f() { X x; x.f(ModuleA()); } |
Автор: | slava [ Среда, 15 Июль, 2009 23:02 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
Vlad писал(а): slava писал(а): и оператор import -- транзитивный (т.е., как include в C). Ничего общего с сишным инклудом.slava писал(а): "Модули" в Python скорее условно равны: namespace + include. В питоне можно сделать из модулей бардак, так что будет не разобраться что откуда импортнулось. Но можно не делать |
Автор: | Vlad [ Среда, 15 Июль, 2009 23:25 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
slava писал(а): В том то и проблема, что квалифицированный импорт... тоже транзитивный. Опишите конкретную проблему? |
Автор: | slava [ Среда, 15 Июль, 2009 23:32 ] |
Заголовок сообщения: | Re: Проблемы трансляции Оберон на Си++ |
Суммируя: для отображения совершенно тривиальных вещей (readonly export, module), необходимо применить почти весь аппарат C++. В одном решении: friend, const&, templates, В другом: inheritance, dynamic_cast, const& и переход от автоматической памяти к динамической. Да, автоматический преобразователь что-то там на генерирует (а что с garbage collector?), но руками это далеко не тривиально (и даже мучительно). При всем при этом о безопасности можно забыть. Так что... Vlad писал(а): Info21 писал(а): Да, настоящие модули -- вещь. Начинаешь это остро ощущать, когда приходится типа переносить на какой-нибудь С++ программу с Оберона. Какие трудности? |
Автор: | Илья Ермаков [ Среда, 15 Июль, 2009 23:40 ] |
Заголовок сообщения: | Re: Проблемы трансляции С++ на Оберон. |
Vlad писал(а): Обратный перевод чрезвычайно трудоемок, если программа изначально написана на C++ и использует такие возможности языка, которые не имеюют прямого отражения в оберон: шаблоны, исключения, конструкторы/деструкторы и т.д. Аналогично, как поднять из ассемблера, написанного вручную, до ЯВУ... Фобия Старуструпа не включить в язык какую-нибудь частность на какой-нибудь "авось понадобится" - просто... беспрецедентная. Это, знаете, как студент-троечник засовывал бы в базис дополнительный линейно зависимый вектор, просто потому, что боялся бы, что "вдруг не хватит". |
Автор: | slava [ Среда, 15 Июль, 2009 23:43 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
Vlad писал(а): slava писал(а): В том то и проблема, что квалифицированный импорт... тоже транзитивный. Опишите конкретную проблему?Код: varA = 5 modB.py:Код: import modA modC.py:Код: import modB модуль modC не импортировал modA, но он имеет доступ к его переменным и функциям.
print modB.modA.varA |
Автор: | Vlad [ Среда, 15 Июль, 2009 23:57 ] |
Заголовок сообщения: | Re: Проблемы трансляции Оберон на Си++ |
slava писал(а): Суммируя: для отображения совершенно тривиальных вещей (readonly export, module), необходимо применить почти весь аппарат C++. Хе-хе Вы не представляете себе масштабы "аппарата" С++ То, что здесь было показано - это даже не цветочки Тривиальные вещи. slava писал(а): В одном решении: friend, const&, templates, В другом: inheritance, dynamic_cast, const& и переход от автоматической памяти к динамической. Не понял. Чем вам не нравится последнее решение? Там нет ни одного из "ужасов", о которых вы пишите slava писал(а): Да, автоматический преобразователь что-то там на генерирует (а что с garbage collector?), GC в данном случае как раз прикручивается без проблем. С GC в C++ начинаются проблемы, когда таки памятью ручками поуправлять хочется. Но в случае трансляции с оберона такой ситуации просто не возникнет. slava писал(а): При всем при этом о безопасности можно забыть. Т.е. вы хотите сказать, что упоминавшийся здесь транслятор из оберона в C небезопасен? До тех пор, пока вы будете переводить с оберона на C++ и не включать отсебятины - с безопасностью все будет хорошо. |
Автор: | Vlad [ Четверг, 16 Июль, 2009 00:03 ] |
Заголовок сообщения: | Re: Проблемы трансляции С++ на Оберон. |
Илья Ермаков писал(а): Vlad писал(а): Обратный перевод чрезвычайно трудоемок, если программа изначально написана на C++ и использует такие возможности языка, которые не имеюют прямого отражения в оберон: шаблоны, исключения, конструкторы/деструкторы и т.д. Аналогично, как поднять из ассемблера, написанного вручную, до ЯВУ... Все правильно, только наоборот C++ - это ЯВУ, и чтобы из него получить ассемблер в лице оберона - надо попариться (поработать компилятором). |
Автор: | Vlad [ Четверг, 16 Июль, 2009 00:08 ] |
Заголовок сообщения: | Re: есть ли ООП в Обероне-07 |
slava писал(а): Код: import modB модуль modC не импортировал modA, но он имеет доступ к его переменным и функциям.print modB.modA.varA И чего? Где проблема то? И импорт здесь вообще никаким боком. Просто модуль в питоне это не просто ключевое слово, но и рефлективная сущность, что вполне логично для динамического языка. Я уверен, что тоже самое вы и в BB сможете сделать, задействовав рефлекшин. То, что на питоне этого добится проще - скорее плюс, чем минус. |
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |