Construction from Constexpr StringView

[larkwiot]

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};

[johnmcfarlane]

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};

[ckormanyos]

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 into uintwide_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.

[ckormanyos]

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

[larkwiot]

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.

[ckormanyos]

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.

[johnmcfarlane]

Hopefully there's a generic way to handle both strings and string_views 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.

[ckormanyos]

a utility function like from_string() is the most appealing to me personally

Hopefully there's a generic way to handle both strings and string_views 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.

[ckormanyos]

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().

[ckormanyos]

Note to self: Implementation detail, ... the proposed from_chars is very similar to the existing rd_string. Adapt accordingly with probably minimal effort.

[ckormanyos]

See also #400

[ckormanyos]

Hi @larkwiot and @johnmcfarlane

from_chars() is in with #400