struct vs. class containers (was: Re: dcollections 1.0 and 2.0a beta released)

[Andrei Alexandrescu]

On 05/24/2010 10:58 AM, Steven Schveighoffer wrote:
> On Sun, 23 May 2010 17:36:52 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> I've thought for a very long time about the class vs. struct choice in
>> a container, and I came to a startling conclusion: it (almost) doesn't
>> matter. Could be either, and the tradeoffs involved are nonessential.
>> Here they are:
>>
>> 1. Using a class makes implementing members easier because there's no
>> need to do work through an additional member. With a struct, you need
>> a pimpl approach. For example:
>>
>> struct Array {
>> struct Impl {
>> ...
>> }
>> Impl * impl;
>> ...
>> @property length() const { return impl->length; }
>> ...
>> }
>>
>> 2. struct gives you more power in managing collection's own memory, as
>> long as the collection doesn't escape item addresses or other
>> addresses of internal handles. So all other things being equal, struct
>> has a net advantage.
>
> Yes, but most containers are node-based, so as long as you use structs
> for nodes, you are generally in control of the bulk of allocation
> (dcollections does this).

I'm saying, the net advantage of struct is that it can safely and 
deterministically release memory in its destructor.

>> 3. The creation syntaxes are different. For Phobos, I suggest adding a
>> simple function make() to std.algorithm. make!T(a, b, c) returns a
>> newly constructed object T by invoking the constructor with arguments
>> a, b, and c. That way we can make client code virtually agnostic of
>> the class/struct choice for a container.
>>
>
> Classes have builtin object monitors. But you could handle that via a
> struct as well. The language support wouldn't be there though.

Oh, and the monitor isn't needed so that's an unused word there. I'd 
forgotten about it.

>> That's it. Otherwise, one could use either to build a container. Let
>> me note that I have reached the conclusion that containers should be
>> at best reference types, with a meta-constructor Value!(C) that takes
>> a container C and makes it into a value type.
>
> The thing that classes really give you is the language support. Structs
> need to be hand-crafted to support the same syntax. Classes are enforced
> as always being reference types and always being on the heap.

I'd agreed classes are more convenient because they make the 
implementation straightforward.

> The
> Value!(C) is questionable because creating the head of a container on
> the stack leads to easily escaped stack references.

I don't understand this. Could you give an example?

> But yeah, a struct as a 'smart pointer' could work, as long as you don't
> 'auto-create' like AA's do.
>
>>
>> It seems Steve took the weekend off.
>
> My son's 2nd birthday party was Saturday, and I had visitors, sorry :) I
> did some responses, but at some point if you want to remain married, you
> have to pay attention to your family.

Congrats. And yes, wise words :o).


Andrei