std::list of C-style arrays

[Spoon]

Hello,

Could someone explain why the following code is illegal?
(I'm trying to use a list of (C-style) arrays.)

#include <list>
typedef std::list < int[2] foo_t;
int main()
{
int v[2] = { 12, 34 };
foo_t bar;
bar.push_front(v);
return 0;
}

$ g++ -std=c++98 -Wall foo.cxx
stl_construct.h: In function `void std::_Construct(_T1*, const _T2&)
[with _T1 = int[2], _T2 = int[2]]':
stl_list.h:438: instantiated from `std::_List_node<_Tp>*
std::list<_Tp, _Alloc>::_M_create_node(const _Tp&) [with _Tp = int[2],
_Alloc = std::allocator<int[2]>]'
stl_list.h:1163: instantiated from `void std::list<_Tp,
_Alloc>::_M_insert(std::_List_iterator<_Tp>, const _Tp&) [with _Tp =
int[2], _Alloc = std::allocator<int[2]>]'
stl_list.h:755: instantiated from `void std::list<_Tp,
_Alloc>::push_front(const _Tp&) [with _Tp = int[2], _Alloc =
std::allocator<int[2]>]'
foo.cxx:7: instantiated from here
stl_construct.h:81: error: ISO C++ forbids initialization in array new
Do I have to wrap the array in a struct?

#include <list>
struct sfoo { int v[2]; };
typedef std::list < sfoo foo_t;
int main()
{
sfoo s = { 12, 34 };
foo_t bar;
bar.push_front(s);
return 0;
}

Regards.

[Pete Becker]

On 2007-12-07 10:50:11 -0500, Spoon <root@localhostsaid:

>
Could someone explain why the following code is illegal?
(I'm trying to use a list of (C-style) arrays.)

Because arrays are neither copy constructible nor assignable.

>

Do I have to wrap the array in a struct?

Yes. Or, if you have TR1, use std::tr1::array, a template that defines
a fixed-size array that's copy constructible and assignable. It's also
slated for C++0x.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Kai-Uwe Bux]

Spoon wrote:

Hello,

Could someone explain why the following code is illegal?
(I'm trying to use a list of (C-style) arrays.)

#include <list>
typedef std::list < int[2] foo_t;
int main()
{
int v[2] = { 12, 34 };
foo_t bar;
bar.push_front(v);
return 0;
}

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

$ g++ -std=c++98 -Wall foo.cxx
stl_construct.h: In function `void std::_Construct(_T1*, const _T2&)
[with _T1 = int[2], _T2 = int[2]]':
stl_list.h:438: instantiated from `std::_List_node<_Tp>*
std::list<_Tp, _Alloc>::_M_create_node(const _Tp&) [with _Tp = int[2],
_Alloc = std::allocator<int[2]>]'
stl_list.h:1163: instantiated from `void std::list<_Tp,
_Alloc>::_M_insert(std::_List_iterator<_Tp>, const _Tp&) [with _Tp =
int[2], _Alloc = std::allocator<int[2]>]'
stl_list.h:755: instantiated from `void std::list<_Tp,
_Alloc>::push_front(const _Tp&) [with _Tp = int[2], _Alloc =
std::allocator<int[2]>]'
foo.cxx:7: instantiated from here
stl_construct.h:81: error: ISO C++ forbids initialization in array new
Do I have to wrap the array in a struct?

#include <list>
struct sfoo { int v[2]; };
typedef std::list < sfoo foo_t;
int main()
{
sfoo s = { 12, 34 };
foo_t bar;
bar.push_front(s);
return 0;
}

You could use std::tr1::array if your implementation provides it.
Alternatively, there is boost::array.
Best

Kai-Uwe Bux

[Juha Nieminen]

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

[Pete Becker]

On 2007-12-07 21:59:30 -0500, Juha Nieminen <no****@thanks.invalidsaid:

Kai-Uwe Bux wrote:

>Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

The simplest answer is that that's the way it is in C. A more complex
answer is that you end up in a tangle, because the name of an array
decays to a pointer to its first element in many contexts, and when
you're down to a pointer you no longer know the size. Yes, C++ could
have added a bunch of rules about when you can and when you can't copy
them, but that would not be productive. If you need copyable arrays,
use std::tr1::array. For more details, see chapter 4 of my book, "The
Standard C++ Library Extensions."

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Abhishek Padmanabh]

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

I can try to justify but I am not sure if that was the real intent. It
could be, though.

This is probably an inherited concept from C. C arrays as well decay
to pointers. Consider this (or just about any string function in
<string.h>):

int strcmp ( const char * str1, const char * str2 );

It is a standard C(-style) string comparison function. Now, consider
that arrays did not decay to pointers and that they were copyable. In
the absence of overloading (and templates) which are C++ concepts, how
would you implement a strcpy function that could work with any length
C-string arrays? It don't think it would have been possible without
having functions like strcmp_1/strcmp_2/... and so on functions. Which
would be a real pain since you just can't write this function for all
possible array lengths.

Now, in C++, this is avoided with optimizations in case of templates.
Example: boost::lexical_cast doesn't rely on such optimizations
though. It is forced that C-style string arrays decay to pointers
during instantiation of lexical_stream otherwise, this might cause
code-bloat. Consider the instantiations for as many C-string arrays as
different sized ones used in a program! In optimized modes, compilers
might do away with that many instantiations and have only one.

So, that (value semantics for arrays) is something that everyone wants
to avoid. Why have it?

[terminator]

On Dec 8, 5:33 pm, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

I can try to justify but I am not sure if that was the real intent. It
could be, though.

This is probably an inherited concept from C. C arrays as well decay
to pointers. Consider this (or just about any string function in
<string.h>):

int strcmp ( const char * str1, const char * str2 );

It is a standard C(-style) string comparison function. Now, consider
that arrays did not decay to pointers and that they were copyable. In
the absence of overloading (and templates) which are C++ concepts, how
would you implement a strcpy function that could work with any length
C-string arrays? It don't think it would have been possible without
having functions like strcmp_1/strcmp_2/... and so on functions. Which
would be a real pain since you just can't write this function for all
possible array lengths.

Now, in C++, this is avoided with optimizations in case of templates.
Example: boost::lexical_cast doesn't rely on such optimizations
though. It is forced that C-style string arrays decay to pointers
during instantiation of lexical_stream otherwise, this might cause
code-bloat. Consider the instantiations for as many C-string arrays as
different sized ones used in a program! In optimized modes, compilers
might do away with that many instantiations and have only one.

So, that (value semantics for arrays) is something that everyone wants
to avoid. Why have it?

arrays are some part of paranoia that C++ iherits from C . C++ is the
result of rapid and uncuatious patching C with a linear algebraic
approach.

regards,
Fm.

[James Kanze]

On Dec 8, 3:33 pm, Abhishek Padmanabh
<[e-mail]:

[...]

It is a standard C(-style) string comparison function. Now,
consider that arrays did not decay to pointers and that they
were copyable. In the absence of overloading (and templates)
which are C++ concepts, how would you implement a strcpy
function that could work with any length C-string arrays?

The same way most other languages implement it? With the size
being an attribute of the array, and not part of its type? With
provisions for an open typed array, as well as a fixed length
array?

There are any number of solutions. Almost all superior to the
one chosen by C.

It don't think it would have been possible without having
functions like strcmp_1/strcmp_2/... and so on functions.

Ada has them. Java has them. In both languages, arrays are
real types, possibly passed by value, and obeying all of the
rules other types do.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[terminator]

On Dec 8, 5:33 pm, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

On Dec 8, 7:59 am, Juha Nieminen <[e-mail]:

Kai-Uwe Bux wrote:

Built-in arrays do not satisfy the Assignable and CopyConstructible concepts
required for types used in standard sequence containers.

Is there any technical or rational reason for this? After all, they
*are* copied and assigned if they are members of a struct/class. Why
can't it be so also when they are bare?

I can try to justify but I am not sure if that was the real intent. It
could be, though.

This is probably an inherited concept from C. C arrays as well decay
to pointers. Consider this (or just about any string function in
<string.h>):

int strcmp ( const char * str1, const char * str2 );

It is a standard C(-style) string comparison function. Now, consider
that arrays did not decay to pointers and that they were copyable. In
the absence of overloading (and templates) which are C++ concepts, how
would you implement a strcpy function that could work with any length
C-string arrays? It don't think it would have been possible without
having functions like strcmp_1/strcmp_2/... and so on functions. Which
would be a real pain since you just can't write this function for all
possible array lengths.

decay is for last decades just forget about it but being intrinsically
convertible to pointer is not conflicting with copy-constructability
and assignability .numeric types are intrinsically convertible to each
other and that does not prevent copy or assign on either one.At the
time C was designed no neither OO was known nor GP and assignabilty/
convertibilty/... did not make sense so decay strategy was used .Why
should we be bound to restrictions that could be removed in a backward
compatible manor? I mean we can safely replace the idea of decay with
convertabiliy. All we need is a minor review.

regards,
FM.