Pass nullptr to CustomVector

[Nils Deppe]

Hi Klaus,

I'm not sure if this is a bug/feature request/open ended question but I'd like to be able to pass nullptr to a CustomVector. Is there any reason why this cannot be done? Naively it seems like a bit of an artificial limitation, since setting a shared_ptr to nullptr is reasonable in other circumstances. Another question, why shared_ptr and not a raw pointer? I would like to live on the edge and not pay for the overhead of a shared_ptr... Maybe the answer is that there should be two (or more) different types of CustomVectors.

Anyway, I'd like to hear your thoughts behind this design because I would prefer something a little leaner and freer (I know it's more dangerous, and I'm willing to use ASAN if I get trouble :) ).

Best,

Nils

[Klaus Iglberger]

Hi Nils!

Thanks for raising this issue. Since you have two separate questions, please allow me to answer them separately.

For the first part of your question: You are correct, it currently isn't possible to pass a nullptr to a CustomVector. The reason is that the interface allows you to express this in a different way:

CustomVector<double,unaligned,unpadded> vec;  // Default constructed custom vector with a size of 0

vec.clear();  // Clearing the custom vector to a size of 0 and resetting the internal shared_ptr instance

Using either of these two functions has the same effect as passing a nullptr and the size of 0, but is cleaner (you don't have a dependency between these two values) and easier. We believe that given these two functions it is not necessary to allow for passing a nullptr and checking for the correct size.

As for the second part of your question: We would also prefer to have a CustomVector with a raw pointer data member. In fact, the initial design of CustomVector used a raw pointer. However, we unfortunately encountered a lot of problems with this design, both technically as well as semantically. Although a raw pointer sounds like the most simple thing to do, it is surprisingly complex. Still, I will try to give you an impression.

First of all, it's important to understand that in Blaze all vector and matrices are value types, i.e. they have regular copy semantics. Initially we tried this with CustomVector as well, but realized that this is semantically and technically not possible. In order to implement regular copy semantics, in its copy constructor, CustomVector would have to allocate memory by itself (the raw pointer must not be copied, else two objects would refer to the same piece of memory). However, semantically, this is not the expected and desired behavior, since CustomVector is supposed to refer to a specific piece of memory, i.e. it should never allocate by itself. From a technical point of view this is not a solution either, since due to copy elision you might end up with no memory allocation, pointer aliasing and subsequently segmentation faults.

The alternative to regular copy semantics is shared semantics: A CustomVector, which has been made a copy of another CustomVector via copy constructor or copy assignment, refers to the same piece of memory. During testing we realized the enormous limitations of a CustomVector, which holds a raw pointer to some memory and never owns. We shortly tried to prohibit copy construction (the problematic operation), but ended up with a class for only a small number of use cases (we might have called this ScopedVector).

In summary, we liked the current solution the best. It is universally applicable (i.e. supports many use cases), does not have performance disadvantages during algebraic operations (e.g. matrix-vector multiplications), and with that provides the most value for the users of Blaze.

Eventually we might add something like a ScopedVector (it is already on our list of possible features), but currently there are unfortunately too many more important issues. I hope this explains the rational of our design decision,

Best regards,

Klaus!