• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

The C modest god

Alternative to memcpy in C++?

26 posts in this topic

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

Enigma
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
std::copy should ALWAYS be prefered to memcpy unless speed is of great important and you are copying POD types
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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]
0

Share this post


Link to post
Share on other sites
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".
0

Share this post


Link to post
Share on other sites
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]
0

Share this post


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

Share this post


Link to post
Share on other sites
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....
0

Share this post


Link to post
Share on other sites
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]
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Lord Bart
That is the problem, specialization it can''t!

You are wrong.

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

Of course it does.

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.

It is precisely through being a function template that it knows enough.

quote:
How is it to know it was passed only primitives?

Because it can see the types being used. It can see, for example, that the input range is defined by pointers to primitives and likewise the output range.

quote:

So the only hope it has to work with all things passed to it is to do a loop with assignment on each element.

Be quiet.
0

Share this post


Link to post
Share on other sites
Hello SabreMan,

I know about template specialization, but then that is a hassel unto it self.
Yes you can go right ahead and create your own specialization of copy for floats/ints (primitives) but then it is not part of the std template copy.
I haven’t every seen a std::copy template specialization for primitives, maybe there is one, but on the systems I seen std::copy on there is none.
It is up to the programmer to do it.

I don''t realy use gcc (at work it is DEC,SUN and MS compilers, though we been trying to push for use of gcc).
If the gcc compiler can correctly make a template specialization to use memcpy for primitives, well that is another reason to ask agian we start to use it.

Now that brings up porting, depending on how your compiler creates templates you might have to do some extra work to make sure your use the specialization and not the std::copy. (DEC compiler is real bad about template instantiations)

So I guess if not using gcc compiler, start to use it , otherwise loop with assignment of each element would be what you get unless your compiler can do what gcc can.
That is why I said be careful of std::copy.
Or create your own specialization copy for that primitive.

Lord Bart
0

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
quote:
Original post by Lord Bart
That is the problem, specialization it can't!

You are wrong.

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

Of course it does.

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.

It is precisely through being a function template that it knows enough.

quote:
How is it to know it was passed only primitives?

Because it can see the types being used. It can see, for example, that the input range is defined by pointers to primitives and likewise the output range.

quote:

So the only hope it has to work with all things passed to it is to do a loop with assignment on each element.

Be quiet.




Hello DrPizza,

I never said it could not be specialized, I guess what I should have said is this.
The std::copy in algorithm does not have specialization templates for primatives.

Yes I poorly worded post for your other points and you are correct, and I agree .

I was trying to say is if you just included algorithm and use the copy that is in it you would only get the std:copy that does loop and assignments. Unless your using gcc, which looks like it can create the specialization usinf memcpy automatically.

So unless your compiler is real good(gcc seems to be) or you create your own specialization template for the primitive you want, you should get the loop and assignment std::copy if you include algorithm, right?

Lord Bart


[edited by - lord bart on February 16, 2004 1:07:31 PM]
0

Share this post


Link to post
Share on other sites
It''s not up to the compiler; it''s up to the library implementation.

g++''s implementation uses memmove() if it can, though it is actually wrong to do this. std::copy() is allowed to clobber things in overlapping ranges; there''s std::copy_backward() to deal with overlapping ranges -- that should use memmove().
0

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
The compiler has the information, and the Standard Library implementer can use that information to create specialisations of memcpy.
I wonder...

That works alright for primitives, but what about PODs? AFAIK, there is no way for a regular programmer to determine at compile-time if a class has a non-trivial copy-constructor, but the compiler can make this kind of deduction. Is a Standard Library implementation allowed to make use of internal info given by the compiler to transform a std::copy(some_pod) into a mem_cpy?

Or perhaps, are there compilers smart enough to recognize a for loop that copies every member of every object one by one (if the copy constructor is inlined in the std::copy), and turn that into a mem_cpy?

Cédric
0

Share this post


Link to post
Share on other sites