From 3c5e0c72fb8463157d0cf7487d9eba6efd4b88a8 Mon Sep 17 00:00:00 2001 From: Marko Ristin Date: Sat, 8 Jun 2019 09:20:05 +0200 Subject: [PATCH] extended readme and docs --- docs/source/cpp_specifics.rst | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/docs/source/cpp_specifics.rst b/docs/source/cpp_specifics.rst index 9f2eb79..1510b2e 100644 --- a/docs/source/cpp_specifics.rst +++ b/docs/source/cpp_specifics.rst @@ -151,9 +151,15 @@ integers and floats and treat all numbers equally, between the integers (represented internally as 64-bit integers) and floats (represented internally as double-precision floats). -TODO: add smallest, largest for integers +Based on the internal representation, C++ deserialization can represent integers +in the range of 64-bit integers (-9,223,372,036,854,775,808 to +9,223,372,036,854,775,807) and floats in the rage of double-precision ( +-1.7976931348623157e+308 to 1.7976931348623157e+308). -TODO: add smallest, largest and lowest for floats +However, note that deserialization in other languages might impose stricter +constraints. For example, Go does not distinguish between integers and floats +when parsing JSON (see :doc:`go_specifics`), so the overall range that you can +represent is smaller if you need Go and C++ de/serialization to inter-operate. Time Libraries ^^^^^^^^^^^^^^ @@ -229,10 +235,13 @@ durations are given as strings and thus can represent a much larger range of durations (basically bounded only on available memory space). In fact, the problem is very practical and you have to account for it when -you deal with long durations. For example, a duration specified as``"P300Y"`` -already leads to an overflow since 300 years *can not* be represented as -nanoseconds with finite integral numbers of 64 bits. - -If yo really need to use a different range, you need to represent the duration -as string and parse it yourself or represent the duration as a float or an -integer and assume the period in your client code. +you deal with long or fine-grained durations. For example, a duration specified +as``"P300Y"`` already leads to an overflow since 300 years *can not* be +represented as nanoseconds with finite integral numbers of 64 bits. +Analogously, ``"PT0.0000000001"`` can not be represent either since the +precision of the duration goes beyond nanoseconds. + +Note also that other languages impose stricter constraints. For example, Python +uses microseconds to represent durations (see :doc:`py_specfics`) and hence +you need to restrict your durations to microsecond granularity if both Python +and C++ de/serializations are needed.