http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
Gašper Ažman changed:
What|Removed |Added
CC||gasper.azman at gmail dot
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gasper.azman at gmail dot com
Target Milestone: ---
Dear GCC wizards,
Recently, the use of std::forward has been idiomatically replaced by the
following:
```
template
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #2 from Gašper Ažman ---
Ivan: indeed, you could use a static cast, or a macro - you're literally just
changing the value category of the expression to its original one. The cast is
safe.
The reason Niebler and friends (including me)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #4 from Gašper Ažman ---
@Eric Gallager: yes, the #pragma solution is what I currently use. It is
entirely unsatisfactory, for the reasons described in my original request.
The long-term usefulness of warnings is directly proportiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #5 from Gašper Ažman ---
s/endif/pragma GCC diagnostic pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #4 from Gašper Ažman ---
As one of the authors, I can assure you you never need to implement this for
c++23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #5 from Gašper Ažman ---
And of course by "this" I meant support for a default argument on the explicit
object parameter.
We might add it back in the future if we find a usecase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #10 from Gašper Ažman ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that usefu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #12 from Gašper Ažman ---
Replies to relevant snippets inline.
That was quite a write-up!
> The only compelling case I can think of for such a thing would be passing a
> pointer type that isn't related by inheritance anyway. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #17 from Gašper Ažman ---
Read through the patch quickly, want to suggest a few tests.
When a lambda has captures, the explicit object parameter is used to get at
them *silently*, if they are related, otherwise the program is ill-fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #19 from Gašper Ažman ---
Correct, the use of the capture is the source of the error, not the
instantiation with an unrelated type.
On Sat, Sep 2, 2023, 09:54 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
> https
oduct: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gasper.azman at gmail dot com
Target Milestone: ---
We've been converting so much code to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #2 from Gašper Ažman ---
-fprofile-constexpr is perfectly fine :), as long as it gets a filename
argument for the output; build automation will be thankful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #4 from Gašper Ažman ---
John McFarlane noted that pre-initializing coverage datastructures with the
results of the constexpr-evaluated traces would also be a possible direction.
It does mean the linker needs to then correctly merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
Gašper Ažman changed:
What|Removed |Added
CC||gasper.azman at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
--- Comment #2 from Gašper Ažman ---
Some more color from twitter, courtesy of @matthewecross:
Interestingly both "return S::f();" and "auto s = S(); return s.f();" both
pass. It's only when you create a temporary instance of S in the return
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #30 from Gašper Ažman ---
I don't really understand what you meant by "they have corresponding object
parameters" - you mean that the object parameters are equal in both constraint
and type? "Corresponding" to my recollection is only
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gasper.azman at gmail dot com
Target Milestone: ---
Repro on GCC 13.3 and 14: https://godbolt.org/z/EdfGEfGcr
code:
```
#include
#include
class
19 matches
Mail list logo
