public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop
@ 2022-08-09 7:43 dcb314 at hotmail dot com
2022-08-09 13:50 ` [Bug c/106569] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: dcb314 at hotmail dot com @ 2022-08-09 7:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
Bug ID: 106569
Summary: enhancement: use STL algorithm instead of a raw loop
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck can produce these style messages for gcc trunk source
code:
$ fgrep useStlAlgorithm cppcheck.20220809.out
trunk.git/gcc/analyzer/call-string.cc:169:9: style: Consider using
std::count_if algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/analyzer/constraint-manager.cc:2454:0: style: Consider using
std::find_if algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/analyzer/region-model-manager.cc:1230:0: style: Consider using
std::any_of algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/analyzer/region.cc:1245:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/cp/constexpr.cc:348:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/cp/constexpr.cc:5965:8: style: Consider using std::find_if
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/cp/constexpr.cc:8991:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/rtl-ssa/change-utils.h:28:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/rtl-ssa/blocks.cc:347:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/rtl-ssa/accesses.cc:1507:7: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/gcc/rtl-ssa/member-fns.inl:854:0: style: Consider using std::any_of
algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/libsanitizer/hwasan/hwasan_thread_list.h:120:20: style: Consider
using std::find_if algorithm instead of a raw loop. [useStlAlgorithm]
trunk.git/libsanitizer/hwasan/hwasan_report.cpp:293:0: style: Consider using
std::find_if algorithm instead of a raw loop. [useStlAlgorithm]
$
None, some or all of these might be worth fixing.
I suspect it would not be worthwhile to implement this style warning in gcc.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
@ 2022-08-09 13:50 ` rguenth at gcc dot gnu.org
2022-08-09 14:07 ` dcb314 at hotmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-09 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I find those less obvious, for example does std::any_of guarantee some
evaluation order?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
2022-08-09 13:50 ` [Bug c/106569] " rguenth at gcc dot gnu.org
@ 2022-08-09 14:07 ` dcb314 at hotmail dot com
2022-08-09 18:23 ` marxin at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dcb314 at hotmail dot com @ 2022-08-09 14:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Richard Biener from comment #1)
> I find those less obvious, for example does std::any_of guarantee some
> evaluation order?
I also find any_of less obvious, but that's because my working knowledge
of C++ stopped about 20 years ago.
According to
https://cplusplus.com/reference/algorithm/any_of/
there is no guarantee of evaluation order.
My best guess is that if gcc trunk is written in some recent version of C++,
then all that recent version can be used.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
2022-08-09 13:50 ` [Bug c/106569] " rguenth at gcc dot gnu.org
2022-08-09 14:07 ` dcb314 at hotmail dot com
@ 2022-08-09 18:23 ` marxin at gcc dot gnu.org
2022-08-09 18:57 ` dcb314 at hotmail dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-08-09 18:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
> My best guess is that if gcc trunk is written in some recent version of C++,
> then all that recent version can be used.
We are written in C++11, is std::find_if available in the given standard?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
` (2 preceding siblings ...)
2022-08-09 18:23 ` marxin at gcc dot gnu.org
@ 2022-08-09 18:57 ` dcb314 at hotmail dot com
2022-08-12 21:43 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dcb314 at hotmail dot com @ 2022-08-09 18:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #3)
> > My best guess is that if gcc trunk is written in some recent version of C++,
> > then all that recent version can be used.
>
> We are written in C++11, is std::find_if available in the given standard?
Yes, there is *a* version of std::find_if available. Some additional
work might be needed to verify exact match.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
` (3 preceding siblings ...)
2022-08-09 18:57 ` dcb314 at hotmail dot com
@ 2022-08-12 21:43 ` redi at gcc dot gnu.org
2022-08-12 21:44 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-08-12 21:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #0)
> Static analyser cppcheck can produce these style messages for gcc trunk
> source code:
>
> $ fgrep useStlAlgorithm cppcheck.20220809.out
> trunk.git/gcc/analyzer/call-string.cc:169:9: style: Consider using
> std::count_if algorithm instead of a raw loop. [useStlAlgorithm]
I don't think count_if would work here. I haven't looked at the others yet, but
this first one seems like a useless suggestion.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
` (4 preceding siblings ...)
2022-08-12 21:43 ` redi at gcc dot gnu.org
@ 2022-08-12 21:44 ` redi at gcc dot gnu.org
2022-08-12 21:48 ` redi at gcc dot gnu.org
2022-08-12 22:28 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-08-12 21:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #2)
> According to
>
> https://cplusplus.com/reference/algorithm/any_of/
cplusplus.com is garbage, use cppreference.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
` (5 preceding siblings ...)
2022-08-12 21:44 ` redi at gcc dot gnu.org
@ 2022-08-12 21:48 ` redi at gcc dot gnu.org
2022-08-12 22:28 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-08-12 21:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
std::find_if exists since c++98.
I'll go through these in a couple of weeks, it's probably not productive for
people who don't know the C++ std::lib well to bother analysing the
suggestions.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/106569] enhancement: use STL algorithm instead of a raw loop
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
` (6 preceding siblings ...)
2022-08-12 21:48 ` redi at gcc dot gnu.org
@ 2022-08-12 22:28 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-08-12 22:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to David Binderman from comment #0)
> > Static analyser cppcheck can produce these style messages for gcc trunk
> > source code:
> >
> > $ fgrep useStlAlgorithm cppcheck.20220809.out
> > trunk.git/gcc/analyzer/call-string.cc:169:9: style: Consider using
> > std::count_if algorithm instead of a raw loop. [useStlAlgorithm]
>
> I don't think count_if would work here. I haven't looked at the others yet,
> but this first one seems like a useless suggestion.
The other suggestions for gcc/analyzer/*.cc look correct, or at least, not
incorrect, but not all of them would improve clarity. Similarly for the
gcc/cp/constexpr.cc suggestions. They would need a lambda expression that
captures local variables, and then compare the result of the algorithm to the
end iterator of the range. I don't think that would improve the code. It would
certainly be more lines of code.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-08-12 22:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-09 7:43 [Bug c/106569] New: enhancement: use STL algorithm instead of a raw loop dcb314 at hotmail dot com
2022-08-09 13:50 ` [Bug c/106569] " rguenth at gcc dot gnu.org
2022-08-09 14:07 ` dcb314 at hotmail dot com
2022-08-09 18:23 ` marxin at gcc dot gnu.org
2022-08-09 18:57 ` dcb314 at hotmail dot com
2022-08-12 21:43 ` redi at gcc dot gnu.org
2022-08-12 21:44 ` redi at gcc dot gnu.org
2022-08-12 21:48 ` redi at gcc dot gnu.org
2022-08-12 22:28 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).