tags:

views:

543

answers:

5

Q1. In Java, all objects, arrays and class variables are stored on the heap? Is the same true for C++? Is data segment a part of Heap?

What about the following code in C++?

class MyClass{
    private:
            static int counter; 
            static int number;
};

MyClass::number = 100;

Q2. As far as my understanding goes, variables which are given a specific value by compiler are stored in data segment, and unintialized global and static variables are stored in BSS (Block started by symbol). In this case, MyClass::counter being static is initialized to zero by the compiler and so it is stored at BSS and MyClass::number which is initialized to 100 is stored in the data segment. Am I correct in making the conclusion?

Q3. Consider following piece of codes:

void doHello(MyClass &localObj){   
// 3.1 localObj is a reference parameter, where will this get stored in Heap or Stack?
      // do something
}

void doHelloAgain(MyClass localObj){   
// 3.2 localObj is a parameter, where will this get stored in Heap or Stack?
      // do something
}

int main(){
      MyClass *a = new MyClass();  // stored in heap

      MyClass localObj;   
      // 3.3 Where is this stored in heap or stack?
      doHello(localObj);
      doHelloAgain(localObj);
}

I hope I have made my questions clear to all

EDIT:

Please refer this article for some understanding on BSS

EDIT1: Changed the class name from MyInstance to MyClass as it was a poor name. Sincere Apologies

EDIT2: Changed the class member variable number from non-static to static

+2  A: 

Q1

Java also stores variables on the stack but class instances are allocated on the heap. In C++ you are free to allocate your class instances either on the stack or on the heap. By using the new keyword you allocate the instance on the heap.

The data segment is not part of the heap, but is allocated when the process starts. The heap is used for dynamic memory allocations while the data segment is static and the contents is known at compile time.

The BSS segment is simply an optimization where all the data belongning to the data segment (e.g. string, constant numbers etc.) that are not initialized or initialized to zero are moved to the BSS segment. The data segment has to be embedded into the executable and by moveing "all the zeros" to the end they can be removed from the executable. When the executable is loaded the BSS segment is allocated and initialized to zero, and the compiler is still able to know the addresses of the various buffers, variables etc. inside the BSS segment.

Q2

MyClass::number is stored where the instance of MyClass class is allocated. It could be either on the heap or on the stack. Notice in Q3 how a points to an instance of MyClass allocated on the heap while localObj is allocated on the stack. Thus a->number is located on the heap while localObj.number is located on the stack.

As MyClass::number is an instance variable you cannot assign it like this:

MyClass::number = 100;

However, you can assign MyClass::counter as it is static (except that it is private):

MyClass::counter = 100;

Q3

When you call doHello the variable localObj (in main) is passed by reference. The variable localObj in doHello refers back to that variable on the stack. If you change it the changes will be stored on the stack where localObj in main is allocated.

When you call doHelloAgain the variable localObj (in main) is copied onto the stack. Inside doHelloAgain the variable localObj is allocated on the stack and only exists for the duration of the call.

Martin Liversage
Q3: References, like pointers, are 32-bit (typically) values which hold a memory address. This goes on the stack in doHello. The class "MyInstance" is 8 bytes (assuming int is 32 bit), and it goes on the stack in doHelloAgain.
Kevin Panko
+1  A: 

Q1. In Java, all objects, arrays and class variables are stored on the heap? Is the same true for C++? Is data segment a part of Heap?

No, the data section is separate from the heap. Basically, the data section is allocated at load time, everything there has a fixed location after that. In addition, objects can be allocated on the stack.

The only time objects are on the heap is if you use the new keyword, or if you use something from the malloc family of functions.

Q2. As far as my understanding goes, variables which are given a specific value by compiler are stored in data segment, and unintialized global and static variables are stored in BSS (Block started by symbol). In this case, MyInstance::counter being static is initialized to zero by the compiler and so it is stored at BSS and MyInstance::number which is initialized to 100 is stored in the data segment. Am I correct in making the conclusion?

Yes, your understanding of the BSS section is correct. However, since number isn't static the code:

MyInstance::number = 100;

isn't legal, it needs to be either made static or initialized in the constructor properly. If you initialize it in the constructor, it will exist wherever the owning object is allocated. If you make it static, it will end up in the data section... if anywhere. Often static const int variables can be inlined directly into the code used such that a global variable isn't needed at all.

Q3. Consider following piece of codes: ...

void doHello(MyInstance &localObj){

localObj is a reference to the passed object. As far as you know, there is no storage, it refers to wherever the variable being passed is. In reality, under the hood, a pointer may be passed on the stack to facilitate this. But The compiler may just as easily optimize that out if it can.

void doHelloAgain(MyInstance localObj){

a copy of the passed parameter is placed on the stack.

MyInstance localObj;
// 3.3 Where is this stored in heap or stack?

localObj is on the stack.

Evan Teran
"objects can be allocated on the stack" I agree with that, but is that the same in case of java?
Devil Jin
No, java only allocates primitives and references on the stack, not objects.
nos
+1  A: 

In C++, objects may be allocated on the stack...for example, localObj in your Q3 main routine.

I sense some confusion about classes versus instances. "MyInstance" makes more sense as a variable name than a class name. In your Q1 example, "number" is present in each object of type MyInstance. "counter" is shared by all instances. "MyInstance::counter = 100" is a valid assignment, but "MyInstance::number = 100" is not, because you haven't specified which object should have its "number" member assigned to.

Jim Lewis
+2  A: 

This is somewhat simplified but mostly accurate to the best of my knowledge.

In Java, all objects are allocated on the heap (including all your member variables). Most other stuff (parameters) are references, and the references themselves are stored on the stack along with native types (ints, longs, etc) except string which is more of an object than a native type.

In C++, if you were to allocate all objects with the "new" keyword it would be pretty much the same situation as java, but there is one unique case in C++ because you can allocate objects on the stack instead (you don't always have to use "new").

Also note that Java's heap performance is closer to C's stack performance than C's heap performance, the garbage collector does some pretty smart stuff. It's still not quite as good as stack, but much better than a heap. This is necessary since Java can't allocate objects on the stack.

Bill K
nice info about java's heap performance and c's stack performance comparison
Devil Jin
All Java objects are stored in the heap, yes. Object variables store references to them. Primitive variables (int, float, bool, etc) store their own values; they are not references. Method parameters are passed by value.
Kevin Panko
At this point I really despise the whole pass by value/reference terminology and try not to use it. In Java it's easiest just to remember that when dealing with objects, you always have a reference, you never pass the actual object. To say this is not "Pass By Reference" confuses the hell out of anyone trying to understand how the language works (even if it's true) so I've completely abandoned the terminology.
Bill K
@Devil Jin Yeah, the way Java does heap allocation doesn't require any per-allocation action to free memory for short-lived objects (which is just the way C does stack allocation--a single "return" pops all stack objects at once). There are some white papers out there that make for really nice reads.
Bill K
1 vote up. i agree
Devil Jin
+1  A: 

All memory areas in C++ are listed here

Tadeusz Kopec