etl
etl copied to clipboard
ETLCPP
Feature request: Helper functions to convert strings to numeric values
We have the to_string() functions that are really ergonomic, especially when paired with format.
Having a utility that would do a conversion the other way round would be really usefull addition to ETL.
Do you think that the string passed should only contain the numeric string to convert, or should it search for the start and end of the numeric?
i.e. find non-numeric characters.
"abc# 123.45*sne"
^ ^
I think that the string passed should be just the value. Even if the incoming string has other characters, then we can just give the conversion functions a string_view of the part to the value, right?
I'd rather have the functions tell me that the string does not match the type of data I told it it would be. Ie. it was supposed to be an int and the string has a dot in it. So it can do a bit of validation.
That would definitely be the easiest to implement, and it separates the two steps of 'search' & 'convert', though I would probably let the conversion functions automatically ignore leading and trailing whitespace.
Including conversion of strings in binary, octal & hex formats? It may need an explicit base parameter or deduction from the prefix.
etl::to_arithmetic<int>("1234", etl::hex());
etl::to_arithmetic<int>("0x1234");
- The return type of the functions will be an
etl::optional<T>, whereTis an arithmetic type. - A failure to convert will result in a default constructed
etl::optional<T>. - I'm thinking that I should not bother handling stripping off any
0x,0X,0bor0Bprefix from hex and binary strings. - I'm also thinking that binary, octal and hex strings that are prefixed with
-are not converted (Or-is ignored?). - An attempt to convert a negative decimal string to an unsigned type will also be a failure.
- A
+prefix to any numeric string will be ignored. - Leading or trailing whitespace will be ignored.
- Any failure to convert will be submitted to the error handler or thrown as an exception (dependent on configuration)
- Should binary, octal and hex only be allowed to convert to unsigned?
- Error on conversion overflow.
Examples:
" +123 " as signed decimal OK
" -123 " as signed decimal OK
" -123 " as unsigned decimal FAILURE
" +123 " as unsigned hex OK
" 123 " as signed hex FAILURE
" -123 " as signed hex FAILURE
" 0x123 " as unsigned hex FAILURE
At the moment, "" is not an error (and returns a default constructed etl::optional<T>), but "-" or "+" are errors.
Hm, what would then be a difference between an error and a default constructed etl::optional<t>?
From 4 comments above:
- A failure to convert will result in a default constructed etl::optional<T>.
- Any failure to convert will be submitted to the error handler or thrown as an exception (dependent on configuration)
I was under the impression that a default constructed etl::optional<T> indicated an error, and depending on the additional config it can throw an exception.
Which ever one it is I would say an empty string would should have the same consequence as any other string that can not be converted.
Sorry for my confusing description.
When I said 'errors' I meant a call to ETL_ASSERT. A return of a default constructed etl::optional<T> is of course a 'failure to convert' error, so I agree that an empty string should be treated the same as any other 'failure to convert' error.
How important is the ability to have a constexpr conversion?
At the moment I am returning etl::optional<T>. Unfortunately, etl::optional cannot be constexpr due to the aligned storage member.
EDIT: I realised that I can probably specialise etl::optional for fundamental types to be constexpr.