On Wednesday, October 05, 2016 21:10:01 Begah via Digitalmars-d-learn wrote:
> Although the triple buffer seems a good idea, there is one
> problem.
> I will need three time as much ram than what i currently need.
> Not to mention, every time i switch buffer i will need to copy
> all changes made
On Wednesday, 5 October 2016 at 12:48:07 UTC, Jonathan M Davis
wrote:
On Wednesday, October 05, 2016 11:25:57 Begah via
Digitalmars-d-learn wrote:
[...]
Unless you're writing lock-free algorithms (which really should
only be done by experts, and even then, they should probably
reconsider
e a method that accepts being called by both a
> >> shared and non-shared object, to prevent having to copy
> >> methods and adding a "shared"?
> >
> > You could templatize them, but really, the idea is that you
> > _don't_ call much of anything on a
On Wednesday, 5 October 2016 at 07:36:58 UTC, Jonathan M Davis
wrote:
On Tuesday, October 04, 2016 19:22:10 Begah via
Digitalmars-d-learn wrote:
How can I make a method that accepts being called by both a
shared and non-shared object, to prevent having to copy
methods and adding a "s
On Tuesday, October 04, 2016 19:22:10 Begah via Digitalmars-d-learn wrote:
> How can I make a method that accepts being called by both a
> shared and non-shared object, to prevent having to copy methods
> and adding a "shared"?
You could templatize them, but really, the idea
eContents(6);
imShared.printContents();
}
Non-`shared` methods are not required to be somehow thread-safe at all.
So they can't be allowed to be called on `shared` objects.
The compiler can't automatically ensure thread-safety, because it can't
know what can run in parallel and what can't.
= new shared Image("Test2", 80);
imShared.printContents();
imShared.changeContents(6);
imShared.printContents();
}
How can I make a method that accepts being called by both a
shared and non-shared object, to prevent having to copy methods
and adding a "shared&qu
