summaryrefslogtreecommitdiffstats
path: root/qt-models/divecomputermodel.h
diff options
context:
space:
mode:
authorGravatar Berthold Stoeger <bstoeger@mail.tuwien.ac.at>2020-10-05 09:56:21 +0200
committerGravatar Dirk Hohndel <dirk@hohndel.org>2020-10-16 14:26:37 -0700
commitfd8bd9d5c717799313c4decaa85796ba68449f8a (patch)
tree5d07a6d5a03db8e81238aee535c7683e082c7929 /qt-models/divecomputermodel.h
parent4e479677a078f43959dc7101fc47ba5afd79f344 (diff)
downloadsubsurface-fd8bd9d5c717799313c4decaa85796ba68449f8a.tar.gz
cleanup: use std::string in struct device
struct device is a core data structure and therefore shouldn't use QString. QString stores as UTF-16 (which is a very questionable choice in itself). However, the real problem is that this puts us in lifetime-management hell when interfacing with C code: The UTF-16 has to be converted to UTF-8, but when returning such a string, this puts burden on the caller who has to free it. In fact, instead of looping over devices from C-code we had a callback that sent down temporary C-strings with qPrintable. In contrast, std::string is guaranteed to store its data as contiguous null-terminated and C-compatible strings. Therefore, replace the QString by std::string. Keep the QString just in one place that formats a hexadecimal number to avoid any potential change. The disadvantage of using std::string is that it will crash when constructed with a NULL argument, consistent with C-style functions such as strcmp, etc. Arguably, NULL is different from the empty string even though we treat both as the same. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Diffstat (limited to 'qt-models/divecomputermodel.h')
0 files changed, 0 insertions, 0 deletions