On Friday, 27 May 2016 at 21:41:02 UTC, Kagamin wrote:
On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote:
Is this code valid D or is the behavior undefined due to the
cast ?
A mutable object can be synchronized on:
synchronized(Category.instance){}
This will create and store a mutex in the object (sad but true,
design taken from java). If the immutable object is in readonly
memory, it will crash on write.
That is a good argument. Thanks. It would indeed be a good idea
to put immutable objects in a read only portion of the code.
Would it be different if the object was declared const instead of
immutable ?
I want compile time instantiation and mutable references to the
object. Apparently only immutable and const objects can be
instantiated at compile time. I also want an app wide singleton
(not stored in TLS). If I use _gshared I apparently wouldn't get
a compile time instantitation.
It's to implement the flyweight pattern. I don't want to use
Rebindable because the assembly code generated by dmd is
currently inefficient. Rebindable cast away the const but the non
constant reference is not exposed.
What is the difference between a const and immutable object ?
would a const object be allowed to modify itself by using a hash
table or caching results inside ? Is a static const Category c
variable a TLS variable ?
This is a bit frustrating because it is trivial to implement in C
and C++.
