всем доброго утра.
каким образом можно вызвать конструктор базового класса не зная кто предок?
код:

http://liveworkspace.org/code/9c0aa5263526...22d9cf0e0da1e70

спасибо.

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

что-то вроде этого
http://liveworkspace.org/code/5593f2deabab...e404db3d33b550c


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



Это сообщение отредактировал(а) azesmcar - 12.10.2010, 05:30

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


а конструктор по умолчанию?
собственно в этом то и вопрос - нужно создать объект потомок, при этом инициализируя предка неким значением.


хм... именно этого я и хотел избежать.
есть еще варианты?

в новом стандарте можно вот так

судя по всему это продолжние темы о rpc, и класс i_type это база пакета протокола..

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

  


  


на стороне сервера кто-то же должен реализовать обработчики.

и при чем тут виртуальные методы пакета протокола ?!

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

покажите набросок этого связывания, если не сложно.. 
по идеи достаточно должно быть интерфейса базового класса.. 



Это сообщение отредактировал(а) mes - 12.10.2010, 09:15

  

вот что говорит:

как понимать?

Добавлено через 1 минуту и 25 секунд

чуть позже..

ну вот.. опять ждать 
  

Даже Comeau так не умеет. Кстати, в текущем draft я такой фичи не нашел...

я даже не искал. ибо не знаю что искать  

на то он и новый стандарт  

http://gcc.gnu.org/gcc-4.5/cxx0x_status.html

N2540




12.9 Inheriting Constructors
текущий черновик


Это сообщение отредактировал(а) azesmcar - 12.10.2010, 12:49

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

У вас есть два вида типов интерфейса пакета,
  один это пользовательские данные такие как :

ничего больше, чем нужно пользователю, тут быть не должно..

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

терь нам осталось только совместить первое со вторым в одном классе.. делаем шаблон :

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

ну и для передачи по сети  нам нужен ид. Получать мы его можем автоматом на основе списка типов:

ну и естественно перед использованием списков типов нужно избавиться в нем от дубликатов(на всякий случай)

P.S. чему равен аналог Loki::IndexOf<> в бусте не знаю, но если его нету, то и самому написать не сложно.. 

Это сообщение отредактировал(а) mes - 14.10.2010, 14:53

mes, большое спасибо 
я не в коем случае не забил на задачу, т.к. она мне как воздух важна. но приходится еще и другими проектами заниматься.
естественно, все эти дни я не дурью маялся, и тоже кое-что накодил  

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


сгенерит это:

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

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

на стороне сервера используется так:

вот 

зы
может попросить модераторов чтоб перенести в первоначальную тему?

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

  
было б хорошо добавить еще и раздельную кодогенерацию.. отдельно структуры, мета-описания и мета-определения..



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

и... если у Вас

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


Добавлено @ 17:38

с ид отдельная история.. с одной стороны делать их абсолютно автоматическими, как показано в моем примере, тоже не годится,
но и жестко привязываться в пользовательском коде, тоже не хорошо.. Лучшим вариантом было бы разгрузить через посредника, который бы по типу выдавал нужный ид. Тогда можно выбирать стратегию определения id..  Но их пока оставим на потом.. 





Это сообщение отредактировал(а) mes - 14.10.2010, 17:42

эм... поясните...


так и задумано. хочу в будущем реализовать динамическое связывание объектов по запросу клиента.
т.е.:



это переходная версия  
далее такого не будет.


угу.


Это сообщение отредактировал(а) boostcoder - 14.10.2010, 17:53

наскoлько я понимаю тут не хватает <registration_api>

a также  заметен сдвиг в сторону асинхроности..  

Добавлено @ 18:01

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


т.е придется разделить один макрос на три, но как то так, чтоб не пришлось трижды набирать структуру..
т.е. грубо говоря вначале дефайнить описание, а после подвергать различным кодогенерациям в нужном месте.. 
P.S. через #define может и не получится, а через #include вполне.. хотя первое удобнее..



 


  

Это сообщение отредактировал(а) mes - 14.10.2010, 18:05

ааа, ну да  


да-да. конечно. иначе сейчас в одном хидере вся кодогенерация. там черт ногу сломет  

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


Это сообщение отредактировал(а) mes - 14.10.2010, 18:42