Use of rvalue reference in the given scenario

[Andre Zunino]

Hello.

Given

class Sprite { /*...*/ };

class Toon : public Sprite { /*...*/ };

, then doing the following

Sprite& s1 = Toon {};

is invalid since the result of the right-hand side expression is an
rvalue, which can't be bound to a non-const reference.

Sure enough, making it const like

const Sprite& s1 = Toon {};

takes care of the problem.

Now, suppose you actually want to keep the reference as non-const, in
order to be able to invoke non-const members, would it be OK to use an
rvalue reference?

Sprite&& s1 = Toon {};

I've been using it like that and have not run into any problems, but I'd
like to know where I'm stepping.

Thank you for your comments.

--
Andre Zunino

[Öö Tiib]

On Sunday, 19 July 2015 04:48:11 UTC+3, Andre Zunino wrote:
> Hello.
>
> Given
>
> class Sprite { /*...*/ };
>
> class Toon : public Sprite { /*...*/ };
>
> , then doing the following
>
> Sprite& s1 = Toon {};
>
> is invalid since the result of the right-hand side expression is an
> rvalue, which can't be bound to a non-const reference.
>
> Sure enough, making it const like
>
> const Sprite& s1 = Toon {};
>
> takes care of the problem.
>
> Now, suppose you actually want to keep the reference as non-const, in
> order to be able to invoke non-const members, would it be OK to use an
> rvalue reference?
>
> Sprite&& s1 = Toon {};

Yes. However where you need that? In most circumstances
that works lot better:

Toon s1{};

> I've been using it like that and have not run into any problems, but I'd
> like to know where I'm stepping.

Yes, tell us why you use it?

[Andre Zunino]

On 07/18/2015 10:05 PM, Öö Tiib wrote:
>> Now, suppose you actually want to keep the reference as non-const, in
>> order to be able to invoke non-const members, would it be OK to use an
>> rvalue reference?
>>
>> Sprite&& s1 = Toon {};
>
> Yes. However where you need that? In most circumstances
> that works lot better:
>
> Toon s1{};
>
>> I've been using it like that and have not run into any problems, but I'd
>> like to know where I'm stepping.
>
> Yes, tell us why you use it?

No special reason, really. I just wanted to treat those objects as
"Sprite" without doing dynamic allocation or introducing a new
identifier, like:

Toon t1 = Toon {...};
Sprite& s1 = t1;

Honestly, I suppose I was just trying to challenge myself by forcing me
to deal with such questionable requirements. But thank you for answering.

Best regards,

--
Andre Zunino

[Gareth Owen]

Andre Zunino <neyz...@hotmail.com> writes:

> No special reason, really. I just wanted to treat those objects as
> "Sprite" without doing dynamic allocation or introducing a new
> identifier, like:
>
> Toon t1 = Toon {...};
> Sprite& s1 = t1;

't1' is already a Sprite, and can be treated as one in every context
where it makes sense to do so. That is how public inheritance works
(see Liskov Substitution Principle).

[Öö Tiib]

On Monday, 20 July 2015 05:06:41 UTC+3, Andre Zunino wrote:
> On 07/18/2015 10:05 PM, Öö Tiib wrote:
> >> Now, suppose you actually want to keep the reference as non-const, in
> >> order to be able to invoke non-const members, would it be OK to use an
> >> rvalue reference?
> >>
> >> Sprite&& s1 = Toon {};
> >
> > Yes. However where you need that? In most circumstances
> > that works lot better:
> >
> > Toon s1{};
> >
> >> I've been using it like that and have not run into any problems, but I'd
> >> like to know where I'm stepping.
> >
> > Yes, tell us why you use it?
>
> No special reason, really. I just wanted to treat those objects as
> "Sprite" without doing dynamic allocation or introducing a new
> identifier, like:
>
> Toon t1 = Toon {...};
> Sprite& s1 = t1;

It is difficult to work with dynamic polymorphism without doing
dynamic allocations. Above case is lucky and so no dynamic
polymorphism is needed since we do know that it is 'Toon'.
There are no need to type 'Toon' twice above however in
order to try to nail the fact deeper into our brains. :) Type:

Toon t1{ /*...*/ };

The 't1' will be treated as 'Sprite' already everywhere without
additional identifiers needed since 'Sprite' is 'Toon's public
base class. So it is shorter to type and works better.

> Honestly, I suppose I was just trying to challenge myself by forcing me
> to deal with such questionable requirements. But thank you for answering.

With dynamic polymorphism there are some things that should
not be even attempted. All that cppy, move, passing by value, 'swap'
etc. simply does not work polymorphically.