delete[]

Destructors should not do anything though except to free up resources that have been allocated. This includes unlocking mutexes. If pthread_mutex_unlock() returns an error ignore it.

If you really have to give a warning, ensure that giving a warning is an exception-safe action.

A destructor on a database transaction should ALWAYS rollback. It is against the nature of a destructor to commit it.

You may decide to have a wrapper class that, in one step, will commit the transaction then delete the transaction object. But that would not be a destructor.

I don' tknow why, when you are talking about smart pointers, you mean reference counting smart pointers, don't you? I know, they are useful, but actually home made, naive implementations are much slower than GCs[1] and as stated above, they have problems with reference cycles. Some GCs also use smart pointers, so if you don't like GC in some part of your code, you just use RAII with new/delete and there is no problem.

1. RAII is nice pattern, especially when you have objects allocated on the stack. But with heap allocated ones I can see one problem: what happens if you forget to call delete (or an exception is raised)? You've got a difficult to debug resource leak. So you must be really careful.

2. And now, let's consider you have a GC. You define a method in the object that does what the destructor would do and name it e.g. "dispose". You also define a destructor, that checks if dispose() was called and if not, it issues a warning and calls it. Of course, you manually call dispose just before you don't need the object anymore, so that it is disposed as early as possible. This would work just as well as in point 1. with exception that if you forget to call dispose(), you WILL surely know it, and you've got a chance to debug, which object it was.

Of course this concerns only resources that must be disposed as early as possible. For other objects (majority[2]), if you have GC, you just don't need destructors.

[1] Hans Boehm "Memory Allocation Myths and Half-Truths" << It's really good. Read it :) This guy is a real expert.
[2] We work on a Java project that is now more than 400 classes large, and there are only a few classes that require deterministic destruction.

My largest gripe about garbage collectors is that they don't work well (i.e. they greatly complicate) real-time systems. You have to worry about how long collection will take, the priority of the GC thread if it runs in a seperate thread, etc.... GC has its place. But it doesn't belong everywhere.

Quote:

---

Originally Posted by marten_range

The heap, as well as a disk, may become cluttered with many small pockets/holes of memory that doesn't quite fit an object but still takes memory. GCs usually can defragment heaps and remove such pockets.

---

Quote:

---

Originally Posted by marten_range

A place where GC doesn't quite deliver is when the GC is run by a another thread (most implementations is like that).

---

I was talking about using a GC in C++ application (not in a managed language such as C# or Java).
And GC cannot compact data if the data structures are not clearly defined, so with C++ GC are conservatives (that is, every DWORD in memory is considered as a pointer).
And it cannot compact.

And for thread safety reasons, the GC cannot collect garbage in another thread.

I don't doubt that a managed language can be fine.

In fact, in all my projects that used reference counting, it was explicit reference counting:
That is, some relatively big objects which needed some reference counting were derived from a class like that:

Code:

---

class TAutoObject
        {
  private:
  DWORD cRefs;
  TAutoObject(const TAutoObject &);
  void operator=(const TAutoObject &);
  public:
  void AddRef() {++cRefs;}
  void Release()
          {
      if (--cRefs==0) delete this;
      }
  protected:
  TAutoObject():cRefs(1) {}
  virtual ~TAutoObject() {}
  };

---

And i used AddRef at a few locations in my code, when a new strong reference was truly needed.
Because my objects belonged only to one thread, AddRef/Release did not need to be thread safe.

The only thing that could really slow my application, is the fact that such reference-counted objects uses 4 bytes for each objects (generally my objects were using at least 12 other bytes).

So reference counting can be very fast, combined with a good memory allocation routine (VC++ uses a really slow malloc, but there are some other allocation routines available on internet).

A good GC can also be very fast.

I can't agree with statement that GCs are not suitable for real-time applications. It was right perhaps 10 years ago. Nowadays there are some real-time implementations for C++. I know at least 3: BDW in incremental mode, RTGC and my SMEIL.

It is also not true, that GC cannot run in a separate thread. Actually most of GCs for C++ do it this way. Another myth is that GC must stop users's threads for a time of collection. It depends only on the collection algorithm. There are algorithms that can run concurrently or can be stopped and resumed in the middle of the collection cycle. Modifications of pointer values while collecting garbage also don't spoil anything. Of course there is a little overhead if compared to traditional blocking collectors, but this overhead is usually less than a few percent.

A problem with reference counting is thread-safety. If you write a single-threaded implementation, probably it can be only little slower than best real-time GCs. You still have to copy additional pointer, increase, decrease counter and check a condition per every pointer assignment. In thread-safe reference counting is worse, because you need to do interlocked increment and decrement. These usually need calling system functions, and are slower even more (if you do it with mutexes, you can get hundreds times slower - so don't do it like that).

In SMEIL for example, the only overhead is copying additional 4B field and setting a flag, which takes not more than 20% of time for reference count update. And it is thread-safe.

Heap fragmentation myth is fortunately only a myth. Size of heap hardly ever exceeds 150% of required memory size in good, native allocators [1]. So using a heap that is twice as large as needed [2] right from the start to fight fragmentation in managed environments like C# or Java is a bad idea of saving memory. It is done to speed up the allocation process, not to save memory.

What is the most advantage of GCs C++ over GCs in Java/C# is that C++ applications produce much less garbage. Most of short living objects live on the stack, and don't slow down the collector.

[1] According to Boehm's measurements.
[2] At least half of the heap is never used in Java.

Quote:

---

Originally Posted by pkolaczk

What is the most advantage of GCs C++ over GCs in Java/C# is that C++ applications produce much less garbage. Most of short living objects live on the stack, and don't slow down the collector.

---

That is right, C++ uses less pointers to tiny objects, and it is probably the reason why conservative GC in C++ is not slower than GC in managed languages as said Boehm.

Quote:

---

Originally Posted by pkolaczk

I can't agree with statement that GCs are not suitable for real-time applications. It was right perhaps 10 years ago. Nowadays there are some real-time implementations for C++. I know at least 3: BDW in incremental mode, RTGC and my SMEIL.

---

Interesting. I'll have to take a look at those 3 in case I do need them in the future.

However, if you take another look at my post, I said that using GC's are more complicated in a real-time environment, not that they couldn't be used. They complicate things, because (a) you're not sure how long a particular collection will take [a concern if you don't run the GC in a seperate thread] and (b) if you run the GC in a seperate thread, you have to think about the thread priority of the GC thread and how it relates to other thread's priorities. I've usually found it easier with the applications I've dealt with anyway, to avoid GC's altogether. But maybe the 3 GC's mentioned will help alleviate the issues I have.