|
Boost : |
From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-12-04 18:56:50
On Wed, Dec 4, 2019 at 1:50 PM Peter Dimov via Boost
<boost_at_[hidden]> wrote:
>
> Andrey Semashev wrote:
> > On 2019-12-04 18:24, Alexander Grund via Boost wrote:
> > >
> > >> I would hope to see close to the same semantics as std::array<T,0>,
> > >> which I believe allows data() to return nullptr.
> > >
> > > I don't think so:
> > >
> > > "There is a special case for a zero-length array (|N == 0|). In that
> > > case, array.begin() == array.end(), which is some unique value. The
> > > effect of calling front() or back() on a zero-sized array is undefined."
> > > from https://en.cppreference.com/w/cpp/container/array
> > >
> > > IMO this excludes nullptr as that won't be unique
> >
> > I don't think iterators from different instances of a container are
> > comparable. IOW, "unique" means distinct from any possible values of valid
> > iterators obtained from this particular container instance.
> >
> > That might not apply to pointers, though.
>
> Pointers are comparable with ==, and array<T, 0> usually returns
> reinterpret_cast<T*>(this) from data() to satisfy the uniqueness
> requirement.
>
> Or used to return - I see that libstdc++ returns nullptr now, probably
> because reinterpret_cast can't be constexpr.
>
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/array#L76
Precisely for this reason, but also the uniqueness requirement was on
`begin()` and `end()` and not `.data()`:
"In the case that N == 0, begin() == end() == unique value. The
return value of data() is unspecified."
-- Working Draft, http://eel.is/c++draft/array#zero-2
begin() and end() are already restricted library-wide to not be
comparable with begin() and end() -- let alone any iterator -- from a
container that does not generate them, so cross-container uniqueness
has never been a thing. There is an issue open to generate better
wording around this to make it more clear:
https://cplusplus.github.io/LWG/lwg-active.html#2157
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk