Re: [lmi] Various C++ m12ns

[Vadim Zeitlin]

On Wed, 1 Feb 2017 21:47:34 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim, what do you think about...
GC> 
GC> (1) Changing '> >' to '>>' to close template-parameter-lists? That seems
GC> like the removal of a nuisance to me. (Of course, it creates a nuisance
GC> for compiler writers, but they've already accommodated it.) However, does
GC> it create a problem with any tools you use? E.g.:
GC> 
GC> 
http://stackoverflow.com/questions/7304699/what-are-all-the-syntax-problems-introduced-by-the-usage-of-angle-brackets-in-c/7304730#7304730
GC> 
GC> | ctags fails for some template definitions, which makes it
GC> | unusable with our current C++ project

 I do use ctags with all of my projects and I haven't had any problems due
to this. As much as I love (exuberant-)ctags, I have to admit that it
doesn't parse code using non-trivial templates very well -- but usually
it's good enough for me and, again, I've never seen any problems
specifically due to the use of ">>". So yes, I'd definitely remove the
spaces, if only because there is no reason to have them in the new code and
consistency is good.


GC> (2) Replacing
GC> 
GC>   class foo : private lmi::uncopyable<foo>
GC> 
GC> with
GC> 
GC>   class foo
GC>   ...
GC>       foo(foo const&) = delete;
GC>       foo& operator=(foo const&) = delete;
GC> 
GC> ? I'm not convinced that such a change should be made. If C++11 let us
GC> write it the way we can write 'final':
GC>   class foo : uncopyable
GC> then that would be best. But declaring two extra member functions
GC> requires writing the class's name four times, and typically those
GC> declarations would be somewhere in the middle of the class declaration,
GC> after public members and before other private members. It just seems
GC> more verbose and less readable to me.

 I understand this point of view, but I don't agree with it mainly because
I have a rule, predating C++11, consisting in always doing something about
the compiler-generated functions because forgetting to do it is so common
in C++ code, that it's very nice to have an explicit reminder that the
author did think about it. So even if the default behaviour is appropriate,
I would always write a comment like this

        // Compiler-generated copy ctor and assignment operator are ok.

in C++98 code. And in C++11 code I use

        foo(foo const&) = default;
        foo& operator=(foo const&) = default;

to say this in code instead of comments. So from my point of view, it's
natural to have the same with "= delete" if the compiler-generated
functions are not appropriate and, in fact, jarring not to see these 2
lines in the code.

 This is, of course, a question of habit, but I believe it's a good habit
to have.

 Regards,
VZ