Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Alternative to memcpy in C++?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
26 replies to this topic

#1 The C modest god   Banned   -  Reputation: 100

Like
Likes
Like

Posted 15 February 2004 - 01:13 AM

?

Sponsor:

#2 Puzzler183   Members   -  Reputation: 540

Like
Likes
Like

Posted 15 February 2004 - 01:16 AM

Just use memcpy. Seriously, why would you want something else?

#3 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 February 2004 - 01:23 AM

maybe because it copies BYTES *duh*

#4 Enigma   Members   -  Reputation: 1402

Like
Likes
Like

Posted 15 February 2004 - 01:24 AM

If you do want something else (i.e. type safety) use std::copy from <algorithm>.

Enigma

#5 _DarkWIng_   Members   -  Reputation: 602

Like
Likes
Like

Posted 15 February 2004 - 01:24 AM

std::copy()

You should never let your fears become the boundaries of your dreams.

#6 Leadorn   Members   -  Reputation: 100

Like
Likes
Like

Posted 15 February 2004 - 01:28 AM

google for memcpy_amd.cpp and memcpy_amd.h

#7 Shannon Barber   Moderators   -  Reputation: 1391

Like
Likes
Like

Posted 15 February 2004 - 04:26 AM

memcpy can copy to and from byte alignment, the actual copy in all likelyhood, uses a dword rep mem sto for the aligned block.

There''s also memmove.

#8 emilk   Members   -  Reputation: 216

Like
Likes
Like

Posted 15 February 2004 - 04:30 AM

std::copy should ALWAYS be prefered to memcpy unless speed is of great important and you are copying POD types

#9 SabreMan   Members   -  Reputation: 504

Like
Likes
Like

Posted 16 February 2004 - 12:35 AM

quote:
Original post by Puzzler183
Just use memcpy. Seriously, why would you want something else?

Because direct memory manipulation undermines the type system. You should strive to avoid use of memcpy and friends.


#10 Lord Bart   Members   -  Reputation: 226

Like
Likes
Like

Posted 16 February 2004 - 01:13 AM

Hello The C modest god,

I will take issue with what SabreMan said about not using memcpy.

"Because direct memory manipulation undermines the type system."

Type of system is exactly why you should use memcpy and its friends. And what C/C++ program that does anything complex doesn''t use some were direct memory manipulation?

memcpy is perfectly fine to use and should be use over most other methods for the biggest reason of all.
Every C/C++ compiler has a memcpy as part of it standard C library.
And as since it is part of the standard C library it is Cross Platform.

Now it can be true that the implementation of memcpy can vary, it is for the most part fine to use and should get the same results no matter what type of system your on.

Now if you want to get a little better performance then there are memcpy like functions that use MMX or other instruction sets to achieve greater speed.

Lord Bart


#11 quorn3000   Members   -  Reputation: 819

Like
Likes
Like

Posted 16 February 2004 - 02:45 AM

Write copy constructors for your classes and use std::copy. It will copy the data correctly instead of just doing a bitwise copy. This is partly what SabreMan means by not undermining the type system.

If you have POD types that are no more than C-style structures then std::copy will be doing what memcpy does anyway.

[edited by - petewood on February 16, 2004 9:46:37 AM]

#12 DrPizza   Members   -  Reputation: 160

Like
Likes
Like

Posted 16 February 2004 - 03:01 AM

quote:
Type of system is exactly why you should use memcpy and its friends. And what C/C++ program that does anything complex doesn''t use some were direct memory manipulation?


He said "type system", not "type of system".


#13 Lord Bart   Members   -  Reputation: 226

Like
Likes
Like

Posted 16 February 2004 - 03:25 AM

Opps,
Ok I see my misunderstanding, my mistake, sorry SabreMan.

type system (type safetly(checking) system) vs type of system (implementation on a system), I inserted "of" when reading it.

Anyway be very careful of the std::copy method.
Remember std::copy must work for all std container classes and as such must loop trough all elements.

I believe it breaks down into a loop of assignments which is great when dealing with classes/structs, which is good and has type saftly in it.

But if your just going to copy memory around (ie texture, array data, etc) memcpy is going to do it faster then the looping assignment of each data element.

With memcpy you loose type safety but gain speed, and since the programmer is god to the program he should know when to use ethier method and understand the good and the bad of his choice.

Lord Bart


[edited by - lord bart on February 16, 2004 10:27:10 AM]

#14 DrPizza   Members   -  Reputation: 160

Like
Likes
Like

Posted 16 February 2004 - 03:44 AM

AFAIK there''s no reason that std::copy with pointers to primitives (at the very least) cannot itself call memcpy as a specialization.


#15 Cipher3D   Members   -  Reputation: 340

Like
Likes
Like

Posted 16 February 2004 - 03:49 AM

if you''re looking for speed using asm.

and if you''re uberleet reinvent-the-wheel type, write it in asm, and then implement the type safety that std::copy includes...that''s what i did...ugh...nightmares for about two years....

#16 quorn3000   Members   -  Reputation: 819

Like
Likes
Like

Posted 16 February 2004 - 04:15 AM

quote:
Original post by Lord Bart
With memcpy you loose type safety but gain speed


The first half is right the second half isn't necessarily right.

[edited by - petewood on February 16, 2004 11:15:29 AM]

#17 Lord Bart   Members   -  Reputation: 226

Like
Likes
Like

Posted 16 February 2004 - 04:36 AM

quote:
Original post by DrPizza
AFAIK there''s no reason that std::copy with pointers to primitives (at the very least) cannot itself call memcpy as a specialization.



That is the problem, specialization it can''t!
std:copy does not have the info needed in order to determine if it can specialize to a memcpy. It is a templated function and is made as generic as possible to work with all std container classes and arrary of classes/structures or primitives.
How is it to know it was passed only primitives?
So the only hope it has to work with all things passed to it is to do a loop with assignment on each element.

Lord Bart

#18 Enigma   Members   -  Reputation: 1402

Like
Likes
Like

Posted 16 February 2004 - 04:53 AM

quote:
Original post by Lord Bart
That is the problem, specialization it can''t!


Yes it can, using template specialization. If you want proof, try compiling an example program under gcc. You''ll find that memcpy and std::copy run at exactly the same speed (at least for floats, I didn''t try it on anything else).

Enigma



#19 SabreMan   Members   -  Reputation: 504

Like
Likes
Like

Posted 16 February 2004 - 05:00 AM

quote:
Original post by Lord Bart
std:copy does not have the info needed in order to determine if it can specialize to a memcpy.

The compiler has the information, and the Standard Library implementer can use that information to create specialisations of memcpy.
quote:

It is a templated function and is made as generic as possible to work with all std container classes and arrary of classes/structures or primitives.
How is it to know it was passed only primitives?

I don''t want the comedic value of your posts to be completely removed, but perhaps come back when you''ve learned about template specialisation.


#20 SabreMan   Members   -  Reputation: 504

Like
Likes
Like

Posted 16 February 2004 - 05:22 AM

quote:
Original post by Cipher3D
and if you''re uberleet reinvent-the-wheel type, write it in asm, and then implement the type safety that std::copy includes

What do you mean `implement the type safety''? If you are talking about laborious manual adherence to a set of conventions, then that is not what is usually meant by type-safety, as its only as certain as the assurance that the convention is always followed. In turn, an assurance that the convention is always followed is only as certain as the mechanism used to ensure that the convention is always followed. See the problem? For this to actually work, you have to use asm to implement a compiler for a language which is type-safe, and then write programs in that language, in which case you are not `writing it in asm''.

If you''re going to make such an argument, you may aswell just use memcpy and invent a convention that you never use it in a manner which violates type-safety. But then you need that assurance. This is what I mean by `undermines the type-system''. I''m not saying you will necessarily violate the type-system, I am saying you can''t be sure your programs are type-safe, since you''re disabling the assured mechanisms for reporting violations.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS