#96477 - Nave Adair - Thu Aug 03, 2006 3:21 pm
I have an array of enemies, like:
u8 enemy1[5];
So that gives me enemy1[0] through enemy1[4]. Say I wanted to extend it to six places, giving me enemy1[5], how would I do that, if possible?
#96498 - racarate - Thu Aug 03, 2006 4:33 pm
In C, use a linked list.
In C++, use a std::vector.
_________________
Neko: I love meow-tain climbing!
Need anything? I'll even save your game!
#96508 - Nave Adair - Thu Aug 03, 2006 5:12 pm
| racarate wrote: |
In C, use a linked list.
In C++, use a std::vector. |
Okay? Do you have an example or know of any decent tutorials on vectors?
#96520 - naleksiev - Thu Aug 03, 2006 6:03 pm
Linked list is something you defenetly need to learn.
Just look in google about "C++ linked list" and you will find a lot of information.
But depending from the game sometimes is better to add an array with the enemies even a little bigger that you will need most of the time. So you can have a flag is this enemy exist or it's just a part of the array that you still not using. The pluses in this case are that you do not need to allocate/dealocate memory all the time.
#96528 - sgeos - Thu Aug 03, 2006 6:12 pm
The alternative is to cap the size of the array instead of growing it.
| Code: |
int itemCount;
struct item item[ITEM_MAX];
for (i = 0; i < itemCount; i++)
doSomething( &(item[i]) ); |
-Brendan
#96532 - Optihut - Thu Aug 03, 2006 6:31 pm
Or how about using new and delete depending on how many items in the array you need?
#96535 - tepples - Thu Aug 03, 2006 6:36 pm
| Optihut wrote: |
| Or how about using new and delete depending on how many items in the array you need? |
Because 'new' throws exceptions, and exception handling brings in a whole lot of the C++ standard library, bloating the executable. Developers who have 256 KB of EWRAM to work with have to watch each kilobyte.
There is new(nothrow), but that's deprecated.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#96564 - sajiimori - Thu Aug 03, 2006 9:35 pm
Disabling exceptions is a reasonable thing to do. In fact, I'd strongly recommend it.
#96567 - tepples - Thu Aug 03, 2006 9:50 pm
| sajiimori wrote: |
| Disabling exceptions is a reasonable thing to do. In fact, I'd strongly recommend it. |
Can you link to a guide to disabling exceptions that results in zero (or negligible) exception-handling code ending up in the binary and applies to devkitARM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#96570 - sajiimori - Thu Aug 03, 2006 10:32 pm
Sorry, I don't use devkitARM. The usual GCC argument is -fno-exceptions.
#96581 - tepples - Thu Aug 03, 2006 11:47 pm
But does that disable exceptions in the standard library, or just exceptions in your own code? If a standard library component throws an exception, won't that bloat the binary in the same way? Is there a way to produce a linker warning if a library throws an exception?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#96605 - sajiimori - Fri Aug 04, 2006 3:39 am
I can't think of any component of the standard library that throws, off the top of my head.
In fact, I vaguely recall something about it being undefined if you throw an exception that unwinds through standard library code, which most often happens when you instantiate an STL container with your own type, and a contained object throws during the execution of a container method.
At any rate, when you choose to link in a library, you'd better know what you're taking on. Using ld directly is a good way to avoid accidentally linking in something you don't want.
Also, much of the standard library is composed of templates. Since these templates are compiled during your own build process, and using your own compiler flags, the build will fail if you set options that are incompatible with them. Setting -fno-exceptions means it's an error to use the 'throw' or 'catch' keywords, so you can rest assured that the templates aren't using them.
Edit: Not using exceptions has made me forget the cases when the standard library throws. The most common examples are out-of-memory errors, bad dynamic_casts, and various IO failures (which escape me entirely).
#96608 - sajiimori - Fri Aug 04, 2006 3:54 am
BTW, disabling exceptions should cause your compiler suite to react appropriately. For example, my compiler at work handles bad dynamic_casts by calling abort().
#96609 - tepples - Fri Aug 04, 2006 3:54 am
| sajiimori wrote: |
| I can't think of any component of the standard library that throws, off the top of my head. |
Don't std::ostream and std::string both call new, which throws? And isn't use of C equivalents in <cstdio> and <cstring> deprecated in C++ code?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#96618 - sajiimori - Fri Aug 04, 2006 4:37 am
As I understand it, according to ISO C++, there is no such thing as "disabling exceptions." Exceptions are part of the language, and that's that.
In practice, every compiler I know of provides the ability to disable exceptions, and lots of developers do it (especially on embedded platforms).
So yes, operator new can throw... according to ISO C++. My operator new does not throw, ever.
I haven't heard of cstdio and cstring being deprecated.