[boost] Re: GUI Library Proposal for a Proposal

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".