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"
// ptr to const int
const(int)* p;
int* q = cast(int*)p;
*q = 3; // undefined behavior
But why would
simendsjo:
> But why would you want to cast away const then?
I presume for a situation where you are sure your code is just reading the
information and not modifying it, and you need something that is not const.
> assert(i == 10); // i still 10 though.. How is this possible?
You have don
On 08/08/2010 22:56, simendsjo 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"
Casting away const is mostly for dealing with external non D libra
Hello simendsjo,
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"
// ptr to const int
const(int)* p;
int* q = cast(int*)p;
*q = 3; // undefined behavi
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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 y
Steven Schveighoffer:
> 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?
In my opinio
Steven Schveighoffer wrote:
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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 w
e data can't be undefined behaviour, otherwise casting const
away is useless and can be totally disallowed.
Casting away const just to read the data is useless. You can read const
data without a cast.
But my understanding is that casting away const to write should be doable
if you know
On Mon, 09 Aug 2010 10:11:39 -0400, Don wrote:
Steven Schveighoffer wrote:
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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"
nd
then reading the data can't be undefined behaviour, otherwise casting
const away is useless and can be totally disallowed.
Casting away const just to read the data is useless. You can read const
data without a cast.
No you can't. You can't pass it to a C function.
But my
Hello Steven,
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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 "y
Hello Steven,
On Mon, 09 Aug 2010 10:11:39 -0400, Don wrote:
Steven Schveighoffer wrote:
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
wrote:
I'm totally new to the const/immutable thing, so this might be a
naive question..
The spec says:
"modification after casting
d its const nature with a cast. Just casting const away and
then reading the data can't be undefined behaviour, otherwise casting
const away is useless and can be totally disallowed.
Casting away const just to read the data is useless. You can read
const data without a cast.
No you c
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 l
On Mon, 09 Aug 2010 10:24:56 -0400, BCS wrote:
Hello Steven,
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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" => "undefin
reading the data can't be undefined behaviour, otherwise
casting const away is useless and can be totally disallowed.
Casting away const just to read the data is useless. You can read
const data without a cast.
But my understanding is that casting away const to write should be
doable if you kn
stion..
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 co
Hello Steven,
On Mon, 09 Aug 2010 10:24:56 -0400, BCS wrote:
Hello Steven,
On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
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"
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" wa
On Mon, 09 Aug 2010 11:04:40 -0400, Steven Schveighoffer
wrote:
On Mon, 09 Aug 2010 10:53:48 -0400, BCS wrote:
OTOH that is effectively a hidden cast and has 100% of the same issues
(re undefined behavior) as casting away const while being slightly
harder to find.
But you just said
Steven Schveighoffer:
> extern(C) int strlen(const(char)* str);
C has no const(char)* so I am now thinking about a possible D2 diagnostic
enhancement request that turns that line of code into a compile time error :-)
Bye,
bearophile
On Mon, 09 Aug 2010 11:15:38 -0400, bearophile
wrote:
Steven Schveighoffer:
extern(C) int strlen(const(char)* str);
C has no const(char)* so I am now thinking about a possible D2
diagnostic enhancement request that turns that line of code into a
compile time error :-)
But an extern(C
Steven Schveighoffer:
> But an extern(C) function does not have to be written in C :)
You are right. But that function written in an arbitrary language has to follow
the C interface rules and limitations, and among those there is no way to
define a variable to be const(char)*.
So in that line o
const.
OTOH that is effectively a hidden cast and has 100% of the same
issues (re undefined behavior) as casting away const while being
slightly harder to find.
But you just said that casting and reading is not undefined? Isn't
this the same thing?
Casting away const or tacking co
Steven Schveighoffer wrote:
class C
{
private Mutable!(int) cache = -1;
int expensiveFunction() const { return cache == -1 ? cache =
_expensiveFunctionImpl() : cache; }
private int _expensiveFunctionImpl() const {...}
}
If this is undefined, then something like this cannot be reli
ut the result of opAssign.
Note also that the optimization you stated is not possible, even without
casting away const, but would be possible on an immutable class. But the
fact that the compiler cannot peek into the implementation of the opAssign
means it's forced to make no assumption
Am 09.08.2010 17:31, schrieb bearophile:
Steven Schveighoffer:
But an extern(C) function does not have to be written in C :)
You are right. But that function written in an arbitrary language has to follow
the C interface rules and limitations, and among those there is no way to
define a vari
after you
>>>> have removed its const nature with a cast. Just casting const away
>>>> and then reading the data can't be undefined behaviour, otherwise
>>>> casting const away is useless and can be totally disallowed.
>>> Casting away const just to
Mafi:
> I think, that isn't a good idea.
I agree, that idea doesn't work well.
Bye,
bearophile
bearophile wrote:
> Mafi:
>> I think, that isn't a good idea.
>
> I agree, that idea doesn't work well.
>
> Bye,
> bearophile
I think it still is a good idea to forbid this in safe mode. Perhaps in trusted
too.
On Mon, 09 Aug 2010 14:39:58 -0400, Lutger
wrote:
bearophile wrote:
Mafi:
I think, that isn't a good idea.
I agree, that idea doesn't work well.
Bye,
bearophile
I think it still is a good idea to forbid this in safe mode. Perhaps in
trusted
too.
Note, this isn't any less safe tha
Steven Schveighoffer wrote:
> On Mon, 09 Aug 2010 14:39:58 -0400, Lutger
> wrote:
>
>> bearophile wrote:
>>
>>> Mafi:
I think, that isn't a good idea.
>>>
>>> I agree, that idea doesn't work well.
>>>
>>> Bye,
>>> bearophile
>>
>> I think it still is a good idea to forbid this in safe mode.
Steven Schveighoffer wrote:
Note also that the optimization you stated is not possible, even without
casting away const, but would be possible on an immutable class. But
the fact that the compiler cannot peek into the implementation of the
opAssign means it's forced to ma
Simen kjaeraas wrote:
Steven Schveighoffer wrote:
Note also that the optimization you stated is not possible, even
without casting away const, but would be possible on an immutable
class. But the fact that the compiler cannot peek into the
implementation of the opAssign means it&#
On Mon, 09 Aug 2010 15:49:12 -0400, Simen kjaeraas
wrote:
Simen kjaeraas wrote:
Steven Schveighoffer wrote:
Note also that the optimization you stated is not possible, even
without casting away const, but would be possible on an immutable
class. But the fact that the compiler
On Monday, August 09, 2010 07:13:31 Steven Schveighoffer wrote:
> Casting away const just to read the data is useless. You can read const
> data without a cast.
That's not actually quite true. If all code were const-correct, then it would
be, but much of D is not. For instance, toHa
On Mon, 09 Aug 2010 17:15:41 -0400, Jonathan M Davis
wrote:
On Monday, August 09, 2010 07:13:31 Steven Schveighoffer wrote:
Casting away const just to read the data is useless. You can read const
data without a cast.
That's not actually quite true. If all code were const-correct, th
On Monday, August 09, 2010 15:01:28 Steven Schveighoffer wrote:
> Then the author failed to make it const, and it's a bug in the function
> definition. "Casting away const if you don't write" is crap, and should
> be treated as suspiciously as code that writes to cons
On Mon, 09 Aug 2010 19:35:38 -0400, Jonathan M Davis
wrote:
On Monday, August 09, 2010 15:01:28 Steven Schveighoffer wrote:
Then the author failed to make it const, and it's a bug in the function
definition. "Casting away const if you don't write" is crap, and
39 matches
Mail list logo
