std.container and classes

Jonathan M Davis jmdavisProg at gmx.com
Tue Dec 20 20:44:44 PST 2011


On Tuesday, December 20, 2011 22:15:43 Caligo wrote:
> On Sun, Dec 18, 2011 at 10:12 PM, Jonathan M Davis 
<jmdavisProg at gmx.com>wrote:
> > So, I'm beginning to think that we're going to have to go the struct
> > route.
> > 
> > - Jonathan M Davis
> 
> Two questions:
> 
> 1. If you guys, the D experts, are having such a difficult time with this,
> what happens to the rest of us when we need to implement data structures
> that are not offered by Phobos?  Do we just wait and see what happens with
> Phobos and learn from it?

Containers are fairly straightforward in general. So, if you need to implement 
your own, it's not generally all that hard. The problem here is that the 
standard library needs to be efficient in the general case. We don't know under 
what circumstances these containers are going to be used, so we're under 
different constraints than someone who's writing a container for their own use.

Clearly, containers can be either structs or classes. Both will work. The 
issue is which will be more efficient in the general case. And if you're 
implementing your own containers, you can choose to do what Phobos does or go 
another route - especially since you're going to know under what circumstances 
you're using your own containers. For the most part, I think that the issues 
being discussed with regards to classes vs structs are as big a deal in this 
case as they are because it's the standard library.

Ideally, Phobos will take the most efficient route such that if you want your 
containers to be as absolutely as efficient as possible, you'd do the same thing 
that they're doing with your own containers, but you wouldn't necessarily need 
to. Since, as Andrei has been pointing out, the standard library is the sort 
of place where you go to extremes to make code efficient, and you don't always 
do things in the way that would normally be considered the nice way to do it, 
because it _needs_ to have that efficiency and can afford to be nastier code,  
since it's generally the experts who are working on it.

So yes, learn from Phobos, but you don't have to do everything the way that it 
does.

> 2.  Are the new containers going to be multi-threaded?  i.e., will I be
> able to insert elements into a container from multiple threads?

No. That would introduce unnecessary overhead. If you want synchronized 
containers, then wrap the standard ones in your own. Maybe some sort of 
synchronized wrapper will be provided by Phobos at some point, but the 
containers themselves are definitely not going to be. You can add the multi-
threading protections and the cost that they bring on top of an implementation 
that doesn't have them, but if you have such protections built-in, those using 
the containers can't remove them and would be stuck with the performance cost.

- Jonathan M Davis


More information about the Digitalmars-d mailing list