[Bug c++/94997] New: cc/cp/call.c: 4 * member function could be const ?

[Bug c++/94997] New: cc/cp/call.c: 4 * member function could be const ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

            Bug ID: 94997
           Summary: cc/cp/call.c: 4 * member function could be const ?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk.git/gcc/cp/call.c:529:8: style:inconclusive: Technically the member
function 'z_candidate::rewritten' can be const. [functionConst]
trunk.git/gcc/cp/call.c:530:8: style:inconclusive: Technically the member
function 'z_candidate::reversed' can be const. [functionConst]
trunk.git/gcc/cp/call.c:9194:8: style:inconclusive: Technically the member
function '::NonPublicField::operator()' can be const. [functionConst]
trunk.git/gcc/cp/call.c:9211:8: style:inconclusive: Technically the member
function '::NonTrivialField::operator()' can be const. [functionConst]

There may be some small value in making sure that member functions
that consist only of a return statement are marked const.

[Bug c++/94997] gcc/cp/call.c: 4 * member function could be const ?

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE
           Severity|normal                      |enhancement

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Assuming this is meant to be an enhancement request to add new option to
suggest to make member functions const the same enhancement request has already
been raised in pr80711, so resolving as a dupe.

(I don't suppose you are just noting that the four instances of the message
below would be solved by marking the functions const.  There must be many more
such opportunities in GCC, as well as countless others where const could be put
to good use.)

If this is about something else please feel free to reopen the report and
explain in some detail what it's about.  (A more descriptive Summary would be
helpful.)

*** This bug has been marked as a duplicate of bug 80711 ***

[Bug c++/94997] gcc/cp/call.c: 4 * member function could be const ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 48485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48485&action=edit
text file

[Bug c++/94997] gcc/cp/call.c: 4 * member function could be const ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Sebor from comment #1)
> Assuming this is meant to be an enhancement request to add new option to
> suggest to make member functions const the same enhancement request has
> already been raised in pr80711, so resolving as a dupe.

It is an enhancement request, but for one source code file only,
not the implementation of the feature in gcc.

> (I don't suppose you are just noting that the four instances of the message
> below would be solved by marking the functions const.  There must be many
> more such opportunities in GCC, as well as countless others where const
> could be put to good use.)

Indeed, all I am doing is noting four places where const could be used.

However, cppcheck did look at the general case of all of the source code
of the gcc compiler and it found 237 places. I only mentioned
four in this bug report, to keep things simple.

List attached.

[Bug c++/94997] gcc/cp/call.c: 4 * member function could be const ?

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
After noticing pr94995 (and subsequently also your clarification in comment #3)
I see I was wrong in my assumption.  While I'm a big fan of const correctness
and agree that those functions (and probably many others) could be declared
const, I see more overhead than value in reports suggesting these types of
improvements to the code base.  If you think they're worthwhile to make, just
do it.  You can submit a patch for review but you don't even need to ask for
approval to commit it (see https://www.gnu.org/software/gcc/svnwrite.html#all).

OTOH, where I see much more value is in adding features to detect these
opportunities and adding them to -Wall (and for those, having reports in
Bugzilla is also important).

[Bug c++/94997] gcc/cp/call.c: 4 * member function could be const ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94997

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Sebor from comment #4)
> ... I see more overhead than value in reports suggesting
> these types of improvements to the code base.  

Righto. I've provided the list of all known 237 places, so
I won't report any more from the list.

I've checked about 20 of them and they look valid to me,
but there could be some false positives.

> If you think they're worthwhile to make, just do it.  
> You can submit a patch for review but you
> don't even need to ask for approval to commit it (see
> https://www.gnu.org/software/gcc/svnwrite.html#all).

Thanks but no. I prefer to encourage other developers to 
write into gcc repository than do it myself.

> OTOH, where I see much more value is in adding features to detect these
> opportunities and adding them to -Wall (and for those, having reports in
> Bugzilla is also important).

Agreed. I find the best first step to getting a new feature into gcc
is to point out as many as possible places in the source code of gcc
where that feature would help.

Whether 237 cases is enough is now in the hands of a keen developer
with enough time to implement the feature.