switch()

Started by
36 comments, last by mikeman 17 years, 10 months ago
Quote:
I wrote an extensive answer to jpetrie, but the forums ate it.


Yea, they ate mine a couple times too. With all the 500 errors recently, I've taken to composing my posts offline in a text editor and pasting them in.

I've got nothing new to add to the discussion, really. As somebody said previously, it is hard to come up with solid, defensible arguments against syntax-altering macros, especially ones like yours (versus others, like my foreach example, Emmanuel's loop_on, and MAPLOOPXY). However, I do have some rebuttals:

Quote:
1)Std::for_each: It's not a coincidence they named it that way, is it? A beginner would confuse it with a "for each" loop and try to put a lambda instead of a function. An experienced programmer would wonder why is there a construct named after the universally known for each that does not do the same thing at all, and what it does is hardly exciting.


Not a coincidence at all, true. But a beginner who cannot distinguish between a function call and a control flow construct is too much of a neophyte to be included in this discussion. Conversely, an experienced programmer who doesn't realize that C++ does not support for-each loops natively can hardly call himself experienced (with respect to C++).

Quote:
2)About consistency: I didn't invent switches, you know. C/C++ already has both switches(for integrals) and if-elses that do the same thing for everything,including integrals. Do you use if-else everywhere or just when you can't use switch? If the former, you lose the jump table optimization. If the latter, you lose consistency.


A valid point regarding the jump-table optimization. I'd mostly concede the point about consistency as well, even though switch and if/else don't completely overlap in their use/behavior. However, introducing a second style of switch (for three more-or-less equivalent ways to do the same thing) still reduces consistency; now we're getting closer and closer to Perl. :)

Quote:
About Boost: Yes, noone championed their macros and templated voodos as a good thing, but everyone is using it.


Using boost::lexical_cast or boost::format is one thing, though. Using Boost's preprocessor stuff or Spirit (which are both prime examples of kinds of nastiness discussed or mentioned in this thread) is another thing entirely. In this sense, you can't treat Boost as a whole; I do use Boost, but I've never found a need for its uglier parts that was so great it outweighed my aversions to the ugliness (e.g., I tried Spirit once, and it solved my problem, but I found that I died a little inside every time I looked at the code so I turned to a dedicated external parser generator).

Advertisement
Quote:

2)About consistency: I didn't invent switches, you know. C/C++ already has both switches(for integrals) and if-elses that do the same thing for everything,including integrals. Do you use if-else everywhere or just when you can't use switch? If the former, you lose the jump table optimization. If the latter, you lose consistency.


You loose functionality, in C/C++ you should be able to do things like below. By using your macro this would result in unexpected behaviour.

Doing things like
int i=0;int n=1;switch(n){for(;i<5;i++){i++;case 1:   /*code here* /}}

wouldnt work as expected with your code for example
Check this for more info when this is done:
Duff's device
Dang, I just knew there was some solid reason to prevent me from using these macros here and there. They can't implement Duff's device! How could I missed that?

However, let's study the example you have earlier without my dreaded macros, but with a simple twist:

int _tmain(int argc, _TCHAR* argv[]){int k=1;int i=0;switch(k){	case(0):	for (i=10;i<2;++i)	{		printf("And am I supposed to be executed?I'm above the first case that is evaluated true!\n");	case (1):		printf("%How the hell did I got here?\n");	}}return 0;}


Truely, this is really intuitive and not syntax-breaking at all. We have 2 supposedly well-defined flow control structures(not like the evil(IMO) goto), which cause the first to do a jump right in the middle of the other(exactly like the evil goto). In other words, switch causes the for loop to be not entirely executed,(because part of it is "inside" case 0), but not entirely skipped either(because part of it is "inside" case 1). Nice! See, C++ doesn't need my help, it's entirely capable of mutilating its syntax itself.

[Edited by - mikeman on June 16, 2006 6:56:58 PM]
I'm going to agree with you here; Duff's device is really toeing the line. I wouldn't consider the inability to use it a valid argument against your switch macros.
Agreed too. I hope the inventor of Duff's device (hey... Mr Duff?) will rot in hell during a full milemnium [smile]
I'd use a series of ifs and elses.
Quote:Original post by Nathan Baum
I'd use a series of ifs and elses.


Well, the macros and even the real switches don't do much else than that(semantically,because real switches can implement jump tables), with the addition of fallthroughs.

I admit that I was in a little bit of bad mood yesterday and stubbornly defended the particular macros point-to-point, instead of looking at the big picture: If I can't find solid arguments against begin_switch(), then why stop at that? Why not also use macros(with whatever small imperfections they may have,just like begin_switch) to traverse lists? Or trees? Or for a whole bunch of other stuff? That indeed would be a Bad Idea. And if I have to limit myself, how will I do that? Why choose to keep begin_switch() instead of traverse_tree() or the other way around? More importantly, in a team project, how will I convince the other programmers not to create their own trickeries and clutter the code completely, since I do exactly the same? I failed to see all that because of the scope I used the macros: A personal project, an in a very limited piece of code(basically a quick-n-dirty console implementation for my engine).

I still use those macros occasionally on my personal projects, but I wouldn't do it in a large-scale one involving other programmers, that's for sure.

This topic is closed to new replies.

Advertisement