Subject: Re: string. vector vs string_view, span in reflection API
From: Hana DusÃkovÃ¡ (hanicka_at_[hidden])
Date: 2021-04-09 07:40:24
We already have a mechanism how to allocate in constexpr/consteval context. And in C++20 std::string and std::vector is constexpr thanks to Louis Dionne's heroism. We currently only don't have a mechanism how to transfer an allocation from compile-time into runtime. That's something https://wg21.link/p1974r0 <https://wg21.link/p1974r0> is trying to solve.
> On 9. 4. 2021, at 14:35, Matus Chochlik via SG7 <sg7_at_[hidden]> wrote:
> Hi Peter
> On Fri, Apr 9, 2021 at 2:26 PM Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
> Matus Chochlik wrote:
> > Hi,
> > IIUC the current plan is to use `string` and `vector<meta::info>` in the
> > reflection API (both of which require consteval dynamic allocation). Is this
> > correct and if so, was there some reason for not using `string_view` and
> > `span<meta::info>` instead? The returned metadata is always static, so
> > mutable containers look like overkill.
> I would go even further and argue in favor of returning char const*. You
> can construct a string_view from that but not vice versa.
> 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.
> Just saying, in case solving dynamic allocation in constexpr/consteval contexts is something blocking us moving forward with reflection.
> Or am I missing something?
> SG7 mailing list
SG7 list run by firstname.lastname@example.org
Older Archives on Google Groups