Re: Can an arbitrary continuous sequence of objects of type T be
interpreted as an array of T?
Am 25.10.2011 23:49, schrieb Nikolay Ivchenkov:
On 25 Oct, 14:52, Nikolay Ivchenkov<ts...@mail.ru> wrote:
Unfortunately, the following code doesn't work.
std::vector<std::string[2]> v(3);
v[2][1] = "text";
This is because std::allocator cannot properly handle arrays.
Agreed, but I consider the here mentioned problems with arrays as mostly
core language problems, less as library problems. The next problem is
that arrays are never CopyAssignable nor can they ever satisfy
is_copy_assignable. I'm not convinced that the library can or should
compensate for all these deficiencies of the core language rules (It
should be added here that in fact std::pair is no longer copy-assignable
in C++11 if at least one member is an array type).
There is another reason why a conforming implementation may reject
such code (as well as with the improved allocator): std::vector is
overconstrained itself. It requires the element type to be
Destructible and in the given case also DefaultConstructible. Arrays
are neither Destructible nor DefaultConstructible.
I agree, but there is a promising looking paper in the LWG paper queue,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3301.pdf
which would solve the DefaultConstructible problem for std::vector.
In addition to
"CopyInsertable", "MoveInsertable", and "EmplaceConstructible"
concepts (see 23.2.1/13) LWG might introduce the following:
T is Erasable from X - allocator_traits<A>::destroy(m, p) is well-
formed;
I agree that this is a suggestion, it looks like a missing link given
the existing and planned allocator-related expression requirements.
T is DefaultInsertable into X - the same as T is
EmplaceConstructible into X from empty args.
IMO it makes sense to define an independent expression definition for
this, e.g. similar to what is currently suggested by n3301:
"T is DefaultInsertable into X means that the following expressions are
well formed:
allocator_traits<A>::construct(m, p);
[..]"
In regard to your example
<quote>
std::vector<std::array<std::string, 2>> v(3);
v[2][1] = "text";
This is not a solution if we already have an immutable interface that
expects a pointer to built-in array.[..]
</quote>
I wonder why you don't apply your initial idea to the std::array element
within std::vector:
std::string (*arr)[2] = reinterpret_cast<std::string (*)[2]>(v[2].data());
Arguably that would be quite more natural, if
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930
would have been accepted with a c_array() accessor for the underlying array.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]