Alpaka: Provide default constructors for BufCpu and the like

[krzikalla]

We have a class, which provides a view to alpaka-allocated or user-allocated (runtime decision) memory.
If user-allocated memory is used, then the member holding the alpaka-allocated memory can't be initialized.

Current workaround:

class A 
{
  using HostBufferType = decltype(alpaka::mem::buf::alloc<T, size_t>(...));
  std::unique_ptr<HostBufferType> hostBuffer_;  // default constructible
}

I want to get rid of the std::unique_ptr. Solution is easy, just introduce a BufCpu() = default;
Same for BufCudaRt and maybe other similar classes.

[BenjaminW3]

From my point of view adding a default constructor only hides one problem and creates many new problems.
What is a BufCpu that is default constructed? It is not a buffer anymore because it has no underlying memory, does not have a size, pitch nor does it have a device. We would have to make DevCpu default constructible as well for this to work. But what is a default constructed device? It would have to be an invalid one (which we do not have for good reasons).
Adding a zombie state only to have a default constructor requires us to handle this zombie state in every method that works with buffers. Currently we can simply expect that when we have a buffer, it is a valid buffer. This would not hold true afterwards.
Therefore I prefer to decline this feature request.

If you do not want a buffer (BufCpu) then simply do not create one in your class. The std::unique_ptr is perfectly fine. boost:.optional might be even more appropriate. You still have to track which of your two buffers is initialized. To combine all of this, you might want to use std::variant<HostBufferType, UserBuffertype>. Then you would express your intention even better.

[krzikalla]

I don't see how a default-constructible BufCpu requires a default-constructible DevCpu. BufCpu holds only a smart_ptr, which can be simply zero-initialized. Also, actually I don't need to track the state of my hostBuffer_, since I hold a view to the memory anyway. The view is initialized on ctor time - either with the allocated buffer or the user memory. Afterwards the hostBuffer_ isn't touched anymore - only implicitly during destruction time.

That said, I understand your design philosophy. I guess, optional is the best way to express the design (I prefer std::optional over boost::optional, but that's another topic).

[psychocoderHPC]

@BenjaminW3 I will reopen this issue. You points are all valid but please give all developer the time to think about it. Maybe there is a solution maybe not.

[psychocoderHPC]

Note: std::optional and std::variant are both c++17 features and my be not usable (depending on the requirements). To switch to boost is maybe also not a solution if @krzikalla do not like to introduce boost into the project beside that alpaka is using it.

[ax3l]

std::variant has a great C++11 implementation that we are using in other projects: https://github.com/mpark/variant

Avoid Boost in new projects, it's pre-C++11 legacy and not adopting fast enough to established community standards (modularity, built system, removing C++98 work-arounds, missing compiler coverage, to name a few. Direct opinions to #481).

[ax3l]

@krzikalla would a makeBuf factory solve your needs as well? I can understand both arguments above.

I want to get rid of the std::unique_ptr.

Not sure if that's a good idea, it will soon replace your new/delete in C++ :)
But you can then auto from a makeBuf factory :)

[krzikalla]

@ax3l Are you aware, that your link points to an April's fool?

And no, I don't see how a factory could solve the issue. Either you allow default constructed (and thus somehow invalid) buffer types or you don't. Both variants have their pros and cons.

From my side the issue could be closed. From my point of view std::optional would be the optimal way to go. While we wait for it, we go witch unique_ptr.

[ax3l]

Ha, that's very disappointing ;)