Custom allocator problems

[D_Drmmr]

The idea was that different vectors wouldn't use the same allocator instance.

I understand, but the vector implementation cannot assume that. It seems very reasonable to me that when an implementation asks for two allocations without deallocating in between that it requires to receive non-overlapping memory ranges from the allocator.

[JohnW@Wessex]

I think what really bugs me is that, as my allocators used to work OK under VS2008, it must be possible to produce an STL container that is compatible with allocators that contain their own storage.

BTW My original allocators worked with raw byte storage, aligned to the type, rather than an array of actual objects that my simplified example used.

[superbonzo]

I think what really bugs me is that, as my allocators used to work OK under VS2008, it must be possible to produce an STL container that is compatible with allocators that contain their own storage.

actually, the issue in c++03 was even worse because implementations were allowed to always consider equal allocator instances of the same type ( copy constructed or not ). So, even an allocator storing a pointer to an external arena was at least non portable in c++03.

anyway, an easy workaround to adapt your existing code to work with vs2010 is to make the allocator fallback to the heap when constructed from an allocator of different type (eg. the template copy constructor). Given that auxillary allocators are used for debugging purpose only ( at least in std::vector and std::list, I'm not sure for set/map ) you should recover the expected stack-only allocation behavior on release builds.

Clearly, this solution is not portable ...

[JohnW@Wessex]

anyway, an easy workaround to adapt your existing code to work with vs2010 is to make the allocator fallback to the heap when constructed from an allocator of different type

Unfortunately, that goes against my design requirements. Although the code is compiled and run on Windows for simulation purposes, the final application runs on a DSP platform with a lot less resources.

The object was to create an efficient allocator that could be used for STL containers on a memory restricted, time critical platform. The fixed storage overhead needed to be defined and placed in specified memory regions at compile time.

This would be especially useful when using std::list and other such containers where the storage cannot normally be reserved upfront.

[monarch_dodra]

You guys have me kind of lost, so I might be saying something stupid. The problem only occurs when objects from one container are swapped to another container that uses a different allocator, right?

Rather than re-code entire containers, isn't it possible to explicitly compare the allocators outside of the containers, and swap by value if the allocators are different?

Maybe stl containers don't explicitly support this, but that doesn't mean you can't add the support yourself explicitly via a new traits?