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 2 of 2 — ← Prev page 1 [2]

#123721

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.

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

#123723

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

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

#123729

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.

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

#123730

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

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

#123733

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.

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

#123752

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

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

#123754

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?

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

#123755

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.

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

#123756

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

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

#123722

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.

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

#123724

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?

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

#123726

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.

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

#123749

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

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

#123750

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web