Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 17 Dec 2009
Offline Last Active Today, 06:41 AM

Posts I've Made

In Topic: Slow down when using OpenMP with stl vector per thread

15 June 2015 - 05:55 AM

You could try using vector.reserve(n)

That should be the solution but is not worth to implement at the moment.

Wait, what? One line of code is not worth implementing?

In Topic: Malloc/Calloc question

06 June 2015 - 11:02 AM

After the line ptr += 50;, ptr points to memory you don't own, and you should not modify it with *ptr = 7;.

In Topic: Defning a namespace class in a header file

31 May 2015 - 01:37 AM

The reason you're getting the error is because in main(), you don't have the full definition of GameManager, you only know it exists by knowing its symbol name.


In order to instantiate anything, you have to know it's exact size, which you accomplish by including the header that has its whole definition, which is your second header.


This has nothing to do with namespaces. Namespaces are used to contain symbols in a named scope, so they don't clash with symbols with the same name from other libraries.


You should probably use namespaces like this:

//GameManagerFwd.h, used when you just need a forward declaration, but rarely actually used
namespace Logic
   class GameManager;

//GameManager.h, used when you need to instantiate the manager of call any of it's methods
namespace Logic
   class GameManager
      void init();
      void run();

//GameManager.cpp, here you can use two forms, where the first is more common
namespace Logic
   void GameManager::init()

void Logic::GameManager::run()

In Topic: New to templates - Compiler can't find member name

20 May 2015 - 12:32 AM

In your Path class header, add forward declarations to Node and Point:

template<typename T> class Node;
class Point;

Right now, the header file is not self sufficient, meaning if you look at the header file alone without considering any other inclusions, it has no idea what Node and Point are. So your fix to move the #include statements of Node and Point to it works because now the header knows what Node and Point are.


As far as best practices goes, forward declare what you can, #include what you must.

In Topic: Asset Loaders/Managers: One for all or separate instances?

18 May 2015 - 08:32 AM

What if for one of your loaders you decide it won't allocate resources on the heap, but rather pull them from an array or some internal memory pool? You're calling delete on all resources because you assume all of them will be allocated on the heap. It would be better if you'd call a release() method on the loader for every resource and let it decide on proper memory management.

For instance, you would be unable to use this resource manager for FMOD sounds nor DirectX COM objects without seriously modifying it because you should not call delete on FMOD::Sound* nor ID3D11Texture2D*.


You need to separate concerns. Loading stuff from files into memory, processing that memory into a structure/object/data, ownership+lifetime of the data, keeping a pointer to that data for repeated access via a key, mapping a user friendly name to the key... these are all different concerns, and different objects that do just that thing, and a manager, if there would be something called like it, would merely coordinate these objects into a series of function calls on these objects in order to give you a handle to the resource you need.