Date: Thu, 23 May 2024 09:49:11 +0100
On Thu, May 23, 2024 at 12:57 AM Thiago Macieira wrote:
>
> They why are you insisting on it, despite being asked multiple times to find
> other uses?
I'm not insisting on it. It's an example. Sort of like how last year I
demonstrated a strange physical exercise to my shoulder surgeon to
show him the range of motion I had after my surgery -- he could have
barked back at me that nobody would ever deliberately move their
shoulder that way, and he would have been right (it was certainly a
peculiar motion), but he had gumption to know that I was merely using
the movement as a demonstration, as an example of what my shoulder can
do.
> Tiago's argument was that the reasons why you don't want to do that for
> std::mutex may apply to for any other class type, so he's asking you to give a
> couple of real examples where the feature would be useful and what
> alternatives exist.
Look I realise that there's more than one personality on this mailing
list, and I accept that two rational and intelligent people can form
very different opinions about a topic given the same evidence and
observations, so I don't claim to have a monopoly on the truth there.
I had perceived that Tiago was focusing specifically on the
'std::mutex' class, whereas you appear to have perceived Tiago to have
been making a more generic point along the lines of "It's pointless
for mutexes and it's pointless for every other class too". If we were
to agree that it's the latter rather than the former, then that's a
very different discussion. That other discussion would be about
whether NRVO ever makes sense at all for any type in any scenario.
> > No matter how many times it's re-iterated on this mailing list that
> > the whole locked mutex thing is just a quick-and-easy example, more
>
> And that's the issue. Stop giving quick-and-dirty examples because they lead
> people to the wrong path. Give a *proper* example.
A handful of extremely skilled programmers on this mailing list
latched onto my mutex example because it's simple and shows the
principle. And while I'm not a mind reader and haven't conducted a
survey, I estimate that 9 out of 10 people here knew that std::mutex
was being used for only one reason: It's unmovable and uncopyable. No
other reason.
> Not a gimmick class either. A real one. Preferably, three different ones, so we
> know this is a real problem, not just an accident of bad API design somewhere.
So I think you want to change the discussion from:
"Reasons why you'd never want to return a locked mutex by value
from a function"
to:
"Reasons why you'd never want to return a
post-constructionally-modified class type by value from a function"
And that might actually be a very interesting discussion. My main
argument in favour of having NRVO is just simple a visceral feeling
that "This is something that we should have in our toolbox", as I want
C++ to be versatile and have all sort of features that can be used in
all sorts of ways. But when it comes down to it, if I think back on
the C++ programs I've been writing since 2002, I actually have never
needed NRVO. Even today, 22 years later and being gainfully employed
to program microscopes and their supporting desktop PC software, I
haven't ever come across a scenario where I need NRVO. The only
scenarios that even came close to needing NRVO, I probably just used
an std::optional.
So maybe NRVO actually is pointless and not worth writing into the
Standard, so maybe we should all just use std::optional (in
combination with std::elide -- see paper P3288). With that said
though, I never needed RVO either but that made it in C++17.
>
> They why are you insisting on it, despite being asked multiple times to find
> other uses?
I'm not insisting on it. It's an example. Sort of like how last year I
demonstrated a strange physical exercise to my shoulder surgeon to
show him the range of motion I had after my surgery -- he could have
barked back at me that nobody would ever deliberately move their
shoulder that way, and he would have been right (it was certainly a
peculiar motion), but he had gumption to know that I was merely using
the movement as a demonstration, as an example of what my shoulder can
do.
> Tiago's argument was that the reasons why you don't want to do that for
> std::mutex may apply to for any other class type, so he's asking you to give a
> couple of real examples where the feature would be useful and what
> alternatives exist.
Look I realise that there's more than one personality on this mailing
list, and I accept that two rational and intelligent people can form
very different opinions about a topic given the same evidence and
observations, so I don't claim to have a monopoly on the truth there.
I had perceived that Tiago was focusing specifically on the
'std::mutex' class, whereas you appear to have perceived Tiago to have
been making a more generic point along the lines of "It's pointless
for mutexes and it's pointless for every other class too". If we were
to agree that it's the latter rather than the former, then that's a
very different discussion. That other discussion would be about
whether NRVO ever makes sense at all for any type in any scenario.
> > No matter how many times it's re-iterated on this mailing list that
> > the whole locked mutex thing is just a quick-and-easy example, more
>
> And that's the issue. Stop giving quick-and-dirty examples because they lead
> people to the wrong path. Give a *proper* example.
A handful of extremely skilled programmers on this mailing list
latched onto my mutex example because it's simple and shows the
principle. And while I'm not a mind reader and haven't conducted a
survey, I estimate that 9 out of 10 people here knew that std::mutex
was being used for only one reason: It's unmovable and uncopyable. No
other reason.
> Not a gimmick class either. A real one. Preferably, three different ones, so we
> know this is a real problem, not just an accident of bad API design somewhere.
So I think you want to change the discussion from:
"Reasons why you'd never want to return a locked mutex by value
from a function"
to:
"Reasons why you'd never want to return a
post-constructionally-modified class type by value from a function"
And that might actually be a very interesting discussion. My main
argument in favour of having NRVO is just simple a visceral feeling
that "This is something that we should have in our toolbox", as I want
C++ to be versatile and have all sort of features that can be used in
all sorts of ways. But when it comes down to it, if I think back on
the C++ programs I've been writing since 2002, I actually have never
needed NRVO. Even today, 22 years later and being gainfully employed
to program microscopes and their supporting desktop PC software, I
haven't ever come across a scenario where I need NRVO. The only
scenarios that even came close to needing NRVO, I probably just used
an std::optional.
So maybe NRVO actually is pointless and not worth writing into the
Standard, so maybe we should all just use std::optional (in
combination with std::elide -- see paper P3288). With that said
though, I never needed RVO either but that made it in C++17.
Received on 2024-05-23 08:49:25