RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Good Parasite Class Explained : Page 2

A good parasite class promotes the use of objects that are never destroyed, a controversial notion in C++. So why use it? What other advantages does it offer? Can you declare additional member functions in such a class? The inventor of the good parasite technique explains.


Q. Why Do You Consider std::vector a Bad Choice for Implementing a Self-Recycling Buffer?

A. Although you can get by with std::vector, it's not an ideal choice for this specific task for three reasons:

  1. Allocation time. The self-recycling buffer's size is fixed and known at compile-time. From a performance and an exception-safety standpoint, deferring the buffer allocation to runtime is pointless.
  2. Space. The std::vector template incurs considerable memory overhead (32 bytes on my compiler), which you can eliminate completely by using a raw memory buffer or the std::array template. Recall that the main application engine may launch thousands of threads, each with a unique buffer. Under these circumstances, you cannot justify the space overhead of std::vector. In some cases, it's simply unacceptable.
  3. Ownership. The std::vector template owns the buffer, which means the buffer is unconditionally destroyed when the vector is destroyed. In most cases, this is well-intended—unless you want to decouple the raw memory buffer from the object that manipulates it, which is exactly what the good parasite does.

Q. How Can You Claim That vector::clear() Causes Reallocation When clear() Doesn't Change the Capacity of Vector?

A. I stand corrected. Several members of the C++ standards committee who read the 10-Minute Solution have pointed out to me that the C++ standard guarantees—albeit in a very indirect way—that clear() doesn't change the capacityof its vector; it changes only the vector's size.

However, the committee members all agree that the current phrasing of the standard is underspecified in this respect. They propose that the standard should explicitly guarantee that no reallocations will occur as a result of calling clear(). In spite of that, I still find std::vectora poor choice for implementing a fixed-size buffer for the reasons listed above.

Q. Does C++09 Really Tolerate Types That Can Never Be Destroyed?

A. Most committee members reluctantly agree that the addition of deletedprivate destructors to C++09 effectively ushers in types that have no callable destructors. Here's the chain of reasoning: C++09 supports deleted destructors. –> The program can never call a deleted destructor. –> A class that declares a private deleted destructor is practically indestructible, at least not in the conventional way.

Q. In Your Example, You Construct a New Object Over and Over Again on the Same Memory Address Without Ever Destroying the Previous Objects. Is This Valid C++?

A.I admit that the ice is thin here. C++ is rather strict about object lifetime issues, but the good parasite is an unusual beast. Since there's nothing to destroy, you don't really need to destroy the previous object before you construct a new one on top of it. More specifically, as every new object incurs zero space overhead, you're not risking memory leaks. Because the good parasite doesn't own any resources either, there's no risk of resource leakage or race conditions. Recall that the usage of a good parasite is very restricted. For instance, you cannot create arrays of such objects nor can you store them in STL containers.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date