Ok, never coded a compiler, and never probably will, I program C++ but I'm not an expert, anyway from the outside here are my 2 cents: The code mixes runtime decisions with compile time checks and that does not add up, no way that can be implemented on the current standard. About the given problem, the solution is using dynamic polymorphism directly: all classes returned by get_class<n> match an interface defining virtual void foo( T const& ) for each possible T, possible implementation being assert(false) in the base class. Then if all get_class<n> resulting classes inherit from that base class the code will compile and solve the problem at hand. I am now assuming that the code was just an example to represent the feature that is being requested. To support that feature, the compiler must add code that checks at runtime for the existence of foo( specific_T const& ) and if it does not find it ends execution. This code should be added in dispatch_on_value and must check RTTI from the result of get_class<n>, which in the example is easy to spot, but it is not hard to consider the same 'try wellformed { ... }' structure with many more lines, and the compiler must decide for which parts of the code the extra runtime check must be generated. Should it be generated only for objects returned from templated functions/template methods, or is the softer type check also required for all the code? If it is for all the code, do all binaries have the appropiate RTTI info? Can we not link against C dynamic libs? Libs generated with other compilers? With other compiler options? Then again, I can assume that easing the programming of the compiler is just an excuse (I am not going to code the compiler anyway! :P), but then...
From the programmers standpoint that feature will lift some of the type safety requirements. Suddenly if something is surrounded in such a block, type safety is not checked there until runtime, errors that are now detected during compilation creep into binaries and can only be found through extensive testing of all execution flows that go through the block (all cases for which 's==some_string(n)' in the example, but quite harder task on other code) and the error messages will probably be quite less explicit --I already have problems following compile time errors using boost libs, I surely don't want to debug with just the output of a runtime (possibly stripped, optimized) binary. Here's your new gun, go shoot yourself.
My opinion on this subject is that the implications of the extension to the standard seem to help with an specific use case, at the cost of quite some work on the compiler, heavier binaries and harder debugging for the programmer. If you add to it that it is not an 'enabling' technology --it does not solve any now-unsolvable problem, AFAIK. I would not be optimistic in the acceptance of such a feature. Then again, I am no expert. David P.S. Please don't anyone get offended, I am probably wrong on some of the specifics (some of questions at the end of first paragraph?), but I do believe on the whole idea. On 10/18/07, David Abrahams <dave@boost-consulting.com> wrote:
on Wed Oct 17 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Tue Oct 16 2007, "Marco Costalba" <mcostalba-AT-gmail.com> wrote:
I would like to ask you if someone has never dreamed of something like
try well_formed {
.... your code here...
} catch {
.... fall back code in case former is not compilable...
};
I would think this would be an extension that greatly will open new gates to C++.
Yes, the compiler vendors have a really hard time seeing how such a feature could be implemented. The problem is that they have data structures such as symbol tables that are updated as code is parsed, and there's no way to roll them back to the state they were in before the try block if the code turns out to be ill-formed.
OK, that has got to be one of the lamest excuses I've heard from compiler vendors so far. All the compilers I've written have had some form of stacked symbol tables for the sole point of implementing scopes. And this is just another scope use case.
No, it's not. You have to be able to undo template instantiations and other permanent state changes that can't be stacked.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost