Date: Fri, 9 Apr 2021 14:35:29 +0200
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?
>
--Matus
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?
>
--Matus
Received on 2021-04-09 07:35:45