Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123717 > unrolled thread

Move semantics with literals

Back to article view | Back to comp.lang.c++

Contents

  Move semantics with literals boltar@caprica.universe - 2026-04-14 14:57 +0000
    Re: Move semantics with literals Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 11:01 -0400
      Re: Move semantics with literals wij <wyniijj5@gmail.com> - 2026-04-14 23:04 +0800
      Re: Move semantics with literals Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 11:10 -0400
        Re: Move semantics with literals David Brown <david.brown@hesbynett.no> - 2026-04-14 17:26 +0200
        Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-14 18:25 +0200
          Re: Move semantics with literals Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 13:02 -0400
          Re: Move semantics with literals boltar@caprica.universe - 2026-04-15 08:18 +0000
            Re: Move semantics with literals Paavo Helde <eesnimi@osa.pri.ee> - 2026-04-15 12:50 +0300
            Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-15 14:24 +0200
              Re: Move semantics with literals boltar@caprica.universe - 2026-04-15 15:07 +0000
                Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-15 17:49 +0200
                Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-15 17:51 +0200
                  Re: Move semantics with literals boltar@caprica.universe - 2026-04-16 08:29 +0000
                    Re: Move semantics with literals scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 14:41 +0000
                      Re: Move semantics with literals Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-04-18 06:41 -0400
                Re: Move semantics with literals Richard Damon <Richard@Damon-Family.org> - 2026-04-18 12:46 -0400
              Re: Move semantics with literals "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:08 -0700
                Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-16 09:02 +0200
                  Re: Move semantics with literals "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-16 04:39 -0700
      Re: Move semantics with literals boltar@caprica.universe - 2026-04-14 15:10 +0000
        Re: Move semantics with literals Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 11:15 -0400
        Re: Move semantics with literals scott@slp53.sl.home (Scott Lurndal) - 2026-04-14 17:17 +0000
          Re: Move semantics with literals Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 13:36 -0400
            Re: Move semantics with literals boltar@caprica.universe - 2026-04-15 08:21 +0000
        Re: Move semantics with literals Andrey Tarasevich <noone@noone.net> - 2026-04-18 10:16 -0700
          Re: Move semantics with literals boltar@caprica.universe - 2026-04-19 08:59 +0000
            Re: Move semantics with literals boltar@caprica.universe - 2026-04-19 09:09 +0000
            Re: Move semantics with literals Andrey Tarasevich <noone@noone.net> - 2026-04-19 12:01 -0700
    Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-14 17:14 +0200
      Re: Move semantics with literals boltar@caprica.universe - 2026-04-14 15:23 +0000
        Re: Move semantics with literals Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-14 18:23 +0200
    Re: Move semantics with literals Andrey Tarasevich <noone@noone.net> - 2026-04-18 09:27 -0700
      Re: Move semantics with literals Andrey Tarasevich <noone@noone.net> - 2026-04-18 09:46 -0700

Page 1 of 2  [1] 2  Next page →

#123717 — Move semantics with literals

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?

[toc] | [next] | [standalone]

#123718

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

[toc] | [prev] | [next] | [standalone]

#123719

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 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.  ;)

It C++'s fault.

[toc] | [prev] | [next] | [standalone]

#123720

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

[toc] | [prev] | [next] | [standalone]

#123725

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?
> 

[toc] | [prev] | [next] | [standalone]

#123727

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.

[toc] | [prev] | [next] | [standalone]

#123728

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

[toc] | [prev] | [next] | [standalone]

#123732

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.

[toc] | [prev] | [next] | [standalone]

#123737

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.

[toc] | [prev] | [next] | [standalone]

#123738

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.

[toc] | [prev] | [next] | [standalone]

#123739

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.

[toc] | [prev] | [next] | [standalone]

#123740

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.

[toc] | [prev] | [next] | [standalone]

#123741

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.

[toc] | [prev] | [next] | [standalone]

#123744

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.

[toc] | [prev] | [next] | [standalone]

#123746

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".

[toc] | [prev] | [next] | [standalone]

#123748

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.

[toc] | [prev] | [next] | [standalone]

#123751

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.

[toc] | [prev] | [next] | [standalone]

#123742

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? ;^)

[toc] | [prev] | [next] | [standalone]

#123743

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 );
	}

[toc] | [prev] | [next] | [standalone]

#123745

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web