C++ Standards Committee Meeting in Rapperswil, June 2014
botondballo.wordpress.com
botondballo.wordpress.com
The (elem : range) proposal seen here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n385...
I'm really looking forward to as well. I wish it could have been in C++14. STL (the guy) is right when he says (auto elem : range) is very tempting. Its so easy for a novice user to not understand they are making a ton of potentially (and likely) unneeded copies. Also in code review its quite common, to see (const auto &elem : range) when it should be (const auto &&elem : range).
After getting bogged down years ago in a crappy C++03 codebase I eased off C++ for a few years, but i must say, the language is really getting better. 5 years ago if you would have told me I would be looking forward to writing something major in C++ I would have laughed.
For the typical enterprise developer, at least in many of our projects, I am happy that we manly use other languages.
I feel like crying every time I see C style coding in C++, with its usual set of security exploits.
I have seen quite a few projects with developers that could barely handle VB, being thrown to C++ projects.
Others where the style guide was making it, C compiled with a C++ compiler.
I'm not sure why would anyone do that, if they want to produce a quality result. Finding good programmers and engineers is hard though.
> Others where the style guide was making it, C compiled with a C++ compiler.
Yes, that can be pretty annoying, and I had to deal with maintaining such code in the past. Luckily this doesn't happen anymore in our development.
Pay as less as possible for project costs.
Note that nothing's wrong with "const auto& elem", except that it prohibits modification. On the other hand, "const auto&& elem" will typically not compile (it'll insist on binding to rvalues, which only proxy iterators return).
Thats of course right about const auto &&.. It won't work, I did mean (auto &&elem : range).
I was at first relieved to see this topic addressed at the top of Q&A, then disappointed to see "Just do it the old way if you want const." I feel that we don't use const enough in C++, and making it easier (yet still clear) to use would be of significant benefit.
If you agree, perhaps there is still time to support "for (const elem : range)" - it seems to me natural and no more disruptive than the rest of the proposal.
There's already a Standard precedent in form of C++11 lambdas -- and const-by-default has some technical niceties (perhaps simplicity, too -- arguably making this the default removes some complexity from the language from the beginner's point of view, e.g., by preventing accidental mutation) that may make this worth it.
// I see that you addressed the constness in A17, but I believe allowing the `mutable` opt-in, as in the lambdas, takes care of the "limiting" aspect; "confusing", OTOH, is a matter of taste -- after all, `std::for_each` operates on InputIterators as well (thus, perhaps the similarity with a non-modifying nature[1] of a Standard Library analog is arguably preferable from the consistency / least-surprise-principle point of view?), and, again, lambdas also have constness by default.
Thoughts?
// [1] -- in principle, at least (for completeness, there's an allowance for nonconstant functions w/ mutable iterators)
for_each() does not add constness, and can modify elements in-place. The fact that it is grouped with the "non-modifying algorithms" is a confusing historical artifact (and was actually the subject of the first Library Issue I had a part in filing) - the algorithm itself does not modify things (unlike sort(), say) but the given functor can.
Interesting that the constness in `for each` caused confusion (did it offer a `mutable` opt-in, though?), would intuitively expect it to be the POLS behavior. I guess given that you were probably receiving feedback on that, I will take it as something to be acknowledged.
I can see the reference semantics point, in this context the difference from the lambdas seems to make more sense.
// Just to explore another avenue, again mostly out of curiosity :-), how realistic (from the impl. POV) would be to have value-semantic range-based `for` with _mandated_ copy elision whenever possible?
True about `std::for_each`, that's what I've referred to as the "allowance" for the mutable iterators, wasn't aware about the grouping being merely a historical artifact, though. I've always felt a bit dirty using it for mutation[1], it seems that maybe unnecessarily so :-)
// [1] -- perhaps due to the algorithm being specified in terms of the InputIterator concept; hm, that being said, I suppose that while it only guarantees that we can read (dereferenced) `it`, it doesn't say that `it` _itself_ has to be immutable (right?), so it could be that I should think of a better metaphor to internalize. How do you think about InputIterators?
Nope.
> would intuitively expect it to be the POLS behavior.
If you give me (the implementation) a modifiable range, and I invisibly add constness before giving you back an element, that's surprising. C++ doesn't add constness by default anywhere (with the novel exception of lambda function call operators). If you give me a modifiable range, the least surprising thing to do is to give you a modifiable element, because that's what all of ptr[idx], * ptr, and * iter would do.
> how realistic (from the impl. POV) would be to have value-semantic range-based `for` with _mandated_ copy elision whenever possible?
If you say "for (auto elem : range) { elem = stuff; }" the write to the elem-copy will be dropped on the floor. Copy elision can't solve that.
> it doesn't say that `it` _itself_ has to be immutable (right?)
Correct.
> How do you think about InputIterators?
The concept is single-pass, read-only, but a given iterator may be stronger. for_each() is kind of special (it's the only algorithm that takes InputIterators, yet allows stronger iterators to be used with modifying functors), but other algorithms are vaguely similar. For example, transform(InIt first, InIt last, OutIt result, UnOp op) permits transform(first, last, first, op) for an in-place transformation - here, first/last's type clearly has to be InIt and OutIt simultaneously, i.e. a mutable FwdIt iterator or stronger.
Presumably that should be "decreasing", not "increasing" (or "compilation speed" rather than "compile times").
modules ! modules ! modules !
He's also writing a new book that's available in Rough Cuts from O'Reilly that covers C++11/14: http://scottmeyers.blogspot.com/2014/06/effective-modern-c-s... and has given a talk covering some of the same ground: http://vimeo.com/97318797
Herb Sutter has "Elements of Modern C++ Style": http://herbsutter.com/elements-of-modern-c-style/ and has given several talks, such as http://channel9.msdn.com/Events/Build/2014/2-661
Finally, you can't really beat Stroustrup's book: http://www.amazon.com/The-Programming-Language-4th-Edition/d...
So why forcing everyone to jump through hurdles just to do some simple uses of 2D programming?
Plain simple 2D graphics like BGI, to allow any C++ beginner not to worry which bazillion libraries s/he needs to download to draw some colored squares.