Comments for bigdavedev.com http://bigdavedev.com Tue, 21 Dec 2010 19:48:12 +0000 hourly 1 Comment on C++ does NOT need garbage collection! by Dave http://bigdavedev.com/?p=18#comment-5 Dave Tue, 21 Dec 2010 19:48:12 +0000 http://bigdavedev.com/?p=18#comment-5 The vtable is definitely a slight drawback, but you can either rethink your inheritance structure, or use static functions as these are guaranteed to be available in constructor calls. Alternatively, just code a solution that works best for you! I don't understand why doing stuff in the constructor is bad for testability. You can dump stuff to streams, you can step through them in debuggers. I would be interested in hearing his views on it though! The vtable is definitely a slight drawback, but you can either rethink your inheritance structure, or use static functions as these are guaranteed to be available in constructor calls. Alternatively, just code a solution that works best for you!

I don’t understand why doing stuff in the constructor is bad for testability. You can dump stuff to streams, you can step through them in debuggers. I would be interested in hearing his views on it though!

]]> Comment on C++ does NOT need garbage collection! by Jonny H http://bigdavedev.com/?p=18#comment-4 Jonny H Tue, 21 Dec 2010 10:05:59 +0000 http://bigdavedev.com/?p=18#comment-4 Hey Dave! Really liking the website. RAII is definitely a usefull tool, especially when implementing various standard design patterns (the command pattern for instance). Something that doesn't work well with RAII though is inheritance and virtual methods. You can't really safely call a virtual method in the constructor/destructor because the vtable isn't fully constructed. Would you say that if you run into this issue then your RAII implimentation is flawed and needs redesigned? I kept hearing Mark talk about doing stuff in the constructor as being bad for testability. I don't really know too much about that though, testing is for the weak! :P Hey Dave!

Really liking the website.

RAII is definitely a usefull tool, especially when implementing various standard design patterns (the command pattern for instance). Something that doesn’t work well with RAII though is inheritance and virtual methods. You can’t really safely call a virtual method in the constructor/destructor because the vtable isn’t fully constructed. Would you say that if you run into this issue then your RAII implimentation is flawed and needs redesigned?

I kept hearing Mark talk about doing stuff in the constructor as being bad for testability. I don’t really know too much about that though, testing is for the weak! :P

]]> Comment on An effective game loop: Part 2 by An effective game loop: Part 1 » BigDaveDev.com http://bigdavedev.com/?p=95#comment-10 An effective game loop: Part 1 » BigDaveDev.com Mon, 25 Oct 2010 19:07:09 +0000 http://bigdavedev.com/?p=95#comment-10 [...] next article in this series will cover timing to keep consistent and smooth timing for your animations and [...] [...] next article in this series will cover timing to keep consistent and smooth timing for your animations and [...]

]]> Comment on An effective game loop: Part 1 by An effective game loop: Part 2 » BigDaveDev.com http://bigdavedev.com/?p=58#comment-9 An effective game loop: Part 2 » BigDaveDev.com Sat, 23 Oct 2010 13:41:27 +0000 http://bigdavedev.com/?p=58#comment-9 [...] part 1 we established our basic game loop for a Win32 system.  We discussed the two message retrieving [...] [...] part 1 we established our basic game loop for a Win32 system.  We discussed the two message retrieving [...]

]]> Comment on Memory leaks… by Dave http://bigdavedev.com/?p=43#comment-8 Dave Sat, 04 Sep 2010 19:30:49 +0000 http://bigdavedev.com/?p=43#comment-8 Rory: So instead of showing you the line where the memory was allocated, it shows the line where the pointer goes out of scope, causing the leak? That's pretty handy indeed! However, if you employ the RAII idiom, then the memory should be allocated within the constructor. Thus you would simply need to add the appropriate delete to the destructor. Scott: When I first discovered this, I was over the moon. I have almost no leaks thanks to the RAII idiom, and it having the output tell me that my application is clean adds piece of mind. It's either that or log all the memory allocation and deallocation! No thanks hehe. Rory: So instead of showing you the line where the memory was allocated, it shows the line where the pointer goes out of scope, causing the leak? That’s pretty handy indeed! However, if you employ the RAII idiom, then the memory should be allocated within the constructor. Thus you would simply need to add the appropriate delete to the destructor.

Scott: When I first discovered this, I was over the moon. I have almost no leaks thanks to the RAII idiom, and it having the output tell me that my application is clean adds piece of mind. It’s either that or log all the memory allocation and deallocation! No thanks hehe.

]]>