Copy construction of arrays - how?

  • Follow


Hi,

Which syntax (if any) should I use to perform copy construction of
arrays?

E.g. 
class X
{
   char array[100];
};

X:X (const X& x)
: array (?)
{}

The reason I am asking is that I notticed that if I do not specify
copy contsructor, the default one does it more efficiently than e.g.
memcpy or manually-coded loop. I would like to use the same efficiency
that the built-in copy ctor has in my own one.


Radoslav Getov

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply rgetov643 (2) 12/21/2003 4:34:50 PM

"Radoslav Getov" <rgetov@ultraheap.com> wrote in message news:1e27bd36.0312210355.606d233a@posting.google.com...

> 
> The reason I am asking is that I notticed that if I do not specify
> copy contsructor, the default one does it more efficiently than e.g.
> memcpy or manually-coded loop. I would like to use the same efficiency
> that the built-in copy ctor has in my own one.
> 
This is a sticky issue.  Arrays are only half-assed types in C++
as they don't support the copying/assignment semantics that
every other data type does.

My suggestion would be to wrap it in another type that has reasonable
semantics.   std::vector would be one way.   Alternatively if you want
to retain the array actually being stored in the class memory directly,
just wrap a simple struct around it:

class X {
    struct array1000 { char array[1000]; } carray;

   X(const X& x) : carray(x.carray) { ...


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Ron 12/21/2003 8:48:27 PM


"Ron Natalie" <ron@sensor.com> wrote in message news:<3fe5ef9f$0$70088$9a6e19ea@news.newshosting.com>...
 > "Radoslav Getov" <rgetov@ultraheap.com> wrote in message news:1e27bd36.0312210355.606d233a@posting.google.com...
 >
 > >
 > > The reason I am asking is that I notticed that if I do not specify
 > > copy contsructor, the default one does it more efficiently than e.g.
 > > memcpy or manually-coded loop. I would like to use the same efficiency
 > > that the built-in copy ctor has in my own one.
 > >
 > This is a sticky issue.  Arrays are only half-assed types in C++
 > as they don't support the copying/assignment semantics that
 > every other data type does.
 >
 > My suggestion would be to wrap it in another type that has reasonable
 > semantics.   std::vector would be one way.

Why does everyone always recommend std::vector in situations like
this?  If the user has an array on the stack, they are most likely
doing this because the objects will be created and destroyed
frequently, or because they need access to local data.  std::vector is
good for neither of these cases.

 > Alternatively if you want
 > to retain the array actually being stored in the class memory directly,
 > just wrap a simple struct around it:
 >
 > class X {
 >     struct array1000 { char array[1000]; } carray;
 >
 >    X(const X& x) : carray(x.carray) { ...
 >
 >

Yes, excellent idea.  I had never thought of that before.  Just one
suggestion- template it on the data type and the size so it can be
reused later.

template <typename T, size_t i> struct copyable_array {
  T array[i];
};

Now, it might be nice to add some common methods to this class, like
size(), begin(), end(), etc... boost has a class like this, as do many
other libraries.  However, sometimes simple is simple, and the quick 3
line class above can be very useful, as you have pointed out.

joshua lehrer
factset research systems
NYSE:FDS

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply usenet_cpp 12/22/2003 8:41:43 AM

> Why does everyone always recommend std::vector in situations like
> this?  If the user has an array on the stack, they are most likely
> doing this because the objects will be created and destroyed
> frequently, or because they need access to local data.  std::vector is
> good for neither of these cases.

My experience is that people who have arrays on the stack do so most often
because they do not know how to use vectors, or because they believe
(usually mistakenly) that vectors are slower than they can afford.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Andrew 12/22/2003 7:22:11 PM

usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote in message
news:<31c49f0d.0312212012.502062ff@posting.google.com>...
 > "Ron Natalie" <ron@sensor.com> wrote in message
 > news:<3fe5ef9f$0$70088$9a6e19ea@news.newshosting.com>...
 > > "Radoslav Getov" <rgetov@ultraheap.com> wrote in message
 > >  news:1e27bd36.0312210355.606d233a@posting.google.com...

 >  > > The reason I am asking is that I notticed that if I do not
 >  > > specify copy contsructor, the default one does it more
 >  > > efficiently than e.g.  memcpy or manually-coded loop. I would
 >  > > like to use the same efficiency that the built-in copy ctor has
 >  > > in my own one.

 >  > This is a sticky issue.  Arrays are only half-assed types in C++ as
 >  > they don't support the copying/assignment semantics that every
 >  > other data type does.

 >  > My suggestion would be to wrap it in another type that has
 >  > reasonable semantics.  std::vector would be one way.

 > Why does everyone always recommend std::vector in situations like
 > this?

Because it is a pretty good default choice.

 > If the user has an array on the stack, they are most likely doing this
 > because the objects will be created and destroyed frequently, or
 > because they need access to local data.  std::vector is good for
 > neither of these cases.

Sure it is.  At least until the profiler tells you otherwise.

OK, I'm exagerating a little -- I know that there are cases where you
know in advance that the dynamic allocation is going to cost.  If I were
defining a Point3D in an image processing application, where I knew that
there would be std::vector< Point3D > with millions of elements, I might
use double[3] instead of double x,y,z, but I certainly wouldn't use
std::vector<double>.  But such cases are the exception, not the rule.
Most of the time, when I use a C style array instead of std::vector, it
is because of the initialization syntax; often even, the desire for
initialization to be static (which avoids certain order of
initialization problems).

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/     http://www.gabi-soft.fr
                     Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply kanze 12/22/2003 7:41:43 PM

On 22 Dec 2003 14:22:11 -0500, Andrew Koenig wrote:

>> Why does everyone always recommend std::vector in situations like
>> this?  If the user has an array on the stack, they are most likely
>> doing this because the objects will be created and destroyed
>> frequently, or because they need access to local data.  std::vector is
>> good for neither of these cases.
>
>My experience is that people who have arrays on the stack do so most often
>because they do not know how to use vectors, or because they believe
>(usually mistakenly) that vectors are slower than they can afford.

I don't disagree with you but I think that most people have no idea what
the overhead is in using a vector<char> x(100); on the stack is instead
of  char x[100].

In the case of the vector, you get 100 default initialised elements and
some compilers/libraries don't distinguish between built in types or
class types and actually execute 100 calls to a constructor function for
this.  The same goes for functions such as vector assign versus strcpy -
the difference in efficiency can be substantial.

Graeme

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Graeme 12/23/2003 2:12:25 AM

5 Replies
115 Views

(page loaded in 0.144 seconds)

Similiar Articles:













7/25/2012 11:06:48 AM


Reply: