Re: Template metaprogramming question
On Jul 15, 11:03 pm, Noah Roberts <u...@example.net> wrote:
suman.nan...@gmail.com wrote:
I have a base class, say B and lots of classes D1 .. Dn
publicly derived from it. Over the course of development the
number of derived classes may increase.
I want that before the execution of one of my particular
code, I should have a list of pointers to all the derived
classes, say std::list<B*> ptrList; // contains 'n' elements
which are pointers to D1 .. Dn.
I don't want to have anything like:
ptrList.push_back (new D1);
ptrList.push_back (new D2);
..
As Bazarov stated, use a registration object.
// id argument is unnecissary for registration, but it does make it
possible to register more than
// one control in a .cpp file while still making some sense.
#define REGISTER(whatever, id) \
namespace \
{ \
ControlCenter::registration reg_##id =
ControlCenter::control_center().register(whatever); \
}
Just an idea, but if you use __LINE__ instead of id, and you
won't need the extra argument.
In my case, id is an integral defined in resource.h as a Win32
control object and this implements a state/command pattern
tool system.
ControlCenter::registration can easily simply be a bool and is
normally ignored. You'll be able to access it if necessary,
keeping scoping issues in mind, though as the variable name is
quite predictable.
Developers write a class and then put "REGISTER(construction,
id)" in the cpp file. You could easily simply use the ID
instead, or something along those lines, so that instantiation
is not necessary (in my case it is). There's no need to even
have a header for these objects at all...the class interface
and implementation can be in the CPP file and never exposed to
anyone at all.
I'm not sure I understand. You need a header for the class
ControlCenter (or whatever it would be called), and the register
macro, since the registration will take place in many different
files. (Personally, I've never bothered with the macro. I just
define a member class of ControlCenter, and require a static
instance of that, e.g.:
ControlCenter::Registerer someId( whatever ) ;
It's up to the user to worry about someId, and do whatever he
feels necessary to avoid name clashes, but the effort has never
seemed sufficient to justify a macro. IMHO.)
Also I don't want to instantiate any static variable of D1
.. Dn, so that inside the constructor I may register the
'this' pointer.
I don't know what you mean here so I can't say if it'll solve
your problem.
He's saying basically that he wants something, but refuses to
use any of the known techniques to achieve it.
All I want is the developer should just write the definition
of derived classes, possibly with some constraints and
should not bother about anything else.
What you want is not possible, at least no way I can think of.
It's not really a template metaprogramming problem either.
There might be something you could do with a traits function
explicit instantiation, one that the REGISTER macro would
create, but I don't understand what your problem is well
enough to say.
It seems rather obvious that template metaprogramming couldn't
be a solution in itself, since templates are fully resolved at
compile time, and as I understand it, the system must be open to
classes which are separately compiled. You can't say, I want
this resolved at compile time, but the information won't be
available until link time (or maybe runtime, if dynamic linking
is being used).
Note that if static linking is being used, it should be possible
to insert a small script which generates a source with all of
the information, in a statically initialized table (with
std::find being used for lookup). This can have certain
advantages in some cases (and major disadvantages in others).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34