588. requirements on zero sized tr1::arrays and other details

Section: 23.3.3 [array] Status: NAD Submitter: Gennaro Prota Opened: 2006-07-18 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [array].

View all issues with NAD status.

Discussion:

The wording used for section 23.2.1 [lib.array] seems to be subtly ambiguous about zero sized arrays (N==0). Specifically:

* "An instance of array<T, N> stores N elements of type T, so that [...]"

Does this imply that a zero sized array object stores 0 elements, i.e. that it cannot store any element of type T? The next point clarifies the rationale behind this question, basically how to implement begin() and end():

* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() == end() == unique value."

What does "unique" mean in this context? Let's consider the following possible implementations, all relying on a partial specialization:

a)
    template< typename T >
    class array< T, 0 > {
    
        ....

        iterator begin()
        { return iterator( reinterpret_cast< T * >( this ) ); }
        ....

    };

This has been used in boost, probably intending that the return value had to be unique to the specific array object and that array couldn't store any T. Note that, besides relying on a reinterpret_cast, has (more than potential) alignment problems.

b)
    template< typename T >
    class array< T, 0 > {
    
        T t;

        iterator begin()
        { return iterator( &t ); }
        ....

    };

This provides a value which is unique to the object and to the type of the array, but requires storing a T. Also, it would allow the user to mistakenly provide an initializer list with one element.

A slight variant could be returning *the* null pointer of type T

    return static_cast<T*>(0);

In this case the value would be unique to the type array<T, 0> but not to the objects (all objects of type array<T, 0> with the same value for T would yield the same pointer value).

Furthermore this is inconsistent with what the standard requires from allocation functions (see library issue 9).

c) same as above but with t being a static data member; again, the value would be unique to the type, not to the object.

d) to avoid storing a T *directly* while disallowing the possibility to use a one-element initializer list a non-aggregate nested class could be defined

    struct holder { holder() {} T t; } h;

and then begin be defined as

 iterator begin() { return &h.t; }

But then, it's arguable whether the array stores a T or not. Indirectly it does.

-----------------------------------------------------

Now, on different issues:

* what's the effect of calling assign(T&) on a zero-sized array? There seems to be only mention of front() and back(), in 23.2.1 [lib.array] p4 (I would also suggest to move that bullet to section 23.2.1.5 [lib.array.zero], for locality of reference)

* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit inconsistent with that of other sequences: that's not a problem in itself, but compare it for instance with "A vector is a kind of sequence that supports random access iterators"; though the intent is obvious one might argue that the wording used for arrays doesn't tell what an array is, and relies on the reader to infer that it is what the <array> header defines.

* it would be desiderable to have a static const data member of type std::size_t, with value N, for usage as integral constant expression

* section 23.1 [lib.container.requirements] seem not to consider fixed-size containers at all, as it says: "[containers] control allocation and deallocation of these objects [the contained objects] through constructors, destructors, *insert and erase* operations"

* max_size() isn't specified: the result is obvious but, technically, it relies on table 80: "size() of the largest possible container" which, again, doesn't seem to consider fixed size containers

[ 2009-05-29 Daniel adds: ]

1. star bullet 1 ("what's the effect of calling assign(T&) on a zero-sized array?[..]");

   assign has been renamed to fill and the semantic of fill is now defined in terms of the free algorithm fill_n, which is well-defined for this situation.

2. star bullet 3 ("it would be desiderable to have a static const data member..."):

   It seems that tuple_size<array<T, N> >::value as of 23.3.3.7 [array.tuple] does provide this functionality now.

[ 2009-07 Frankfurt ]

Alisdair to address by the next meeting, or declare NAD.

Moved to Tentatively NAD.

[ 2009 Santa Cruz: ]

Moved to NAD.

Proposed resolution:

[ Kona (2007): requirements on zero sized tr1::arrays and other details Issue 617: std::array is a sequence that doesn't satisfy the sequence requirements? Alisdair will prepare a paper. Proposed Disposition: Open ]