SDK samples and C++ 'new operator'

I hate overloading function names, I don't know why that is a good thing honestly, perhaps you can change the new "new" to "OVRnew" or something like that

"Ametcalfe74" wrote:
In OVR_types.h there is a redefinition of new that the comments say is to help with debugging memory leaks and should be removed for release builds.

This only occurs if you define the preprocessor macro OVR_BUILD_DEBUG, which should only be defined by the project files for the sample applications. If you're sure it's being defined it's probably because you copied the project files out of the SDK, or copied the defines settings for some reason. Remove that definition and it should work fine. Alternatively, you can use this code to restore the original definition of new.

#include <OVR.h>
#undef new

Sorry for nercroing this thread.

Some short explanation of the problem. I'm working on implementing the rift in our engine, problem is though that it's alot of legacy code written by some C-programmers that had no idea how to do stuff the proper way in C++.

Which means that new/delete operators are now overloaded globally...

I currently use the 0.2.5c SDK build and I can't find anyway to get around the OVR_Allocator. They kinda clash and it seems like OVR_BUILD_DEBUG doesn't control the overload of new/delete anymore.

So is there anyway to get past the allocator? Thanks in advance.

Also, why do a hardware API overload new/delete?.. How much resources is there to handle. I've worked with a lot of other APIs(D-box, kinect, different joysticks), but never encounter and API that seems to contain so much stuff that isn't needed.

"feroza" wrote:
Also, why do a hardware API overload new/delete?.. How much resources is there to handle. I've worked with a lot of other APIs(D-box, kinect, different joysticks), but never encounter and API that seems to contain so much stuff that isn't needed.

The impression I've gotten working with the codebase and from previous communications with OVR is that the coding style and policy is a legacy of the fact that most of the code has been brought over from the previous company of the core developer group. The lack of use of STL and the internal implementation of many pieces of functionality may be a function of constraints of the original target platforms for that company that don't necessarily apply to the Rift. I'm hoping that with the hiring of Marshall Cline that the overall complexity of the SDK may go down, and that a clearer distinction between internal OVR SDK implementation logic and the exposed API be made in future versions of the SDK. Failing that, I'm eventually planning on doing a re-write of the SDK to accomplish the same ends, take full advantage of STL, C++11 and possibly Boost.

In the meantime it's not hard to segment your code so that interaction with the OVR SDK only occurs in a single CPP file and the issues with overloaded new and delete are confined to that file. Just make sure you undef new and delete in that file before including the OVR header.