Trienco

Forward declarations should be used if you only need a pointer or reference to minimize includes. Making every member a pointer and basically screwing up your design, just so you can use forward declarations isn't going to make your code cleaner. The consequences will be far messier than just having that include. Are you deleting the object behind the pointer in the destructor? Did you create a copy constructor and assignment operator to prevent crashes from deleting it twice (or at least make your class noncopyable)? That's a lot of extra code and effort just to be able to avoid that one include.

 

I'm also not sure how it's supposed to save you code. Whether it's "include xxx" or "class xxx", you are going to have this one line of code.

Of course replacing the static value of sqrt(i) with a multiplication that needs to be done on every iteration will eventually be slower, if your i gets really big (as in "unlikely big").

The biggest performance issue in the original code would seem to be doing the sqrt in the loop condition and pointlessly calculate it every single time (unless the compiler is friendly enough to optimize that out).

You seem to be getting lost in your own variable names. pHeap is created, assigned and then never used for anything.

It's also weird that the code in front of your loop is exactly the same as the one inside the loop. Also, where are you setting up the next pointers? From what little code I can see, all your nodes next pointers are either pointing to the original list or to random garbage.

Your test should be to print out both lists with the players name and the address. If your code is working, all the names must be the same, but the addresses must be different.

If you don't mind a bit of headache, you can usually avoid all the "is this the head?" or "is the head NULL?" special cases by using pointer to pointer (ie. pointer to next pointer instead of using next pointer directly, so your head elements turns into just the first "next" element). But that isn't something to worry about until stuff is actually working in the first place.

4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.

This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.

Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.

Now I completely solved the problem.
I have no idea why the crash occurred.

Not to rain on your parade, but those two statements are usually mutually exclusive.

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..

dynamicmounting.com

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.

Of course reversing a string in C++ is kind of boring:

string original("some text");
string reversed(original.rbegin(), original.rend());

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".