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

А в учебниках С++ чему учат? Тому, что нужно по 1 переменной "прищёлкивать"? И всё переписывать по 2-3 раза заново, определяя один и тот же класс?
Копировать из тела класса копипастом, заменять точки с запятыми - одними запятыми, потом всё заново: брать каждую переменную в скобочки, двоеточие, потом запятые...
А при описани нового типа - опять всё заново.
Что-то оно как-то.... "есть как надо" что ли? И "есть методы для тех, от кого отделаться надо, а если невозможно, то пусть на неудобъях ломаются и ничего толком в итоге" чтоли?

И вроде бы есть хороший язык... но никто не расскажет как нужно на нём что-то делать, чтобы не просто труд потратить, но и результат получить.
И все говорят о "быстром развитии постоянн. меняющ. совр. технологий", при этом мечтают о типах по void*, а они реализованы в Obj C в 1983... как-то уже, то есть... и это имеет коммерческое применение десятилетиями... но новичкам говорят, что "это не правильно и не нужно"... и программисты Си "с коммерческой точки зрения" никому ненужны, хотя Mac OS, Cocoa, - вот же они.

Какое-то такое впечатление. Непонятное.

1. Тип можно представить как массив (или список) переменных и функций.

2. Если этот принцип дополнить принципом objective C (он же слот/сигнал, он же «принцип win API», он же рецийвер-рефлектор Иррлихта, он же sf::Event SFML).
То тип уже можно представить как «чёрный ящик» содержащий переменные, управление которыми осуществляется посредством функций.
Это управление осуществляется с помощью единственной ф-ции «reflect» принимающий «события» или «сигналы» и содержащая «отражающую матрицу», то есть массив или список «функций реакции».


3. То есть из 2 первых принципов следует:
а) то, что существует необходимость лишь в массиве функций. Массив переменных уже избыточен;
б) переменные можно представить не массивом, а структурой Си (для облегчения манипуляций с ними как с единым целым, применительно к Иррлихту: вместо Си структуры просто берётся указатель на ноду иди элемент – имеем оригинальный паттерн Proxy);
в) тогда классу C++ останется лишь управление памятью (конструктор/деструктор) и единственная функция:


4. Следствия.
а) В отличие от обычного порядка определений ф-ций класса такой подход теоретически позволят «добавлять классу функции налету» (то есть после его определения).

б) Частично отпадает необходимость в вирт. Наследовании и кастах, теперь класс представляет собой «конструктор» состоящий из различных комбинаций элементов, в первую очередь отражающих функций и переменных. Сигнал (message, event, функтор) отделён от слота и может «приниматься» слотами объектов различных типов. Слот может добавляться типу после его определения. Наличие функций и переменных класса можно проверить. Можно идентифицировать класс или получить информацию о нём через наличие опред. ф-ций или их комбинации (для этого даже не нужно знать тип объекта!);

5. Вышеописанное – это принципы. Дальше реализации «технологии».
А реализована она может быть несколькими способами (возможно даже описаны не все):
а) с помощью switch/case (подход из Иррлихта) или определения элемента в массива по ID;
б) с помощью виртуального наследования или [массива + enum-ератов];
в) с помощью частич. специализации шаблонов и списка функторов.

Последний метод:
а) в принципе, быстр, так как ветвление с «выбором класса по типу» переносится на этап компиляции;
б) позволяет добавлять типу ф-ции в любой момент, уже после его объявления;
в) чтобы функтор имел доступ к приватным переменным класса они просто передаются ему Си-структорой или указателем на ноду Иррлихта. В функции reflection класса. То есть ф-тор принимает 2 переменные структуру данных типа и «событие» или «message» – как Си структуру или же другой функтор.

1. Так как в программировании не существует других данных кроме цифровых и текстовых, то при сведении данных к тексту выгоднее использовать скриптовый порт (что облегчит и сохранение/загрузку данных и их передачу текстовым GUI).

2. И для маршалинга текстовых и для маршаллинга числовых данных удобнее всего использовать потоки C++ (std::stringstream). Текстовые для сведения к текстовым данным, они же предоставляют наиболее удобный инструментарий для парсинга-обработки текста. И числовые для сведения к цифровой форме. Структуры Си содержащие простые Си-данные можно загонять в числовой (например файловый) поток «целиком».

3. Хотя для работы с «сериализованными» данными было бы удобно иметь специальную «потоковую БД», некий «ускоренный/оптимизированный» аналог std::map (по парам ключ-значение). Или что-то вроде этого. Суть – БД (осущ. быструю работу с упорядоченными, универсал. (сведённ. к единой форме хранения) данными).

4. Данные GUI оч. удобно хранить в HTML + CSS (на худой конец XML). Парсинг данных к XML/HTML и обратно (суть сериализовать данные из контролов, записать в HTML БД, потом считать оттуда, записать обратно в контрол) удобнее всего осуществлять средствами скриптов поддерживающих регулярные выражения (или) (Lua, JavaScript: V8, Пайтон (Python) и т. д.)

Другой вариант это:
1. Добавление в класс С++ Си-массива SAny * elem_arr имеющего вид:


2. Ф-ция reflection () не на шаблонах, а на ID.
3. Т.е. класс - это массив переменных и функций, без различий между перем. и функ.
4. Что позволит "автоматизировать" составление массива перем и функц. (отображ. внутр структ. Obj C класса)
5. Остаётся лишь реализовать рассчёт ID один из возможных вариантов которого:
5.1- На этапе комилляции:
Как добавить ID типу/классу, если изначально ID у него нет?

5.2 На этапе исполнения: