Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 May 2010
Offline Last Active Dec 21 2012 06:19 AM

Posts I've Made

In Topic: Is using std::move() necessary?

19 July 2012 - 05:35 AM

Then it would indeed make sense to move it.

Just a side note about that though. If you're doing this to make use of move semantics and gain performance, you might actually not get much out of it. The indirection caused by the pointer may actually take more time due to cache misses than copying a small matrix, like 4x4, that's already present in the cache. The performance would be obvious in larger matrices of course. I recommend you do some tests, if this is for optimization.

In Topic: Is using std::move() necessary?

19 July 2012 - 04:32 AM

Another thing to keep in mind is why you'd want to move it. If your matrix class is flat and contains the data itself, there's no point in moving it.

Moving for optimization's sake only ever makes sense when a class holds pointers to data that it owns on the heap. In such case the move result in only the pointer being moved and thus the heap data stays put and is now owned by the newly located object. In comparison: a proper copy/assignment operation should copy all the data pointed to as well.

But if the class contains all its data directly it will have to move (copy really) each value in the class to the new location anyway. It's the same procedure whether you copy it or not and you wont get any performance gain. Only reason to use move in this case would be to make absolutely sure that the data is unique to one instance, but since it's a matrix class this wouldn't make sense.

In Topic: [Help] How do you properly organize game architecture?

06 July 2012 - 01:03 PM

In simple words, a message queue is where messages are stored until they're handled. Call it a buffer if you'd like. If you've ever used SDL, its events are put into a queue, which you pull the events from at a good time in your main loop. A message queue is required here because your program can't just stop in its tracks when ever SDL receives a new input and asks your program to handle it. Instead, you get the option to look at it later.

This is called asynchronous message handling. You fire off an event and it may be handled at what ever time the receiver thinks is a good time. Much networking works like this and things like Node.js make use of it to a great extent.

The opposite is synchronous message handling in which case something fires off the event and wont continue execution until the event is handled. No queue is required here, because the receiver will only handle one message because the sender wont be able to send more than one message at the time.

Apart from being essential for networking and multi-threading, a message queue can also be used if you want to send events that wont be handled until the next game turn or "tick". Of course, a message queue can be polled at less frequent intervals.. I don't have much say in that. But the most normal use would be for it to handle events each iteration of the game loop.

In Topic: Global variables in comparison to #define

05 July 2012 - 05:42 PM

So basically you're all saying that if I can use a global constant rather than a #define, I should?

You can only benefit by doing so. Const values can be defined in headers as well. If you need a global variable (god forbid) you'll have to use the extern keyword in the header and define it in an implementation file.

In Topic: Separate headers for declaration and definition

05 July 2012 - 05:34 PM

I used to put all #includes in a header for a specific implementation file with its declarations. This is of course problematic if that header has to be used by other headers for other implementation files, causing them to include a whole lot of other headers. My solution which is a bit in the middle, is simply to take all the #includes that aren't mentioned in the declarations in the header file can be moved to the top of the implementation file.

For instance, a class uses std::string in its interface and uses std::stringstream internally. Putting only the #include <string> in the header and the #include <sstream> in the implementation file, since code referencing to this class need not know about what's used by the implementation.

It helped my compile times a lot.. but maybe I'm doing something now that every one is doing by common sense from the get go. =P

How many use the monster headers with all an implementation's includes put into them? (Of those who aren't using forward declaring headers)
Might just have been me...