Recommended Posts

return 0; return 1; which one is failure and which one is success? I return 0 from main if nothing goes wrong but a lot of other things use 0 as a fail flag. Calling a function like if(!func() ) { /*error*/ }. And is using a linked list too much for animation purposes with a sprite? Having the last frame loop back to the first frame instead of iterating over an array?

Share on other sites
First, main should return 0 if there are no errors.

Second, with a linked list, you don't know how the data will end up laid out in memory. However, the overhead of iterating through a linked list is probably not significantly different from the overhead of iterating through an array. Therefore, I would recommend an array because it will guarantee good spatial locality.

Share on other sites
I've always used 0 as failure. !function seems much more like "failure" to me.

Share on other sites
Yes, I agree !function seems like failure, like testing for NULL, and a lot of code seems to use that.

But returning non-zero for failure opens up the possibility for different errors. Like AUDIO_ERR=1, INIT_ERR=2, SUPER_BAD_ERR=4. Whereas success usually comes in one flavor.

For the animation question, I would use an array, as a linked list seems overkill. Afterall, you know ahead of time how many frames are in the animation sequence. But my friend says there is no performance difference, and doesn't want to keep track of the array and the counter, when you can just deference the next element in the animation list.

Share on other sites
Linked lists are also overkill for this as they use extra memory (more things need to be stored)

Share on other sites
setFrame(frames[++currFrame]);if(currFrame == maxFrames)  currFrame = 0;

Share on other sites
but in contrast
curr_frame = *(curr_frame.next);// or if that's a pointercurr_frame = curr_frame.next;

Share on other sites
The array will have better caching performance. It might be miniscule, but miniscule savings add up quickly. One drop at a time, the pot is filled.

Share on other sites
Quote:
 Original post by moagstar *** Source Snippet Removed ***

Agh. Don't go indexing the array before you've corrected for the loop-back condition.

currFrame = currFrame + 1 % frames.length(); // assuming std::vector
setFrame(frames[currFrame]);

Anyway. I'd go with the array (well, std::vector) simply because getting real (idiosyncratic) benefit out of the linked list would require a circular linked list, and the STL list just doesn't do that. (And rolling your own is not terribly much fun, especially the part about making sure all the links are right when you add or remove something.)

Share on other sites
You could use stl::vector instead of the array. Presumably you'll know how many frames of animation you have, so you can reserve memory before filling the vector:

vector<Sprite> animation;
animation.reserve(numFrames);

//now populate frames

Vectors offer all the efficiency benefits of arrays (the STL *requires* vectors implement their underlying storage as an array) but also offer additional benefits such as automatic growth, helper methods and standard STL algorithms. Assuming you're using C++ of course.

For your own functions, I'd recommend 1 == success, -n = failure. That way, negative numbers can be used to signify different errors. You could even have different (positive) success codes if you required it.

HTH,
Kent

Share on other sites
meh - no point optimising until you find that the way you are doing things is a problem. Choose whatever is right for you - a linked list is valid and allows insertion and deletion of an underfined amount of animation stills - esp as you want it ciruclar. Arrays are also valid - esp if each of your animations have the same number of stills (easy reuse via inheritance). But would need constant checking to ensure the index stays in bounds, and reset to zero at the top.

Don't be afraid of using STL stuff either if it fits your needs... you don't always want to roll your own and sometimes it can be counter productive.

The returning thing depends entirely on the contract of the function. Some Win32 apis return 1 (TRUE) for success. Where as some WM_ messages expect 0.

As a rule, try not to concentrate too much on the details until you have some kind of structure for your application established.

Share on other sites
Quote:
 Original post by ZahlmanAgh. Don't go indexing the array before you've corrected for the loop-back condition.

Yes your right, rushed that post, the lines should have been the other way round

Share on other sites
Quote:
 Original post by TelastynI've always used 0 as failure. !function seems much more like "failure" to me.

This is purely a view of our mind. None (may it be 0 or nor zero) is a correct failure flag. From a semantic point of view, how could a value which can represent both something correct and something wrong be OK?

But I understand this is not the point of this discussion :)

An error return value should match the semantic of your method/function. If it returns a pointer, then return NULL should indicate a problem (tes: if (func()) error. If it returns a position in a string, then the error should be return -1 (test: if (func()<0) error). If it returns a positive unsigned integer (a file descriptor, for example), the error should be signaled by return (unsigned int)(-1) (test, assuming 32 bit integers: if (func()&0x80000000) error. If your function returns a boolean, return false is the error. And so on.

The base idea is:
* make it consistent with your semantic
* wherever you can use positive logic, use it (positive logic does mean that you'd better call a function (isOk() which return true when it is OK than a function isBad() which return true when it it bad. The two are the same, but the first one is easier to use).

HTH,

Share on other sites
Quote:
 Original post by Boderreturn 0; return 1; which one is failure and which one is success?I return 0 from main if nothing goes wrong but a lot of other things use 0 as a fail flag. Calling a function like if(!func() ) { /*error*/ }.

0 stands for false and 1 for true, so logically 1 can go for success.....

Quote:
 Original post by BoderAnd is using a linked list too much for animation purposes with a sprite? Having the last frame loop back to the first frame instead of iterating over an array?

Hey not a bad idea, try it out.It would do away with a few computations ;)

Share on other sites
Does the operating system even look at whether your main function returns
1 or 0? Sometimes i declare

char* main()
{
//whatever

return "Hello"
}

Or somthing like that and it seems to make no difference.
Just curious.

Share on other sites
if you are creating a console program, then you can check the program return code with ERRORLEVEL. If you are calling your program from a makefile, then make (or nmake, or gmake) checks the return code to know whether there had been an error or not.

HTH,

Share on other sites
Quote:
 Original post by squirrelman3000Does the operating system even look at whether your main function returns1 or 0? Sometimes i declarechar* main(){...}

At least in gcc when I try to do something like that, the program won't compile.(the compiler says "main should return int").

Share on other sites
I use my return values as 'error meters', returning 0 for success, 1 for a general error, often specified by the error code that is set, and anything above 1 is specific to each function.

However, now that I look at this discussion, perhaps things would be a bit clearer, not to mention nicer, if 0 was error, 1 was success, and everything above 1 be the same as before :) A little more logical, if nothing else...

Share on other sites
0 for failure, partly because !function makes more sense, but also to be consistant with functions returning possibly null pointers.

It would be nice to have multiple error codes though. I suppose if one really wanted to, they could just return an Error class with the appropriate operators defined, and additional functions for error details.

Share on other sites
The OS doesn't care what you return from main() but other apps might. In particular 'make' and it's relatives expect 0 to mean success.

If it bothers you just remember that main returns an int, not a bool. 0 means no error, -1 is some error code, -2 is some other error code, etc.

Share on other sites
I feel 0 should be for errors, and anything else should be success. The best part is that it works well with pointers. You can't return a non-zero pointer for an error and NULL for success, can you? Unfortuantly, virtually every other library I use uses 0 for success, so it's probably better to stick with that to avoid confusion.

Share on other sites
For wrapping an index value, which is better?

int index = 0;index++;if (index >= MAX_FRAMES) { index=0; }// orindex %= MAX_FRAMES;

Share on other sites
Quote:
 Original post by BoderFor wrapping an index value, which is better?*** Source Snippet Removed ***

It Depends on what you mean by "better".

If you mean "faster", then it still depends - on the size of the array, and probably a bunch of other things; I wouldn't dare call it one way or the other without profiling, and I wouldn't trust myself to write an accurate test of it either.

If you mean "easier to understand", then it still depends - use what makes sense to you. I find the % version to be perfectly idiomatic, and it appeals to me because it is concise. I also come from a mathematical background where I spent a lot of time doing stuff with modulo arithmetic. I'm sure many programmers would side with me on this one, having no problem with it.

Many others, I'm sure, would prefer to write out the if-logic, because it states the wrap-around more explicitly to them. It doesn't to me, because it's not what I'm used to, and so I have to think about both if-cases.

Share on other sites
Quote:
 Original post by squirrelman3000Does the operating system even look at whether your main function returns1 or 0? Sometimes i declarechar* main(){ //whatever return "Hello"}Or somthing like that and it seems to make no difference.Just curious.

I once returned 42 from main and then set a file load stream to main.cpp. It compiled fine but displayed the number "-80000". Pretty wierd...

Create an account

Register a new account

• Forum Statistics

• Total Topics
627718
• Total Posts
2978792

• 9
• 9
• 21
• 14
• 12