[boost] Re: switch-based runtime type selection (for variant)

From: Brian Simpson (wheber_at_[hidden])
Date: 2003-08-20 16:50:33

Eric,
I've been too lazy to reply.

>From: "Eric Friedman" <efriedman_at_[hidden]>
>Subject: Re: switch-based runtime type selection (for variant)
>Date: Thu, 14 Aug 2003 02:09:41 -0400
>
>Brian Simpson wrote:
> > Eric,
> > It sounds like you've become convinced that the switch is, indeed, worth
>the
> > effort?
>
[snip]
Thanks for the explanation.
>
>
> > Still, I would like to put forward a couple of considerations.  These 
>are
> > comparatively subjective:
> > 1) The "runtime_type_selected_invoker" component is implemented
>independent
> > of variant.  Two benefits deriving from this approach are:
> >   a) "variant" becomes a client rather than a collaborator in the usage 
>of
> > the functionality.  The practical differences?  A three-argument 
>function
> > call rather than a six-argument call dependent on two supporting 
>typedefs.
>
>Generally I might agree with this argument, but I disagree in this instance
>because of the the heavy use of templates invovled. Thus, even if the
>visitation mechanism were in a separate header, any changes will require 
>any
>code dependent on variant.hpp to be recompiled. So with that given, I'm not
>sure what other advantages there would be (apart from perhaps a
>slightly-simplified invocation in variant's raw_apply_visitor
>implementation).
>
And, I agree, that's no significant advantage.
>
> >   b) Distribution decisions can be made separately for the two.  One 
>that
>I
> > thought of was preprocessing.  If someone wants to distribute 
>preprocessed
> > versions of code, he can make one decision for variant and another for
> > "rtts".
>
>I actually do agree with this. Accordingly, I've factored 
>apply_visitor_impl
>into a separate detail header. And I do plan to look into preprocessing at
>some point...
>
Cool!
>
> > 2) An interesting characteristic of your approach is that it results in
>the
> > generation of "extra" cases which should never be executed.  There seems
>to
> > be some extra complexity involved in implementing these extra cases.  
>The
> > implementation I propose does not suffer this problem.  (Don't these 
>extra
> > cases seem like constructing a foundation with the cracks "built-in"?  I
> > know that the correctness of the class should make it impossible to ever
> > fall in, but it still makes me nervous.)
> > If you don't have to worry about how to implement "extra" cases, you can
> > spend more time implementing more visible stuff!
>
>Hmm... If the variant class is not correct then a more reliable visitation
>mechanism isn't going to help anything (and may potentially mask any
>problems). Furthermore, there have been assertions in forced_return (and 
>now
>apply_visitor_impl itself) to catch obviously broken implementations.
>
>So I guess this point could work either way, but I don't know if its worth
>changing anything now as a result. (Please reply if you disagree.)
>
This reply does not indicate disagreement.  If this component was not 
currently under development and I was not intensely interested in it, I 
wouldn't know enough about the implementation to be worried.  Accordingly, I 
intend to forget the aforementioned worries.

I have some features that I'd like to see added, yet, but I'll try to come 
up with proofs of concept before requesting them.

As it stands, variant is a powerful component.

--Brian

_________________________________________________________________
<b>Get MSN 8</b> and help protect your children with advanced parental 
controls.  http://join.msn.com/?page=features/parental