Eric, I've been too lazy to reply.
From: "Eric Friedman" <[EMAIL PROTECTED]> 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.
And, I agree, that's no significant advantage.
> 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).
Cool!
> 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...
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.
> 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.)
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
