Boost logo

Boost :

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

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
> > effort?
Thanks for the explanation.
> > Still, I would like to put forward a couple of considerations. These
> > comparatively subjective:
> > 1) The "runtime_type_selected_invoker" component is implemented
> > of variant. Two benefits deriving from this approach are:
> > a) "variant" becomes a client rather than a collaborator in the usage
> > the functionality. The practical differences? A three-argument
> > call rather than a six-argument call dependent on two supporting
>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
>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
And, I agree, that's no significant advantage.
> > b) Distribution decisions can be made separately for the two. One
> > thought of was preprocessing. If someone wants to distribute
> > versions of code, he can make one decision for variant and another for
> > "rtts".
>I actually do agree with this. Accordingly, I've factored
>into a separate detail header. And I do plan to look into preprocessing at
>some point...
> > 2) An interesting characteristic of your approach is that it results in
> > generation of "extra" cases which should never be executed. There seems
> > be some extra complexity involved in implementing these extra cases.
> > implementation I propose does not suffer this problem. (Don't these
> > 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
>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.


<b>Get MSN 8</b> and help protect your children with advanced parental

Boost list run by bdawes at, gregod at, cpdaniel at, john at