I decided to take a break form game programming books and do some good reading on the C++ language.  It has been a few years since I just studied the language, mostly because once I graduated from collage with my programming degree I have been busy using my new skills.  Anyways I found this book to be interesting and wanted to update my C++ skills a little since many things have changed.  Join me on this wonderful journey as I read through another book and post my thoughts on the book and what it covers.

Okay so I stole a little line from Shakespeare in this blog title. The question is when should be use braces and when should we not use them when instantiating an object.

The author has clearly got a great talent for writing something so technical it is hard to follow.  The quagmire explanation at times gets so confusing that event the answer to brace or not to brace still seems confusing. Most of the time I think it would be safe to use a brace instead of a bracket or parenthesis.  But then we are thrown a myriad of exceptions when this will be a problem.  Event if you're using C++11 or C++14 you may run into specific issues where the compile will not know what you mean.

The bottom line so far for me is use try and use them for instantiation cases and for the most part you will be safe.  But like any time you're learning a new technique or in general building software make sure you do enough testing you know what to expect!

If you are a class author then make sure you read his chapter on braces and understand all the construction rules that could cause you potential bugs and headaches.  Design your classes properly to help avoid some of the potential gotchas.

Today I was able to get through the preference and the first chapter.  The odd thing is when I was reading even the author said most of the stuff in the first chapter was just mind numbing and very boring to read.  My question is if this is the case then why not spice it up a little and make this material a little more understandable.

With that in mind I plodded through this first chapter and read a lot about the auto feature of C++11 and C++14.  Most of what I take from this chapter is that the new auto feature is another way of using template in place of using a type defined variable.  Granted there is a lot more to this subject then what I just said but hey I’m still trying to make sense of what I read.

As I was reading through this quagmire of information a few ideas started to percolate on how I could rewrite my event system.  The couple of experiments I tried failed but it got me thinking about a couple of problems I have faced with my current event system.

1. It currently only supports pointers to a function.  This is problematical when you want a method in a class to be called instead.
2. Events are dependent on the frame rate and everything is running through a single core.
3. Events are very simplistic and use very generic parameters

This is just a few things I have ran into on the event system but the good new is most of the drawbacks have been easy to work around.  But my current goal is to make it even easier to use and provide a more flexible way to pass in callable code based on event triggers.

Back to my reading though it has been very insightful why the auto definition may speed up my code.  The author explains in very clear terms in certain places where the auto feature will make your code faster in some loops.  I still not completely convinced it make the code easier to read and even the author admits some time the auto feature has a hard time properly defining the variable.  Like any new automated system there maybe gotchas that we need to avoid.

Personally I feel that if you need a language that is easier to program then maybe C++ isn’t the language you should be using.  On the other hand who want to write this declaration out 100 times in your class:

	list::iterator it...

Then add on top of this the namespace location for your class definition and this simple line could get super messy. So with auto this same line would be written as:

	auto it = myList.begin()...

Before you jump on the bandwagon and start using the auto feature I highly recommend you do your studying on this subject. You will need to know a couple of things when it comes to tracking down bugs. This feature has the potential to really introduce major buggy code and without some good debugging skills it maybe impossible to track these bugs down.

Fortunately for me I have this book to read and he goes over several really cool debugging steps to make it easier to find what type a variable is being assigned when it is not so obvious.