Mathew Robertson wrote:
[snip]
All what you say here already exists in C++. For instance, you can have a look at QT.
It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files..
Does anyone here think that requiring a pre-compiler is a reasonable thing to require?
It is much neater not needing preprocessing of files, and that not needing anything but a C++ standard compiler which is what boost::signal<> provides. Having worked with implementations which required C++ extensions in order to do design time programming, I can say that I would have preferred that such extensions were not needed, but they were worth it because C++ does not provide the mechanisms to make that sort of environment work as flawlessly as it did in those environments. Needless to say, everything one could do at design time, one was able to do at run-time also and that made those environments particularly enjoyable. If, however, mechanisms exist in standard C++ to do something which some preprocessor or C++ extension provides with the exact same functionality and ease of use, naturally I would always prefer standard C++. But I am not a purist. I still intuit that a complete run-time reflection mechanism will be needed to make design-time RAD programming possible in standard C++. But of course many C++ programmers do not see the need for such an environment, often having used one, so they will not see the need for run-time reflection.