std.container and classes
jessekphillips+d at gmail.com
Sat Dec 17 16:06:55 PST 2011
On Sat, 17 Dec 2011 17:31:46 -0600, Andrei Alexandrescu wrote:
> The second decision is classes vs. structs. Walter correctly pointed out
> that the obvious choice for defining a reference type in D - whether the
> type is momonorphic or polymorphic - is making it a class. If containers
> aren't classes, the reasoning went, it means we took a wrong step
> somewhere; it might mean our flagship abstraction for reference types is
> not suitable for, well, defining a reference type.
This is an interesting reasoning to go with class. Which is similar to
what you end up saying here:
> One fear I have is that people would be curious,
> look at the implementation of std.container, and be like "so am I
> expected to do all this to define a robust type"? I start to think that
> the right answer to that is to improve library support for good
> reference counted types, and define reference counted struct containers
> that are deterministic.
I'm not really sure the answer, but here are some thoughts.
There is interest in having reference counting, and making it easy. There
was a question on SO about how to make a reference counted object. I gave
it my best shot answering having never done it myself. It isn't very
straight forward and I think people will expect to use it similar to
auto_prt. And considering how similar each wrapped object is, I think D
can pull it off.
So building a reference counted container type probably shouldn't be a
challenge in D (or I should say it should be a goal to make it not a
challenge). For example, it might be as simple as, a build a value
container which you then expose wrapped with RefCounted!T
alias RefCounted!ContainerImp Container;
But as to whether this should be what is implemented in the standard
library, I don't know. You make mention of custom allocators and such. Is
this interest going to be of benefit, or is it just something people are
use to having from C++? If it makes sense to have such then the
containers should support it. Don't classes allow for custom allocators?
Is there a reason that can't be used? Do we need to improve on that?
More information about the Digitalmars-d