By ref and by pointer kills performance.
FeepingCreature
feepingcreature at gmail.com
Sun Feb 18 16:44:03 UTC 2024
On Sunday, 18 February 2024 at 13:41:42 UTC, FeepingCreature
wrote:
> On Friday, 16 February 2024 at 15:12:58 UTC, Kagamin wrote:
>> On Friday, 16 February 2024 at 11:10:13 UTC, Richard (Rikki)
>> Andrew Cattermole wrote:
>>> Immutable objects can be in read only memory, since nothing
>>> is allowed to modify the contents process wide.
>>
>> Then you won't be able to create a monitor for them.
>
> I don't get this point. The monitor field can just be the
> single pointer that is not transitively immutable? I mean. The
> compiler knows *exactly* when you access the monitor field.
> It's never accessed manually! This is a pointer access that can
> be generated at exactly line of code in the compiler. Just drop
> immutable there.
> I hope someone can find the link to some DConf talk (me or
> Andrei) or forum post where I talk about why LDC assumes that
> immutable(uint*) points to mutable (nota bene) data. The reason
> is the mutable thread synchronization field in immutable class
> variable storage (__monitor), combined with casting an
> immutable class to an array of immutable bytes.
Okay I think I overread this, probably because it's absurd. Why
is this idiom worth protecting? You're hardcasting *anyways*,
it's forbidden in @safe *anyways*, just cast __monitor to uint*
instead of immutable(uint*). If you're interacting with classes
at such a deep level, asking you to remember that there's a
mutable field in there even in immutable classes doesn't seem
like a big ask.
More information about the Digitalmars-d
mailing list