Aside from dynamic memory allocation, is there a functional difference between the following two lines of code:
Time t (12, 0, 0); //t is a Time object
Time* t = new Time(12, 0, 0);//t is a pointer to a dynamically allocated Time object
I am assuming of course that a Time(int, int, int) ctor has been defined. I also realize that in the second case t will need to be deleted as it was allocated on the heap. Is there any other difference?
The line:
Time t (12, 0, 0);
... allocates a variable of type Time in local scope, generally on the stack, which will be destroyed when its scope ends.
By contrast:
Time* t = new Time(12, 0, 0);
... allocates a block of memory by calling either ::operator new() or Time::operator new(), and subsequently calls Time::Time() with this set to an address within that memory block (and also returned as the result of new), which is then stored in t. As you know, this is generally done on the heap (by default) and requires that you delete it later in the program, while the pointer in t is generally stored on the stack.
N.B.: My use of generally here is speaking in terms of common implementations. The C++ standard does not distinguish stack and heap as a part of the machine, but rather in terms of their lifetime. Variables in local scope are said to have "automatic storage duration," and are thus destroyed at the end of local scope; and objects created with new are said to have "dynamic storage duration," and are destroyed only when deleted. In practical terms, this means that automatic variables are created and destroyed on the stack, and dynamic objects are stored on the heap, but this is not required by the language.
One more obvious difference is when accessing the variables and methods of t.
Time t (12, 0, 0);
t.GetTime();
Time* t = new Time(12, 0, 0);
t->GetTime();
As far as the constructor is concerned, the two forms are functionally identical: they'll just cause the constructor to be called on a newly allocated object instance. You already seem to have a good grasp on the differences in terms of allocation modes and object lifetimes.
I think you already understand all the differences. Assuming that you are well aware about the syntax difference of accessing a member of t through a pointer and through a variable (well, pointer is also a variable but I guess you understand what I mean). And assuming also that you know the difference of call by value and call by reference when passing t to a function. And I think you also understand what will happen if you assign t to another variable and make change through that other variable. The result will be different depending on whether t is pointer or not.
Use new：
Call operator new function to get dynamic memory, and then to call the constuctor function.
Not use new:
Will not call operator new function, just directly to call the constuctor function. The stack will be used directly, no use to malloc.
There is no functional difference to the object between allocating it on the stack and allocating it on the heap. Both will invoke the object's constructor.
Incidentally I recommend you use boost's shared_ptr or scoped_ptr which is also functionally equivalent when allocating on the heap (with the additional usefulness of scoped_ptr constraining you from copying non-copyable pointers):
scoped_ptr<Time> t(new Time(12, 0, 0));
There is no other difference to what you know already.
Assuming your code is using the service of default operator new.
No.. There is no other difference..
void foo (Time t)
{
t = Time(12, 0, 0);
}
void bar (Time* t)
{
t = new Time(12, 0, 0);
}
int main(int argc, char *argv[])
{
Time t;
foo(t);//t is not (12,0,0),its value depends on your defined type Time's default constructor.
bar(&t);//t is (12,0,0)
return 0;
}
Related
I am trying to understand the difference between the stack and heap memory, and this question on SO as well as this explanation did a pretty good job explaining the basics.
In the second explanation however, I came across an example to which I have a specific question, the example is this:
It is explained that the object m is allocated on the heap, I am just wondering if this is the full story. According to my understanding, the object itself indeed is allocated on the heap as the new keyword has been used for its instantiation.
However, isn't it that the pointer to object m is on the same time allocated on the stack? Otherwise, how would the object itself, which of course is sitting in the heap be accessed. I feel like for the sake of completeness, this should have been mentioned in this tutorial, leaving it out causes a bit of confusion to me, so I hope someone can clear this up and tell me that I am right with my understanding that this example should have basically two statements that would have to say:
1. a pointer to object m has been allocated on the stack
2. the object m itself (so the data that it carries, as well as access to its methods) has been allocated on the heap
Your understanding may be correct, but the statements are wrong:
A pointer to object m has been allocated on the stack.
m is the pointer. It is on the stack. Perhaps you meant pointer to a Member object.
The object m itself (the data that it carries, as well as access to its methods) has been allocated on the heap.
Correct would be to say the object pointed by m is created on the heap
In general, any function/method local object and function parameters are created on the stack. Since m is a function local object, it is on the stack, but the object pointed to by m is on the heap.
"stack" and "heap" are general programming jargon. In particular , no storage is required to be managed internally via a stack or a heap data structure.
C++ has the following storage classes
static
automatic
dynamic
thread
Roughly, dynamic corresponds to "heap", and automatic corresponds to "stack".
Moving onto your question: a pointer can be created in any of these four storage classes; and objects being pointed to can also be in any of these storage classes. Some examples:
void func()
{
int *p = new int; // automatic pointer to dynamic object
int q; // automatic object
int *r = &q; // automatic pointer to automatic object
static int *s = p; // static pointer to dynamic object
static int *s = r; // static pointer to automatic object (bad idea)
thread_local int **t = &s; // thread pointer to static object
}
Named variables declared with no specifier are automatic if within a function, or static otherwise.
When you declare a variable in a function, it always goes on the stack. So your variable Member* m is created on the stack. Note that by itself, m is just a pointer; it doesn't point to anything. You can use it to point to an object on either the stack or heap, or to nothing at all.
Declaring a variable in a class or struct is different -- those go where ever the class or struct is instantiated.
To create something on the heap, you use new or std::malloc (or their variants). In your example, you create an object on the heap using new and assign its address to m. Objects on the heap need to be released to avoid memory leaks. If allocated using new, you need to use delete; if allocated using std::malloc, you need to use std::free. The better approach is usually to use a "smart pointer", which is an object that holds a pointer and has a destructor that releases it.
Yes, the pointer is allocated on the stack but the object that pointer points to is allocated on the heap. You're correct.
However, isn't it that the pointer to object m is on the same time
allocated on the stack?
I suppose you meant the Member object. The pointer is allocated on the stack and will last there for the entire duration of the function (or its scope). After that, the code might still work:
#include <iostream>
using namespace std;
struct Object {
int somedata;
};
Object** globalPtrToPtr; // This is into another area called
// "data segment", could be heap or stack
void function() {
Object* pointerOnTheStack = new Object;
globalPtrToPtr = &pointerOnTheStack;
cout << "*globalPtrToPtr = " << *globalPtrToPtr << endl;
} // pointerOnTheStack is NO LONGER valid after the function exits
int main() {
// This can give an access violation,
// a different value after the pointer destruction
// or even the same value as before, randomly - Undefined Behavior
cout << "*globalPtrToPtr = " << *globalPtrToPtr << endl;
return 0;
}
http://ideone.com/BwUVgm
The above code stores the address of a pointer residing on the stack (and leaks memory too because it doesn't free Object's allocated memory with delete).
Since after exiting the function the pointer is "destroyed" (i.e. its memory can be used for whatever pleases the program), you can no longer safely access it.
The above program can either: run properly, crash or give you a different result. Accessing freed or deallocated memory is called undefined behavior.
I am still new to C++. I have found that you can instantiate an instance in C++ with two different ways:
// First way
Foo foo;
foo.do_something();
// Second way
Baz *baz = new Baz();
baz->do_something();
And with both I don't see big difference and can access the attributes. Which is the preferred way in C++? Or if the question is not relevant, when do we use which and what is the difference between the two?
Thank you for your help.
The question is not relevant: there's no preferred way, those just do different things.
C++ both has value and reference semantics. When a function asks for a value, it means you'll pass it a copy of your whole object. When it asks for a reference (or a pointer), you'll only pass it the memory address of that object. Both semantics are convertible, that is, if you get a value, you can get a reference or a pointer to it and then use it, and when you get a reference you can get its value and use it. Take this example:
void foo(int bar) { bar = 4; }
void foo(int* bar) { *bar = 4; }
void test()
{
int someNumber = 3;
foo(someNumber); // calls foo(int)
std::cout << someNumber << std::endl;
// printed 3: someNumber was not modified because of value semantics,
// as we passed a copy of someNumber to foo, changes were not repercuted
// to our local version
foo(&someNumber); // calls foo(int*)
std::cout << someNumber << std::endl;
// printed 4: someNumber was modified, because passing a pointer lets people
// change the pointed value
}
It is a very, very common thing to create a reference to a value (i.e. get the pointer of a value), because references are very useful, especially for complex types, where passing a reference notably avoids a possibly costly copy operation.
Now, the instantiation way you'll use depends on what you want to achieve. The first way you've shown uses automatic storage; the second uses the heap.
The main difference is that objects on automatic storage are destroyed with the scope in which they existed (a scope being roughly defined as a pair of matching curly braces). This means that you must not ever return a reference to an object allocated on automatic storage from a regular function, because by the time your function returns, the object will have been destroyed and its memory space may be reused for anything at any later point by your program. (There are also performance benefits for objects allocated on automatic storage because your OS doesn't have to look up a place where it might put your new object.)
Objects on the heap, on the other hand, continue to exist until they are explicitly deleted by a delete statement. There is an OS- and platform-dependant performance overhead to this, since your OS needs to look up your program's memory to find a large enough unoccupied place to create your object at. Since C++ is not garbage-collected, you must instruct your program when it is the time to delete an object on the heap. Failure to do so leads to leaks: objects on the heap that are no longer referenced by any variable, but were not explicitly deleted and therefore will exist until your program exits.
So it's a matter of tradeoff. Either you accept that your values can't outlive your functions, or you accept that you must explicitly delete it yourself at some point. Other than that, both ways of allocating objects are valid and work as expected.
For further reference, automatic storage means that the object is allocated wherever its parent scope was. For instance, if you have a class Foo that contains a std::string, the std::string will exist wherever you allocate your Foo object.
class Foo
{
public:
// in this context, automatic storage refers to wherever Foo will be allocated
std::string a;
};
int foo()
{
// in this context, automatic storage refers to your program's stack
Foo bar; // 'bar' is on the stack, so 'a' is on the stack
Foo* baz = new Foo; // 'baz' is on the heap, so 'a' is on the heap too
// but still, in both cases 'a' will be deleted once the holding object
// is destroyed
}
As stated above, you cannot directly leak objects that reside on automatic storage, but you cannot use them once the scope in which they were created is destroyed. For instance:
int* foo()
{
int a; // cannot be leaked: automatically managed by the function scope
return &a; // BAD: a doesn't exist anymore
}
int* foo()
{
int* a = new int; // can be leaked
return a; // NOT AS BAD: now the pointer points to somewhere valid,
// but you eventually need to call `delete a` to release the memory
}
The first way -- "allocating on the stack" -- is generally faster and preferred much of the time. The constructed object is destroyed when the function returns. This is both a blessing -- no memory leaks! -- and a curse, because you can't create an object that lives for a longer time.
The second way -- "allocating on the heap" is slower, and you have to manually delete the objects at some point. But it has the advantage that the objects can live on until you delete them.
The first way allocates the object on the stack (though the class itself may have heap-allocated members). The second way allocates the object on the heap, and must be explicitly delete'd later.
It's not like in languages like Java or C# where objects are always heap-allocated.
They do very different things. The first one allocates an object on the stack, the 2nd on the heap. The stack allocation only lasts for the lifetime of the declaring method; the heap allocation lasts until you delete the object.
The second way is the only way to dynamically allocate objects, but comes with the added complexity that you must remember to return that memory to the operating system (via delete/delete[]) when you are done with it.
The first way will create the object on the stack, and the object will go away when you return from the function it was created in.
The second way will create the object on the heap, and the object will stick around until you call delete foo;.
If the object is just a temporary variable, the first way is better. If it's more permanent data, the second way is better - just remember to call delete when you're finally done with it so you don't build up cruft on your heap.
Hope this helps!
For example this class:
class RTPIPv4Address{
public:
RTPIPv4Address(int a, int b);
}
Silly question but... I just stumbled on code which initialized a class instance like that with for example
RTPIPv4Address adr(2,2);
Now I am wondering, is this just another syntax for the usual
RTPIPv4Address* adr = new RTPIPv4Address (2,2);
or does it have any other effects? For example, given the lack of a pointer and a new(), is it declared on the stack like other local variables do and then get deallocated at function return or is it saved on the heap and therefore persist?
Thanks in advance
Yes, the first example is stack-allocated and will have it's destructor called and be deallocated as soon as the variable loses scope. For a local variable, this usually happens when the function returns, though you can force it to lose scope earlier with curly braces.
function
{
RTPIPv4Address adr(2,2);
return; //adr loses scope and destructor is called
}
That's how it's normally allocated on the stack and where it loses scope, but it can happen other places as well.
function
{
if (condition)
{
RTPIPv4Address adr(2, 2);
//do stuff with adr
} //adr loses scope and destructor is called
//do more stuff
return;
}
The two both construct an object but apart from that are very dissimilar. The first constructs on the stack, the second on the heap. The first form should be used wherever possible. The second form should be used if and only if you need the object to persist, or, it is too large to fit on the stack. new is not the "usual" form of object creation at all in C++.
The first example will stack-allocate your object. The only way to get something on the heap is via new (and, obviously, malloc or other low-level operations like mmap).
Aside from dynamic memory allocation, is there a functional difference between the following two lines of code:
Time t (12, 0, 0); //t is a Time object
Time* t = new Time(12, 0, 0);//t is a pointer to a dynamically allocated Time object
I am assuming of course that a Time(int, int, int) ctor has been defined. I also realize that in the second case t will need to be deleted as it was allocated on the heap. Is there any other difference?
The line:
Time t (12, 0, 0);
... allocates a variable of type Time in local scope, generally on the stack, which will be destroyed when its scope ends.
By contrast:
Time* t = new Time(12, 0, 0);
... allocates a block of memory by calling either ::operator new() or Time::operator new(), and subsequently calls Time::Time() with this set to an address within that memory block (and also returned as the result of new), which is then stored in t. As you know, this is generally done on the heap (by default) and requires that you delete it later in the program, while the pointer in t is generally stored on the stack.
N.B.: My use of generally here is speaking in terms of common implementations. The C++ standard does not distinguish stack and heap as a part of the machine, but rather in terms of their lifetime. Variables in local scope are said to have "automatic storage duration," and are thus destroyed at the end of local scope; and objects created with new are said to have "dynamic storage duration," and are destroyed only when deleted. In practical terms, this means that automatic variables are created and destroyed on the stack, and dynamic objects are stored on the heap, but this is not required by the language.
One more obvious difference is when accessing the variables and methods of t.
Time t (12, 0, 0);
t.GetTime();
Time* t = new Time(12, 0, 0);
t->GetTime();
As far as the constructor is concerned, the two forms are functionally identical: they'll just cause the constructor to be called on a newly allocated object instance. You already seem to have a good grasp on the differences in terms of allocation modes and object lifetimes.
I think you already understand all the differences. Assuming that you are well aware about the syntax difference of accessing a member of t through a pointer and through a variable (well, pointer is also a variable but I guess you understand what I mean). And assuming also that you know the difference of call by value and call by reference when passing t to a function. And I think you also understand what will happen if you assign t to another variable and make change through that other variable. The result will be different depending on whether t is pointer or not.
Use new：
Call operator new function to get dynamic memory, and then to call the constuctor function.
Not use new:
Will not call operator new function, just directly to call the constuctor function. The stack will be used directly, no use to malloc.
There is no functional difference to the object between allocating it on the stack and allocating it on the heap. Both will invoke the object's constructor.
Incidentally I recommend you use boost's shared_ptr or scoped_ptr which is also functionally equivalent when allocating on the heap (with the additional usefulness of scoped_ptr constraining you from copying non-copyable pointers):
scoped_ptr<Time> t(new Time(12, 0, 0));
There is no other difference to what you know already.
Assuming your code is using the service of default operator new.
No.. There is no other difference..
void foo (Time t)
{
t = Time(12, 0, 0);
}
void bar (Time* t)
{
t = new Time(12, 0, 0);
}
int main(int argc, char *argv[])
{
Time t;
foo(t);//t is not (12,0,0),its value depends on your defined type Time's default constructor.
bar(&t);//t is (12,0,0)
return 0;
}
In my browsings amongst the Internet, I came across this post, which includes this
"(Well written) C++ goes to great
lengths to make stack automatic
objects work "just like" primitives,
as reflected in Stroustrup's advice to
"do as the ints do". This requires a
much greater adherence to the
principles of Object Oriented
development: your class isn't right
until it "works like" an int,
following the "Rule of Three" that
guarantees it can (just like an int)
be created, copied, and correctly
destroyed as a stack automatic."
I've done a little C, and C++ code, but just in passing, never anything serious, but I'm just curious, what it means exactly?
Can someone give an example?
Stack objects are handled automatically by the compiler.
When the scope is left, it is deleted.
{
obj a;
} // a is destroyed here
When you do the same with a 'newed' object you get a memory leak :
{
obj* b = new obj;
}
b is not destroyed, so we lost the ability to reclaim the memory b owns. And maybe worse, the object cannot clean itself up.
In C the following is common :
{
FILE* pF = fopen( ... );
// ... do sth with pF
fclose( pF );
}
In C++ we write this :
{
std::fstream f( ... );
// do sth with f
} // here f gets auto magically destroyed and the destructor frees the file
When we forget to call fclose in the C sample the file is not closed and may not be used by other programs. (e.g. it cannot be deleted).
Another example, demonstrating the object string, which can be constructed, assigned to and which is destroyed on exiting the scope.
{
string v( "bob" );
string k;
v = k
// v now contains "bob"
} // v + k are destroyed here, and any memory used by v + k is freed
In addition to the other answers:
The C++ language actually has the auto keyword to explicitly declare the storage class of an object. Of course, it's completely needless because this is the implied storage class for local variables and cannot be used anywhere. The opposite of auto is static (both locally and globall).
The following two declarations are equivalent:
int main() {
int a;
auto int b;
}
Because the keyword is utterly useless, it will actually be recycled in the next C++ standard (“C++0x”) and gets a new meaning, namely, it lets the compiler infer the variable type from its initialization (like var in C#):
auto a = std::max(1.0, 4.0); // `a` now has type double.
Variables in C++ can either be declared on the stack or the heap. When you declare a variable in C++, it automatically goes onto the stack, unless you explicitly use the new operator (it goes onto the heap).
MyObject x = MyObject(params); // onto the stack
MyObject * y = new MyObject(params); // onto the heap
This makes a big difference in the way the memory is managed. When a variable is declared on the stack, it will be deallocated when it goes out of scope. A variable on the heap will not be destroyed until delete is explicitly called on the object.
Stack automatic are variables which are allocated on the stack of the current method. The idea behind designing a class which can acts as Stack automatic is that it should be possible to fully initialize it with one call and destroy it with another. It is essential that the destructor frees all resources allocated by the object and its constructor returns an object which has been fully initialized and ready for use. Similarly for the copy operation - the class should be able to be easily made copies, which are fully functional and independent.
The usage of such class should be similar to how primitive int, float, etc. are used. You define them (eventually give them some initial value) and then pass them around and in the end leave the compiler to the cleaning.
Correct me if i'm wrong, but i think that copy operation is not mandatory to take full advantage of automatic stack cleaning.
For example consider a classic MutexGuard object, it doesn't need a copy operation to be useful as stack automatic, or does it ?