C++ Logo


Advanced search

Subject: Re: string. vector vs string_view, span in reflection API
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2021-04-09 09:25:42

On Fri, Apr 9, 2021 at 4:16 PM David Vandevoorde via SG7 <
sg7_at_[hidden]> wrote:

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

This is quite close to what I'd expect from the API, with the
minimal-vector-like (doing only what is necessary for consteval) class
being a public part of the API.
(+ maybe a guarantee that the underlying strings covered by the string_view
is always zero-terminated when returned by reflection)

> > 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.
> >
> >> Hana
> >>

SG7 list run by sg7-owner@lists.isocpp.org

Older Archives on Google Groups