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

у нас есть клиент, который может аутенфицировать себя на сервере..
на сервере есть сервис для аутентификации... 

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


Это сообщение отредактировал(а) mes - 3.12.2010, 13:56

идеальным вариантом был бы такой вариант, который бы позволял регистрировать объекты в независимости от их реализации/назначения/использования.

в последнем посте я хотел придти от классической интеграции объектов к распределенной, но не сразу а постепенно..
в обоих случаях "фактически " исполнение конечных точек одинаково..  поэтому для начала нам нужны эти точки.. 

а Вам предлагаю их написать, чтоб не так трудно было понимать мои примеры 

и так для начала нам нужно две конечные точки (клиентскую и серверную ) функционала "аутенфикация".. 
  

если бы Вы привели наглядный пример - был бы очень благодарен.


непонимаю..  

Это сообщение отредактировал(а) boostcoder - 3.12.2010, 20:35

хм.. не понимаете что есть "конечные точки" или что представляют из себя клиент и сервис аутенфикации ?

и то, и другое  

ну давайте попробуем разобраться..

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

Добавлено через 1 минуту и 54 секунды
в общем другими словами, при передачи имени (с паролем) сервис аутенфикации возвращает дескриптор временного или постояного (для зарегистрированного юзера) файла..

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

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

Добавлено @ 23:46



Это сообщение отредактировал(а) mes - 4.12.2010, 12:23

это понятно.

теперь сделаем шаг к распределенности.. для начала определим преграды :
1. использование ссылок..(общее адресное пространство )
2. имена  классов и метода не рефлексивны

для расширения пространства введем понятие remote_ref
для рефлексии классов и методов мы можем отразить их на карту.. 

Это сообщение отредактировал(а) mes - 4.12.2010, 12:28

Это сообщение отредактировал(а) mes - 4.12.2010, 12:44

вызов удаленных методов предполагается посредством оператора << , a не ->

Добавлено @ 13:27
в С++ есть три различных синтаксиса функций: свободные ф-ции, статические и нестатические ф-ции-члены.. 
нам желательно привести к одному виду..  наиболее общим является вид свободной функции..

т.е. считаем что описание класса будет таким 




Это сообщение отредактировал(а) mes - 4.12.2010, 13:29

метод может иметь прототип и определение..
первого достаточно для вызова, второе необходимо для выполнения.. 

и?