Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Trienco

Member Since 22 Aug 2001
Offline Last Active Yesterday, 10:00 PM

#5013886 What makes Debug different from Release?

Posted by Trienco on 24 December 2012 - 12:55 AM

So I made sure I was always set to Debug mode after this thread, and so far I haven't had any errors. But then I switched to Release to test something out, and now everything has been thrown into chaos again.

 

Which generally means that you still have some major bugs in your code and are simply lucky that those bugs don't have any visible consequences in debug mode, either because your data has a different and less tightly packed memory layout or because stuff is being initialized for you.

 

The most important lesson in programming: just because it compiles, doesn't mean it's working and just because it appears to be working, doesn't mean it isn't full of serious bugs. Especially when it comes to C/C++, "trial and error coding" will bite you and you should be knowing what you're doing every step along the way. Never "try" something and decide that if it doesn't crash right away it must be "correct" to do it that way.

 

If your bugs don't show in a debug build and a release build is too optimized or lacking debug symbols to be useful, you will want to copy your release configuration and change the settings, hopefully finding one where the bugs are still happening and you can decently debug. Otherwise, there is always caveman debugging, where you spam debug outputs all over the place to figure out where things are going wrong.

 

As for "how I can be sure it will work on other computers". That's why "testing" is a very complex subject of its own, involving unit tests, black/white box tests, regression tests and all kinds of other test strategies. Essentially writing tests will take up about the same amount of time as writing the actual code (at least if you want to do it "right").




#5013400 Using a pointer to point to a new object every frame

Posted by Trienco on 22 December 2012 - 07:28 AM

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.




#5012713 Calculating prime numbers with memoization

Posted by Trienco on 19 December 2012 - 11:21 PM

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


#5011547 Trouble with copy constructor

Posted by Trienco on 16 December 2012 - 11:22 PM

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.


#5010079 Bullet animation

Posted by Trienco on 12 December 2012 - 11:34 PM

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.


#5009334 Crash in std::set::insert()

Posted by Trienco on 10 December 2012 - 11:24 PM

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.


#5008988 2D Platformer - Shooting in the direction of the mouse cursor

Posted by Trienco on 09 December 2012 - 11:08 PM

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.


#5008397 Transferring from java to c++

Posted by Trienco on 08 December 2012 - 12:26 AM

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.


#5006977 C Do/While Loop problem

Posted by Trienco on 03 December 2012 - 11:37 PM

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


#5005961 Is C++ too complex?

Posted by Trienco on 01 December 2012 - 01:10 AM

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.


#5004115 Code::Blocks "warning: deprecated conversion from string constant to ‘ch...

Posted by Trienco on 25 November 2012 - 11:24 PM

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.


#5003384 [C++] Delayed action of srand() - coordinates for object

Posted by Trienco on 22 November 2012 - 11:27 PM

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.


#5001444 Completed Tic Tac Toe - Critical Critiques and Advice

Posted by Trienco on 15 November 2012 - 11:18 PM

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.


#5000465 Switch vs if else

Posted by Trienco on 12 November 2012 - 10:59 PM

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.


#4997877 C++ pointer strangeness

Posted by Trienco on 05 November 2012 - 11:31 PM

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




PARTNERS