Quote:
Additional typing? Exactly as much typing as C/C++ switches require, no more, no less.
You require a couple extra characters of overhead, mostly in the "begin_switch" and "end_switch" parts. case_default is longer than default, as is case_of(foo) compared to case foo:. The typing overhead is relatively minor, however, I should not have listed it first.
Quote:
Yes they are(notice the switch_hit?).
Oops, I did miss that. I stand corrected.
Quote:
The syntax of begin_switch() is as close to the syntax of real switches as it can be. If I remember correctly, STL has a for_each construct for sequences, no? Or is that syntax "mutilation" ok simply because it pretends to be "valid" by using templates?
It's as close as it can be, but its not the same.
for_each() is a different beast; it's a
function and its not trying to mimic the syntax of the foreach
loops present in other languages. Something more similar to modified switch statements would be:
#define for_each(container_type,container,element) for(container_type::iterator element = container.begin(); element != container.end(); ++element)
which I'd have about the same adverse reaction to (this is actually far worse than your switch, since its much less generic).
(EDIT: Made macro multi-line so I don't break the thread layout.)
(EDIT: Apparently that didn't work, and the forums are giving me 500's, so just pretend that macro has the appropriate slash characters to make it multi-line.)
The big problem I see with the (switch) construct being confusing is the scope of its use. Do you use it everywhere, or only when you have to? If the former, than the fact that you are potentially losing the jump table optimization is an issue. If the latter, it's not, but now you've introduced multiple ways to do the same thing so you are giving up a little bit of consistancy.
Quote:
Especially those pseudo-variadic template paremeters of Boost with their splendid BOOST_VARIANT_LIMIT_TYPES are a true beauty to behold, really, and not at all a hack. So, a tiny bit of additional ugliness wouldn't hurt.
I disagree; a tiny bit of ugliness does hurt. The more tiny bits of ugliness creep into your code, the uglier and harder to get in to it is overall, and that's a bad thing.
A relative beginner who comes across a syntax-redefining macro like yours will be confused, probably won't understand what's going on, or the subtleties that may be involved in its use. They may attempt to use it, thinking they are following established coding standards (because very few people actually read coding standard documentation, instead they try and pick it up via osmosis by examining existing code), and use it incorrectly or in situations where it shouldn't be (like situations where a regular switch would suffice).
Conversely, an experienced programmer who comes across a syntax-redefining macro will be confused, wonder why on earth it is in place, and attempt to figure out what exactly its doing -- because the assumption will generally be that it does something signifigantly different than the established convention for the language (in this case, an if/else chain). If he discovers it does do something remarkably different, he'll wonder why attempts were made to hide the important differences (being explict is generally better and safer). If he discovers it doesn't do anything remarkably different, he'll wonder why somebody confused the issue with a needless abstraction.
The syntax of the macros is only familiar when you know what the macros do. When you don't, they look familiar (but may not be) and should set off warning flags, because they require either investigation or assumption, both of which can decrease productivity.
Boost is not an issue. While a lot of Boost is wonderful and useful, an equal amount is really damned ugly, and often for very little benefit. They're just as guilty of doing nasty things, and that shouldn't be an excuse. Since nobody has championed their macro and template voodoo as a Good Thing, I don't think bringing it up really strengthens your position at all.
