* [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