HOW TO IMPLEMENT GARBAGE COLLECTION IN C++

From How to implement garbage collection in C++.

Garbage collection in C and C++ are both difficult topics for a few reasons:

• Pointers can be typecast to integers and vice-versa. This means that I could have a block of memory that is reachable only by taking an integer, typecasting it to a pointer, then dereferencing it. A garbage collector has to be careful not to think a block is unreachable when indeed it still can be reached.
• Pointers are not opaque. Many garbage collectors, like stop-and-copy collectors, like to move blocks of memory around or compact them to save space. Since you can explicitly look at pointer values in C and C++, this can be difficult to implement correctly. You would have to be sure that if someone was doing something tricky with typecasting to integers that you correctly updated the integer if you moved a block of memory around.
• Memory management can be done explicitly. Any garbage collector will need to take into account that the user is able to explicitly free blocks of memory at any time.
• In C++, there is a separation between allocation/deallocation and object construction/destruction. A block of memory can be allocated with sufficient space to hold an object without any object actually being constructed there. A good garbage collector would need to know, when it reclaims memory, whether or not to call the destructor for any objects that might be allocated there. This is especially true for the standard library containers, which often make use of std::allocator to use this trick for efficiency reasons.
• Memory can be allocated from different areas. C and C++ can get memory either from the built-in freestore (malloc/free or new/delete), or from the OS via mmap or other system calls, and, in the case of C++, from get_temporary_buffer or return_temporary_buffer. The programs might also get memory from some third-party library. A good garbage collector needs to be able to track references to memory in these other pools and (possibly) would have to be responsible for cleaning them up.
• Pointers can point into the middle of objects or arrays. In many garbage-collected languages like Java, object references always point to the start of the object. In C and C++ pointers can point into the middle of arrays, and in C++ into the middle of objects (if multiple inheritance is used). This can greatly complicate the logic for detecting what's still reachable.

So, in short, it's extremely hard to build a garbage collector for C or C++. Most libraries that do garbage collection in C and C++ are extremely conservative in their approach and are technically unsound - they assume that you won't, for example, take a pointer, cast it to an integer, write it to disk, and then load it back in at some later time. They also assume that any value in memory that's the size of a pointer could possibly be a pointer, and so sometimes refuse to free unreachable memory because there's a nonzero chance that there's a pointer to it.

As others have pointed out, the Boehm GC does do garbage collection for C and C++, but subject to the aforementioned restrictions.

Interestingly, the upcoming C++0x standard will include some new library functions that allow the programmer to mark regions of memory as reachable and unreachable in anticipation of future garbage collection efforts. It may be possible in the future to build a really good C++ garbage collector with this sort of information. In the meantime though, you'll need to be extremely careful not to break any of the above rules.

NEED A COPY CONSTRUCTOR

Let's look at the following example:

#include <iostream>

using namespace std;

class Student 
{
public:
 int id;
 char *name;
 Student() 
 {
  id = 0;
  name = "";
 }
};

int main() 
{
 Student student1;
 student1.id = 10;
 char nm[] = "Clinton";
 student1.name = nm;

 Student student2 = student1;
 student2.name[0] = 'P';
 cout << student1.name; // Plinton
 return 0;
}

As shown in the example, we made another instance of Student class which is student2 from an existing instance student1. However, later we modified an element of the name array. It turned out that modifying a field of one instance can affect the other instance, and that's not we wanted.

So, to control the assigning operation, we need our own copy constructor not the default copy constructor that compiler provides:

#include <iostream>

using namespace std;

class Student 
{
public:
 int id;
 char *name;
 Student() 
 {
  id = 0;
  name = "";
 }

 Student(Student &s)
 {
  id = s.id;
  name = strdup(s.name);
 }
};

int main() 
{
 Student student1;
 student1.id = 10;
 char nm[] = "Clinton";
 student1.name = nm;

 Student student2 = student1;
 student2.name[0] = 'P';
 cout << student1.name << endl; // Clinton
 cout << student2.name << endl; // Plinton
 return 0;
}

Note that strdup() in our own copy constructor does dynamic memory allocation for the character array including the end character '\0' and returns the address of the heap memory. In other words, the new instance has its own memory to store the name not shared one with which it was instantiated from.

Learn object oriented databases

Learn about Object Oriented Databases from following:

http://www.odbms.org
http://www.comptechdoc.org/independent/database/basicdb/dataobject.html
http://www.artima.com/lejava/articles/javaone_2008_anat_gafni.html
http://en.wikipedia.org/wiki/Object_database

Object Oriented Modeling and Design

e-Notes	Topic	Subject Experts
Unit 2 & 5	Advanced Class Modeling, State Modeling & Application Analysis, System Design	Prof.Raghuveer, NIE, Mysore.
Unit 1 & 4	Introduction, Modeling Concepts, Class Modeling & Process Overview, System Conception, Domain Analysis	Prof.Annapurna Patil, MSRIT, B'lore.
Unit 7 & 8	Design Patterns 1-2 & Idioms.	Prof.Radika K, BMSCE, B'lore.
Unit 3 & 6	Advanced State Modeling, Interaction Modeling & Class Design. Implementation modeling, Legacy Systems.