[Issue 16423] ModuleInfo missing when linking to static lib with classes

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Mon Oct 10 05:38:48 PDT 2016


https://issues.dlang.org/show_bug.cgi?id=16423

--- Comment #7 from Martin Nowak <code at dawg.eu> ---
(In reply to Steven Schveighoffer from comment #5)
> This is penny-wise and pound-foolish. First we need to solve megabyte sized
> template symbol names. Then we need full shared library support. The few
> kilobytes that moduleinfo adds is nothing. Trim out unused classinfo? Then
> we need to remove Object.factory method.

- Yes we need to solve the long symbol names, but they don't bloat the code
segment or affect the performance
- shared libraries were just one workaround I named (and they can be fully used
on linux/FreeBSD atm.)
- It's not the ModuleInfo or the ClassInfo, it's the fact, that this drags in
the complete tree of symbols reachable by any referenced class, i.e. the whole
module in most cases. The static constructors and class references are one of
the main reasons for our huge binaries (code segment, not file size which is
just a distribution problem).
- Object.factory is slow by design, it's in the interest of everyone to avoid
that facility if possible, and there aren't many use-cases that really require
it

If we have enough prove that it's a necessary pattern, I'd be in favor of
adding a global, synchronized, namespaced dynamic class registration facility
in phobos or druntime. That could be used for certain patterns such as
registering deserializable subclasses, factory.register!("orange.deserializer",
MyOpenSubclass).
It could also make use of a hash table to speed up instantiating, and maybe
even support non-standard constructors.
The question is really, do we really need it, and who builds it.

--


More information about the Digitalmars-d-bugs mailing list