fix via mdinger

pull/10/head
Alexis Beingessner 10 years ago committed by Manish Goregaokar
parent c2e44a36f3
commit b6cf288741

@ -109,7 +109,7 @@ struct FooRepr {
And indeed this is approximately how it would be laid out in general And indeed this is approximately how it would be laid out in general
(modulo the size and position of `tag`). However there are several cases where (modulo the size and position of `tag`). However there are several cases where
such a representation is ineffiecient. The classic case of this is Rust's such a representation is inefficient. The classic case of this is Rust's
"null pointer optimization". Given a pointer that is known to not be null "null pointer optimization". Given a pointer that is known to not be null
(e.g. `&u32`), an enum can *store* a discriminant bit *inside* the pointer (e.g. `&u32`), an enum can *store* a discriminant bit *inside* the pointer
by using null as a special value. The net result is that by using null as a special value. The net result is that
@ -121,4 +121,4 @@ nested enums pooling their tags into a single descriminant, as they are by
definition known to have a limited range of valid values. In principle enums can definition known to have a limited range of valid values. In principle enums can
use fairly elaborate algorithms to cache bits throughout nested types with use fairly elaborate algorithms to cache bits throughout nested types with
special constrained representations. As such it is *especially* desirable that special constrained representations. As such it is *especially* desirable that
we leave enum layout unspecified today. we leave enum layout unspecified today.

Loading…
Cancel
Save