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