Good evening all,

Getting an opportunity to get a bit of programming in again at night. Started back working on some concepts that interest me and right now the focus is on a simple terrain and A* path-finding. In an effort to learn bare bones I've not utilized any of the STL to date and have gotten away with Casey's bulk arena allocation and PushStruct / PushArray style container / memory management.

That was until I started turning some pseudo A* code into actual implementation code. Here for the first time, since the # of path points is unknown and I need to erase the open list, etc. I found that a dynamic array would likely be the best way to store the calculated way-points. In lieu of writing my own dynamic array implementation tonight, I started with std::vector and ran into a bit of trouble.

After an hour of research and debugging, I found the first push_back call provided an error that EHsc needed to be turned on. Purely from an educational standpoint, why does the STL vector require exception handling to be turned on?

Also if I decide to continue using the STL vector container moving forward, what is the biggest performance improvement technique? The one I'm assuming to prevent all the resizing would be pre-allocating size if it can be determined ahead of time?

Thanks in advance.

Because in C++ operator new throws exception (std::bad_alloc) when it cannot allocate memory. Which is used by default std::vector allocator.

Yes, easiest way is to simple have array with static max size and extra counter for keeping how many elements actually are in use. This is not really about performance, you won't see much difference from std::vector. But its more about ease of use, structuring your code and improving compile times (by not including thousands of lines of templates).

Btw if you don't know how exceptions work, or you are not using them in your code that means your code is potentially very buggy. One stray uncaught and unprocessed exception and your program will crash. You must understand how to write exception safe code if you are using C++ with STL. Using plain C arrays will avoid this situation, because there is nothing to "catch". Or even plain malloc or any other C function, because then you can easily check return value and decide based on that if something failed or not. If you disable exceptions then funny stuff will happen in STL depending on compiler and linker. In some situations it will call std::terminate to abort process, in some cases it will still throw exception (shared linking to C++ runtime), etc...

Thanks Martins. Yeah I didn't realize the allocator required exception handling. I handn't used the STL on this project yet and explictelly had exception handling off, which caused all the issues. In previous projects coding through VS builds it must be turned on by default.

I'll be putting together a simple array via some macros tonight so I can get rid of std::vector and go back to good old plain C. Although you are right I could use static arrays for the pathfinding code just like I did for the terrain data. I was thinking the explict clear, pop, and erase functions would come in handy but the whole exception error really just slowed me down more. I've enjoyed my programming immensely more since adopting the style Casey shows of more plain C, assert error catching and other simple tricks.

Appreciate the info.

you can supply your own allocator and if you can guarantee that there will always be memory to satisfy the demand you can not throw the exception.

Thanks everyone. It's super simple for now, but got a very basic terrain generator via perlin noise and A* path-finding up and running using the basic Manhattan distance formula. Pretty happy with tonight's progress.

Wanted to use the dynamic array versus a static array since the path coordinate list is variable, but I guess a static array and counter would have worked just as well, as they have for all the terrain generation.