On Sunday, 29 May 2016 at 05:43:31 UTC, Mike Parker wrote:
On Sunday, 29 May 2016 at 05:35:33 UTC, Mike Parker wrote:
Well then, this completely breaks my understanding of variable
scope.
OK, I see now at [1] the following:
" Immutable data doesn't have synchronization problems, so the
On Sunday, 29 May 2016 at 06:49:42 UTC, chmike wrote:
What is the right way to use it ?
I answer to my self after testing so that people looking for that
info can find it here.
The right way would be
immutable Category category_;
Rebindable!(immutable Category) instance() { return
On Saturday, 28 May 2016 at 21:21:34 UTC, ag0aep6g wrote:
On 05/28/2016 09:54 PM, chmike wrote:
The only inconvenience left is that we can't have mutable
references
to immutable objects.
There is std.typecons.Rebindable for that.
That would be a good news. What is the right way to use it ?
On Sunday, 29 May 2016 at 05:35:33 UTC, Mike Parker wrote:
Well then, this completely breaks my understanding of variable
scope.
OK, I see now at [1] the following:
" Immutable data doesn't have synchronization problems, so the
compiler doesn't place it in TLS."
I've read that page more
On Saturday, 28 May 2016 at 15:39:44 UTC, ag0aep6g wrote:
On 05/28/2016 10:34 AM, Mike Parker wrote:
On Saturday, 28 May 2016 at 05:30:26 UTC, chmike wrote:
[...]
Is a static const Category c variable a TLS variable ?
Yes. All variables are TLS unless explicitly marked with
__gshared or
On 05/28/2016 09:54 PM, chmike wrote:
The only inconvenience left is that we can't have mutable references
to immutable objects.
There is std.typecons.Rebindable for that.
On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote:
I need to create an app wide singleton instance for my class.
The singleton is immutable, but I want to allow mutable
references to that singleton object so that I can do fast 'is'
tests.
I declared this
class Category
{
protected
On 05/28/2016 06:09 PM, chmike wrote:
In the following instruction of the above commit, what effect has the []
after init ?
_store[0 .. __traits(classInstanceSize, T)] = typeid(T).init[];
T is a template argument that is a class derived from Error.
I couldn't find an explanation here
On Saturday, 28 May 2016 at 08:47:48 UTC, Kagamin wrote:
For a trick of static mutable allocation see
https://github.com/dlang/druntime/pull/1325
In the following instruction of the above commit, what effect has
the [] after init ?
_store[0 .. __traits(classInstanceSize, T)] =
On 05/28/2016 10:34 AM, Mike Parker wrote:
On Saturday, 28 May 2016 at 05:30:26 UTC, chmike wrote:
[...]
Is a static const Category c variable a TLS variable ?
Yes. All variables are TLS unless explicitly marked with __gshared or
shared.
I don't think that's true.
import core.thread;
On Saturday, 28 May 2016 at 08:47:48 UTC, Kagamin wrote:
For a trick of static mutable allocation see
https://github.com/dlang/druntime/pull/1325
Thank you that looks promising. I'll study an experiment with the
code.
If I would like that the instances are not in TLS, can I use the
following
On Saturday, 28 May 2016 at 05:30:26 UTC, chmike wrote:
Would it be different if the object was declared const instead
of immutable ?
Sometimes compiler is able to figure out that const data is
immutable.
This is a bit frustrating because it is trivial to implement in
C and C++.
For a
On Saturday, 28 May 2016 at 08:34:17 UTC, Mike Parker wrote:
const(F) cf = f;
immutable(f) if = f;
And, of course, those should be const(Foo) and immutable(Foo).
On Saturday, 28 May 2016 at 05:30:26 UTC, chmike wrote:
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 ?
The difference lies in the guarantees of const and immutable.
Foo f = new
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
On Friday, 27 May 2016 at 20:20:36 UTC, chmike wrote:
The public interface of Category is designed so that the
object's state can't be modified and thus remains immutable.
Then... why cast away immutable?
I suppose there's always a core set of variables that are what
the object actually
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
On 5/27/16 4:20 PM, chmike wrote:
I need to create an app wide singleton instance for my class.
The singleton is immutable, but I want to allow mutable references to
that singleton object so that I can do fast 'is' tests.
I declared this
class Category
{
protected static immutable
I need to create an app wide singleton instance for my class.
The singleton is immutable, but I want to allow mutable
references to that singleton object so that I can do fast 'is'
tests.
I declared this
class Category
{
protected static immutable Category instance_ = new Category;
19 matches
Mail list logo
