[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Various C++ m12ns
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Various C++ m12ns |
Date: |
Wed, 1 Feb 2017 22:58:53 +0100 |
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