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