you are describing undefined behavior, const value in a scope can't be changed by a current thread, compile with -fstrict-aliasing
-
-
Replying to @hankadusikova
But the target of a pointer to a const value can. And while sometimes that's good enough, often it's not really an option. Sometimes escape analysis is sufficient for the compiler to realize an external call won't affect content of a dynamic allocation, but not that often.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec
In the language model of C++ it can't and optimizer is allowed to optimized on this premise. Changing the value is an undefined behavior. Let me be clear, I'm not talking about any existing CPU or real computer. I'm talking about C++ model.
1 reply 0 retweets 0 likes -
Replying to @hankadusikova
I think there might be a misunderstanding here. I'm talking about something like int foo(const sometype *p) { if (p->blub < 10) return 0; compute_something(); if (p->blub < 100) return 1; return -1; }
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
AFAIU it isn't UB for p->blub to change across inside of compute_something(). Unless I get the compiler to see that p was allocated const (e.g. const sometype st = ...; foo(&st);) C++ doesn't allow to make the assumption on its own.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
Even if allocated const the compiler often won't see that (cross TU, too many layers). Also, often it's not actually desirable to have the value be constant for the whole lifetime. It's just for a region of code. Unless I copy the value I cannot make C[++] recognize that.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Ok, thank you for the example. In this case you can't tell C++ it won't change. The best way is to change your code, so it won't use globals. And if it's member function, you should mark it const.
1 reply 0 retweets 0 likes -
Replying to @hankadusikova
Not using globals doesn't mean the compiler *knows* I'm not. That's kind of my point. Just because I *could* have another pointer the compiler needs to generate slower code. I.e. I don't want less UB, instead I want to add a way to make it UB for pointed to objects to change.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @hankadusikova
(In realistic examples compute_something() would affect code flow and probably take parameters, i.e. wouldn't only be meaningful if it did something with globals. Was too quick to type out the example to think of that.)
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec
Oh, this is part of a very actual discussion in the committee about contracts and assumptions. You will be able to write an assumption that the object is not changed. And compiler will be able to use it for making an optimization.
3 replies 0 retweets 1 like
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.