Our source code assumes all-UTF-8 strings, on Windows the 8-bit active
code page is admin-adjustable. Hence we need to convert at runtime.
Signed-off-by: Simon Rozman <simon.rozman@amebis.si>
Technically, this is still binary compare with no locale-specific
ordering knowledge. But takes Unicode representation of UTF-16 surrogate
pairs when comparing.
Signed-off-by: Simon Rozman <simon.rozman@amebis.si>
Standard C++ implementation has std::ctype<wchar_t> for UTF-32, but no
UTF-16 one. Since NSString is UTF-16, we need support for UTF-16 in C++
too if unnecessary translations between UTF-16/32 are to be avoided.
Signed-off-by: Simon Rozman <simon@rozman.si>
Some invalid handle values are -1 or INVALID_HANDLE_VALUE, hence our
handle template has a specific invalid handle value parameter we should
always test against. Time and again, I find my code simply comparing
handle against zero.
Signed-off-by: Simon Rozman <simon@rozman.si>
The handle validation is done with valid() method now, so using operator
T to auto-retrieve object handle should not provide ambiguities any
more. As long as we remember to use valid() for testing!
Signed-off-by: Simon Rozman <simon@rozman.si>
read() blocks when there is no more data to read. However, we do need
to loop when read is divided into blocks.
Signed-off-by: Simon Rozman <simon@rozman.si>
Looping ReadFile() system call is Windows-specific. POSIX systems don't
need this. In fact: with pipes using buffered streams, this blocks the
read until one full buffer of data is available.
Signed-off-by: Simon Rozman <simon@rozman.si>
Where test expression is already or almost boolean type, using ternery
operator is excessive and possibly more difficult to read.
Signed-off-by: Simon Rozman <simon@rozman.si>
Code analysis got quite good and we'd better keep warnings on our radar.
Either:
1. Research and resolve the reason for the warning.
2. Remove silencing and let code analysis complain.
3. Comment why some warning silencing is there.
Signed-off-by: Simon Rozman <simon@rozman.si>
When exception processing is unwinding the stack, any exception thrown
in destructors end up std::terminate()-in our process.
Since all workarounds to report errors from destructors seems an
overkill, and the only important place where we should notify the user
about a failure is the stdex::stream::cache::~cache() (data loss occurs
when failure happens here), and if we'd throw in stdex::stream::cache::
~cache(), our process would get terminated anyway so the data loss is
inevitable, let's just silence this for now and come up with a better
solution later if we get smarter anytime in the future.
Signed-off-by: Simon Rozman <simon@rozman.si>
