On Sun, Aug 20, 2017 at 10:23:27PM -0700, chou wrote:
> I guess that const will be substitute literally at compile time
> for performance improvements. So there is not such variable in
> run time.
>
> Is it right?
One of the reasons for this is that constants in Go have properties
which set them apart from values:
- For numerics, they are allowed (and enforced to a certain extent)
to have size and/or precision way larger than of the regular types
supported by the language.
That is
const onethird = 1 / 3
has greater precision than
onethird := float64(1) / 3
and this may affect calculations done on floating-point numbers.
See for instance [2] for a recent example on why this matters.
[3] is an in-depth explanation of those effects, and [4] is a gentler
one.
- Constant are "almost typeless": they have default type for their
literal value (say, int for the literal 42 or string for the literal
"42") but the compiler allows a much greater freedom when you assign
a constant to a variable (which has exact type).
Say, in Go, it's impossible to do
i := 0
uint32 j := i
but it's perfectly valid to do
const i = 0
uint32 j := i
As you can see, having these properties appears to be incompatible
with actually storing the values of the constants in some R/O memory
and making them addressable.
Please read [1] to get full grasp on constants in Go.
1. https://blog.golang.org/constants
2. https://groups.google.com/d/topic/golang-nuts/XP-_nRWjKnM/discussion
3. http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
4. http://floating-point-gui.de/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
