[API] Use std::vector<uint8_t> instead of std:string

[da2ce7]

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 ?

[tigusoft-vm]

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.

[rubendv]

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.

[da2ce7]

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.

[rubendv]

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?

[berkus]

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.

[berkus]

It could, but if you're concerned with cleansing() the container it will work correctly regardless of SSO.