Typical class has its fields all set to zeroes so .init member of this class usually contains plain zeroes, which can result in intensive spam from compiler. Consider this code: --- class A { int[10] a; } void main() { auto a=new A(); } --- which in compiled form takes 96kb and after raising array size to 10000, compiled execatable takes 135kb. So as number of class declarations grows, object code gets polluted with zeroes.
It works as designed. Design, however, can be given another thought. I agree it is a bad idea of storing T.init as raw data within executable. Instead, T.init could be made a property (function) that returns default-initialized value. T init(ref T value); could be used to initialize value in-place. Both would use dynamic initializer (memset etc) when appropriate.
Other possible optimizations: 1. Move zero memory to bss section and zero it at startup. Not only .inits contain zeroes, all static data does. 2. If zero data is invariant, different instances of this data can refer to the same memory location, though, if programmer casts one of these pointers to mutable data and overwrite it, this will cause disaster :)
> 1. Move zero memory to bss section and zero it at startup. This will be efficient in terms of both time and storage requirements.
Intializing to zero won't work for floats and char (which init to 0xFF...). But it'd be a nice optimisation for other cases.
The .init block is never all zero, as the first member is the vtpr initializer.
One of the solutions is to introduce non-nullable types (both reference and value-types). In this case T.init would be useless (and thus may be safely removed from language*), because user will *have to* initialize it: double d; // compare to "double? d;" which is ok to be non-initialized double dd = 100.0; Same for structs: Foo f; // not initialized (CT-error or write-only until initialized) Foo ff = Foo(); // ok, default-initialized Note that this is very close to classes (same rule - same syntax): Bar b; // not initialized (CT-error or write-only until initialized) Bar bb = new Bar(); // ok, default-initialized As a general rule for all types, T t; // is not an initialized value, a compile-time error is raised, // or just not allowed to be read until initialized (relaxed rule) T t = initializer_expression; // ok, an initialized value -- * I don't mind if T.init will be removed from language specs altogether as I never found it useful. It may still be left for some time in compiler internals (to copy T[] prior to calling T.__ctor), just don't expose it to users.
(In reply to comment #6) > One of the solutions is to introduce non-nullable types (both reference and > value-types). In this case T.init would be useless (and thus may be safely > removed from language*), because user will *have to* initialize it: So, as much as I like nonnull types, and as much as I like your proposal, there's this .. kind of icky part too. auto a = new ClassType[10]; How exactly do you allocate an array of nonnull types? > * I don't mind if T.init will be removed from language specs altogether as I > never found it useful. It may still be left for some time in compiler internals > (to copy T[] prior to calling T.__ctor), just don't expose it to users. I've found it useful!
It wasn't clear to me that this is talking about ClassInfo.init rather than Type.init. Non-nullable types do nothing for this problem. Class initialization consists of three stages: 1. allocate appropriate size 2. memcpy ClassInfo.init to allocated space 3. run constructor With or without explicit initialization requirements, you could put that initialization in the constructors. That is going to be slower than copying bytes in some circumstances. Of course, if there's only a few fields to set, since the allocator already zeroes out allocated memory, that's less work. In any case, it will be convenient to have ClassInfo.init, for doing various There Be Dragons things.
> With or without explicit initialization requirements, you could put that > initialization in the constructors. .init can't be moved to constructor, because you won't be able to set vptr correctly. Possible solution is to generate .init as a static function and inline it (or not) in the user code after call to new. Then call constructor. And trusting malloc to zero memory can be a good optimization. And I don't think .init for primitive types is copied as an array of bytes.
> > With or without explicit initialization requirements, you could put that > > initialization in the constructors. > .init can't be moved to constructor, because you won't be able to set vptr > correctly. Though setting of main vptr can be done in user code and other fields initialization can be moved to constructor (including interface fixups). Though this hardly makes difference in the case of inlining.
oops... *fix there's no interface fixups in the object, only vptrs.
Not a spec issue.
There are a few issues in the bug tracker for this, with some up-to-date information. For example https://issues.dlang.org/show_bug.cgi?id=7319 and https://issues.dlang.org/show_bug.cgi?id=13678 . So marking this as duplicate. *** This issue has been marked as a duplicate of issue 7319 ***