[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

memcpy equivalent in C++

mthread

11/19/2008 9:12:00 AM


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

Maxim Yegorushkin

11/19/2008 9:15:00 AM

0

On Nov 19, 9:11 am, mthread <rjk...@gmail.com> wrote:

>            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/...

--
Max

Erik Wikström

11/19/2008 6:58:00 PM

0

On 2008-11-19 10:11, mthread wrote:
> 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.

--
Erik Wikström

Jeff Schwab

11/19/2008 7:27:00 PM

0

Maxim Yegorushkin wrote:
> On Nov 19, 9:11 am, mthread <rjk...@gmail.com> wrote:
>
>> 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...

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.

Pete Becker

11/19/2008 7:41:00 PM

0

On 2008-11-19 14:26:34 -0500, Jeff Schwab <jeff@schwabcenter.com> said:

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

Yes, they do.

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

James Kanze

11/20/2008 8:28:00 AM

0

On Nov 19, 8:26 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> Maxim Yegorushkin wrote:
> > On Nov 19, 9:11 am, mthread <rjk...@gmail.com> wrote:

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

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

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

Juha Nieminen

11/20/2008 1:02:00 PM

0

Erik Wikström wrote:
> On 2008-11-19 10:11, mthread wrote:
>> 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.

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?

Jeff Schwab

11/20/2008 1:03:00 PM

0

James Kanze wrote:
> On Nov 19, 8:26 pm, Jeff Schwab <j...@schwabcenter.com> wrote:

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

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?

Jeff Schwab

11/20/2008 1:14:00 PM

0

Juha Nieminen wrote:
> Erik Wikström wrote:
>> On 2008-11-19 10:11, mthread wrote:
>>> 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.
>
> 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?

That depends what you consider "basic types." If the types involved are
POD, the behavior is defined (as long as neither of the objects is a
sub-object of the other). See 3.9 Types [basic.types], paragraph 3.

Bo Persson

11/20/2008 5:01:00 PM

0

Jeff Schwab wrote:
> James Kanze wrote:
>> On Nov 19, 8:26 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>
>>> 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.
>
> 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

11/21/2008 9:58:00 AM

0

On Nov 20, 2:03 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> James Kanze wrote:
> > On Nov 19, 8:26 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> >> 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.

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