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