rubendv
[API] Use std::vector<uint8_t> instead of std:string
When looking through the design of sodiumpp, I'm curious of the choice of std:string.
I would have thought that the more natural format for binary data (or UTF-8 encoded text), was std::vector<uint8_t>.
Was/Is is there a special reason for the choice of std::string ?
By the way,
we have some modifications of the code including better support for locking secrets in memory e.g. "locked_string" - that will be offered as PR in some time in future https://github.com/tigusoft-vm/sodiumpp/tree/tigusoft/sodiumpp
if sodiumpp would change to vector<uint8_t> then we can easily follow that in our small patchset as well.
std::string was already used by the original NaCl C++ API, and I'd like to keep it that way for the low level API. For the high level API std::vector<uint8_t> is fine for me, but you would have to convert between the two when calling the low level API, which may get messy. I do think that using std::string will be more convenient for people to use, as you'll probably have your data as an std::string anyway when you're reading files.
When a programmer looks at an API and sees std::string, he/she expects uft8 (or other text) encoded data.
When a programmer looks at an API and sees std::vector<unit8_t>, he/she expects binary data.
When designing API's they should be intuitive for those who use them.
I agree that std::vector<uint8_t> is a better fit, but that would mean breaking with the NaCl C++ api: (e.g. https://nacl.cr.yp.to/box.html). I suppose we could overload them and implement both for the low level API?
std::string is a binary container, so there's no need really.
programmer expecting utf8 in a std::string should better go read the stdlib documentation.
It could, but if you're concerned with cleansing() the container it will work correctly regardless of SSO.