Date: Fri, 9 Apr 2021 15:57:43 +0300
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.
> Hana
>
> > 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
> >>> predicate.)
> >>
> >> 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
> consteval.
> >
> > 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
> > C++.
> >
> > 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_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> 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.
> Hana
>
> > 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
> >>> predicate.)
> >>
> >> 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
> consteval.
> >
> > 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
> > C++.
> >
> > 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_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
Received on 2021-04-09 07:57:54