Re: [boost] C++0x question

From: David Rodríguez Ibeas (dibeas_at_[hidden])
Date: 2007-10-18 16:12:19

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_at_[hidden]> 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
>