A Question On Reference Type

First please look at the code

Code:

---

#include <iostream>

using namespace std;

class Test {
public:
    Test() { cout << "Test" << endl; }
    ~Test() { cout << "~Test" << endl; }
};

int main()
{
    const Test& t = Test();
    //Test();
    cout << "haha" << endl;

    return 0;
}

---

and the output

Quote:

---

Test
haha
~Test

---

If I comment out "const Test& t = Test();" and use "Test();" instead, the output will be

Quote:

---

Test
~Test
haha

---

Don't you think it weird? Does the standard say that a temporary object's destruction will be deferred if it is referenced by an object of const reference type?

what this has to do with const?
first sample creates object that is destructed when the function main is finished

second sample creates temporary object that is destructed as soon as the call to Test() is finished...

Quote:

---

Originally Posted by vart

what this has to do with const?
first sample creates object that is destructed when the function main is finished

second sample creates temporary object that is destructed as soon as the call to Test() is finished...

---

but why the temporary object in the first sample is destroyed when after main is finished where as the temporary object in the second sample is destroyed immediately? Test() creates just the same temporary object no matter in the 1st/2nd sample, the only difference is that in the 1st sample, Test() is referenced

In the first example, the standard guarantees the object will exist until the enclosing scope is exited - ie on return from main().

In the second example, the only guarantee is that the temporary object will exist until the next sequence point - which means it may be destroyed before the next statement. That next statement is your cout << "haha" line.....

Quote:

---

Originally Posted by grumpy

In the first example, the standard guarantees the object will exist until the enclosing scope is exited - ie on return from main().

In the second example, the only guarantee is that the temporary object will exist until the next sequence point - which means it may be destroyed before the next statement. That next statement is your cout << "haha" line.....

---

Can you please tell me which section of the Standard guarantees these behaviors and why the 1st behaviour is guaranteed? For what good?

Quote:

---

Originally Posted by Antigloss

Can you please tell me which section of the Standard guarantees these behaviors and why the 1st behaviour is guaranteed? For what good?

---

As long as you have a variable that refers to the object, the object must also exist. Since the variable t exists within the entire part of main, the object must also exist that long. In the second case, you create an object with nothing to "hold on to" the object, so there is no need for it to exist more than the blink that is from it's construction to it's destruction - how is the object going to be used if there's nothing to refer to it by?

--
Mats

It's 12.2/5 in the current draft standard for C++0x. I don't know where it is in the original, but it's there.

As for why, I don't know; there's no rationale in the standard. Probably for this:

Code:

---

const T &ref = foo();

---

This code should work whether foo() returns an object or a reference.

well, i see. Thanks alot, everybody

By coincidence, it's in Section 12.2 para 5 of the 1998 standard as well.

Would you really want the object to be destructed before you're finished using it?

>> By coincidence, it's in Section 12.2 para 5 of the 1998 standard as well.
I doubt that's coincidence.

>> Would you really want the object to be destructed before you're finished using it?
No, but that happens if you use a non-const reference or a pointer, so tat rationale doesn't seem to apply here.

Quote:

---

Probably for this:

Code:

---

const T &ref = foo();

---

---

In the new standard, this will be possible with an rvalue reference if 'foo()' is just a function? The code CornedBeef showed is erroneous for the current standard? The line

Code:

---

const Test& t = Test();

---

does work because this creates the temporary object.

Am I right?

Huh?

The code is perfectly valid for the current standard. If the function returns by-value, the reference will bind to the return value temporary, whose lifetime is extended. If the function returns by-ref, the reference will alias the return value referenced object, and the lifetime must be long enough anyway.

Rvalue references bring a new dimension to the game. I don't actually know what happens if you try to make a const lvalue reference alias an rvalue reference.

Sorry, I've got it a little wrong.

It is due to the 'const' declaration that the reference can bind to a temporary in

Code:

---

const Test& t = Test();

---

or in

Code:

---

const T &ref = foo();

---

Non-const references cannot be bind to temporaries=rvalues , so there's where the rvalue reference comes in place:

Code:

---

Test&& t = Test();
int&& t = foo(); // suppose foo returns an int

---

I'll have to study a little more on move semantics, but from what I've seen I love it :-)

http://www.artima.com/cppsource/rvalue.html

Is

Code:

---

Test t(); //or
Test t;

---

Equal to

Code:

---

Test &t =Test();

---

?

No. The former declares a function named t that takes no arguments and returns a Test. The latter is not allowed, as noted by MarkZWEERS.

How the constructor is called without using 'new'? Is it implicity called when you call the constructor? It seems by calling the constructor weare implicity using 'new', am I right?

Quote:

---

The latter is not allowed, as noted by MarkZWEERS.

---

Would you explain more, please?

Quote:

---

How the constructor is called without using 'new'? Is it implicity called when you call the constructor?

---

Whenever you create an object, one of the object's constructors is implicitly called. Even the use of new does not explicitly call a constructor (and I believe that applies even to placement new).

Quote:

---

It seems by calling the constructor weare implicity using 'new', am I right?

---

No.

Quote:

---

Would you explain more, please?

---

Attempt to compile this program:

Code:

---

class Test {};

int main()
{
    Test &t = Test();
}

---

This code compiled and ran successfully:

Code:

---

#include <iostream>

using namespace std;


class Test {
public:
    Test() { cout << "Test" << (int)this << endl; }
    ~Test() { cout << "~Test" << endl; }
      void test(){cout <<"fun"<<endl;}
};

int main()
{
    Test& t = Test();
      t.test();
    cout << "main" << endl;

    return 0;
}

---

[edit]

Quote:

---

Whenever you create an object

---

Where did we create an object in

Code:

---

Test();

---

?

Quote:

---

This code compiled and ran successfully:

---

Disable compiler extensions. Your code should not compile on a standard compliant implementation.

Quote:

---

Disable compiler extensions.

---

Yes now it is giving me two errors

Quote:

---

delme.cpp(8) : error C2440: 'type cast' : cannot convert from 'Test *const ' to 'int'
The target is not large enough
delme.cpp(15) : error C2440: 'initializing' : cannot convert from 'Test' to 'Test &'
A non-const reference may only be bound to an lvalue

---

What is this extension?

Visual C++ is a known compiler to allow this extension. If you go to warnings level 4, you should also receive a warning saying non-standard extension used.
The extension allows you to bind a non-const reference to a temporary, which is disallowed by the standard (only const references can bind to temporaries, which has been pointed out earlier).

OK. When we write

Code:

---

Test()

---

What happens? Does a memory allocation take place for class on heap or it is just a temp on stack (or somewhere else)? Why it can be bind to const ref but not non-const?

Unless you use new, it's on the stack. Always the stack, unless it's new.
I believe it's because you shouldn't be able to modify a temporary because it's just that - a temporary. Its lifetime is less than that of the variable it's bound to. Bad things would happen if you try to modify it after its lifetime has expired (while the lifetime of the variable holding the reference is still alive).

When I disabled extension it generates error for my type cast. So how should I cast that?
Second this code works fine:

Code:

---

class Test {
public:
    Test() { cout << "Test"  << endl; }
    ~Test() { cout << "~Test" << endl; }
      void test(){cout <<"fun"<<endl;}
};

int main()
{
      Test();
    Test t = Test();
      t.test();
    cout << "main" << endl;

    return 0;
}

---

Why by calling constructor it takes place in stack?

[EDIT]And what about this

Code:

---

class Test {
public:
    Test() { cout << "Test"  << endl; }
    ~Test() { cout << "~Test" << endl; }
      void test(){cout <<"fun"<<endl;}
}rt;

---

rt is static in stack in file scope. Right?

That's one thing that has burned me a number of times... What exactly is the lifetime of a temporary object? It's obviously less than a regular variable which ends when it gets to its closing brace.
I think this is one of the cases where I've gotten burned:

Code:

---

std::string Func() { ... }

int main()
{
  ...
  AnotherFunc( Func().c_str() );
  ...
}

---

In the case above, I believe the temporary object doesn't even life until the end of the function call.

Quote:

---

When I disabled extension it generates error for my type cast. So how should I cast that?

---

What type cast?

Quote:

---

Why by calling constructor it takes place in stack?

---

What is the stack?

Quote:

---

Originally Posted by siavoshkc

Code:

---

class Test {
public:
    Test() { cout << "Test"  << endl; }
    ~Test() { cout << "~Test" << endl; }
      void test(){cout <<"fun"<<endl;}
};

int main()
{
      Test();
    Test t = Test();
      t.test();
    cout << "main" << endl;

    return 0;
}

---

Why by calling constructor it takes place in stack?

---

That line (in green) is completely useless since you're calling the default constructor twice. Just do this:

Code:

---

Test t;

---

>> When I disabled extension it generates error for my type cast. So how should I cast that?
Why do you need a cast there? Just output this (or cast to void*).

Temporaries passed to a function live until the function ends, but in cpjust's example the result of Func() isn't passed to a function, a pointer is. So the result of Func() lives until c_str() is called and it's value is sent to the function. Then it can be destroyed.

A temporary lives until the end of the "full-expression", i.e. the next semicolon. Unless, that is, it is bound to a reference, in which case its lifetime is extended to that of the reference.

In particular, a temporary appearing with function parameters lives until the full expression containing the function call finishes. However, if the function keeps a reference to the object in question, this reference will soon be invalid.

>> A temporary lives until the end of the "full-expression", i.e. the next semicolon.
That would mean that cpjust's example should work.

Quote:

---

That line (in green) is completely useless since you're calling the default constructor twice. Just do this:

---

I know that I am exactly calling constructor in different ways.
[EDIT] Sorry you are right I thought you are saying something else.
When constructor has no parameter we should use TestClass t; But not TestClass t();
When for example it takes an int we should write TestClass t(intA);

Quote:

---

Why do you need a cast?

---

QUOTE]What type cast?[/QUOTE]
To cout << this; in constructor

stack is a part of memory where local variables and arrays are stored in LIFO. It is also used for passing function parameters.

>> To cout << this; in constructor
I know. Use void*.

Quote:

---

stack is a part of memory where local variables and arrays are stored in LIFO. It is also used for passing function parameters.

---

Then you have answered your own question. t is a local (or perhaps more accurately in the context of the question, an automatic) variable.

C++ has three kinds of storage: static, dynamic and automatic.

They are typically mapped to the OS's .data/.bss, heap and stack.

What kind of storage an object uses is generally very obvious:
1) Globals, static class members and static locals are in static storage.
2) Everything allocated by normal new, the malloc family, and std::get_temporary_buffer is in dynamic storage. There may be additional, implementation-specific means of obtaining memory in dynamic storage (e.g. HeapAlloc in Win32).
3) Everything else - including temporaries, obviously - is automatic storage.

Quote:

---

I know. Use void*.

---

Thanks. I should practice programming with extensions turned off or at least WL 4. Note the edit in my former post.
But I still don't know why by calling constructor, class takes place in stack.

Quote:

---

But I still don't know why by calling constructor, class takes place in stack.

---

You're mistaking the cause here. The object is on the stack because it's not a global or on the heap. The constructor is called because it's an object.

Quote:

---

You're mistaking the cause here. The object is on the stack because it's not a global or on the heap. The constructor is called because it's an object.

---

It is not anywhere. You mean by defining the class, it will be placed on the stack?

No.
You create it inside a function, so it isn't global.
You don't create it with static, so it's not a static variable.
You don't create it with new, so it's not on the heap.
What's left? The stack! It's created on the stack.
Everything that is not global, static or on the heap is placed on the stack!

Class definition has nothing to do with it.

Quote:

---

You mean by defining the class, it will be placed on the stack?

---

Careful with your terminology. This is a class definition:

Code:

---

class Foo
{
 int m1;
public:
  void bar();
};

---

Quote:

---

Careful with your terminology. This is a class definition:

---

I exactly mean it.

By defining a class it is nowhere. It is just for compiler. If its true. How its constructor can be called?

When we define a function in a file its code will be loaded into memory each time programs executes. But when its a member function of a class it is nowhere unless it has been defined static or the class has been instantiated.

The functions (where the code lies) of the class is called the implementation.
Also, it's true that the code in the class, the functions, are indeed created and put in memory, but what has that to do with the instance being created on the stack? Btw, all the member data is placed on the stack, but the function aren't, because they're code.

Quote:

---

By defining a class it is nowhere. It is just for compiler. If its true. How its constructor can be called?

---

It's called per instance.