On 2013-10-22, Neil Cerutti <ne...@norwich.edu> wrote:
> On 2013-10-22, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
>> On Tue, 22 Oct 2013 14:04:57 +0000, Dave Angel wrote:
>>> but here you go on to say the C code is unsafely skipping
>>> initialization, which is not the case.
>>
>> Are you talking generically, or specifically about the C code
>> referenced in the link I gave?
>>
>> "Memory is always zeroed" is one of the advantages of Go over C and C++,
>> at least according to Rob Pike:
>>
>> http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
>> more.html
>
> Go initializes variables to defined zero values, not simply to
> all-bits zero as (I think) C does.
C initializes to defined zero values. For most machines in use today,
those values _happen_ to be all-bits-zero.
This makes the implementation trivial: chuck them all into some
pre-defined section (e.g. ".bss"), and then on startup, you zero-out
all the bits in the section without having to know what's where within
that section. If you design a machine such that integer, pointer, and
FP representations where 0, NULL, and 0.0 are all zero-bits, then life
get's tougher for the guys writing the compiler and startup code.
But the language doesn't require or assume that initializer values are
all-bits-zero. FP values have to be initizliaed to 0.0. Int's have
to be initialized to integer value 0, pointers have to be initialized
to (void*)0. Nowhere it the languauge is it required or assumed that
any or all of those values are all represented by contiguous blocks of
all-zero-bits.
> This isn't as great a feature as it seems, since the zero value for
> some built in types, e.g., map, is unusable without manual
> construction. In addition, you can't define a zero value for your own
> types.
--
Grant Edwards grant.b.edwards Yow! Oh my GOD -- the
at SUN just fell into YANKEE
gmail.com STADIUM!!
--
https://mail.python.org/mailman/listinfo/python-list
