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