Re: [Libreoffice-commits] core.git: cppcheck style fix for noExplicitConstructor in writerfilter

On 12/05/2016 02:00 PM, j.nitschke@ok.de wrote:
> On 12/05/2016 10:58 AM, Stephan Bergmann wrote:
> > * Why that concentration on single-parameter ctors?  Is cppcheck a
> > pre-C++11 tool?  That leads to an arbitrary-looking mix of explicit
> > and non-explicit ctors in cases like
> This is simply following guides like the C++ Core Guidelines. [1]
> I think the reason for the rule didn't went away with C++11. But with {
> initialisation } there is a new good use case now.

Hm, [1] states "Single-argument constructors should be declared 
explicit.  Good single argument non-explicit constructors are rare in 
most code based [sic]."  No idea whether or not that's true; just found 
it puzzling that cppcheck would warn about each (non-copy/move) ctor 
with one parameter, without any further heuristics.  (And why doesn't it 
also warn about ctors callable with one argument?  Probably an oversight.)

> [1]
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-explicit
> [2] http://dev-builds.libreoffice.org/cppcheck_reports/master/

> PS: could someone look into the cppcheck warnings:

I find one each of those in [2]:

> accessForwarded - Access of forwarded variable expression

<http://dev-builds.libreoffice.org/cppcheck_reports/master/466.html#line-63> 
is harmless.  What's relevant in the OUStringBuffer ctor call is not the 
content of the passed argument (which is ignored anyway by the special 
RTL_STRING_UNITTEST ctors) but only its type.

> accessMoved - Access of moved variable pReleasedFormat.

<http://dev-builds.libreoffice.org/cppcheck_reports/master/664.html#line-4657> 
looks OK, too:  SwDoc::DelTableStyle will either store pReleasedFormat 
in a new SwUndo and return an empty std::unique_ptr, or return 
pReleasedFormat.  That code was added by 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=0943ee2decb8d5a1a2a5bf3b1c233934a89e9c97> 
"GSoC Writer Table Styles; Create by example; fix undo"---any further 
thoughts from its author or committer (on cc)?