[boost] Re: GUI Library Proposal for a Proposal

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-11-09 20:47:49

Russell Hind wrote:
> Edward Diener wrote:
>>
>> The one area where C++ is weaker than other languages for design
>> time UI, and component, development is in its lack of a general
>> run-time reflection mechanism. That is the only area which I see
>> that is holding it back.
>>
>
> A solution I've read about that I like to solve this is a separate
> 'pre-processor' that can pass your current project and look for
> certain members/member-functions and generate code to build up the
> appropriate required run-time information
>
> (e.g. it could recognise the '__published:' section of Borland's VCL
> classes and generate the code containg the list of members in that
> section which would be accessible at runtime)
>
> I'm sure this could be done in a compiler independent way as it would
> be parsing C++ code and generating C++ code to then be compiled by
> your
> compiler of choice.
>
> I can't remember where I first read about this idea but perhaps
> someone
> else has more information.

.NET actually adds code to the source files using a component, based on
design time decisions by the programmer, but it uses .NET reflection on the
compiled component in order to do so. What you are suggesting is that one
must parse component source code at design time in order to add code to the
source which uses that component. This presupposes that the source code for
all components used at design time must be available. Sorry if I find that a
disagreeable thought.

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.

Having to parse C++ code at design-time may be doable but I do not think it
is a good way of doing things. Besides needing the source for the component,
it is always possible that the source is incorrect and has errors. When
run-time reflection can actually be used on the compiled component, there is
no need for component source and the compiled component is always correct.

For these reasons I much prefer a guaranteed run-time reflection mechanism
rather than a source code parser for design time RAD developement. In the
area of run-time reflection, Java, .NET, and Python have an obvious
advantage over C++. Other than run-time reflection, I find C++ generally
equal to, or better, than those other languages and environments, although I
have a great fondness for Python nonetheless.