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.

On 2007-12-07 10:50:11 -0500, Spoon <root@localhost> said:

>
> 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)

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

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 2007-12-07 21:59:30 -0500, Juha Nieminen <nospam@thanks.invalid> said:

> 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)

On Dec 8, 7:59 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> 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 <nos...@thanks.invalid> wrote:
> 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?

On Dec 8, 5:33 pm, Abhishek Padmanabh <abhishek.padman...@gmail.com>
wrote:
> On Dec 8, 7:59 am, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > 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 <nos...@thanks.invalid> wrote:
>
> > 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.

On Dec 8, 3:33 pm, Abhishek Padmanabh
<abhishek.padman...@gmail.com> wrote:

[...]
> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34