Re: Circumventing __USE_MALLOC and templatized containers

[Wolfgang Bangerth <wolfgang dot bangerth at iwr dot uni-heidelberg dot de>]

> > use. That's why I asked how people solve these problems?
> 
> Thanks.  Imho, the need to replace allocators has been
> underestimated or even neglected.  I've had this problem
> too and found no satisfactory solution: it is not possible
> to replace the (default) allocator without practically
> having to rewrite the STL and ending up with a totally
> incompatible set of STL containers etc.

That's my opinion as well. I am led to think that this wholesale
replacement of one allocator by another is not what was intended.
In my view, selecting between malloc-based or other allocators should be
possible either by a mechanism like __USE_MALLOC, or, as I understand the
ABI concerns that were raised, by a special flag that is set once per
program execution.

For example, it is conceivable that the default allocator checks a global
variable indicating which method of memory allocation to use. Of course,
for proper operation, this variable has to be set once upon program start
and must not be modified during run time. Since therefore setting it at
run-time is not an option, one possibility would be to give a special flag
upon linking which generates a static variable with a value indicating
the allocation method. The right place to do so would probably be at the
location where libstdc++ is added to the linker line.


> In my case I fortunately only needed a very limited
> number of variations (I only store 'char' in the containers),

The library I maintain (deal.II) uses them with more than 50 different
types, many of which are themselves templatized, so this makes...

> so I "solved" things by creating non-templated types like
> 
> typedef ::std::basic_string<char, ::std::char_traits<char>,
> internal_allocator> internal_string; 

...this rather unpracticable.


> however, I also used
> 
> template <typename T>
>   struct internal_vector : public ::std::vector<T, typename internal_allocator::rebind<T>::other>
>   { };
> 
> only using the default constructor of internal_vector
> anywhere else in my application.

But that's a serious limitation and doesn't allow the use of these
containers with the standard algorithms.

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth          email: wolfgang.bangerth@iwr.uni-heidelberg.de
                             www: http://gaia.iwr.uni-heidelberg.de/~wolf