memcpy equivalent in C++

[mthread]

Hi,
I would like to know if C++ has a class equivalent to
memcpy and its associated functions available in C.

 

[Maxim Yegorushkin]

           I would like to know if C++ has a class equivalent to
memcpy and its associated functions available in C.

It is std::copy() from <algorithm> header. http://www.sgi.com/tech/stl/copy..html

 

[Erik Wikström]

Hi,
I would like to know if C++ has a class equivalent to
memcpy and its associated functions available in C.

memcpy() is also available in C++, but you should only use it for raw
data, if you use it on objects you might get nasty surprises. For
objects you should use std::copy() as Max pointed out.

 

[James Kanze]

std::copy is not the same thing as memcpy. std::copy honors
C++ objects' copy semantics, which can be a lot more
complicated than what memcpy supports. The OP probably wants
std::memcpy, from the <cstring> header.

I wonder whether popular implementations of std::copy delegate
to memcpy for types with trivial copy constructors.

They may or they may not. With a good compiler, generating the
code directly inline probably results in faster code, and maybe
even smaller code.

 

[Juha Nieminen]

memcpy() is also available in C++, but you should only use it for raw
data, if you use it on objects you might get nasty surprises. For
objects you should use std::copy() as Max pointed out.

If a class has only basic types (and possible arrays of basic types)
as members and only has the default compiler-generated copy constructor
and assignment operator, is the behavior of copying objects of that
class with memcpy() still undefined?

 

[Bo Persson]

That raises another interesting question: Are there any platforms
that define both their C and C++ standard libraries on top of a
shared subset, rather than just providing C++ aliases for old C? For
example, are there any implementations that just forward both
memcpy and (sometimes) std::copy to an internal __inline_memcpy?

Yes. For example one produced by a big company that also does OSs and
office packages.

Not only will memcpy be inlined by the compiler, but a for loop in
user code will also be optimized into identical machine code.


Using memcpy is NOT a magical optimization trick!


Bo Persson

 

[James Kanze]

That raises another interesting question: Are there any
platforms that define both their C and C++ standard libraries
on top of a shared subset, rather than just providing C++
aliases for old C?

There are probably some, but in many cases, the C library is
bundled with the system.

For example, are there any implementations that just forward
both memcpy and (sometimes) std::copy to an internal
__inline_memcpy?

I always thought that the usual implementation of memcpy in the
C header was something like:

extern void* memcpy( void* dest, void const* src, size_t n ) ;
#define memcpy( dest, src, n ) __builtin_memcpy( dest, src, n )

(But of course, this causes problems when the library is bundled
as well.) And of course, since it is a template, the compiler
can already see all of the code for std::copy, and optimize
accordingly.

Of course, this is only valid for simple functions like memcpy.
I can't imagine any implementation using a compiler builtin for
something like strftime.

 

[James Kanze]

If a class has only basic types (and possible arrays of basic
types) as members and only has the default compiler-generated
copy constructor and assignment operator, is the behavior of
copying objects of that class with memcpy() still undefined?

If the class is a POD struct or a POD union, the behavior is
well defined. If the class contains pointers, it may not be
what you want, but it is well defined.

 

[Jorgen Grahn]

Using memcpy is NOT a magical optimization trick!

I always thought of it as the opposite of optimization, since (if it's
not builtin, and on popular architectures) it has to copy a byte at a
time, or spend time deciding if it can copy 16, 32 or 64 bytes at a
time.

I often see memcpy() being used in sub-standard C and C++ code, used
in situations where a simple struct copy would have been faster (not
to mention clearer and safer).

/Jorgen

 

[Juha Nieminen]

I often see memcpy() being used in sub-standard C and C++ code, used
in situations where a simple struct copy would have been faster (not
to mention clearer and safer).

I have always wondered why those people prefer writing

memcpy(&dest, &src, sizeof(src));

rather than:

dest = src;

 

[Matthias Buelow]

Perhaps they were counting on the undefined behavior one gets when dest
and src name the same object (and thus cause the regions passed to memcpy
to overlap).

Ye Good Olde C (pre-ANSI) didn't support struct copying, so memcpy() was
the usual way to do that. Some old habits take a long time to die.

 

[Bo Persson]

I have always wondered why those people prefer writing

memcpy(&dest, &src, sizeof(src));

rather than:

dest = src;

Because they have heard that using memcpy will make their programs
extremely fast. And that this is very important.

Unfortunately they never heard anything about checking sizeof(dest)
first. :-(



Bo Persson

 

[Old Wolf]

Holdovers from the bad old days of early K&R, where I believe struct
assignment wasn't allowed?  My copy of K&R 1ed is at work, alas.

You recall correctly; struct assignment was not
in K&R 1. Some programmers who learned C before
standardization, eschew structure copy operations
(including passing structures to functions, and
returning them).

 

[Juha Nieminen]

You recall correctly; struct assignment was not
in K&R 1. Some programmers who learned C before
standardization, eschew structure copy operations
(including passing structures to functions, and
returning them).

C and C compilers have supported struct assignment for... how long? At
least 15 years?

 

[Bill Davy]

C and C compilers have supported struct assignment for... how long? At
least 15 years?

Sadly, some compilers for embedded work are not that advanced.