Say I have a class, something like the following;
class MyClass
{
public:
MyClass();
int a,b,c;
double x,y,z;
};
#define PageSize 1000000
MyClass Ar
You could use memcpy
for copying array of POD types. And it will be a good idea to add static assert for boost::is_pod
is true. You class is not a POD type now.
Arithmetic types, enumeration types, pointer types, and pointer to member types are POD.
A cv-qualified version of a POD type is itself a POD type.
An array of POD is itself POD. A struct or union, all of whose non-static data members are POD, is itself POD if it has:
- No user-declared constructors.
- No private or protected non-static data members.
- No base classes.
- No virtual functions.
- No non-static data members of reference type.
- No user-defined copy assignment operator.
- No user-defined destructor.
Let me give you an empirical answer: in our realtime app, we do this all the time, and it works just fine. This is the case in MSVC for Wintel and PowerPC and GCC for Linux and Mac, even for classes that have constructors.
I can't quote chapter and verse of the C++ standard for this, just experimental evidence.
You could. But first ask yourself:
Why not just use the copy-constructor that is provided by your compiler to do a member-wise copy?
Are you having specific performance problems for which you need to optimise?
The current implementation contains all POD-types: what happens when somebody changes it?
I will notice that you admit there is an issue here. And you are aware of the potential drawbacks.
My question is one of maintenance. Do you feel confident that nobody will ever include a field in this class that would botch up your great optimization ? I don't, I'm an engineer not a prophet.
So instead of trying to improve the copy operation.... why not try to avoid it altogether ?
Would it be possible to change the data structure used for storage to stop moving elements around... or at least not that much.
For example, do you know of blist
(the Python module). B+Tree can allow index access with performances quite similar to vectors (a bit slower, admittedly) for example, while minimizing the number of elements to shuffle around when inserting / removing.
Instead of going in the quick and dirty, perhaps should you focus on finding a better collection ?
Calling memcpy on non-POD classes is undefined behaviour. I suggest to follow Kirill's tip for assertion. Using memcpy can be faster, but if the copy operation is not performance critical in your code then just use bitwise copy.
When talking about the case you're referring to I suggest you declare struct's instead of class'es. It makes it a lot easier to read (and less debatable :) ) and the default access specifier is public.
Of course you can use memcpy in this case, but beware that adding other kinds of elements in the struct (like C++ classes) is not recommended (due to obvious reasons - you don't know how memcpy will influence them).