 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Vyacheslav Lanovets Guest
|
Posted: Mon Aug 08, 2005 7:41 am Post subject: Reflection |
|
|
Hello, All!
I wonder what is the status of reflection in C++?
Is anybody thinking of defining and implementing it?
Reflection does not have to be dynamic (at least at first) - it only has to
give a snapshot of a small part (accessible from the type being reflected)
of the type system at the point of application.
I.e. all base classes, members, including types of return values and types
of arguments, primary member templates until "primitive" leafs of the tree
are reached..
Or developer could set the depth of reflection for a type. And linker could
compact same symbol tables to save space because well-behaved progam doesn't
change the type's declaration with macros, hacks and bugs in different
modules.
To demonstrate how it could be useful... We now use quite unportable way to
do a reflection (MS BSC toolkit) for our serialization system:
it tracks down all added and all deleted fields in a tree of PODs and
(re)stores them in DB. So when a new field added to some struct, it gets
"default" value on next start, and when a field is deleted, it's not
read/written anymore. If the field's class has some "special" method
(xerialize), it gets called for serialization instead of memcpy-ing.
To use it you just checkout, compile and then check in - very simple - even
for beginner developers. After the serialization scheme was implemented we
did not have any problems, and made more than a thousand of new fields in
our options structs with several hundreds deleted. I LOVE the way it works.
We just bother that MS may not support it's reflection's toolkit in the
future (oh, they LIKE doing such things, only look at VS2005's support for
Windows CE). And it's a pity but we could not use open source C++
compilers - they don't compile MS Platform SDK headers
And certainly we do not have access to MS C++ compiler.
And even we had, I would not be happy to integrate there home-grown
reflection support I was hardly able to grok sources of one of the very
simple C++ compilers available.
So, you see, some form of reflection is really needed and according to the
rule 80/20 it could be very useful even in the simplest form, for instance
without template members support at all.
And as I showed there are applications where you don't need reflection
support in _all_ of your compilers.
Best regards, Vyacheslav Lanovets
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Larry Evans Guest
|
Posted: Mon Aug 08, 2005 3:04 pm Post subject: Re: Reflection |
|
|
On 08/08/2005 02:41 AM, Vyacheslav Lanovets wrote:
| Quote: | I wonder what is the status of reflection in C++? Is anybody
thinking of defining and implementing it?
Reflection does not have to be dynamic (at least at first) - it only
has to give a snapshot of a small part (accessible from the type
being reflected) of the type system at the point of application.
I.e. all base classes, members, including types of return values and
types of arguments, primary member templates until "primitive" leafs
of the tree are reached..
|
The code in:
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/fields_visitor/
can't do the anything related to supertypes or member function
types. It only reflects member variable (i.e. field ) types
[snip]
| Quote: | To demonstrate how it could be useful... We now use quite unportable
way to do a reflection (MS BSC toolkit) for our serialization
system: it tracks down all added and all deleted fields in a tree of
PODs and (re)stores them in DB.
|
[snip]
The fields_visitor library mentioned above allows "visiting" each
"selected" field of a class. A field is selected by applying a thin
"wrapper" around it, as demonstrated by
'simple_record_field_traversal_test.zip' at:
http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=cppljevans/field_visitor_tests
It would at least solve the portability problem you mention above.
-regards,
Larry
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|