Do you have any C++ question? I will try to answer it.
-
-
Replying to @hankadusikova
Is there an upcoming way to properly promise compilers that memory will not change within some region? Const doesn't do the trick in most situations. What is the state of compile time introspection? Any chance to see that in the next revision?
1 reply 0 retweets 1 like -
Replying to @AndresFreundTec
You need to elaborate more about the const not doing the trick. Introspection is on its track and all stakeholders are hoping for 23.
2 replies 0 retweets 2 likes -
Replying to @hankadusikova
Well, const doesn't guarantee that there's no other non-const pointers that could also modify the memory. It's also legal to cast const away if the underlying memory wasn't constant. So it doesn't really help the compiler to recognize the compiler to realize memory won't change.
2 replies 0 retweets 1 like -
Replying to @AndresFreundTec @hankadusikova
Sometimes escape analysis, strict aliasing, restrict etc can get the job done, but it's unreliable as hell. I often see hotspots in profiles dereferencing multiple levels of pointers repeatedly, just because of an intermittent function call.
2 replies 0 retweets 1 like -
Replying to @AndresFreundTec
you are describing undefined behavior, const value in a scope can't be changed by a current thread, compile with -fstrict-aliasing
1 reply 0 retweets 0 likes -
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
And strict aliasing only helps if the types are actually distinct. Far from a given.
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.