Don't complain about explicit no-arg constructors. - #227
Conversation
In the situation, where one git/svn/hg repository is located inside the directory tree of another, the search incorrectly selects the outer one instead of the inner one.
|
This failing check doesn't seem to be caused by my changes. Any guidance on how to get them to pass? |
Previously, cpplint has complained when a no-argument constructor is marked `explicit`. This is bad for two reasons: 1. As of C++11, converting constructors can be called with any number of arguments including 0. Therefore, this check is wrong. (see https://en.cppreference.com/w/cpp/language/converting_constructor ) 2. Even in pre-C++-11 code, it is good defensive programming practice to mark all constructors `explicit`. Marking a constructor that cannot be a conversion `explicit` has no ill effect, but if someone alters it to be a possible implicit conversion, it defends you against them forgetting to add `explicit`.
already implemented, all it does is change a test file now
Removes 'lint' subcommand support from setup.py and replaces corresponding steps with the unmasked Python module commands
Most blocked features have been removed, the c++tr1 and c++14 categories have been removed, and the c++17 category has been added. Same for relevant tests 1. The only blocked features I can see in the specification that haven't been blocked elsewhere are headers 2. Most of these blocked features aren't blocked in the style guide 2.1: A lot of these unwarrantedly blocked features, like ratio, are also very useful 2.2: TR1 is super old and we shouldn't be thinking about it anyways 3. There aren't enough features we need to block to warrant separate functions for each C++ standard
The verbose pytest output is quite annoying to read in a CI, and using a timeout solves the issue of knowing which tests hang. Also included: tox.ini now installs the extra [dev], so we only need to make changes in one place now.
A chromium sample has been updated to a version that uses C++17 stuff READMEs of samples have been clarified regarding licensing Two licenses have also been updated Our setup.py now includes a BSD classifier for PyPI
Move usage to its own section and provide rudimentary instructions to defuse error caused by external package managers
Follow-up to cpplint#217, another try to fix cpplint#27. This stops IWYU on erring on tokens with namespace prefixes that aren't std. This change should preserve backward compatibility while preventing false positives for common names in other namespaces.
|
Note that the only change is c607830, I just merged to see if CI passes. I think that was a bad idea and I'll just run tox locally next time... |
"Implicit conversions can sometimes be necessary and appropriate for types that are designed to be interchangeable, for example when objects of two types are just different representations of the same underlying value. In that case, contact your project leads to request a waiver of this rule."
aaronliu0130
left a comment
aaronliu0130
left a comment
There was a problem hiding this comment.
Seems okay, but I'm not so experienced in that field. Is there any plausible reason you could think of for never marking zero-param constructors as explicit?
aaronliu0130
changed the title
explicit no-arg constructors.explicit no-arg constructors.
|
The Google style guide neither recommends nor forbids it. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions Some C++ experts recommend it.
https://quuxplusone.github.io/blog/2023/04/08/most-ctors-should-be-explicit/
https://hsutter.github.io/cppfront/cpp2/types/#implicit-controlling-conversion-functions There is probably room for a tool to warn against not having explicit for non-move/copy/initializer list constructors. But the need seems small. |
10 participants
Previously, cpplint has complained when a no-argument constructor is marked
explicit. This is bad for two reasons:As of C++11, converting constructors can be called with any number of arguments including 0. Therefore, this check is wrong. (see https://en.cppreference.com/w/cpp/language/converting_constructor )
Even in pre-C++-11 code, it is good defensive programming practice to mark all constructors
explicit. Marking a constructor that cannot be a conversionexplicithas no ill effect, but if someone alters it to be a possible implicit conversion, it defends you against them forgetting to addexplicit.