What about copy constructors, using the class in STL list types, getting the class on the stack? All of these are lost (and / or become bug prone) if you start doing junk like this.

On copy constructors, how does Pimpl interfere with them? Observe:

It is a simple matter of invoking the copy constructor for the implementation class/struct. Just as you would for any data member held in a pointer.

Personally, I work with everything by pointer. Rather, by boost::shared_ptr. This is because I would rather code than debug memory leaks. So I rarely have need to invoke a copy constructor for most classes.

As long as the class has a functioning copy constructor, you can use it in an STL container quite reasonably. As for putting it on the stack, what is stopping you?

The object itself would be on the stack; its true contents would not.

I would also like to point out that for games, most objects are not suitable for stack objects. Some objects are, like utility classes; matrices, vectors, etc. But objects of significant importance like images, entities, sounds, GUI windows, and so forth are not appropriate stack objects.

So I would suggest that the need to put all of the memory of such objects on the stack is not so great in most cases.

I'm quite the opposite: I do not like it when any object is copied, because it takes up performance. Often needlessly. I pass just about everything by smart pointer or const&.

I wait in breathless anticipation for C++0x and it's "move constructor" &&.

The class being on the stack means that it will be automatically destroyed. So long as the constructors allocate memory, and the destructors deallocate memory correctly, you have 0 memory leaks. It is always better to wrap a bare pointer in some kind of object, whether a Pimpl class, shared_ptr, or something else.

Copy constructor overhead will kill performance a lot faster than not being in stack memory. The copy constructor for every STL container will perform at least one memory allocation, so you lose any of the malloc/free advantage.

I'm afraid you have misunderstood my point.

If you use stack objects directly and nearly exclusively, your code will necessarily pass objects by value more frequently than code that uses pointers or other forms of references often. I previously stated that my style of programming does not use the copy constructor at all for most objects. By passing objects by reference as a matter of course, I avoid any unintentional copy operations. That means that your code will use the copy constructor more frequently than mine.

As an example, std::vector is often maligned for its brutal performance when resizing a vector. It must copy all of its elements to a new location when it resizes itself. After doing so, it will destroy the initial array.

Under your programming style, a list of entities would be stored in a std::vector<Entity>If vector<Entity> needs to reallocate its memory, it will provoke the copy constructor on a number of Entity objects, then destroy the originals. If your Entity object stores a lot of other objects, like a list of BITMAPs, SAMPLEs, or other things, each of them will need to be copied using the Allegro or otherwise API. These are not fast operations and all of them will involve memory allocation. The destructor will have to delete these objects as well.

In my case, I would store a std::vector<boost::shared_ptr<Entity> >, which is a much lighter-weight class. Even though my Entity class would be Pimpl-ed, and a deep-copy constructor would cause an extra allocation, no such operation happens in this case. The shared_ptr class's copy constructor copies the internal pointer and bumps a reference count. The destructor decrements a reference counter. The previous increment of the counter guarantees that the reference count will not hit zero and provoke an actual destructor.

Another point. If the allocation overhead for the interface class ever becomes onerous, I can always override operator new/delete on the class to use an pool allocator. The size of the interface class will always be the size of one pointer if it has no virtual members. This makes memory allocation time nil for all practical purposes.

I think your problem with Pimpl stems from your personal unwillingness to use references or pointers. You have designed a specific style of coding around this limitation. The problem isn't that Pimpl is bad; the problem is that you should not use the rest of your coding style with Pimpl. Just like a C programmer working in C++ should not pretend that classes do not exist.

Again there seems to be some miscommunication. Allow me to return to the beginning.

You pointed out that a Pimpl class cannot "be put on the stack" because its true contents are not on the stack. The contents are not in "prime high-speed memory" that "removes any malloc / free overhead".

This is not true on several levels.

If you have a class:

class NotOnTheStack
{
private:
  std::vector<Something> m_notStack;
};

The actual list contents of m_notStack are exactly as named: they are not on the stack. If you store any kind of STL container in a class, the true contents of that container are not in "prime high-speed memory", nor does it "remove any malloc / free overhead". The STL class will still allocate memory on the heap.

Some might even say that class NotOnTheStack is very similar to a Pimpl'd class.

The only way you can get a list on the stack is to make it a static list, like this:

class OnTheStack
{
private:
  Something m_stackVar[20];
};

So not Pimpl'ing a class is no guarantee of avoiding malloc/free overhead. The only way to do so is to only ever use static lists. This limits the flexibility of a design.

Another problem is that stack memory is not "prime high-speed memory" at all. It is just memory, no different from heap memory.

What stack memory is is more likely to be cached. But even that has its limits. If you put a large object on the stack, you will likely be using parts of the stack that are not in the cache.

The likelihood of the stack to be cached also depends on how much the stack is used. If you use a very small stack, it will not take up much room in the cache. This leaves plenty of room for frequently accessed objects.

If you use a lot of stack memory, it will likely be cached. If you use little stack memory, you have more cache room for heap memory. The cache works for the code either way; it will store whatever it is that you frequently use. But stack memory itself is not faster by the virtue of being stack memory.

I would also like to take this opportunity to point out the following: Pimpl is not something I invented. It is in use in the world. It is not exactly common, but it is far from rare to see code employ Pimpl. FreeType, a C library, uses Pimpl. Allegro uses a degree of Pimpl by hiding implementation details of an object behind a driver. And the new Allegro API will go further than that. Others have mentioned that KDE, one of the two desktop systems for Linux, employs Pimpl.

What I'm saying is that there are a lot of lines of Pimpl'd code that gets used every day. Pimpl does not need to be proven or supported. It has a track record that speaks for itself.

You don't have to use it or even like it. I didn't much care for it until I worked on a project with so many header inclusions that it took an hour to recompile just for touching certain header files. But you should respect it as a valuable tool for solving programming problems.

It is a tool that has its uses. If you don't think you need it then fine, don't use it. Just don't think that it doesn't have any use what so ever.

Stack is just more likely to be cached as it lives in the same area where code does, that is all the difference there is. Once the data is cached there is no speed difference what so ever.

Also as Neil pointed out, most STL objects don't have their data in stack anyway.

I'm just wondering, has anyone actually made some real-life benchmark on stack vs heap data. Sure, initial loading will be much slower for heap but if your variables are used frequently they'll be in caches for most of the time anyway and if they are not used frequently then the slowdown they cause is insignificant.

Just think of Pimpl as a way to trade very little runtime performance for great compile time speedups.

How much classes are stored in heap anyways, most stuff lives in containers and they are certainly not in heap. I tried to think of a few examples but for my current program there are almost no heap classes at all, at least not the ones that are used often.

So, have you actually tried using it?

You have a very silly religion-esk style of arguing. To improve your point you surround it with unrelated points and you believe this somehow makes your argument stronger.

What does me and my level of arrogance have to do with any of this?

I find your conversational skills annoying.

Here is your first paragraph, separated into two chunks.

Now here is a quote from my last post.

An exercise for the reader: Why would I post this quote again?

Moving on, the burden is on you to make logical arguments that are logical and follow proper flow. You can easily demonstrate that you do not use this cheap trick by refraining from doing the cheap trick. Clearly, this is too hard for you.

I would ask you to please demonstrate that you know what you're talking about but to be honest I think your response would be a boring post to read, so I wont.