Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-11-11 20:00:19


Russell Hind wrote:
> Edward Diener wrote:
>>
>> C++ Builder, as I am sure you know, actually uses reflection at
>> run-time to create the correct values for properties and events
>> handlers, without altering the source one sees for the user of the
>> component. I actually feel this is cleaner. However both .NET and
>> C++ Builder use run-time reflection of components and do not need
>> component source in order to set up the correct values.
>>
>
> Do you need the source? Aren't the header files enough which you will
> have for a C++ project?

You have made a good point. I still feel uncomfortable about parsing header
files to determine type information. If header files were used, since
run-time reflection does not exist, one would have to inject the correct
code into source files based on design-time decisions. But it does seem as
if it could be done since header files in C++ must be distributed to allow a
component to be used. Of course one would have to find the correct header
file which corresponds to a particular component when one is dropped on a
form from a toolbox of components. I also admit I do not relish the correct
parsing of header files. The one difficulty of this is that the header file
might present different information depending on compile-time options when
the component was built, and these options may not be easily available to
the design-time environment parsing it. Compile time options could determine
what portions of the header file actually represent the component itself,
via #defines, #ifs, and #ifdefs, and with headers including other headers
the correct parsing may not at all be easy. This could theoretically get
very difficult. I think that is why I am much more comfortable with some
possible run-time reflection mechanism, which would always reflect the
actual types and objects in the run-time code without having to discern them
from header file source.

>
> All this would do is generate a temporary cpp files which creates a
> global object which contains the reflection information which you can
> then traverse at runtime. I don't see how this is so different from
> what C++ Builder and .Net do. You don't require component source,
> only header file. It doesn't insert source code in to your cpp
> files, but
> creates temporary C++ files which get linked in to your project each
> time you build.

Whether one changes the source code or adds temporaray C++ files which then
get compiled, is all the same to me. Aside from my objection above, I can
not think of an argument why this would not work, but the parsing might be
very difficult. I would still prefer a run-time reflection mechanism which
was able to find out the internal types and values of a class or object at
run-time in order to do property and event binding on the fly from
resources. In this area I much prefer C++ Builder's hidden workings to
,NET's source code insertions, probably because a resource file, which
encapsulates information into a single concept of resource information seems
somehow more elegant than all those injections of code in .cpp files with
markings that say "do not touch".


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk