Sign in to follow this  

Platform Independence (ZeroMemory!?)

This topic is 3720 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, so this post is actually about the ZeroMemory macro, but bare with me here... When thinking about the architecture, I’m not really trying to achieve a cross-platform architecture, but generally try to put up a layer of abstraction between OS specific APIs like DirectX and the OS (WINAPI) itself. Not that difficult really, but good if you decide to port your game at one point. But when I looked closer at the ZeroMemory (winbase.h) function in WINAPI I noticed it’s a macro for RtlZeroMemory which I only seem to find in the kernel driver documentation... and there is this other method RtlZeroBytes but obsolete, for better performance use RtlZeroMemory. I'm awfully confused why not memset would accomplish the exact same thing, obviously that seems to not be the case... Anyone care to shed some light?

Share this post


Link to post
Share on other sites
thanks, helps a lot

futher digging showed that the RtlZeroMemory was another macro defined as:

memset(Destination, 0, Length)

at this point is even more confusing as to why it's 2 macros for doing memset and that there's really no documentation on this detail...

i this just due to history or what?

Share this post


Link to post
Share on other sites
Yes it's history. ZeroMemory is a Win32 function. RtlZeroMemory is, strictly speaking, not a Win32 function.

The original NT kernel was designed to run several different subsystem platforms - notably OS/2, Posix, and of course Win32. The kernel has it's own API and RtlZeroMemory is one of them. Win32 API's wrap the native NT API's. In some cases the wrapper is extremely thin.

Share this post


Link to post
Share on other sites
In C++, prefer std::fill:


// Omitted all the relevant header declarations, except the important one:
#include <algorithm> // This is where std::fill comes from

class Foo {
// lots of complicated stuff here

Foo(); // the class does have a default constructor at least, but we'll say
// for the sake of argument that there are virtual functions, members of
// non-primitive types, pointers etc. such that simply zeroing out the memory
// of a Foo object is a REALLY BAD idea.
// The proper way to "clear" an array of Foos is to put a default-constructed
// Foo into each spot, which std::fill can do...
};

int main() {
std::vector<Foo> fooContainer;
int x[42];
char y[23];
// lots of magical code here that puts stuff in the containers.

// std::fill can zero out the arrays regardless of their type:
std::fill(x, x + 42, 0);
std::fill(y, y + 23, '\0');
// And it can blank the contents of the vector, too:
std::fill(fooContainer.begin(), fooContainer.end(), Foo());
// Although you would usually just .clear() the container and re-fill it :)
}

Share this post


Link to post
Share on other sites

This topic is 3720 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this