Improving memory safety using modern c++ standard library about openjph HOT 2 CLOSED

Thank you for the suggestion.

I do not support moving the internal arrays to std::vector and the likes, for a few reasons.

The STL library wraps the simple structures I need with "cloaks," providing less visibility in what is going behind the scenes. Each std::vector has its own constructor/destructor, which can slow things down. I also need my arrays to have certain alignment. The codestream has a lot of structures, and it is impractical to do all this allocation/de-allocation of these data structures.

Using std::vectors does not protect against buffer overflows, unless we use the .at() function, which checks against the buffer boundary. We can do that as well, but it comes with performance hit. I understand the code has been written by more experienced programmers than myself. There's also assumption that the compiler would optimize out many of the functions.

IIRC, most libraries, such as openjpeg, libpng, libjpeg, ...etc. use C or C++ with little no STL structures. This might be due to historic reasons.

I am also not very knowledgeable in them, sorry.

For the supporting executable, I am not that resistant; certain parts might benefit from the use of STL.

I also do not like to make the library depends on other libraries -- boost, or others. This dependency creates headaches, which programmers have tried to solve using docker. I understand for large project that might be the only option, but for this project, I would like to keep it all in one place.

from openjph.

I understand your concerns here. STL is one approach to this - but there are others we can consider:

1. We can create a Buffer class which encapsulates the pointer to allocated memory and length. This would increase safety while providing control and avoiding a third party dependency. The Buffer class can do bounds checking (maybe just in debug mode) for added safety
2. Leverage C++ templates to generalize this Buffer class for strong typing (e.g. unsigned 16 bit, signed 16 bit, etc).

from openjph.