From: Edward Diener (eddielee_at_[hidden])
Date: 2004-08-25 18:57:07
Mathew Robertson wrote:
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk