Ada_Ru форум

Hello!

У меня вдруг возникли странные сомнения по поводу того, что происходит при создании экземпляра
пакета.

Допустим, мы имеем пакет, предоставляющий некий сервис, и несколько пакетов его использующих (
пусть так примитивненько ):

package SERVER is
   ...
   procedure A (ITEM  : in SOME_TYPE);
   function B return SOME_TYPE;
   ...
end SERVER;

package body SERVER is
   ...
   SETTINGS  : SOME_TYPE;
   WRONG     : constant SOME_TYPE := ...;

   procedure A (ITEM  : in SOME_STRING) is
   begin -- A
       SETTINGS := OPERATION (ITEM);
       ...
   end A; 

   function B return BOOLEAN is
   begin -- B
       if SETTINGS /= WRONG then 
          return TRUE;
       else
          return FALSE; 
       end if;
    end B;
end SERVER;


with SERVER
package body CLIENT_1 is
   ...
end CLIENT_1;

package body CLIENT_1 is
   ...
   package MY_SERVER is new SERVER;
       use MY_SERVER;

   procedure C is
   begin -- C
      ...
       A (SOME_DATA);
       ....
    end C;
    ...
end CLIENT_2;
 

 with SERVER
package body CLIENT_2 is
   ...
end CLIENT_2;
 ....
 

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

 

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

 А в случае, если SERVER у нас generic и имеет параметры настройки на тип данных, и у нас
клиентские пакеты настраивают свои экземпляры одинаково. Тут как? А несколько групп с одинаковой
настройкой generic'а внутри группы ( т.е. пара текстовых, пара двоичных, например )?

> Допустим, мы имеем пакет, предоставляющий некий сервис, и несколько пакетов его использующих (
пусть так примитивненько ):
> 
> package SERVER is
>    ...

>    package MY_SERVER is new SERVER;

Так нельзя. Конструкция настройки пакета применима только к настраиваемым (generic) пакетам. 

> А в случае, если SERVER у нас generic

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

Hello!

Спасибо.

Значит, буду пользоваться generic'ом. Всё равно какая-то подстройка под клиента нужна, вот её и
затолкаю в параметры настройки сервера. Оно даже и нагляднее получится.

Интересно, откуда у меня возникло такое ощущение, что обычные пакеты можно "тиражировать"?
Наверное, по аналогии с задачами.

Когда стал писать текст пакета-сервера, решил кое-что уточнить в документации и нашёл такой абзац (
https://en.wikibooks.org/wiki/Ada_Programming/All_Chapters#Generics
https://en.wikibooks.org/wiki/Ada_Programming/All_Chapters#Generics ):

 

 The reason why formal objects are nonstatic is to allow the compiler to emit the object code for
the generic only once, and to have all instances share it, passing it the address of their actual
object as a parameter. This bit of compiler technology is called shared generics. If formal objects
were static, the compiler would have to emit one copy of the object code, with the object embedded
in it, for each instance, potentially leading to an explosion in object code size (code bloat).
 (Note to C++ programmers: in C++, since formal objects can be static, the compiler cannot
implement shared generics in the general case; it would have to examine the entire body of the
generic before deciding whether or not to share its object code. In contrast, Ada generics are
designed so that the compiler can instantiate a generic without looking at its body.)
 

 Что я бы перевёл так ( поправьте, если ошибся ):
 

 Причина, по которой формальные параметры нестатические, в том, чтобы позволить компилятору создать
код для настраиваемого модуля только один раз и разделять его со всеми экземплярами модуля,
передавая адрес их реального объекта, как параметр. Это черта технологии компиляции называется
разделяемые настройки. Если б формальные объекты были статическими, то компилятору пришлось бы
создавать одну копию объектного кода со встроенным в него объектом для каждого экземпляра, что
потенциально ведёт к взрывному росту размера объектного кода ( раздувание кода ).
 ( Примечание для программистов на C++: Поскольку в C++ формальные объекты могут быть статическими,
компилятор не может реализовать разделяемые настройки в общем случае; ему нужно будет проверять
полностью текст настраиваемого модуля прежде, чем решить разделять код или нет. В отличие от этого
в Ada'е настраиваемые модули спроектированы так, что компилятор может создавать экземпляры, не
глядя в тело настраиваемого модуля. )
 

 То есть, всё-таки код единиый для всех экземпляров.

  
 Как интересно отливается изначальная примитивность языка ( C ) и компилятора при дальнейшем
развитии. Философские трактаты писать можно. Воистину: "Дубли у нас простые"!

> > То есть, всё-таки код единиый для всех экземпляров.
 
 > Не обязательно, и совершенно точно не так в случае GNATa. Язык определяет
 > лишь семантику и ничего не говорит о том, как именно она должна быть 
> обеспечена.

Но идея красивая. И возможность заложена правильная.
 
> И вообще, Вики в данном случае - крайне ненадежный источник информации :)

Да, но, к сожалению, времени на вдумчивое чтение и поиск более надёжных источников просто нет.
 > > Как интересно отливается изначальная примитивность языка ( C ) и
 > > компилятора при дальнейшем развитии. Философские трактаты писать
 > > можно. Воистину: "Дубли у нас простые"!
 
 > Трактаты - это да! Жаль, не нужны никому :(

А я в последнее время что-то не видел каких-то серьёзных новых по программированию. Самое свежее,
что читал -- описание системы "Оберон" Вирта. Красиво спроектирована.

И как-то коллеги ничем не интересуются. Сунул одному почитать Янга. Тот в руках покрутил, сказал:
"Нет, спасибо"...

cs_a994@... [ada_ru] wrote:

> То есть, всё-таки код единиый для всех экземпляров.

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

И вообще, Вики в данном случае - крайне ненадежный источник информации :)

  
> Как интересно отливается изначальная примитивность языка ( C ) и
> компилятора при дальнейшем развитии. Философские трактаты писать
> можно. Воистину: "Дубли у нас простые"!

Трактаты - это да! Жаль, не нужны никому :(

> Что я бы перевёл так ( поправьте, если ошибся ):

Перевели вы правильно, но интерпретируете не совсем правильно :)

> Причина, по которой формальные параметры нестатические, в том, чтобы ПОЗВОЛИТЬ компилятору (...)

Иными словами, речь идет о том, что на уровне языка ВОЗМОЖНОСТЬ такой оптимизации принята во
внимание, и семантика разработана с тем условием, чтобы не сделать такую оптимизацию формально
невозможной. Но это не означает, что каждая реализация обязана воспользоваться всеми возможностями
оптимизации (собственно даже не означает, что данная оптимизация на практике осуществима). 

Мораль в том, что вы не можете на это расчитывать, и гнат этого точно не умеет. Допускаю, что при
наличии нескольких экземпляров в одном пакете он в простых случаях сумеет выкинуть неизменяемые
части каждого экземпляра, но даже в этом крайне сомневаюсь. Потому что в самом общем случае это
крайне тяжело. Может в рамках модели раздельной компиляции даже и вообще невозможно.

cs_a994@... [ada_ru] wrote:
> А я в последнее время что-то не видел каких-то серьёзных новых по
> программированию. Самое свежее, что читал -- описание системы
> "Оберон" Вирта. Красиво спроектирована.
>
> И как-то коллеги ничем не интересуются. Сунул одному почитать Янга.
> Тот в руках покрутил, сказал: "Нет, спасибо".

Увы, у меня те же наблюдения по на сильно многочисленным контактам в МГУ.