http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #7 from jarrett.billings...@gmail.com 2009-02-21 10:56 ---
(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 th
http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #6 from 2kor...@gmail.com 2009-02-21 03:30 ---
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*),
http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #5 from bugzi...@digitalmars.com 2009-02-20 21:50 ---
The .init block is never all zero, as the first member is the vtpr initializer.
--
http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #4 from clugd...@yahoo.com.au 2009-02-03 03:12 ---
Intializing to zero won't work for floats and char (which init to 0xFF...).
But it'd be a nice optimisation for other cases.
--
http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #3 from ma...@pochta.ru 2009-02-03 02:07 ---
> 1. Move zero memory to bss section and zero it at startup.
This will be efficient in terms of both time and storage requirements.
--
http://d.puremagic.com/issues/show_bug.cgi?id=2642
ma...@pochta.ru changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from
http://d.puremagic.com/issues/show_bug.cgi?id=2642
--- Comment #1 from 2kor...@gmail.com 2009-02-02 15:36 ---
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
