Non-trivial data sources

[psiha]

Can you make your allocator machinery support allocators (e.g. auto defragmenting allocators) that return handles - objects that contain pointers which can be changed under-the-hood so you cannot store the pointer but rather have to ask the handle for the pointer (call get() or data() on it) every time you need the pointer to the data (it is up to the user to make sure and pin the handle or allocator when data access is required)?

Similarily for the detail::view_builder<>::data_block machinery - can it support data sources that are:

• handles (i.e. one extra level of indirection)
• CRTP derived classes (i.e. the view does not store the source object but casts itself to it - that is the way I 'handle the handle' pardon the pun :D)

template < typename DimensionsParam, typename DataSource >
struct ViewImpl : private DimensionsParam
{
    using Dimensions = DimensionsParam;

    constexpr ViewImpl() noexcept = default;
    constexpr ViewImpl( Dimensions const & dimensions ) noexcept { this->setDimensions( dimensions ); }

    constexpr auto count() const noexcept { return this->dimensions().count(); }

    constexpr auto dimension( std::uint8_t const index ) const noexcept { return this->dimensions()[ index ]; }
    constexpr auto shape    ( std::uint8_t const index ) const noexcept { return dimension( index ); }

    template < typename ... Indices > auto const & operator()( Indices ... indices ) const noexcept { return const_cast< ViewImpl & >( *this ).operator()( indices... ); }
    template < typename ... Indices > auto       & operator()( Indices ... indices )       noexcept { return getData()[ this->dimensions().index( indices... ) ]; }

    ....

private:
    BOOST_FORCEINLINE auto getData()       noexcept { return static_cast< DataSource * >( this )->data(); }
    BOOST_FORCEINLINE auto getData() const noexcept { return const_cast< ViewImpl & >( *this ).getData(); }

protected:
    constexpr void setDimensions( Dimensions const & newDimensions ) noexcept { static_cast< Dimensions & >( *this ) = newDimensions; }
}; // struct ViewImpl

(might be related to #7 WRT storing 'non trivial pointers' in views)

[jfalcou]

This is the next version of data_block: https://github.com/jfalcou/kiwaku/blob/feature/table/include/kwk/container/components/data_block.hpp

I think the handle situation can just be made so the pointer/reference types can be deferred to Source instead of computed via traits.
data() access is fully in the control of the Source type and nothing ask for it to be an actual pointer, just somethign with a [] on it. So I think it's not much to do.

As for the pointer not being stored bug asked every time, that's what source data() does, so we can probably just make a block that do w/e in data(). If you have a concrete example I can make a test and check it works

[jfalcou]

Well, the heap_block class in the feature/table branch just does that: it contains an unique_ptr and uses data() to do the get() so I think it just works.

[psiha]

lol - we already discussed this almost a year ago :D

so repeat the live discussion:

• i'd need a 'viewy thingy' - that might be your 'container' - that would 'crtp-like' delegate the data pointer getting - i guess you'd have to expand your 'source' machinery to support that
• way to explicitly define a view type (so that it can for example be derived from)