August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Steven Schveighoffer wrote: > On Mon, 09 Aug 2010 09:57:47 -0400, bearophile <bearophileHUGS@lycos.com> wrote: > >> 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 opinion if this thing is well designed then you go in undefined behaviour only when you change the contents of something 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 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 understanding is that casting away const to write should be doable if you know what you're doing. If this is undefined behavior, then that's fine, I'm just unclear on what "undefined behavior" actually means. I thought "undefined behavior" means that you cannot count on the behavior to work in the future. > > An example of where casting away const to write should be allowed is for a hypothetical mutable member: > > 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 relied on, even when performance is critical. > > -Steve I really can't see how the compiler could make that work, without destroying most of the benefits of const. For example, if that code is legal, it disallows most const-related optimisation. |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | On Mon, 09 Aug 2010 10:27:09 -0400, Don <nospam@nospam.com> wrote: > Steven Schveighoffer wrote: >> On Mon, 09 Aug 2010 09:57:47 -0400, bearophile <bearophileHUGS@lycos.com> wrote: >> >>> 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 opinion if this thing is well designed then you go in undefined behaviour only when you change the contents of something 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 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. Sure you can. extern(C) int strlen(const(char) *arg); > >> But my understanding is that casting away const to write should be doable if you know what you're doing. If this is undefined behavior, then that's fine, I'm just unclear on what "undefined behavior" actually means. I thought "undefined behavior" means that you cannot count on the behavior to work in the future. >> An example of where casting away const to write should be allowed is for a hypothetical mutable member: >> 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 relied on, even when performance is critical. >> -Steve > > I really can't see how the compiler could make that work, without destroying most of the benefits of const. For example, if that code is legal, it disallows most const-related optimisation. Why not? What possible optimization can the compiler do here? Mutable has an assign operation that is labeled as const, it should be callable by the compiler. I haven't really seen what const optimizations can be, so maybe an example (even if unimplemented) is helpful. -Steve |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Hello Steven, > On Mon, 09 Aug 2010 10:11:39 -0400, Don <nospam@nospam.com> wrote: > >> Steven Schveighoffer wrote: >> >>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo >>> <simen.endsjo@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. -- ... <IXOYE>< |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | On Mon, 09 Aug 2010 10:37:14 -0400, BCS <none@anon.com> wrote:
> Hello Steven,
>
>> On Mon, 09 Aug 2010 10:11:39 -0400, Don <nospam@nospam.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>
>>>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
>>>> <simen.endsjo@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
|
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | On Mon, 09 Aug 2010 10:24:56 -0400, BCS <none@anon.com> wrote:
> Hello Steven,
>
>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
>> <simen.endsjo@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?
>
> I think you are right re the meaning of those terms but I think what you thought it to be is more along the lines of what is correct. I /think/ the situation is that there are things that will work reliably and things that result in undefined behavior and you're on your own figuring out what is what.
I'm sort of interpreting what you're saying is:
In some cases, you can cast away const and modify the variable with no adverse effects, but we can't tell you which cases those are.
Which is kind of like saying "yes, casting away const is allowed, but only people who wrote the compiler can do it".
-Steve
|
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Hello Steven, > On Mon, 09 Aug 2010 09:57:47 -0400, bearophile > <bearophileHUGS@lycos.com> wrote: > >> 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 opinion if this thing is well designed then you go in undefined >> behaviour only when you change the contents of something 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 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 what you're doing. If this is undefined behavior, > then that's fine, I'm just unclear on what "undefined behavior" > actually means. I thought "undefined behavior" means that you cannot > count on the behavior to work in the future. Undefined behavior implies exactly that, once you enter the realm of undefined behavior, /anything/ that happens is your fault, the program can do anything at all and sill be considered a conforming program. It need not even behave the same between one run and the next. The practical implications of this are that compilers are allowed to always assume the code never does anything that results in undefined behavior and generate code that is wrong in any number of ways if that assumption fails. -- ... <IXOYE>< |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Hello Steven, > On Mon, 09 Aug 2010 10:37:14 -0400, BCS <none@anon.com> wrote: > >> Hello Steven, >> >>> On Mon, 09 Aug 2010 10:11:39 -0400, Don <nospam@nospam.com> wrote: >>> >>>> Steven Schveighoffer wrote: >>>> >>>>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo >>>>> <simen.endsjo@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. 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. -- ... <IXOYE>< |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Hello Steven, > On Mon, 09 Aug 2010 10:24:56 -0400, BCS <none@anon.com> wrote: > >> Hello Steven, >> >>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo >>> <simen.endsjo@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? >>> >> I think you are right re the meaning of those terms but I think what >> you thought it to be is more along the lines of what is correct. I >> /think/ the situation is that there are things that will work >> reliably and things that result in undefined behavior and you're on >> your own figuring out what is what. >> > I'm sort of interpreting what you're saying is: > > In some cases, you can cast away const and modify the variable with no > adverse effects, but we can't tell you which cases those are. Yes and no. Yes, sometimes casting away const and then writing to the pointer doesn't crash your program (or do anything else) but no that's not what I was saying. It's still undefined behavior even if it "works". What "your on your own" with is making sure you don't write to the pointer. Once you cast, the compiler won't check your work. > > Which is kind of like saying "yes, casting away const is allowed, but > only people who wrote the compiler can do it". > > -Steve > -- ... <IXOYE>< |
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | On Mon, 09 Aug 2010 10:53:48 -0400, BCS <none@anon.com> wrote:
> Hello Steven,
>
>> On Mon, 09 Aug 2010 10:37:14 -0400, BCS <none@anon.com> wrote:
>>
>>> Hello Steven,
>>>
>>>> On Mon, 09 Aug 2010 10:11:39 -0400, Don <nospam@nospam.com> wrote:
>>>>
>>>>> Steven Schveighoffer wrote:
>>>>>
>>>>>> On Sun, 08 Aug 2010 17:56:25 -0400, simendsjo
>>>>>> <simen.endsjo@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.
>
> 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?
Const is such a strange beast because it plays no role in code generation, it's effectively only a tool to help the compiler decide what is possible. It doesn't occupy any space or translate whatsoever to the underlying code.
I think there are definite good uses for writing to const or immutable data besides ones that can be stored in ROM. That is, if you are sure a const or immutable piece of data is on the heap/stack, it should be reasonable to be able to modify it for performance gains.
-Steve
|
August 09, 2010 Re: Casting away const | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Mon, 09 Aug 2010 11:04:40 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Mon, 09 Aug 2010 10:53:48 -0400, BCS <none@anon.com> 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 that casting and reading is not undefined? Isn't this the same thing?
>
> Const is such a strange beast because it plays no role in code generation, it's effectively only a tool to help the compiler decide what is possible. It doesn't occupy any space or translate whatsoever to the underlying code.
>
> I think there are definite good uses for writing to const or immutable data besides ones that can be stored in ROM. That is, if you are sure a const or immutable piece of data is on the heap/stack, it should be reasonable to be able to modify it for performance gains.
I should say, when performance gains are not possible because of the limitations of the const/immutable notation. The classic example is the mutable cache for avoiding recalculations on an immutable object.
-Steve
|
Copyright © 1999-2021 by the D Language Foundation