Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-10 10:14:12

Tobias Schwinger wrote:
> Joel de Guzman wrote:
>> Tobias Schwinger wrote:
>>> Joel de Guzman wrote:
>>>> Tobias Schwinger wrote:
>>>>
>>> Both the built-in switch statement and the interfaces you proposed 
>>> restrict client code to a single number of cases which is known at 
>>> preprocessing time. Steven's approach OTOH allows the number of cases to 
>>> vary at compile time.
>>>
>>> Further, requiring a function object for every case is often not 
>>> required and just overhead.
>> "Often"? On the contrary. It's the opposite. What's your use cases?
> 
> Ones where I don't know the number of cases at preprocessing time...

I think we are on a different page and it's perhaps a good idea
to look back beyond our current mindset. AFAIK, my proposal
*can* accommodate that.

>> I have lots with composition of *many* function objects. 
> 
> ...so those ^^ will be in a Sequence. Therefore I'm happy with the pure 
> dispatch and a compile time index.
> 
> Further, that index is more flexible, as I can look whatever I like (not 
> just function objects but arbitrary objects).
> 
>> We've
>> discussed some in earlier posts. "Overhead"? There is no overhead.
>> The compiler will optimize them away. Look at how proto does it,
>> for example. 
> 
> I know. This process will cost precious compile time!

Everything costs at compile time.

>> Zero overhead.
> 
> Depends on what you count...

If you count compile time, I'd say minimal overhead. But really,
all this talk at this early stage is premature optimization if
you jump to the conclusion that the added interface is not
sound because of this potential overhead.

>>> Picking the simplest interface without these limitations will basically 
>>> yield what we are currently reviewing.
>> For the purpose of clarification, let me call the original
>> interface A and my proposal B.
>>
>> Again:
>>
>> * Transforming A to B requires minimal amount of coding. The smarts
>>    is already in the PP code. The cost is cheap.
> 
> The cost is cheap and the effect is destructive :-).

Why is it destructive? You must be seeing a use-case that I
don't.

>> * Building B on top of A requires Fusion or repeating the PP
>>    code all over again. The cost is high!
> 
> It's not about *repeating* -- it takes 'unfused' or PP code to mess up 
> the interface and remove all flexibility from it :-).

I'm confused. Please be more straight to the point.

> Building A on top of B is much worse, and this time we *are* repeating 
> the PP code!
> A brilliant software architect like you should find this sign alarming 
> enough to take a deep breath and give things another thought.

To be honest, I really don't see your point. I still don't see why
you'd want to build A on top of B.

>>>>> The fact that we can't do it the other way around (at least not easily 
>>>>> -- even given "fused switch") indicates that the current design is the 
>>>>> better-suited one for automation purposes!
>>>> I don't know what you mean by "other way around".
>>>>
>>> Implementing Steven's interface in terms of yours is not possible 
>>> without repeating the PP code.
>> But why do you want to do that? 
> 
> To allow the number of cases to vary at compile time (as opposed to 
> preprocessing time).

You already said that. Here:

     template <typename Cases>
     void foo(Cases cases) {
         switch_<void>(n)(cases);
     }

The number of cases *can* vary at compile time. I have a guess that
we're talking past each other.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net