Date: Fri, 14 Nov 2025 11:52:29 -0600
Hi,
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
I don't really see how this is useful.
In the case of a microcontroller where you happen to be able to write
to flash under certain circumstances, you'd pretty much never write
class types anyway. Microcontrollers that support writing to their
flash to do so that they can flash themselves, that's a memcpy of
bytes not a placement new of classes with mutable members. This is a
pretty rare thing and the type of bug you're trying to protect against
is not hard to prevent against. This is not a situation that needs or
would really benefit from language support. The same story goes for
desktops.
Even if this was a situation that would benefit from language support
there is a much larger set of considerations here than just whether
types have mutable members. Usually you are writing to memory first
before locking it into place read-only, if you want type-system
protection against accidentally writing it later on you'd also need to
ensure you have no non-const references or pointers to objects in that
memory.
Jeremy
On Fri, Nov 14, 2025 at 8:38 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Microcontrollers have a single address space for non-volatile and
> volatile memory.
>
> 0x0 - 0x2000 might be the non-volatile Flash
> 0x2000 - 0x8000 might be the volatile SRAM
>
> At runtime, the flash can be toggled writable or read-only.
>
> Similarly on desktop PC's, a page of memory can be toggled from
> writable to read-only.
>
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
>
> So I've implemented "std::contains_mutable". Here's my compiler patch
> for GNU g++:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_contains_mutable
>
> And here it is tested up on GodBolt:
>
> https://godbolt.org/z/KosvqTETo
>
> Looking over the recent papers on reflection . . . I think this would
> be done in reflection as follows:
>
> https://godbolt.org/z/4ezv58zxx
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
I don't really see how this is useful.
In the case of a microcontroller where you happen to be able to write
to flash under certain circumstances, you'd pretty much never write
class types anyway. Microcontrollers that support writing to their
flash to do so that they can flash themselves, that's a memcpy of
bytes not a placement new of classes with mutable members. This is a
pretty rare thing and the type of bug you're trying to protect against
is not hard to prevent against. This is not a situation that needs or
would really benefit from language support. The same story goes for
desktops.
Even if this was a situation that would benefit from language support
there is a much larger set of considerations here than just whether
types have mutable members. Usually you are writing to memory first
before locking it into place read-only, if you want type-system
protection against accidentally writing it later on you'd also need to
ensure you have no non-const references or pointers to objects in that
memory.
Jeremy
On Fri, Nov 14, 2025 at 8:38 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Microcontrollers have a single address space for non-volatile and
> volatile memory.
>
> 0x0 - 0x2000 might be the non-volatile Flash
> 0x2000 - 0x8000 might be the volatile SRAM
>
> At runtime, the flash can be toggled writable or read-only.
>
> Similarly on desktop PC's, a page of memory can be toggled from
> writable to read-only.
>
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
>
> So I've implemented "std::contains_mutable". Here's my compiler patch
> for GNU g++:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_contains_mutable
>
> And here it is tested up on GodBolt:
>
> https://godbolt.org/z/KosvqTETo
>
> Looking over the recent papers on reflection . . . I think this would
> be done in reflection as follows:
>
> https://godbolt.org/z/4ezv58zxx
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-11-14 17:52:46
