Jump to content

  • Log In with Google      Sign In   
  • Create Account

Jason Z

Member Since 04 Feb 2004
Online Last Active Today, 07:26 AM

Posts I've Made

In Topic: How dangerous is returning a initialized pointer in C++?

22 July 2014 - 09:21 AM

Second, and more importantly, on some systems (notably one major desktop operating system), shared libraries have (or may have) their own heap.
All the more reason for stack allocation!

In Topic: Math related to 3D graphics.

22 July 2014 - 05:00 AM

You probably won't be able to directly apply advanced calculus or real analysis to a computer graphics problem, except when you are setting up the basic parameters of your algorithm.  It might be beneficial for you to see some of the rendering techniques that are implemented in modern GPUs, such as in the GPU Gems series (part 3 is here).  That will give you an idea of what kind of analysis is needed and used for designing an algorithm.

In Topic: [Depth buffer] From linear -> non-linear depth values

22 July 2014 - 04:52 AM

Retrieving the result via the original projection matrix is an option yes, but for educational purposes I was interested in the equation.
This is obtained by using the original projection matrix, and just taking the z component.  As long as you know how your projection matrix is constructed, then you would have the symbolic equivalent of your equation quickly and easily!

In Topic: How dangerous is returning a initialized pointer in C++?

21 July 2014 - 08:58 PM


What are you trying to accomplish with this design?  You could just as easily stack allocate the EngineAPI object in your main function, and then pass around a pointer to that object.  This would control the timing of the object creation, it would trivially ensure that the object is destroyed when it goes out of scope, and there is no question of ownership or shared ownership.  I usually default to the simplest solution with the fewest strings attached to it, and unless you have a good reason to hide the object creation behind a factory/singleton hybrid method, I think you are unnecessarily complicating this!

ALl I'm trying to do is making the framework a bit more tidy then I think it is. In a framework shouldn't everything be interchangablly connected as in a car engine or even a tree? I'm probably like you said am putting too much thought in this framework design. I don't think the main ENgineAPI will be a singleton class. The way I see it as of right now - everything's fine I just have a habit of reworking on or redesigning on idea I have.


I'm not saying it is right or wrong - I'm just saying that it would be simpler and more safe if you stack allocate the object instead of the method you showed above.  There is no more or less dependencies on the implementation of your object in either method, so like I mentioned above, I would tend toward the simplest alternative.

In Topic: How dangerous is returning a initialized pointer in C++?

21 July 2014 - 08:55 PM

Actually, I think I'm starting to fall in love with smart pointers! I always loved the smart ones. At first it was confusing because I wanted to get the functions I made within that class or struct - you know? I never knew how until I read the tutorial about C++ 11 smart tutorials. I was a bit naive about the std::shared_ptr. So, I tried it on the graphics device struct and there was no worries about ever freeing up the initialized class - just had to dispose the COM objects created by DIrectX. Pretty sweet!
Smart pointers are a great tool, but remember what they are implying - they implement ownership semantics for the object they are wrapping.  If you have a shared pointer to your engine API object, then you are essentially saying that any object that has a reference to it is also an owner of it.  That means that if you have one outstanding reference, the object will not be destroyed.


That can be what you want in many cases, but the usage you point out above is not really one of those (at least in my humble opinion!).