Not sure why anyone would want to deal with angles, when your problem sounds like all you want is "mousePosition - shooterPosition". If all throws are supposed to be equally strong, normalize and multiply with appropriate value. Otherwise just multiply with appropriate factor (and maybe clamp). However if distance to player decides initial speed, it makes aiming weak throws more difficult.
Neither is going to help you learn C++, especially since both are pure C APIs. You might be better off trying to use C++11 features or boost. While it's not a big difference, SFML might be a better choice than SDL in that regard as well.
Result being uninitialized and as such potentially x, not even entering the loop is exactly the kind of bug I love so much. "We have a few customers reporting a really weird bug, but we are completely unable to reproduce it and have now wasted several weeks running test scenarios on a bunch of machines and staring at many thousands lines of related and semi-related code to figure it out. Turns out somebody ignored #1 in the coding guidelines: ALWAYS immediately initialize your variables and never justify laziness with 'better performance'."
So if x is unknown, you would have to initialized with something like "result = x+1" to be safe, resulting in awkward code that is more confusing than it has to be..
I am still of the opinion that exceptions are too costly to use for anything but exceptional situations.
To be fair, that's why they are called "exceptions" and not "common stuff happening" or "code flow control construct". As such you could easily argue that someone using exceptions for situations that aren't actually "exceptional" errors is probably using them wrong.
vector::at throwing at an invalid index is fine (it IS kind of a big screw up), std::find throwing if an element isn't found would be silly (as it's a perfectly expected case). Which leads to a nice anti-pattern called "expectation handling".
c++ is not too complex, just you need some dedication and you can easily learn the c++... first try to learn c it will help you in learning c++ easily and in efficient manner..
Strangely enough, everytime I hear someone claim "C++ is easy" it is accompanied by "C with classes" and the person in question not even knowing enough about C++ and its countless dark corners to realize just how little he/she actually knows.
I use tolua++ to generate Lua bindings and unfortunately, as it currently stands, the generated binding code is filled to the brim with these warnings.
Maybe I'm confused by the name, but ++ suggests that it creates bindings for C++. Everything producing "char*" instead of "const char*" (unless the function might actually modify the string) should be considered flat out broken and worthy of a bug report. Mostly because I'm extremely sick of having to add hacks and workarounds when using C++ strings and c_str. Casting away the const feels like slapping a time bomb and copying the string to a vector<char> is just irritating.
Well, L.Spiro has a version that will at least trigger at all (when one coordinate is getting close enough), while the other version looks like in the end the ball will reach one coordinate first, then start jittering around on one axis, move only along the other axis and finally find a new destination. It also means that if one coordinate is reached, the balls will effectively move at only half the speed.
So obviously I second the approach of using vectors, simply because the other code only allows for 45° steps in motion and I doubt that sudden changes of direction while heading towards a destination are intended.
I think you will get the most in terms of learning experience and better design by not assuming a fixed board size and hard coding every possible win condition. After all, the real core of programming isn't knowing language X or memorizing whole libraries, but about problem solving.
How would you write it, if the board size can be configured to 4 or 5? Ironically, you should find that your code will get a lot shorter, cleaner and contain way fewer messy if-else and switch-case constructs.
Once that is working, how would you handle the win condition not being n in a row (where n equals the board size), but a value that can be configured independently? You should find this to be a very small adjustment to your existing code (okay, I'm lying, unless you didn't realize that only two diagonals need to be checked for n = board size).
What if the board doesn't have to be square? Again, this should end up being only a minor change.
That's a bit too general, don't you think? Without using switch or a bunch if-else statements, what does an event dispatcher look like? How do you implement a factory function?
Event dispatchers can use runtime type information or simply strings and just forward events to all handlers that registered themselves for certain message types. I'd actually be a bit sceptical if my event dispatcher starts switch/casing over event types. Same for a factory. A factory using a big switch/case is usually considered the "naive" approach and while typically good enough, it's probably the least desirable implementation. Generally you do not want to touch your factory (or event dispatcher) every single time a new class/message is added.
It also avoids all the other bugs and issues in the C-style implementation above (loop too short, calling strlen on every single iteration, passing pointer by value, the dreadful "function internally allocating memory" thing).
Of course now you have to ask yourself who is responsible for cleaning it up and when should that happen. Rule of thumb: for every "new" that isn't assigned to a smart pointer, there must be one (and only one) "delete".
This piece of code: "rand() % 9 + 1"generates a number between 1 and 10. In C++, arrays begin at 0, so you may not want the +1 there. (An array with 10 elements, goes from 0 to 9)
Nitpick: the number will be between 1 and 9.
About the implementation of the second option. You actually fooled me, as my first impression was you determine a number between 0 and emptySpaces, then make as many steps from the start (skipping filled spots). In that case you should never have to wrap around. But with your approach of starting at the selected spot and then skipping ahead until the first free cell, is the first part even necessary (as in: does it produce better randomized results)?
My impression would be that it might make it less random. If the first 4 spots are filled, you would ways end up with the 5th spot: 5 spots are empty, so spot = rand() % 5 = 0-4. In each case you get spot = 4.
So I think you should either always create numbers 0-8 and skip empty spots as above, or if you do create a number using only the free spots, it would probably be something like this:
int steps = rand() % numberOfEmptySpaces;
int spot = -1;
while (steps >= 0)
//If free, decrease step count
if (board[spot] != 'O' && board[spot] != 'X')
I believe that should create an equal probability for each spot.
Alternatively (and somewhat more cumbersome) you could add an extra layer of indirection by keeping a list of empty spots and randomly picking an index from that list.
//Declared somewhere and initialized with the board
vector<int> freeSpots; //Fill with 0 - sizeOfBoard
const int idx = rand() % freeSpots.size();
freeSpots.erase(freeSpots.begin() + idx);
Since erasing from anywhere but the end of a vector requires moving stuff in memory, a common method is to not remove a value, but swap it with the end and reducing the size of the vector.
By not removing the last element and instead keeping track of the size yourself, you can keep reusing the same vector and just need to reset the size
vector<int> freeSpots(SIZE_OF_BOARD); //Initialize once when starting up
//When placing a marker
//When resetting the game
numberOfFreeSpots = SIZE_OF_BOARD;
Since all random numbers should be equally likely, it doesn't matter in which order the numbers are stored in freeSpots.
Personally I like this approach for simulating a deck of cards, as you don't need to do any initial "shuffling".
Maybe he forgot to mention something like "for 1 billion test runs". In either case it doesn't really matter, since it has little to nothing to do with the actual topic. It's not about converting string<->int, but essentially about subtracting one number from another (while skipping values outside a certain range and using a different offset depending on which range you're in).
At no point should stringstream, atoi, etc. have anything to do with it.