As reported in #235 formatting the first number which doesn't fit into
int64_t anymore fails to add the thousands separators.
I.e.:
`9223372036854775807` -> `9,223,372,036,854,775,807`
`9223372036854775808` -> `9223372036854775808`
Add a test reproducing that that for all backends.
The shorter paths make the sources easier to navigate.
Basically revert of #99 / f44b3bb771f01fb94614260d57e1d09cdfe1cdff
after the underlying issue is resolved.
When parsing a string like "123.456" to an integer the ICU backend would
first parse it greedily to a floating point value and then cast/truncate
it to an integer.
Set the flag to only parse integers when parsing to an integral number.
Care must be taken not to set that when parsing e.g. a currency or date
to an integer where the truncation is intended.
Try to achieve 100% test code coverage to find accidentally missed ones.
Especially the WinAPI tests had some wrongly uncovered lines at function
start/end which needed to be excluded.
Instead of doing a combined formatting and comparison of many format
parts (`as::date`, `as::time` & `as::datetime`) test each one
individually to be able to spot issues easier when it fails
Move the skip condition into `test_main` to avoid missing compile failures due to wrong/missing includes in the headers and to improve formatting due to the removed indentation level of the PP macros
Gets rid of the `test_` prefix in the filenames and avoids confusing those with the actual tests especially by renaming the test framework file from `test_locale.hpp` to `unit_test.hpp`
To support e.g. recent Cygwins where relative paths to the current file are not automatically resolved
move the sources into a `boost/locale` subfolder and add `src` to the private include paths.
This then allows to include those files as `"boost/locale/foo/bar.hpp"`.
Use a common `main` function calling into custom `test_main` functions and
move all common code into the former.
Also introduce an RAII class for a `locale_t` to avoid leaks and reduce
the code further.
Add some LCOV annotations for lines not expected to be reached.
For consistency the following rules are used:
- public includes (include folder) either include any <boost/locale/*>
first. At least <boost/locale/config.hpp>
- The first include in a cpp file is the corresponding header if any
- Then <boost/locale/*>, <boost/*>, <*>, "*" in this order
- Warning suppression pragmas come last where possible
- Use the C++ headers where available (i.e. <cstring> not <string.h>)