• Move semantics with literals

    From boltar@3:633/10 to All on Tue Apr 14 14:57:14 2026
    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile
    being a reference to a literal but it does. So I'm just wondering why on
    earth and when would you ever do the above? Is there some wierd use case?


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jonathan Lamothe@3:633/10 to All on Tue Apr 14 11:01:22 2026
    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile being a reference to a literal but it does. So I'm just wondering why on earth and when would you ever do the above? Is there some wierd use case?

    The only use case I can see is tricky interview questions. ;)

    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From wij@3:633/10 to All on Tue Apr 14 23:04:15 2026
    On Tue, 2026-04-14 at 11:01 -0400, Jonathan Lamothe wrote:
    boltar@caprica.universe˙writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    ˙˙˙˙˙˙˙ return a * 2;
    }


    :
    ˙˙˙˙˙˙˙ int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compi
    le
    being a reference to a literal but it does. So I'm just wondering why o
    n
    earth and when would you ever do the above? Is there some wierd use cas
    e?

    The only use case I can see is tricky interview questions.˙ ;)

    It C++'s fault.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jonathan Lamothe@3:633/10 to All on Tue Apr 14 11:10:31 2026
    Jonathan Lamothe <jonathan@jlamothe.net> writes:

    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile
    being a reference to a literal but it does. So I'm just wondering why on
    earth and when would you ever do the above? Is there some wierd use case?

    The only use case I can see is tricky interview questions. ;)

    More seriously though, I'm not sure off-hand, but this feels like a case
    of undefined behaviour. At any rate, it's terrible for the clarity of
    the code, which I try to prioritize.

    I hate it when job interview questions don't actually reflect the kind
    of work you'll be expected to do. Though, if this *is* the
    expectation... bullet dodged, I guess?

    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Tue Apr 14 15:10:40 2026
    On Tue, 14 Apr 2026 11:01:22 -0400
    Jonathan Lamothe <jonathan@jlamothe.net> gabbled:
    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile
    being a reference to a literal but it does. So I'm just wondering why on
    earth and when would you ever do the above? Is there some wierd use case?

    The only use case I can see is tricky interview questions. ;)

    Unfortunately it was that kind of interview where they tried to catch you
    out rather than testing your code writing and debugging abilities. Luckily I wasn't fooled by the other questions though it does make me wonder if I'd want to work in a place that has this kind of moronic interview process.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Tue Apr 14 17:14:04 2026
    Am 14.04.2026 um 16:57 schrieb boltar@caprica.universe:

    Where the question was "what would happen". I assumed it wouldn't compile being a reference to a literal but it does. So I'm just wondering why on earth and when would you ever do the above? ...
    It's there just for completeness.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jonathan Lamothe@3:633/10 to All on Tue Apr 14 11:15:42 2026
    boltar@caprica.universe writes:

    <snip> Luckily I
    wasn't fooled by the other questions though it does make me wonder if I'd want
    to work in a place that has this kind of moronic interview process.

    ?

    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Tue Apr 14 15:23:14 2026
    On Tue, 14 Apr 2026 17:14:04 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 14.04.2026 um 16:57 schrieb boltar@caprica.universe:

    Where the question was "what would happen". I assumed it wouldn't compile
    being a reference to a literal but it does. So I'm just wondering why on
    earth and when would you ever do the above? ...
    It's there just for completeness.

    But what kind of completeness? You can't "move" or nullify a literal, its in the read-only text area of the program so whats the point? Surely it should
    be a compile time error or at least a warning?


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Tue Apr 14 17:26:56 2026
    On 14/04/2026 17:10, Jonathan Lamothe wrote:
    Jonathan Lamothe <jonathan@jlamothe.net> writes:

    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile >>> being a reference to a literal but it does. So I'm just wondering why on >>> earth and when would you ever do the above? Is there some wierd use case? >>
    The only use case I can see is tricky interview questions. ;)

    More seriously though, I'm not sure off-hand, but this feels like a case
    of undefined behaviour. At any rate, it's terrible for the clarity of
    the code, which I try to prioritize.


    As far as I understand it, it is fully defined behaviour. The value 123
    is a temporary, and exists until the expression containing it is fully evaluated. (If I am wrong here, hopefully someone will correct me!)

    rvalue references are not much use for simple types like "int". They
    become useful with bigger types. But it would be very strange for the standards to say you could /only/ use them for big types.

    I hate it when job interview questions don't actually reflect the kind
    of work you'll be expected to do. Though, if this *is* the
    expectation... bullet dodged, I guess?




    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Tue Apr 14 18:23:34 2026
    Am 14.04.2026 um 17:23 schrieb boltar@caprica.universe:

    But what kind of completeness? You can't "move" or nullify a literal,
    its in the read-only text area of the program so whats the point? Surely
    it should be a compile time error or at least a warning?

    You can even move() classes that are not moveable, i.e. you will get
    a fallback to copying. The same applies to r-value references to ints.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Tue Apr 14 18:25:09 2026
    Am 14.04.2026 um 17:10 schrieb Jonathan Lamothe:

    More seriously though, I'm not sure off-hand, but this feels like a case
    of undefined behaviour. At any rate, it's terrible for the clarity of
    the code, which I try to prioritize.

    That's not UB. The code falls back to copying, just like with a class
    whose objects aren't move()-able.

    I hate it when job interview questions don't actually reflect the kind
    of work you'll be expected to do. Though, if this *is* the
    expectation... bullet dodged, I guess?

    This isn't an interview question because it's not practical.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jonathan Lamothe@3:633/10 to All on Tue Apr 14 13:02:29 2026
    Bonita Montero <Bonita.Montero@gmail.com> writes:

    I hate it when job interview questions don't actually reflect the kind
    of work you'll be expected to do. Though, if this *is* the
    expectation... bullet dodged, I guess?

    This isn't an interview question because it's not practical.

    I get that. I just don't see a justifiable reason for why it *is* an
    interview question... unless you're building a compiler.

    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Scott Lurndal@3:633/10 to All on Tue Apr 14 17:17:17 2026
    boltar@caprica.universe writes:
    On Tue, 14 Apr 2026 11:01:22 -0400
    Jonathan Lamothe <jonathan@jlamothe.net> gabbled:
    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile >>> being a reference to a literal but it does. So I'm just wondering why on >>> earth and when would you ever do the above? Is there some wierd use case? >>
    The only use case I can see is tricky interview questions. ;)

    Unfortunately it was that kind of interview where they tried to catch you
    out rather than testing your code writing and debugging abilities. Luckily I >wasn't fooled by the other questions though it does make me wonder if I'd want
    to work in a place that has this kind of moronic interview process.


    I dunno, perhaps they're doing it intentionally to weed out
    candidates that did not object to the the silly test?

    I had a science teacher in the 7th grade who once gave a test. The
    first paragraph advised the students to read the entire test before
    starting. It was a several page test and the final point on the last
    page was a note saying that you didn't have to actually do the test.

    For those who didn't read it first, and there were many, they wasted
    a great deal of time by not following the instructions. It was very instructional.

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jonathan Lamothe@3:633/10 to All on Tue Apr 14 13:36:51 2026
    scott@slp53.sl.home (Scott Lurndal) writes:

    boltar@caprica.universe writes:
    On Tue, 14 Apr 2026 11:01:22 -0400
    Jonathan Lamothe <jonathan@jlamothe.net> gabbled:
    boltar@caprica.universe writes:

    To my chagrin I got caught out by this trick question in an interview: >>>>
    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile >>>> being a reference to a literal but it does. So I'm just wondering why on >>>> earth and when would you ever do the above? Is there some wierd use case? >>>
    The only use case I can see is tricky interview questions. ;)

    Unfortunately it was that kind of interview where they tried to catch you >>out rather than testing your code writing and debugging abilities. Luckily I >>wasn't fooled by the other questions though it does make me wonder if I'd want
    to work in a place that has this kind of moronic interview process.


    I dunno, perhaps they're doing it intentionally to weed out
    candidates that did not object to the the silly test?

    <snip>

    That's one of the few reasons I would accept as valid. I have my doubts however as to whether this is what they ware actually doing. In my
    experience, most employers don't like it when their employees push back
    on nonsense.

    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Wed Apr 15 08:18:37 2026
    On Tue, 14 Apr 2026 18:25:09 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 14.04.2026 um 17:10 schrieb Jonathan Lamothe:

    More seriously though, I'm not sure off-hand, but this feels like a case
    of undefined behaviour. At any rate, it's terrible for the clarity of
    the code, which I try to prioritize.

    That's not UB. The code falls back to copying, just like with a class
    whose objects aren't move()-able.

    It begs the question that if move (&&) is permitted why does it error with a standard reference (&)?

    I hate it when job interview questions don't actually reflect the kind
    of work you'll be expected to do. Though, if this *is* the
    expectation... bullet dodged, I guess?

    This isn't an interview question because it's not practical.

    Unfortunately here in the UK these sorts of moronic trick questions are
    all too common.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Wed Apr 15 08:21:36 2026
    On Tue, 14 Apr 2026 13:36:51 -0400
    Jonathan Lamothe <jonathan@jlamothe.net> gabbled:
    scott@slp53.sl.home (Scott Lurndal) writes:
    I dunno, perhaps they're doing it intentionally to weed out
    candidates that did not object to the the silly test?

    <snip>

    That's one of the few reasons I would accept as valid. I have my doubts >however as to whether this is what they ware actually doing. In my >experience, most employers don't like it when their employees push back
    on nonsense.

    I think its safe to say that if an interview candidate called the test
    stupid in from of the interviewer then I doubt they'd be called back for
    a 2nd interview.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Paavo Helde@3:633/10 to All on Wed Apr 15 12:50:09 2026
    On 4/15/2026 11:18 AM, boltar@caprica.universe wrote:
    On Tue, 14 Apr 2026 18:25:09 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 14.04.2026 um 17:10 schrieb Jonathan Lamothe:

    More seriously though, I'm not sure off-hand, but this feels like a case >>> of undefined behaviour.˙ At any rate, it's terrible for the clarity of
    the code, which I try to prioritize.

    That's not UB. The code falls back to copying, just like with a class
    whose objects aren't move()-able.

    It begs the question that if move (&&) is permitted why does it error
    with a
    standard reference (&)?

    It errors with non-const reference (&) because inside the function it is
    not known if the reference points to a temporary or not, and this may
    lead to subtle bugs.

    It works with const reference (&) because then it is not really
    important if the thing is a temporary or not.

    It works with rvalue reference (&&) because then it is known for sure
    the thing is a temporary.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Wed Apr 15 14:24:23 2026
    Am 15.04.2026 um 10:18 schrieb boltar@caprica.universe:

    It begs the question that if move (&&) is permitted why does it error
    with a standard reference (&)?

    Because references on temporaries don't make sense.



    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Wed Apr 15 15:07:46 2026
    On Wed, 15 Apr 2026 14:24:23 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 15.04.2026 um 10:18 schrieb boltar@caprica.universe:

    It begs the question that if move (&&) is permitted why does it error
    with a standard reference (&)?

    Because references on temporaries don't make sense.


    Neither does doing a move operation on a integer literal but here we are.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Wed Apr 15 17:49:15 2026
    Am 15.04.2026 um 17:07 schrieb boltar@caprica.universe:

    On Wed, 15 Apr 2026 14:24:23 +0200

    Bonita Montero <Bonita.Montero@gmail.com> gabbled:

    Am 15.04.2026 um 10:18 schrieb boltar@caprica.universe:

    It begs the question that if move (&&) is permitted why does it error
    with a standard reference (&)?

    Because references on temporaries don't make sense.

    Neither does doing a move operation on a integer literal but here we are.

    It doesn't hurt and it isn't more confusing than applying move() to any
    other copy-only type.

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Wed Apr 15 17:51:57 2026
    Am 15.04.2026 um 17:07 schrieb boltar@caprica.universe:

    Neither does doing a move operation on a integer literal but here we are.

    If you want to know everything about move semantics try that:

    https://leanpub.com/cppmove

    262 pages about such a simple feature ...; C++ is crazy.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Wed Apr 15 23:08:28 2026
    On 4/15/2026 5:24 AM, Bonita Montero wrote:
    Am 15.04.2026 um 10:18 schrieb boltar@caprica.universe:

    It begs the question that if move (&&) is permitted why does it error
    with a standard reference (&)?

    Because references on temporaries don't make sense.



    Tell that to some DirectX examples? ;^)

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Bonita Montero@3:633/10 to All on Thu Apr 16 09:02:13 2026
    Am 16.04.2026 um 08:08 schrieb Chris M. Thomasson:

    On 4/15/2026 5:24 AM, Bonita Montero wrote:

    Because references on temporaries don't make sense.

    Tell that to some DirectX examples? ;^)

    It's simply not possible:

    int main()
    {
    []( int &i )
    {
    return i + 1;
    }( 456 );
    }

    Gives a compile-time error.

    This works:

    int main()
    {
    []( const int &i ) -> int
    {
    return i + 1;
    }( 456 );
    []( int &&i ) -> int
    {
    return i + 1;
    }( 456 );
    }


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Thu Apr 16 08:29:54 2026
    On Wed, 15 Apr 2026 17:51:57 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 15.04.2026 um 17:07 schrieb boltar@caprica.universe:

    Neither does doing a move operation on a integer literal but here we are.

    If you want to know everything about move semantics try that:

    https://leanpub.com/cppmove

    262 pages about such a simple feature ...; C++ is crazy.

    Yes, the language is ridiculously overspecced now. I think I've said on this group before that if I was starting out in dev I'd take one look at C++ and flee to Python. Back when I learnt it in the early 2000s a person could
    learn pretty much the entire language including the STL. There's zero chance anyone could now.


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Thu Apr 16 04:39:40 2026
    On 4/16/2026 12:02 AM, Bonita Montero wrote:
    Am 16.04.2026 um 08:08 schrieb Chris M. Thomasson:

    On 4/15/2026 5:24 AM, Bonita Montero wrote:

    Because references on temporaries don't make sense.

    Tell that to some DirectX examples? ;^)

    It's simply not possible:

    ˙˙˙˙int main()
    ˙˙˙˙{
    ˙˙˙˙˙˙˙ []( int &i )
    ˙˙˙˙˙˙˙ {
    ˙˙˙˙˙˙˙˙˙˙˙ return i + 1;
    ˙˙˙˙˙˙˙ }( 456 );
    ˙˙˙˙}

    Gives a compile-time error.

    This works:

    ˙˙˙˙int main()
    ˙˙˙˙{
    ˙˙˙˙˙˙˙ []( const int &i ) -> int
    ˙˙˙˙˙˙˙ {
    ˙˙˙˙˙˙˙˙˙˙˙ return i + 1;
    ˙˙˙˙˙˙˙ }( 456 );
    ˙˙˙˙˙˙˙ []( int &&i ) -> int
    ˙˙˙˙˙˙˙ {
    ˙˙˙˙˙˙˙˙˙˙˙ return i + 1;
    ˙˙˙˙˙˙˙ }( 456 );
    ˙˙˙˙}


    Yeah, some of their examples have compile time errors as well.

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Scott Lurndal@3:633/10 to All on Thu Apr 16 14:41:20 2026
    boltar@caprica.universe writes:
    On Wed, 15 Apr 2026 17:51:57 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 15.04.2026 um 17:07 schrieb boltar@caprica.universe:

    Neither does doing a move operation on a integer literal but here we are. >>
    If you want to know everything about move semantics try that:

    https://leanpub.com/cppmove

    262 pages about such a simple feature ...; C++ is crazy.

    Yes, the language is ridiculously overspecced now. I think I've said on this >group before that if I was starting out in dev I'd take one look at C++ and >flee to Python. Back when I learnt it in the early 2000s a person could
    learn pretty much the entire language including the STL. There's zero chance >anyone could now.

    When I learned C++ in 1989, STL didn't exist and the C++ syntax was
    translated to C (cfront).

    That was the true "C with classes".

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris Ahlstrom@3:633/10 to All on Sat Apr 18 06:41:12 2026
    Scott Lurndal wrote this screed in ALL-CAPS:

    boltar@caprica.universe writes:
    On Wed, 15 Apr 2026 17:51:57 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 15.04.2026 um 17:07 schrieb boltar@caprica.universe:

    Neither does doing a move operation on a integer literal but here we are. >>>
    If you want to know everything about move semantics try that:

    https://leanpub.com/cppmove

    262 pages about such a simple feature ...; C++ is crazy.

    Yes, the language is ridiculously overspecced now. I think I've said on this >>group before that if I was starting out in dev I'd take one look at C++ and >>flee to Python. Back when I learnt it in the early 2000s a person could >>learn pretty much the entire language including the STL. There's zero chance >>anyone could now.

    When I learned C++ in 1989, STL didn't exist and the C++ syntax was translated to C (cfront).

    That was the true "C with classes".

    I think C++ is way cooler than Python, especially these days.

    --
    QWERT (kwirt) n. [MW < OW qwertyuiop, a thirteenth] 1. a unit of weight
    equal to 13 poiuyt avoirdupois (or 1.69 kiloliks), commonly used in structural engineering 2. [Colloq.] one thirteenth the load that a fully
    grown sligo can carry. 3. [Anat.] a painful irritation of the dermis
    in the region of the anus 4. [Slang] person who excites in others the
    symptoms of a qwert.
    -- Webster's Middle World Dictionary, 4th ed.

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Andrey Tarasevich@3:633/10 to All on Sat Apr 18 09:27:16 2026
    On Tue 4/14/2026 7:57 AM, boltar@caprica.universe wrote:
    To my chagrin I got caught out by this trick question in an interview:

    int func(int &&a)
    {
    return a * 2;
    }


    :
    int b = func(123);
    :

    Where the question was "what would happen". I assumed it wouldn't compile being a reference to a literal but it does. So I'm just wondering why on earth and when would you ever do the above? Is there some wierd use case?


    Um... It is not clear what even triggered your question.

    Firstly, there's no "move semantics" in your code. Moreover, there's no
    "move semantics" in C++ language. "Move semantics" is a user-level
    concept - something you implement yourself in your user-level code. The
    only thing C++ the language does is provide some low-level primitives to
    help you do that (e.g. rvalue references). But the above example has no
    "move semantics".

    Secondly, what C++ language offers you is various types and their
    semantics. In particular: their initialization rules and their overload resolution rules. That applies to rvalue references the same way it
    applies to any other type. The rules of the language state that it is
    legal to initialize `int &&` reference with `123`. So, your code is
    perfectly legal. End of story.

    I mean, why is it even a surprise to you? Since the beginning of times
    it's been legal to initialize `const int &` reference with `123`. A non-modifiable temporary was created as a target for such lvalue
    reference. The only difference rvalue references bring is that for them
    a _modifiable_ temporary is created.

    That's all there is to it.

    --
    Best regards,
    Andrey



    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Andrey Tarasevich@3:633/10 to All on Sat Apr 18 09:46:34 2026
    On Sat 4/18/2026 9:27 AM, Andrey Tarasevich wrote:
    Moreover, there's no
    "move semantics" in C++ language. "Move semantics" is a user-level
    concept - something you implement yourself in your user-level code. The
    only thing C++ the language does is provide some low-level primitives to help you do that (e.g. rvalue references). But the above example has no "move semantics".


    Of course, the above might be see as a bit self-contradictory. Since I
    myself stated that "move semantics" is a user-level concept, you can
    always claim that your original example is actually "move semantics",
    i.e. it is your user-level vision of it.

    After all, for flat types (like `int`) there's not much point in
    implementing any kind of move semantics different from their usual copy semantics. And that's what the original version of your function does.

    One can also modify it as follows

    int func(int &&a)
    {
    int result = a * 2;
    a = 0;
    return result;
    }

    and then document the behavior, stating that the version of move
    semantics implemented by this function zeroes out the original argument
    (or modifies it in some unspecified way). For some reason. That is also perfectly fine.

    However, keep in mind that this will not even attempt to modify the
    original literal `123`. As I stated in my previous post, a modifiable temporary of type `int` will be created as an argument for the call. It
    is that temporary that will get modified. The literal will remain untouched.

    --
    Best regards,
    Andrey

    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Richard Damon@3:633/10 to All on Sat Apr 18 12:46:58 2026
    On 4/15/26 11:07 AM, boltar@caprica.universe wrote:
    On Wed, 15 Apr 2026 14:24:23 +0200
    Bonita Montero <Bonita.Montero@gmail.com> gabbled:
    Am 15.04.2026 um 10:18 schrieb boltar@caprica.universe:

    It begs the question that if move (&&) is permitted why does it error
    with a standard reference (&)?

    Because references on temporaries don't make sense.


    Neither does doing a move operation on a integer literal but here we are.


    But it does.

    References (non-const) are assumed to be used to modify the state of an object, and their is a high likelyhood that this won't do what was
    intended for a temporary.

    (very old versions of the langauge allowed it, and it was found to be a
    common error)

    The "move" semantics evolved out of a common pattern where a piece of
    code wanted to make a copy of an object to do something with, and it was noticed that it wasn't "uncommon" for the source of the object to not
    need the object after that, and the making of a copy could be made a lot simpler/quicker, if it could "steal" some of the data (as in an object
    it references) rather than making a copy of it when the origianal wasn't needed any more.

    The desire to improve efficiency lead to the creation of the concept of "moving" and object, where the source remaind "a valid object" so normal cleanup could occur, but the process could be optimized based on it no
    longer needing to keep its information.

    This leaves the old "copy" as a valid method of doing a "move", so code
    that didn't need to be modified to work with things that wanted the improvement, it just didn't provide the possible speed up.

    Since a temporary is going to go away at the end of an expression, there
    is no reason to prohibit sending one to a function. This exactly meets
    the case that move semantics were created for.

    And, while you are unlikely to explictly write int&& x, as it is likely
    more efficient to just pass a copy, it effectively does come up with templates, so blocking it doesn't make sense.



    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Andrey Tarasevich@3:633/10 to All on Sat Apr 18 10:16:21 2026
    On Tue 4/14/2026 8:10 AM, boltar@caprica.universe wrote:
    Luckily I
    wasn't fooled by the other questions though it does make me wonder if I'd want
    to work in a place that has this kind of moronic interview process.

    Your repetitive insistence in this being "moronic" and that bizarre (and
    also repetitive) idea that this code is trying "to move a literal" makes
    me suspect that you are simply trying to engage in some primitive trolling.

    However, I'll give it another chance.

    The semantics you were presented with will invariably arise in numerous generic contexts, as a specific specialization of template code. This is exactly what will happen in the following sample

    #include <utility>

    template <typename T> T foo(T &&a)
    {
    return std::move(a) * 2;
    }

    int main()
    {
    return foo(123);
    }

    The generic function is written to take advantage of potential move
    semantics provided by type `T` and its multiplication operator. But if
    type `T` supplies no dedicated move semantics for this context, it will naturally fall back to regular copy semantics. That's basically the
    logic behind the rvalue-reference spec, and how it helps to nicely fit
    the move semantics into the legacy structure of the language.

    Note that for `123` argument the template parameter will be deduced as
    `int` and the template will be specialized as `int foo(int &&)` -
    precisely as in your original example.

    The interviewers simply did not want to overload the question with template-related chaff. They just intended to check whether you are at
    home with the very basics, e.g. whether you understand that

    int &&r = 123;

    is already perfectly valid. But your concerns about "moving a literal"
    (?!) already indicate that such basics are still well outside your reach.

    --
    Best regards,
    Andrey


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Sun Apr 19 08:59:04 2026
    On Sat, 18 Apr 2026 10:16:21 -0700
    Andrey Tarasevich <noone@noone.net> gabbled:
    template-related chaff. They just intended to check whether you are at
    home with the very basics, e.g. whether you understand that

    int &&r = 123;

    is already perfectly valid. But your concerns about "moving a literal"

    Yes , a literal, a value stored in the *read-only* program text area:

    int main()
    {
    int &&i = 123;
    }

    gives

    movl $123, -12(%rbp)

    See that $5? Its hard coded.

    (?!) already indicate that such basics are still well outside your reach.

    Oh do fuck off you patronising prick. Why do people like you even post, just
    to make yourself feel superior?


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From boltar@3:633/10 to All on Sun Apr 19 09:09:44 2026
    On Sun, 19 Apr 2026 08:59:04 -0000 (UTC)
    boltar@caprica.universe gabbled:
    On Sat, 18 Apr 2026 10:16:21 -0700
    Andrey Tarasevich <noone@noone.net> gabbled:
    template-related chaff. They just intended to check whether you are at >>home with the very basics, e.g. whether you understand that

    int &&r = 123;

    is already perfectly valid. But your concerns about "moving a literal"

    Yes , a literal, a value stored in the *read-only* program text area:

    int main()
    {
    int &&i = 123;
    }

    gives

    movl $123, -12(%rbp)

    See that $5? Its hard coded.

    Yes, I meant $123 before nit pickers jump in.



    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Andrey Tarasevich@3:633/10 to All on Sun Apr 19 12:01:10 2026
    On Sun 4/19/2026 1:59 AM, boltar@caprica.universe wrote:
    On Sat, 18 Apr 2026 10:16:21 -0700
    Andrey Tarasevich <noone@noone.net> gabbled:
    template-related chaff. They just intended to check whether you are at
    home with the very basics, e.g. whether you understand that

    ˙ int &&r = 123;

    is already perfectly valid. But your concerns about "moving a literal"

    Yes , a literal, a value stored in the *read-only* program text area:

    int main()
    {
    ˙˙˙˙int &&i = 123;
    }

    gives

    ˙˙˙˙˙˙ movl˙˙˙ $123, -12(%rbp)


    The only kind of [built-in] literal in C++ that can serve as an lvalue
    (i.e. a target for a pointer or a reference) is _string_ literal. All
    other kinds of literals are _not_ lvalues. You cannot "reference" them regardless of what you try. So, the "read-onlyness" and "text-areaness"
    of your `123` should not have been a concern for you from the very
    beginning. Nobody's trying to grab anything from there.

    If the code compiles (and it does), it should have been clear to anyone
    (if only by pure deduction) that the reference will refer to _something_ _else_, not to that "read-only text area".

    And the answer to that have been in the language since the beginning of
    times. And have already mentioned it above. Since the beginning of times
    you could do this in C++

    const int &r = 123;

    and for all means and purposes it was equivalent to

    const int __unnamed_const_int_123 = 123, &r = __unnamed_const_int_123;

    An unnamed temporary object of type `int` was quietly created in storage
    and the reference was bound to it. So, that `123` referenced by the
    reference ends up in "regular" storage, not in your "read-only text area".

    With the introduction of rvalue references in C++11 the above behavior
    was naturally extended to cover

    int &&rr = 123;

    This is expectedly equivalent to

    int __unnamed_int_123 = 123, &&rr = (int &&) __unnamed_int_123;

    Again, in this case an unnamed _modifiable_ temporary object of type
    `int` is created in modifiable storage and the reference is bound to it.

    So, nothing magical happens. Nobody's trying to modify the unmodifiable
    here. Nobody's trying to move anything from your sacred "read-only text
    area". Moreover, there's nothing fundamentally new involved here
    associated with these newfangled `&&` references. It has all been in the languages since dinos roamed the Earth.

    --
    Best regards,
    Andrey


    --- PyGate Linux v1.5.14
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)