C++ Logo

std-discussion

Advanced search

Re: Global array of objects over multiple files

From: Lauri Vasama <wg21_at_[hidden]>
Date: Fri, 18 Oct 2024 17:30:57 +0300
P2889 was discussed in Varna. The reception was favourable but EWGI
wanted to support dynamic linking, which I did not initially propose. To
do this requires something like linked lists, but a hybrid approach is
possible. Instead of linking individual elements, the implementation can
choose to merge multiple elements into arrays and to serve a linked list
of arrays to the user. In practice most of the time all elements can be
placed into a single array, but implementability on more constrained
platforms may require a linked list of arrays or even a linked list of
individual elements.

Currently the main thing needed to advance this proposal is an
implementation. I have a partial one in Clang, but haven't had much time
to work on it recently.

On 18/10/2024 12.56, Federico Kircheis via Std-Discussion wrote:
> On 18/10/2024 11.13, Marcin Jaczewski wrote:
>> czw., 17 paź 2024 o 16:58 Federico Kircheis via Std-Discussion
>> <std-discussion_at_[hidden]> napisał(a):
>>>
>>> Hello,
>>>
>>> I would like to have, in c++, a way to "register" objects from
>>> different
>>> translation units in a global container (an array).
>>>
>>> This is already possible in gcc and msvc with tools outside of the
>>> language, with multiple drawbacks.
>>>
>>
>> It needs to be `array`? If we allow linked list each position can
>> "self append" to global list:
>>
>
> I want to standardize existing practice, not propose something novel.
>
> Existing practice
>
> * works with something that looks like an array
> * does not execute code at runtime during the registration
> * does not require mutable memory, which is a security issue (see the
> EncodePointer function :
> https://learn.microsoft.com/en-us/previous-versions/bb432254(v=vs.85) )
>
> The proposed linked list cannot be compared with such approach.
>
> I was also thinking that exposing span or initializer_list are viable
> alternatives.
> They have the advantage that there is no need for a second symbol for
> tracking the size.

Received on 2024-10-18 14:31:27