Accept Emitter::operator<<(std::string_view).
ABI remains C++11 compatible by exposing new method
Emitter::Write(const char*, size_t).
All affected calls optimized to pass std::string values as pointer + size
tuple into appropriate routines.
Including:
- Remove WORKSPACE and upgrade to MODULE.bazel.
- The integration tests were not included since the directory was misspelled.
- Their header files were not accessible.
Add dragonbox to compute the required precision to print floating point
numbers. This avoids uglification of floating point numbers that
happen by default via std::stringstream.
Numbers like 34.34 used to be converted to '34.340000000000003' as strings.
With this version they will be converted to the string '34.34'.
This fixes issue https://github.com/jbeder/yaml-cpp/issues/1289
For completeness I've implemented escaping for characters outside the
basic multilingual plane, but it doesn't get used (as there's no
EscapeAsAsciiJson emitter option implemented).
Inside of a sequence or map, `YAML::Newline` wouldn't reset the collection state, which would cause behavior like this:
```
nodeA:
k: [{i: 0},
{i:1},
]NodeB:
k: [{i: 0},
{i:1},
]
```
* partially fix clang compilation
Missing header and mistaken algorithm usage.
Also removed it name from range loops. It's not correct.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* run through clang's -Wrange-loop-analysis
Some range loops should not use references as they need to copy.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* manual range loop conversions
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Invalid access via operator[] or as<> will now print the offending key, if possible.
For example:
a:
x: 1
y: 2
node["a"]["z"].as<int>()
will say that the key "z" was invalid.
The issue is that numbers like
2.01 or 3.01 can not be precisely represented with binary floating point
numbers.
This replaces all occurrences of 'std::numeric_limits<T>::digits10 + 1' with
'std::numeric_limits<T>::max_digits10'.
Background:
Using 'std::numeric_limits<T>::digits10 + 1' is not precise enough.
Converting a 'float' into a 'string' and back to a 'float' will not always
produce the original 'float' value. To guarantee that the 'string'
representation has sufficient precision the value
'std::numeric_limits<T>::max_digits10' has to be used.