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.
-
-
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 -
Replying to @hankadusikova
Hm. Seems somewhat painful to write assumptions about memory not changing. Looks like it'd require copying the to-be-asssumed-unchanging memory, writing an assumption about it not having changed using memcmp() or such, and the compiler to realize that the copy is unnecessary?
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
It's currently in the committee pipeline. Perhaps someone should tell them this is an use-case. ^^
@timur_audio2 replies 0 retweets 1 like -
Replying to @hankadusikova @AndresFreundTec
Hm I don't think "this object hasn't changed" is a use case for assumptions. I think you can get what you want by using `const` and `const` references, and re-arranging your functions differently. Am I missing something?
1 reply 0 retweets 0 likes -
Or, even better, use value semantics and pass things by value. Imho that's the best way for you and your compiler to reason about what can change when and where.
2 replies 0 retweets 0 likes
That's not really an option for much of what I'm working on (largely RDBMs), unfortunately. E.g. I hardly can do that for a database's buffer cache - but I can guarantee there are no modifications on a page while holding a lock.
-
-
Passing a query execution plan by value would be way too expensive. There's a lot of query execution time datastructures that should not be copied, and need to be mutable, but there are sections where we know they can't change.
1 reply 0 retweets 0 likes -
And const [references] doesn't do much for my cases (see upthread). I agree that assume seems like a poor fit, it seems more like a type system level issue. But I'd take anything :)
1 reply 0 retweets 0 likes - 7 more replies
New conversation -
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.