Re: [lmi] Updating code to use C++11

[Vadim Zeitlin]

On Mon, 25 Jan 2016 02:58:00 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-25 01:31, Vadim Zeitlin wrote:
GC> > 
GC> >  Personally I'd like to start at least the following new C++11 features in
GC> > the code:
GC> > 
GC> > - "auto" for the variables to avoid duplicating the type of the RHS
GC> > - short loop syntax for the "for each" loops
GC> > - lambdas for the wxWidgets event handlers
GC> > - nullptr instead of 0 or NULL for type safety
GC> > - "override" to make sure methods are really overridden when meant to
GC> > - "= delete" instead of "lmi::uncopyable<>"
GC> > 
GC> >  Of this, I think, only the first one can be potentially controversial, 
but
GC> > please let me know if I'm wrong and if you have anything against the other
GC> > ones and/or also agree with the first one or, at least, don't disagree 
with
GC> > it violently enough to make any attempt to convince you to start using
GC> > "auto" doomed in advance.
GC> 
GC> From what little I've read about it, 'auto' sounds like a good idea,

 I think it mostly is, although, to be honest, I don't have that much
experience with it in bigger code bases and my opinion is still changing,
but the direction seems to be in "auto" favour, i.e. I was more sceptical
about it before I started using it than now, after having used it for a
bit. Generally speaking, the spectre of opinions about it ranges from Herb
Sutter's AAA ("Almost Always use Auto"), see
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
to the conservative "only use auto for complicated types involving
iterators". I certainly agree with at least the latter, e.g. compare this
example from census_view.cpp:

---------------------------------- >8 --------------------------------------
-    typedef std::vector<std::string>::const_iterator sci;
-    for(sci i = all_headers.begin(); i != all_headers.end(); ++i)
+    for(const auto & header : all_headers)
---------------------------------- >8 --------------------------------------

to see what "auto" can bring you, but by now I also definitely prefer to
use it for all numeric types to avoid implicit conversions from larger to
smaller integer types or from signed to unsigned or vice versa. Using
"auto" is nice when you want to use the same type as an existing variable
and it turns out that very often this is exactly what you want.

 And, of course, once you start using "auto" in all these special cases,
it's simpler and -- dare I utter this word -- more concinnous, to just use
it everywhere.

GC> Wasn't 'override' part of the original C++ language?

 No, but "auto" actually was, see http://www.stroustrup.com/C++11FAQ.html#auto

GC> Well, I've got some catching up to do. Are the old guys like Stroustrup and
GC> Scott Meyers still writing? Or has a new generation arisen to rival them?

 Scott Meyers has recently announced his retirement from C++, see
http://scottmeyers.blogspot.fr/2015/12/good-to-go.html but Stroustrup is
still very active and there are plenty of other people writing about C++
(mostly of 14/17 variety by now though), but I'm not sure if any of them
are as exceptional. Which is probably a good thing, there seem to be many
more people very knowledgeable about C++ nowadays than, say, 10 years ago.
Or maybe they're just more visible.

GC> I guess I'm pretty much in favor of what little I understand about C++11.
GC> If you want to move forward with this faster than I learn about it, it
GC> would be a good idea to share a small snippet of each idea first. I can't
GC> provide a C++11 example, but if we were moving from C to C++, you might
GC> suggest changing
GC> 
GC>   int j = 0;
GC>   for(j; j < 9; j++)
GC> 
GC> to
GC> 
GC>   for(int j = 0; j < 9; ++j)
GC> 
GC> (counter declaration inside for-loop; pre- instead of post-increment) so
GC> that I can ask questions or present objections before you put in a lot of
GC> effort. But I might actually have few or no objections. I guess the C->C++
GC> example above is pretty similar to the new 'auto' keyword: once understood,
GC> one wonders why the language didn't always work that way.

 It definitely applies to the "for each" loops. Anyhow, I'll send separate
emails with the rationale (if necessary) and the examples of the proposed
changes, starting from the simplest ones.

 Thanks!
VZ