Construction from Constexpr StringView
larkwiot opened this issue ยท 11 comments
Hello,
Is there any way to construct directly from a StringView? Looking to have something like this in my code:
constexpr static uintwide_t<65535, std::uint64_t> BIG_INT_CONSTANT {"0xA0A0A0000000000000000000000"sv};
It wouldn't be a good design choice to inject a dependency on string_view
into uintwide_t
. Those ought to be two separate types. A non-member function template might be a good idea though, maybe called something like e.g. from_string
.
And as this seems to be a literal value, perhaps a UDL would work, e.g.:
constexpr static uintwide_t<65535, std::uint64_t> BIG_INT_CONSTANT {0xA0A0A0000000000000000000000_wide_integer};
any way to construct directly from a StringView?
Yes, but I agree with John (@johnmcfarlane), who indicates, ...
wouldn't be a good design choice to inject a dependency on
string_view
intouintwide_t
. Those ought to be two separate types. A non-member function template might be a good idea though, ...
There is already a constructor from const char*
, but that does not work for string-view because this constructor requires a Null-Terminated character pointer array and string-view is not Null-Terminated.
I think it owuld be best if we were to discuss either a factory-like non-member function or something like what John sketheced out above.
There is already a constructor from
const char*
Since that constructor is already there, would it be a fair compromise to add a second, default-set length parameter which could handle string-view (which is non-null-terminated).
Could this be a reasonable solution?
Cc: @larkwiot and @johnmcfarlane
Thanks for your guys' time on this!
I personally don't have a preference on the implementation of this, I just like the library and wanted to have some global constants. Of the solutions mentioned so far, a utility function like from_string()
is the most appealing to me personally, but any way this functionality could be implemented is a win for me.
a utility function like
from_string()
is the most appealing to me personally
I appreciate this. There is, however, a special case to handle. When dealing with string_view
, there is no guarantee that the associated char
-pointer array is NULL
-terminated.
Personally, I do not like creating an std::string
(i.e., from a string_view
) for the sole purpose of using its c_str()
method to obtain a NULL
-terminated string. So I think a few overloads of a potential from_string()
method would also be useful.
Let me put together a draft and present it in a future PR.
Hopefully there's a generic way to handle both string
s and string_view
s in the same algorithm.
It might be a little trickier to wrap your head around if you're not used to dealing with iterators and templates as much as indexes and char*
s, but you may find the solution is cleaner and more satisfying. Example.
a utility function like
from_string()
is the most appealing to me personally
Hopefully there's a generic way to handle both
string
s andstring_view
s in the same algorithm.
Of course @johnmcfarlane, I can/will implement (it in a hopefully nice and non-ambiguous way) with template-iterators first
/last
. This would be, ... as usual as possible from the perspective of the STL philosophy.
Oh you know what?
A while back, I implemented something that tries as best as possible to immitate to_chars()
.
I might as well implement now for this issue something that's close to from_chars()
.
Note to self: Implementation detail, ... the proposed from_chars
is very similar to the existing rd_string
. Adapt accordingly with probably minimal effort.
See also #400
Hi @larkwiot and @johnmcfarlane
from_chars()
is in with #400