Date: Thu, 12 Jun 2025 09:06:40 +0000
There's a lot that has changed regarding multi-threading since 2011.
Regardless thread or no thread, modifying a const object should just be UB (with exception of the parts marked mutable) even in single threaded applications.
Using const_cast to cast away const should just be a compiler error straight up, if you do that your code shouldn't be allowed to compile, but for some reason it does now.
Casting away const is not what const_cast should be used for.
-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_lists.isocpp.org> On Behalf Of Marvin Williams via Std-Discussion
Sent: Thursday, June 12, 2025 10:56 AM
To: std-discussion_at_[hidden]
Cc: Marvin Williams <marvinwilliams95_at_[hidden]>
Subject: [std-discussion] Implications of [res.on.data.races]
Hi all,
in the current working draft, clause [res.on.data.races] (ยง16.4.6.10, https://eel.is/c++draft/res.on.data.races), which regards data race avoidance in the standard library implementation, states (Paragraph 3):
"A C++ standard library function shall not directly or indirectly modify objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments, including this."
What I'm reading into this is that it is UB if a standard library function calls a const member function of an object that was passed to it via a const ref, and the the const member function "modifies" the object (via const_cast or a mutable member).
However, I doubt that this is the correct interpretation.
There is some discussion about this clause, but I couldn't find a definitive answer.
Most notably, there is a talk by Herb Sutter:
https://web.archive.org/web/20170119232617/https://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank
At about 15:35, he states that since C++11, const implies threadsafe, because it implies either bitwise const or internal synchronization (e.g., by a mutable std::mutex).
With the above interpretation, I can see how const may imply bitwise const, but I fail to see how Herb derives the internal synchronization requirement. In my understanding, the example given at 26:00, locking a mutable std::mutex member still modifies the object, violating [res.on.data.races], if a standard library function were to call
w.get_info() on a const widget& w.
My main questions are:
What are the requirements for const member functions that are intended to be used with the standard library, and how does thread-safety relate to the const qualifier?
Best
Marvin
--
Std-Discussion mailing list
Std-Discussion_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Regardless thread or no thread, modifying a const object should just be UB (with exception of the parts marked mutable) even in single threaded applications.
Using const_cast to cast away const should just be a compiler error straight up, if you do that your code shouldn't be allowed to compile, but for some reason it does now.
Casting away const is not what const_cast should be used for.
-----Original Message-----
From: Std-Discussion <std-discussion-bounces_at_lists.isocpp.org> On Behalf Of Marvin Williams via Std-Discussion
Sent: Thursday, June 12, 2025 10:56 AM
To: std-discussion_at_[hidden]
Cc: Marvin Williams <marvinwilliams95_at_[hidden]>
Subject: [std-discussion] Implications of [res.on.data.races]
Hi all,
in the current working draft, clause [res.on.data.races] (ยง16.4.6.10, https://eel.is/c++draft/res.on.data.races), which regards data race avoidance in the standard library implementation, states (Paragraph 3):
"A C++ standard library function shall not directly or indirectly modify objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments, including this."
What I'm reading into this is that it is UB if a standard library function calls a const member function of an object that was passed to it via a const ref, and the the const member function "modifies" the object (via const_cast or a mutable member).
However, I doubt that this is the correct interpretation.
There is some discussion about this clause, but I couldn't find a definitive answer.
Most notably, there is a talk by Herb Sutter:
https://web.archive.org/web/20170119232617/https://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank
At about 15:35, he states that since C++11, const implies threadsafe, because it implies either bitwise const or internal synchronization (e.g., by a mutable std::mutex).
With the above interpretation, I can see how const may imply bitwise const, but I fail to see how Herb derives the internal synchronization requirement. In my understanding, the example given at 26:00, locking a mutable std::mutex member still modifies the object, violating [res.on.data.races], if a standard library function were to call
w.get_info() on a const widget& w.
My main questions are:
What are the requirements for const member functions that are intended to be used with the standard library, and how does thread-safety relate to the const qualifier?
Best
Marvin
--
Std-Discussion mailing list
Std-Discussion_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Received on 2025-06-12 09:06:47