On Mon, 09 Aug 2010 10:37:14 -0400, BCS <n...@anon.com> wrote:
Hello Steven,
On Mon, 09 Aug 2010 10:11:39 -0400, Don <nos...@nospam.com> wrote:
Steven Schveighoffer wrote:
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
<simen.end...@pandavre.com> wrote:
I'm totally new to the const/immutable thing, so this might be a
naive question..
The spec says:
"modification after casting away const" => "undefined behavior"
I thought it was "you're on your own", not undefined behavior. The
former implies there is some "right" way to do this if you know more
about the data than the compiler, the latter implies that there is
no
right way to cast away const. Am I wrong?
-Steve
I think you're wrong. It's OK to cast away const, as long as you
don't
modify the thing which is supposed to be const.
But if you modify it, there's no way the compiler can guarantee that
your code will work. Anything could happen.
But then what is the point of casting away const? If you are not
going to modify it, then there is no reason to cast it away.
There are some cases where non-const pointers are used but never
modified (C api's for instance) cast as always is just a way subvert the
type system where it gets in your way.
C's api can be modified at declaration. It has no mangling, so you can
type it how it should be (if C had const). For example:
extern(C) int strlen(const(char)* str);
I find that much more pleasant than having to cast away const.
-Steve
