Windows takes care of internal converter state in MultiByteToWideChar
and WideCharToMultiByte and keeps them thread-safe. On other platforms,
iconv requires user to setup and keep converter state for thread-safe
conversions. This sounds time consuming for every string conversion,
therefore the concept of string converter (or converter state) has been
extended to Windows too, allowing uniform client code. On Windows, using
charset_encoder has no performance benefit, where on Linux and macOS,
there should be. To be measured...
Signed-off-by: Simon Rozman <simon@rozman.si>
"sys_char" sticks out of "wchar_t", "char32_t", "uint32_t"...
Likewise, "sys_string" out of "string", "wstring", "u16string",
"u32string"...
Signed-off-by: Simon Rozman <simon@rozman.si>
Reusing same class instance for different files reused cache content
as well.
Reported-by: Peter Holozan <peter.holozan@amebis.si>
Signed-off-by: Simon Rozman <simon@rozman.si>
Our test program runs 15 minutes using our streams vs. 25 minutes using
std::iostream derived streams.
Streams were ported from Amebis AOsn project.
Signed-off-by: Simon Rozman <simon@rozman.si>
We need this for a rare use-case, so maintaining three flavors of
diagstream is too expensive. Furthermore, the buffering was removed
for simplicity.
Signed-off-by: Simon Rozman <simon@rozman.si>
The sgml.hpp is about converting between SGML and UTF-16/Unicode
actually. The "wstr" naming aligns better with std::wstring, wchar_t
etc.
Signed-off-by: Simon Rozman <simon@rozman.si>
These files are C++ only. They should either have no extension like
standard C++ headers (which is cumbersome on Windows environments), or
.hpp.
.h is used for C and hybrid C/C++ headers.
Signed-off-by: Simon Rozman <simon@rozman.si>
