Where do the components "live"? Getting into implementation specifics, I'll be writing this in C++. So, for the sake of example, let's say I have a position component, a velocity/movement component, and a motion system which acts on both components.
Would it make sense for each entity to have a data member container consisting of pointers to components? If so, how would the motion system keep track of which entities have position and velocity/movement components? Or maybe a better way of phrasing the question is: How does the motion system keep track of which components it needs to iterate over when it runs?
When I look at diagrams and read articles about ECS, everything seems to make sense to me. But when I sit down with a pen and paper and try to map out the class relationships, my level of understanding starts to break down.
Edit: I've thought about this a little bit more, and maybe the a good approach would be to have each system contain a container of pointers to entities that contain a matching set of components. This would mean that every time an entity adds or removes a component, it would have to be examined by each system to determine if it contains the right components to be used by that system. However, this also means that each system doesn't have to go through and check EVERY entity to see if it has the right components in every iteration of the game loop. Thoughts? Am I heading down the wrong path?
especially since C++ is a very poor choice of first language (and if you already know another language, you could be using that instead to start building games now)
In my opinion, this is somewhat subjective advice and should be taken with a grain of salt. Programming languages are tools, and I agree with the sentiment that if you already know how to use a tool to accomplish your goal, it might be a good idea to just go ahead and start hacking away. Game development is difficult enough without throwing the complexities of C++ into the mix at the same time.
However, if you're thinking long term and you have the patience, building super basic games in C++ as you learn the language might not be a bad way to start. It's a pretty powerful tool to have in your belt for a number of reasons. Just my 2 cents.
I prefer the first one as well. Like you said, I think it's much easier to quickly visualize how blocks are nested. I tend to use curly braces even for one line blocks just because I find it easier to read. The biggest counter-argument I've heard is that you can fit more lines of code on your screen using the latter.
However, as you seem to be aware, it's a highly subjective topic that will cause a flame war as often as not. Here's the most "objective" answer you're going to get:
If you're programming by yourself, use whatever is easiest for you to read.
If you're creating something new that involves other people, agree on a set of standards when you're planning the project and stick to them.
If you're working with an existing code base, adapt to the existing code standards for that project.
I've used bootcamp to install Windows and Visual Studio. Things like the keyboard layout weren't ideal, but other than that it worked fine for me. This was a little while ago so I was using Windows XP. I can't imagine you'd encounter substantial problems with Windows 7/8 as long as you're using a legit copy.
It's OK if things are unstructured when you start. It's part of the learning process and as you write more code you'll get a feel for what works and what doesn't.
That being said, the book "Code Complete" is a tome but immensely useful (this is different than "Game Coding Complete" and places more of an emphasis on general programming best practices). Reading up on design patterns would be helpful as well. It's not a silver bullet but it will give you an idea of how some common problems are solved and how the solutions are structured.
Finally, I'm not sure what you do for a living, and this is probably absurdly impractical advice but here it goes: One of the fastest ways that I improved my software engineering was by working at a software company with a lot of smart engineers. Things like peer code reviews are extremely helpful, as is working in a large codebase and getting a chance to see how other people do things. Again, I realize that you're not gonna switch careers just to improve a hobby skill (assuming that this is just a hobby), but the point is that if you find opportunities to read a lot of code and discuss code with other people, it will help a lot. Maybe looking at some open source projects would be helpful, as long as you somehow know in advance that the code in the project isn't crap to begin with :]
Sounds like a neat tool. However, if you're looking for opinions on it, I'd suggest posting this in the "Tools and APIs" forum as people come to this one with questions specific to game programming. You could also post it as an "announcement." Hope this helps, good luck!