Read fixed size strings without padding characters

[FlyingSamson]

This would be one way to overcome the current issue that when reading fixed-size strings into std::strings all padding characters are also returned.

This will certainly introduce a certain overhead compared to not trimming the read string (I did not perform any benchmarks though) which need to be contemplated.
On the other hand, in cases where the caller actually wants the trimmed string, forcing him to trim the string himself after it has been created might incur even larger costs.

Resolves #661

Also relevant for #215 and #224

[FlyingSamson]

Not entirely sure, why this was required in the first place.

From what I understand the code will write shorter strings just fine. This line merely ensured that in the REQUIRE_THAT below write also contained trailing \0 characters.

[ggoneiESS]

I don't quite have the mental capacity to deal with this on a Friday evening, but I would refer you to my comments on a different PR:

ess-dmsc/streaming-data-types#102 (comment)

variable-length datasets cannot be compressed
the data no longer exists contiguously (it necessarily becomes an array of pointers to strings, rather than just raw data)
And (academic but technical arguments)

heap storage requires more space than regular 'raw data' storage (i.e. how the HDF5 object exists in memory)
general reduction in I/O efficiency because it requires individual write operations for each data element rather than one write per dataset chunk (actually, chunking isn't allowed at all)
Performance is definitely at a premium V storage.

I found this via the HDF5 clinic - https://steven-varga.ca/blog/hdf5-fixed-vs-variable-benchmark/ and it provides a CPP file. It might be possible to incorporate into a filewriter test.

Surely if it's like to be a different length wouldn't it be better to use VarLengthString instead anyway?

[yuelongyu]

Hi @FlyingSamson,

Thanks for the PR.

The datatype::StringPad::NullTerm: I agree, it could be removed. However, the padding part, I think it would be good to stay as it is. It might be not the behavior use expected, user writes the string with space padding intentionally and reads it back with different length. For example, in some protocol, it requires fixed length of commands, so padding is needed. If a user save such a command in file and read it back, the user would expect the command is same as what it's written there.