Click to See Complete Forum and Search --> : Some Questions


veer_elluri
July 19th, 2005, 05:08 AM
Hai...

I have some qutions in C++, Please can anybody clarify that?

1) How to control the Memory leaks in C++

2) How to Determine the function is a virtual function in the class(not using virtual key word)
3) When do we over ride the Copy constructor.

4) does memory and size is assigned to the 'this' operator?

5) What is the main Difference between distructor and virtual distructor?

exterminator
July 19th, 2005, 05:30 AM
How about using google or even a search on Codeguru for tutorials, FAQs and threads in various forums?The keywords you should use for the search are - Memory leaks in C++, Copy constructor, 'this' pointer, virtual function, v-tables, destructor and virtual destructor.Here are some links to some of the topics that you are looking answers for:
1. Detecting a Memory Leak (http://msdn.microsoft.com/library/en-us/vccore98/html/_core_detecting_a_memory_leak.asp)
2. Leak Tracer (http://www.andreasen.org/LeakTracer/)
3. New and delete operators (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_the_new_and_delete_operators.asp)
4. The 'this' pointer FAQ (http://www.codeguru.com/forum/showthread.php?t=343480)
5. Difference between delete and delete[] FAQ (http://www.codeguru.com/forum/showthread.php?s=&threadid=231044)
6. Virtual functions FAQ (http://www.codeguru.com/forum/showthread.php?s=&threadid=256624)
7. Virtual destructors (http://www.codersource.net/cpp_virtual_destructors.html)
8. Pure virtual functions/destructors (http://www.gotw.ca/gotw/031.htm)

About controlling memory leaks - flawless design, coding should be done responsibly and proper usage of new-delete and new[]-delete[]. You can get many articles discussing about sources of leaks, effects, controlling measures, detecting tools and measures.
We override the copy constructor. Read up about shallow copies and deep copies of objects.
As for finding a way to determine if a function is virtual or not - cannot comment. Don't know if this is possible except for going into the class definition or documentation and seeing from there.

Hope this helps. :thumb:

Bob Davis
July 19th, 2005, 05:42 AM
1. You control memory leaks by only dynamically allocating memory when you have a good reason to. Many people, especially those who switch from Java to C++, think that you have to use "new" to allocate everything, or that it is the best way to create objects. C++ programmers do exactly the opposite; "new" is only used when other methods of creating objects won't do the job. For dynamic storage of objects, std::vector and the other STL classes provide high-performance, safe management of dynamic memory.

2. I'm not sure what you're asking. Are you wondering if there is a way to tell inside the body of a class's function whether the function is virtual or not? If so, no, there is not.

3. There is a "rule of 3" that should be followed in most cases. If you are in a case where you need either a destructor, copy constructor, or assignment operator for you class, then you probably need all 3. You would overload these if your class held some sort of resource (dynamic memory, semaphores, open files, etc.) that you need to release somehow at the time of destuction of your object. The destructor is the logical place for this code, but your object's contents can also be overwritten by the assignment operator and your object's contents can be transferred to another object by the copy constructor, so you need to handle these cases also. For instance, if your object has a chunk of dynamically-allocated memory that it owns, you'll probably want to make a fresh copy of the memory inside the copy constructor so the new object doesn't own the same chunk.

4. I'm not sure what you're asking.

5. The same difference between any virtual and non-virtual function. Virtual functions can exhibit polymorphic behavior; that is, you can call functions using a base class pointer and the correct derived implementation will be called.

NMTop40
July 19th, 2005, 06:00 AM
1) How to control the Memory leaks in C++


Use RAII. Learn about different types of smart pointers and use them wherever preferably over raw pointers (whenever you allocate a pointer with "new"). Prefer std::vector to arrays and std::string to char *.

You can also use smart-pointers and RAII to control resource leaks. These can occur when there is a matching "close" function to be called after an "open" function.

2) How to Determine the function is a virtual function in the class(not using virtual key word)

You can look in the header of its base class (all the way up the hierarchy). You must have those header files.

Another alternative (not as good) is to write a class derived from that class and attempt to call the function through polymorphism. See if it calls your overload or the base-class version.


3) When do we over ride the Copy constructor.

Normally you need to overload the default copy-constructor when a member-by-member copy is not the desired behaviour. This will often happen if your class contains a member pointer (even a smart pointer) and you actually want a copy to produce a "clone" of the pointer, i.e. a copy of the object it points to rather than another pointer to the same object. (It is better to use a COW smart-pointer though which removes the need to overload in this case).

Whenever you need to overload the default copy-constructor, you usually need to overload the destructor and the operator=() (assignment). You can disable copy-construction and assignment by declaring them in the private section of your class. (No implementation necessary).

4) does memory and size is assigned to the 'this' operator?

I don't quite understand the question but you can do sizeof( *this ). If "this" is a pointer to a base class, I think sizeof( *this ) will give you the size of the base class not the derived class, i.e. it's not a polymorphic operation.

5) What is the main Difference between destructor and virtual destructor?
A virtual destructor will pass through the hierarchy, deleting all derived classes before deleting itself. Note that unlike other virtual functions, all the destructors are called (with the most derived class first). No other virtual functions can be called from the destructor.

exterminator
July 19th, 2005, 06:59 AM
I don't quite understand the question but you can do sizeof( *this ). If "this" is a pointer to a base class, I think sizeof( *this ) will give you the size of the base class not the derived class, i.e. it's not a polymorphic operation.NMTop40, I guess he is asking if there are any memory allocations done for the this operator..basically he is, I guess making a mistake by even calling the this as an operator rather than a pointer. And then he is asking what size if allocated for it.

So I guess the answer he is looking for is - this is a pointer not an operator. you can find the size of the this pointer by using sizeof operator on this i.e. sizeof(this). About the storage location. I guess its the stack or heap depending upon the way the object pointed to by this is created. Correct me if I am wrong here. :thumb:

RoboTact
July 19th, 2005, 08:32 AM
Or it may be register. It doesn't matter. In some cases this pointer may even not be passes anywhere. As well as any other parameter. So it may be considered just one more (implicit) pointer parameter.

NMTop40
July 19th, 2005, 08:50 AM
sizeof(this) will always be the size of a pointer (4 on a 32-bit 8-bits-to-a-byte system).

There's obviously no way to find out how much memory has been subsequently allocated from the class (eg if there are member pointers allocated with new).

exterminator
July 19th, 2005, 09:58 AM
sizeof(this) will always be the size of a pointer (4 on a 32-bit 8-bits-to-a-byte system).Is this for sure? Then why do function pointers take up greater bytes (sometimes 4, 8, even 12). (This question relates information from this thread - Void pointers + const + volatile (http://www.codeguru.com/forum/showthread.php?t=349006)) . SuperKoko here says something about displacement. I did not quite get the meaning. I would be posting this question there itself. please bear with me. Thanks. :thumb:

RoboTact
July 19th, 2005, 10:42 AM
this is pointer-to-object.

NMTop40
July 19th, 2005, 10:56 AM
Is this for sure? Then why do function pointers take up greater bytes (sometimes 4, 8, even 12). (This question relates information from this thread - Void pointers + const + volatile (http://www.codeguru.com/forum/showthread.php?t=349006)) . SuperKoko here says something about displacement. I did not quite get the meaning. I would be posting this question there itself. please bear with me. Thanks. :thumb:

pointers to functions don't have to be the same size as pointers to data. That is why it is undefined behaviour to cast a pointer to a function to void* and vice-versa.

Note therefore that you should not use dlsym() to get a pointer to a function, but instead get your shared-object libraries to always return pointers to objects if you want to be safe (and use them for dynamic loading).

GetProcAddress() is slightly safer in that it returns a more abstract FARPROC handle, which suggests a pointer to a function.

exterminator
July 19th, 2005, 10:57 AM
this is pointer-to-object.Yes RoboTact :) , I understand that. I also apologized for raising my question as in my last post in this thread. I have posted in the other thread of which i gave the link above. My question was related to function-pointers, not the this-pointer. Sorry, If i did not sound clear. :(

exterminator
July 19th, 2005, 11:01 AM
pointers to functions don't have to be the same size as pointers to data. That is why it is undefined behaviour to cast a pointer to a function to void* and vice-versa.

Note therefore that you should not use dlsym() to get a pointer to a function, but instead get your shared-object libraries to always return pointers to objects if you want to be safe (and use them for dynamic loading).

GetProcAddress() is slightly safer in that it returns a more abstract FARPROC handle, which suggests a pointer to a function.Yes, I did come to know about this in the above mentioned thread. And I posted my latest doubt on that thread only. NMTop40, thanks anyways. You are always informative :) . :thumb: