Re: [eigen] Malloc-free dynamic matrices

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

Hi Leon,

On Fri, Mar 5, 2010 at 12:10 PM, leon zadorin <leonleon77@xxxxxxxxx> wrote:
>> If some want MatrixXf to have memory caching/reservation and don't
>> mind extra flags; whilst others don't want extra flags -- what are the
>> reasons for not simply having a template type/policy called
>> MemoryAllocator which will be used by MatrixXf (similar to STL/::std
>> types using allocators)...

At this point, it is hardly possible to follow this path. It would
require enormous changes within Eigen which we will not be able to
apply before 3.0 and more importantly it is not really that simple
since currently parts of Eigen's allocation strategy is controlled by
the template parameters of Matrix/Array. One example being alignment -
we have plenty of algorithms that chose at compile time control paths
depending on the alignment. IIRC, standard allocators as provided by
the STL do not offer flags or other ways to determine alignment at
compile time.

> Because, even if a given basic Allocator is an empty class (i.e. no
> data members whatsoever), the 1st case will use extra 1 to 8 bytes of
> memory (i.e. in C++ a complete object cannot have size 0), but in
> second case an EBO (empty-base-optimization) will be automatically
> used by the compiler to guarantee that 0 extra bytes are associated
> with an given empty (e.g. all static methods) Allocator sub-type
> -object.

We are well aware of this fact and it is once more a little bit
tricky. First, we rely on a specific inheritance structure to get the
expression templates working and in order to make Eigen extensible
without minimal effort. Our inheritance tree also reflects (at least
to some extent) how data is stored -- i.e. you cannot simple inject
the allocator somewhere within the inheritance tree. Multiple
inheritance on the other hand side is also not an option because e.g.
MSVC fails to perform proper EBO in the presence of multiple
inheritance.

Regards,
Hauke