|
proxygen
|
folly/Conv.h is a one-stop-shop for converting values across types. Its main features are simplicity of the API (only the names to and toAppend must be memorized), speed (folly is significantly faster, sometimes by an order of magnitude, than comparable APIs), and correctness.
All examples below are assume to have included folly/Conv.h and issued using namespace folly; You will need:
Using to<Target>(value) to convert one integral type to another will behave as follows:
to inserts bounds checks and throws std::range_error if the target type cannot accommodate the source value. Example:As mentioned, there are two primitives for converting anything to string: to and toAppend. They support the same set of source types, literally by definition (to is implemented in terms of toAppend for all types). The call toAppend(value, &str) formats and appends value to str whereas to<StringType>(value) formats value as a StringType and returns the result by value. Currently, the supported StringTypes are std::string and fbstring
Both toAppend and to with a string type as a target support variadic arguments. Each argument is converted in turn. For toAppend the last argument in a variadic list must be the address of a supported string type (no need to specify the string type as a template argument).
Nothing special here - integrals are converted to strings in decimal format, with a '-' prefix for negative values. Example:
The conversion implementation is aggressively optimized. It converts two digits at a time assisted by fixed-size tables. Converting a long to an fbstring is 3.6x faster than using boost::lexical_cast and 2.5x faster than using sprintf even though the latter is used in conjunction with a stack-allocated constant-size buffer.
Note that converting integral types to fbstring has a particular advantage compared to converting to std::string No integral type (<= 64 bits) has more than 20 decimal digits including sign. Since fbstring employs the small string optimization for up to 23 characters, converting an integral to fbstring is guaranteed to not allocate memory, resulting in significant speed and memory locality gains. Benchmarks reveal a 2x gain on a typical workload.
char to string conversionAlthough char is technically an integral type, most of the time you want the string representation of 'a' to be "a", not 96 That's why folly/Conv.h handles char as a special case that does the expected thing. Note that signed char and unsigned char are still considered integral types.
folly/Conv.h uses V8's double conversion routines. They are accurate and fast; on typical workloads, to<fbstring>(doubleValue) is 1.9x faster than sprintf and 5.5x faster than boost::lexical_cast (It is also 1.3x faster than to<std::string>(doubleValue)
const char* to string conversionFor completeness, folly/Conv.h supports const char* including i.e. string literals. The "conversion" consists, of course, of the string itself. Example:
folly/Conv.h includes three kinds of parsing routines:
to<Type>(const char* begin, const char* end) rigidly converts the range [begin, end) to Type These routines have drastic restrictions (e.g. allow no leading or trailing whitespace) and are intended as an efficient back-end for more tolerant routines.to<Type>(stringy) converts stringy to Type Value stringy may be of type const char*, StringPiece, std::string, or fbstring (Technically, the requirement is that stringy implicitly converts to a StringPieceto<Type>(&stringPiece) parses with progress information: given stringPiece of type StringPiece it parses as much as possible from it as type Type and alters stringPiece to remove the munched characters. This is easiest clarified by an example:Note how the routine ate the leading space but not the trailing one.
Parsing integral types is unremarkable - decimal format is expected, optional `'+'or'-'sign for signed types, but no optional'+'is allowed for unsigned types. The one remarkable element is speed - parsing typicallongvalues is 6x faster than sscanf.folly/Conv.h` uses aggressive loop unrolling and table-assisted SIMD-style code arrangement that avoids integral division (slow) and data dependencies across operations (ILP-unfriendly). Example:
folly/Conv.h uses, again, V8's double-conversion routines as back-end. The speed is 3x faster than sscanf and 1.7x faster than in-home routines such as parse<double> But the more important detail is accuracy - even if you do code a routine that works faster than to<double> chances are it is incorrect and will fail in a variety of corner cases. Using to<double> is strongly recommended.
Note that if the string "NaN" (with any capitalization) is passed to to<double> then NaN is returned, which can be tested for as follows:
Note that passing "-NaN" (with any capitalization) to to<double> also returns NaN.
Note that if the strings "inf" or "infinity" (with any capitalization) are passed to to<double> then infinity is returned, which can be tested for as follows:
Note that passing "-inf" or "-infinity" (with any capitalization) to to<double> returns -infinity rather than +infinity. The sign of the infinity can be tested for as follows:
Note that if an unparseable string is passed to to<double> then an exception is thrown, rather than NaN being returned. This can be tested for as follows:
Note that the empty string ("") is an unparseable value, and will cause to<double> to throw an exception.
tryTo<T> is the non-throwing variant of to<T>. It returns an Expected<T, ConversionCode>. You can think of Expected as like an Optional<T>, but if the conversion failed, Expected stores an error code instead of a T.
tryTo<T> has similar performance as to<T> when the conversion is successful. On the error path, you can expect tryTo<T> to be roughly three orders of magnitude faster than the throwing to<T> and to completely avoid any lock contention arising from stack unwinding.
Here is how to use non-throwing conversions:
Expected has a composability feature to make the above pattern simpler.