Subject: Re: string. vector vs string_view, span in reflection API
From: David Vandevoorde (daveed_at_[hidden])
Date: 2021-04-09 09:16:10
One of the issues that arise is header dependenciesâ¦ do we really want to require that <vector> and <string> be included for any code that does something nontrivial with reflections? Maybe âyesâ, and maybe thatâll be less of a concern with modules?
Meanwhile, our (Faisal & I) current implementation uses std::string_view (with some assumptions about its internal structure) and a very simple vector<info>-like class thatâs part of the <meta> header.
> On Apr 9, 2021, at 8:57 AM, Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
> Hana DusÃkovÃ¡ wrote:
>> One possible use case for me is to creating a new name for a reflection and
>> then splice it somewhere. I would rather manipulate with a string using
>> std::string API than using C to control C++ reflection, that would be
>> embarrassing :)
> That's not a problem because you can always store the result in a std::string.
> The advantage of returning `char const*` is that you can always get either
> string or string_view from it without any trouble. You can also obtain a string
> from a string_view (but not `char const*` from a string_view.)
> It does introduce some slight inconvenience in the case you just want to
> concatenate using + though.
>>> On 9. 4. 2021, at 14:46, Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
>>> Matus Chochlik wrote:
>>>>> vector<info> can't be replaced with span<info> though because it's
>>>>> often built dynamically (e.g. if the contents are filtered with a
>>>> This still happens at compile-time inside of the compiler, so it
>>>> could allocate the filtered range of metaobjects by using some
>>>> internal mechanism, that is not exposing generic "dynamic" allocation in
>>> If all the consteval functions manipulating or returning vector<info>
>>> are compiler built-ins, then yes, that would be possible.
>>> I think the motivation to use vector<info> (and extend the language to
>>> make this possible) was to enable (at least some of) these functions
>>> to be written in
>>> In contrast, I can't think of a case where a string returned by these
>>> facilities isn't produced by the compiler.
>>> (I also hit this limitation when I tried to implement
>>> Boost.Describe-like primitives on top of 2320, which return the
>>> reflection metadata in types, rather than values. It's not possible to go from
>> std::string to that.
>>> vector<info> is however fine as long as range splicing it works.
>>> Although as I'm writing this it occurs to me that I can range-splice a
>>> std::string too, which might enable me to obtain a char const* from
>>> it, after all. :-) )
>>> SG7 mailing list
> SG7 mailing list
SG7 list run by firstname.lastname@example.org
Older Archives on Google Groups