Object.factory() and exe file size bloat

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sat Aug 22 03:11:15 PDT 2015


On 21 August 2015 at 13:35, Steven Schveighoffer via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 8/21/15 7:22 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> Where removing RTTI disables D feature's in a compromising way, I'd
>> start by questioning the why.
>>
>> Eg:  Why does array literals need RTTI?  Looking at _d_arrayliteralTX
>> implementation, it only does the following with the given TypeInfo
>> provided:
>>
>> - Get the array element size (this is known at compile time)
>> - Get the array element type flags (calculated during the codegen stage,
>> but otherwise known at compile time)
>> - Test if the TypeInfo is derived from TypeInfo_Shared (can be done at -
>> you guessed it - compile time by peeking through the baseClass linked
>> list for a given TypeInfo type we are passing).
>>
>> So we have this function that accepts a TypeInfo, but doesn't really
>> *need* to at all.
>>
>> void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint flags, bool
>> isshared);
>>
>> Just putting it out there....
>>
>
> I strongly suggest we *don't* go this route. This means that any changes
> to what is required for the runtime to properly construct an array requires
> a compiler change.
>
> A MUCH better solution:
>
> T[] _d_arrayliteral(T)(size_t length)
>
> Also, isn't the typeinfo now stored by the GC so it can call the dtor?
> Perhaps that is done in the filling of the array literal, but I would be
> surprised as this is a GC feature.
>
>
I only looked at 2.066.1, the runtime implementation did not pass the
typeinfo to the GC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150822/afb9c37e/attachment.html>


More information about the Digitalmars-d mailing list