Tricky question

[Bonita Montero]

Is there a way to enforce that an object
can be only instantiated as a temporary ?

[Alf P. Steinbach]

On 28.03.2021 08:46, Bonita Montero wrote:
> Is there a way to enforce that an object
> can be only instantiated as a temporary ?

No, because you can always bind it to a reference.

When an object such as an operator[] proxy result shouldn't outlive the
object that it refers to one could in principle guarantee that by having
all the objects dynamically allocated and using shared_ptr. But that
impacts negatively on efficiency, clarity, debuggability etc. plus
yields more awkward usage notation. One could then much better switch to
Java, C# or Rust.

So just add a stern comment in the relevant place.

- Alf

[Bonita Montero]

> No, because you can always bind it to a reference.

I could assume that no one would be so stupid to do sth. like this:
Obj const &o = Obj();
So if I make this assumption, what's the solution ?

[Juha Nieminen]

The lifetime of the temporary will be extended to the lifetime of the
reference in that case, so it's not completely stupid.

[Juha Nieminen]

Bonita Montero <Bonita....@gmail.com> wrote:
> Is there a way to enforce that an object
> can be only instantiated as a temporary ?

I'm thinking what happens if all the member functions are
rvalue-qualified, but I haven't tested if that will introduce
that limitation. Maybe not.

[Bonita Montero]

>>> No, because you can always bind it to a reference.

>> I could assume that no one would be so stupid to do sth. like this:
>> Obj const &o = Obj();
>> So if I make this assumption, what's the solution ?

> The lifetime of the temporary will be extended to the lifetime of the
> reference in that case, so it's not completely stupid.

You're right, and look at this:

#include <iostream>

using namespace std;

struct S
{
S()
{
cout << "S::S()" << endl;
}
~S()
{
cout << "~S::S()" << endl;
}
};

int main( int argc, char **argv )
{
S const &s = argc < 0 ? S() : S();
cout << "after destruction?" << endl;
}

Of course argc can never be < 0, but the compiler doesn't know that.
So look at the output:

S::S()
~S::S()
after destruction!
~S::S()

So the code destructs only one object within the statement !

[Richard Damon]

You didn't define a copy constructor, so there may have been a second S
created as a copy of the first, to bind to the reference.

[Bonita Montero]

>> You're right, and look at this:
>> #include <iostream>
>> using namespace std;
>>
>> struct S
>> {
>>     S()
>>     {
>>         cout << "S::S()" << endl;
>>     }
>>     ~S()
>>     {
>>         cout << "~S::S()" << endl;
>>     }
>> };
>> int main( int argc, char **argv )
>> {
>>     S const &s = argc < 0 ? S() : S();
>>     cout << "after destruction?" << endl;
>> }
>>
>> Of course argc can never be < 0, but the compiler doesn't know that.
>> So look at the output:
>> S::S()
>> ~S::S()
>> after destruction!
>> ~S::S()
>>
>> So the code destructs only one object within the statement !

> You didn't define a copy constructor, so there may have been a second S
> created as a copy of the first, to bind to the reference.

You have too much phantasy. That's for sure not required by the
standard, nor it would be realistic that any compiler would do
it that way.

[Manfred]

It's no fantasy, that is what is happening in reality - if you use msvc
(gcc makes no copy) - you would have seen it yourself if you had a copy
(and a move) ctor defined.
[BTW ~S::S() should be S::~S()]

[Paavo Helde]

If you think a copy ctor does not get used in your little experiment,
then how do you explain the output you saw? Or do you suggest the
compiler is buggy and destructs the same object twice? (Hint: it does not.)

[Richard Damon]

Another good thing to do when generating this sort of trace is include
the 'this' pointer (i.e. the object address) and you would see that the
two destruction are at different addresses.