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