memmove on array of objects

[Chris]

Hello all,

Not sure if this is off topic, if it is I apologise in advance.

Is it safe to use memmove() on an array of objects?

I create an array of Objects and I have a cursor to indicate how many of
those objects are in use. The one cravat is that the there are no unused
objects (gaps) between the first element of the array to the cursor.

When I remove an object I want to fill the gap by shifting the objects (on
the right) to the left by one. I currently use a for-loop to in which the
objects's operator=() is used.

I would like to replace the for-loop with something like this:

memmove(data+i, data+i+1, (sz-i-1) * sizeof(Object));

Where,
data is the array
i is the index of the object remove
sz is the number of used objects

I believe using memmove should be ok, but I thought it would be best to get
a 2nd opinion.

Thanks,

--
Chris

[Jerry Coffin]

In article <Cra4k.940$sg6.849@edtnps91>,
ch***@thisisnotanemailaddress.ca says...

Hello all,

Not sure if this is off topic, if it is I apologise in advance.

Is it safe to use memmove() on an array of objects?

Yes, if they're PODs. Otherwise, no. From a practical viewpoint, you can
probably get away with it on some non-POD objects as well.

I, however, would have to wonder why you're doing things this way at
all. I'd use something like a vector...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Chris]

Jerry Coffin wrote:

In article <Cra4k.940$sg6.849@edtnps91>,
ch***@thisisnotanemailaddress.ca says...

>Hello all,

Not sure if this is off topic, if it is I apologise in advance.

Is it safe to use memmove() on an array of objects?

Yes, if they're PODs. Otherwise, no. From a practical viewpoint, you can
probably get away with it on some non-POD objects as well.

I, however, would have to wonder why you're doing things this way at
all. I'd use something like a vector...

No, the Objects are not PODs.

I thought about using std::vector, but task I am doing is fairly trivial and
so far I haven't needed to bring the STL into the project. I think I will
check out the source for std::vector and see how it removes an element. I
suspect it would be via some kind of for-loop.

In the past I got burnt from using memset() on an array of Objects. After
some debugging I discovered that though the primitive members of the
Objects were being set to 0, so was the vtable! I learned a valuable lesson
there. I just wanted to determine if memmove() might cause similar
problems.

Now that I think of it and read the replies, I can see where memmove() would
cause problems for classes especially with the dtors (clean up of pointers,
etc.) of the moved objects.

Thanks

--
Chris

[Fokko Beekhof]

Chris wrote:

Jerry Coffin wrote:

>In article <Cra4k.940$sg6.849@edtnps91>,
ch***@thisisnotanemailaddress.ca says...

>>Hello all,

Not sure if this is off topic, if it is I apologise in advance.

Is it safe to use memmove() on an array of objects?

Yes, if they're PODs. Otherwise, no. From a practical viewpoint, you can
probably get away with it on some non-POD objects as well.

I, however, would have to wonder why you're doing things this way at
all. I'd use something like a vector...

No, the Objects are not PODs.

I thought about using std::vector, but task I am doing is fairly trivial and
so far I haven't needed to bring the STL into the project. I think I will
check out the source for std::vector and see how it removes an element. I
suspect it would be via some kind of for-loop.

In the past I got burnt from using memset() on an array of Objects. After
some debugging I discovered that though the primitive members of the
Objects were being set to 0, so was the vtable! I learned a valuable lesson
there. I just wanted to determine if memmove() might cause similar
problems.

Now that I think of it and read the replies, I can see where memmove() would
cause problems for classes especially with the dtors (clean up of pointers,
etc.) of the moved objects.

Thanks

Actually, in C++ things such as memmove() and memcpy() (C-style) are not
used, but rather std::copy() and such (C++-style). The main difference,
in an informal way of speaking, is that in C++ you write _what_ you want
to do (implicit), and in C you'd write _how_ you'd want something done
(explicit).

For example, using std::copy() would be safer than hardcoding an
memmove(). Then, std::copy() will figure out for you how to do that best
- possibly with a memmove(), maybe otherwise. Using a vector would be
even better.

As you have yourself indicated, doing things "C-style" is not very safe,
at least not in an otherwise C++-environment. In your position, I would
have used the STL, and enjoyed writing safe code with relatively little
effort. Looking into the vector class' code will only tell you what your
current platform does, other implementations might be different, so it
won't give you much useful information.

The "C++" solution: delegate the work to the STL, and just have faith
that it will work. Trying to outsmart the std library is unlikely to
succeed. :-)

cheers,
wateenellende