How to get to a class initializer through introspection?
j at j.nl
Mon Aug 3 14:44:38 UTC 2020
On Monday, 3 August 2020 at 13:01:55 UTC, Andrei Alexandrescu
> On 8/3/20 4:04 AM, Johan wrote:
>> On Sunday, 2 August 2020 at 23:59:23 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu
>>>> Any ideas on how to do that via introspection? The fields
>>>> are accessible, but not their default values.
>>> It is ugly but possible right now to pull in the symbol via
>>> See line 20 in my latest blog's example:
>>> ldc complains but it is a type mismatch not a fundamental
>>> barrier, I just didn't figure out the right thing to silence
>>> it yet.
>>>> It seems like __traits(type, getInitializer) might be
>>> but yes this would be generally nicer anyway imo.
>> That for that post Adam, I've been trying the same thing
>> It's needed to fix this:
> Would it be effective to iterate through the .tupleof and
> initialize each in turn?
Possibly. IIRC, the spec obliges us to initialize the padding
in-between address-aligned members aswell, such that a memcmp
works to compare structs. If that is true, then we have to
initialize the padding aswell and a memcpy would be that much
If `__traits(type, getInitializer)` would return a symbol, then
memcpy is easy and we're done. However, that forces us to emit
these init symbols, except for very simple cases like all-zeros
initialization (for which LDC does no longer emit an init
symbol). It is very benificial for binary size to elide these
all-zero initializer symbols. I don't know how much benefit there
is for eliding near-zero symbols.
If `__traits(type, getInitializer)` would return a function, then
that's a different story...
My current solution [*]:
[*] Hits an obscure mangling bug, so doesn't quite work with
Weka's codebase yet
More information about the Digitalmars-d