queue container?
Jonathan M Davis
jmdavisProg at gmx.com
Wed Oct 26 10:12:00 PDT 2011
On Wednesday, October 26, 2011 09:35 Timon Gehr wrote:
> On 10/26/2011 04:36 PM, Steven Schveighoffer wrote:
> > On Wed, 26 Oct 2011 10:13:06 -0400, Gor Gyolchanyan
> >
> > <gor.f.gyolchanyan at gmail.com> wrote:
> >> It should have both shared and unshared implementations of methods to
> >> be a full-fledged container.
> >
> > Maybe, maybe not.
> >
> > I'm reluctant to add a copy of all functions to the containers just to
> > support shared. We don't have a const or inout equivalent for shared.
>
> Copying all the methods and marking them with shared does not make the
> code thread safe. The shared and unshared versions would have to be
> different anyways. There is no way do get something that relates to
> shared/unshared as const does to mutable/immutable.
If you really want it thread-safe, you have to mark the class/struct as
synchronized, which introduces overhead and would be unacceptable in the
general case. A simple wrapper type would probably suffice for that though.
The main problem then is being able to have the wrapped instance be shared,
and if you have to overload all of the functions for that, that's pretty bad
and would tend to lean toward making shared unusable. Certainly, a large
amount of code which might otherwise be valuable in some situations as shared
wouldn't work with it simply because it wasn't worth the time and effort to
make it possible when it was written.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list