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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-10 10:46:27

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 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!

> Zero overhead.

Depends on what you count...

>> 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 :-).

> * 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 :-).

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.

>>>> 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).

Regards,
Tobias