Add constructors for C-array, std::array<>, container ?

[martinmoene]

[Quuxplusone]

Add constructors for C-array, std::array<>, container ?

FWIW, I'd say "no"; let people use the two-iterator explicit constructor. Unless this is inspired by Ranges TS and would permit some interesting Ranges idiom that the two-iterator constructor doesn't?

[martinmoene]

Hi Arthur, Thanks for your reaction.

While issuing, I already felt some reluctance. It was simply inspired on std::span's constructors taking a container, however it's meaning with ring_span might be unclear.

[DBJDBJ]

Perhaps ...

    // make from native arrays
template< typename T, size_t N >
inline nonstd::ring_span<T> make_ring_span(T(&arr)[N]) {
	return nonstd::ring_span<T>(arr, arr + N, arr, N);
}

// make from std arrays
template< typename T, size_t N >
inline nonstd::ring_span<T> make_ring_span(std::array<T,N> stdarr) 
{
	auto arr = stdarr.data();
	return nonstd::ring_span<T>(arr, arr + N, arr, N);
}

[martinmoene]

Or perhaps assume initially empty buffer:

return nonstd::ring_span<T>(&arr[0], &arr[0] + N, &arr[0], 0);
//                                                         ^     v
return nonstd::ring_span<T>(arr.begin(), arr.end(), arr.begin(), 0);

[DBJDBJ]

I am not that familiar with the API ... but if the last argument is the size of the view on the source, that is OK of course.

There are numerous make_ring_span overloads one can imagine ... a project can add them gradually as it evolves or good contributors can add them to a (git) submodule ... called let's say 'makers'

          template< typename T >
          inline nonstd::ring_span<T> make_ring_span(std::vector<T> ) ;

          template< typename T >
          inline nonstd::ring_span<T> make_ring_span(std::basic_string<T> ) ;

          template< typename T >
          inline nonstd::ring_span<T> make_ring_span(std::unique_pointer<T[]>, size_t ) ;

         // then shared_ptr, map's set's and enyuthing else that has begin and end
         // or is otherwise applicable

I assume C++20 types are out of the question ... std::range as so on..