Hi, 05.04.2018 10:12, Ondrej Pokorny пишет: [...]
1.) Global variables are initialized. (Why is simple global variables initialization needed for internal bookkeeping of the compiler?)
IIRC this was historically introduced by Borland (ages ago) because it was very cheap and easy to ask an OS of their choice to zero-out .data segment upon executable module loading, effectively getting initialization for free, and at that time (ages ago!) speed was what they cared most about.
2.) Class fields are initialized. (Why is simple class fields initialization needed for internal bookkeeping of the compiler?)
Here again, it was relatively cheap and easy to fillchar/memset object's body internally before use. Not competely free, but pretty efficient still. So essentially same reason, I'd say.
3.) Everything else is not initialized.
Apparently this was not so cheap and not so easy for Borland (at least at that time). So apparently they chose to ignore.
From my personal perspective, this indeed is implementation detail, however wildely abused (me included), and it is a rather unfortunate situation. E.g. I'd be in a huge disaster if implicitely initialized strings suddenly start to be '<uninitialized string>' instead of empty. So ideally, something clever should be done about it at some point. Maybe indeed declaring it as a guaranteed behaviour or something. I kind of doubt there is a realistic chance of changing it anyway, due to compatability reasons...
Thank you. Regards, Nikolai _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
