Thanks for the explanation (snipped).
* C++: add a fix-it hint to -Wsuggest-final-methods
To answer your call for other ideas below: There are other
suggestions that GCC could offer to help improve code, including
* to add the const qualifier to function pointer and reference
arguments (including member functions)
When there's a mismatch? Consider e.g.
void test (const char *dst, char *src)
{
memcpy (dst, src, 1024);
}
warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
memcpy (dst, src, 1024);
^~~
note: expected ‘void *’ but argument is of type ‘const char *’
void test (const char *dst, char *src)
^~~~~
------
(here I've added the underlining of the "const" and the fix-it hint
suggestion deletion of "const" on param aren't).
This would be useful as well but...
plus we could add:
warning: argument 2 could be marked as 'const'
void test (const char *dst, char *src)
^~~~~~~~~~
const char * src
... the latter is what I meant. It's common to forget to
declare a pointer (or reference) argument const even when it
doesn't change the object it refers to. Suggesting the const
keyword would help drive const correctness and even expose
optimization opportunities (e.g., with the restrict suggestion
below, but also in other contexts). This could be extended
beyond function arguments and to private class members and
perhaps even local (and static global) variables.
* to add restrict where appropriate (especially to const pointer
and reference arguments)
When is it appropriate? Is this something that we can infer?
Broadly, declaring a pointer argument restrict is appropriate
whenever it's not used to access the same object as another
pointer whose value wasn't derived from the first pointer.
It shouldn't be too hard to infer the simple cases in the alias
oracle. The main benefit I see is for out-of-line functions
that take their arguments by const pointer or const reference.
By declaring the arguments restrict GCC can assume that the
function doesn't change the pointed-to object (otherwise it
must assume that every such function casts the constness away
and changes the object). This optimization isn't implemented
yet.
* to delete or default the default copy ctor or copy assignment
operator if/when it would benefit
Nice idea; is there a way we can tell when this is appropriate?
Suggesting to delete a copy ctor/assignment should be doable
in the middle-end by analyzing the ctor and dtor for paired
calls to functions that acquire and release some resource
(e.g., memory via new and delete). A class that does that
but that doesn't define a dedicated copy ctor or assignment
can be misused to create a copy of an object and have the
same resource released more than once. This is quite
a common mistake to make.
The second case (defaulted functions) should be detectable by
analyzing the special functions' semantics and determining
whether or not they are the same as those of the defaulted
function. Defaulting the special function would then help
make objects of the class usable in more contexts and more
efficiently (especially if the special functions were defined
out of line).
Martin
