OberonCore
https://forum.oberoncore.ru/

Проблемы трансляции Оберон на Си++
https://forum.oberoncore.ru/viewtopic.php?f=30&t=1713
Страница 2 из 3

Автор:  Vlad [ Вторник, 14 Июль, 2009 18:33 ]
Заголовок сообщения:  Re: Проблемы трансляции Оберон на Си++

slava писал(а):
Это "аналог" чего, вот этого? :shock:
Код:
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. Вполне логично. Не так красиво, конечно, но и не сказать, что ужасно. А главное - идея не теряется, код однозначно преобразуюется.
Проблема с Oberon-2/Component Pascal.
Связанные процедуры разных записей одного модуля имеют полный доступ ко всем полям (своих параметров).
В результате либо необходимо объявить гораздо больше фрэндов (думаю не сложно построить пример где потребуется порядка 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 писал(а):
В том то и проблема, что квалифицированный импорт... тоже транзитивный.
Опишите конкретную проблему?
modA.py:
Код:
varA = 5
modB.py:
Код:
import modA
modC.py:
Код:
import modB
print modB.modA.varA
модуль modC не импортировал modA, но он имеет доступ к его переменным и функциям.

Автор:  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
print modB.modA.varA
модуль modC не импортировал modA, но он имеет доступ к его переменным и функциям.


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

Страница 2 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/