C++ mutable in D
IGotD-
nise at nise.com
Sat Jul 31 13:35:21 UTC 2021
On Saturday, 31 July 2021 at 12:27:28 UTC, Gollan wrote:
>
> I'm really surprised you think it doesn't make much sense. What
> about:
>
> - Locking a mutex to avoid data races when returning a class
> member from a const getter function
> - Lazy resource allocation (caching) on first call of a const
> member function
They way I look at it if you don't want the code alter the
*memory location* then it must be immutable/const. The way you
describe it, it is based on what the API expect to do with the
object even if there might be internal memory writes, like the
semaphore example.
With structures where members are expanded into the structure,
then they share the memory location and partial const in my
opinion should be prohibited. Now this can be different with
classes as members are allocated independently but I'm sure about
the practical benefit.
It boils down to what we expect const to represent. I used the
word ROMable for a reason meaning the allocated memory should not
alter.
More information about the Digitalmars-d
mailing list