Developing a plan for D2.0: Getting everything on the table

Leandro Lucarella llucax at gmail.com
Mon Jul 27 11:29:00 PDT 2009


Andrei Alexandrescu, el 27 de julio a las 12:58 me escribiste:
> Bill Baxter wrote:
> >The requirement to add the post-blit is a little annoying.  If a
> >ValueContainer is made fundamental and it is built initially out of
> >components with value semantics, then no explicit post-blit will be
> >necessary.  However if you go the other way and start with a
> >RefContainer then a post-blit will be necessary when you implement the
> >ValueContainer based on it.   So to me it seems a little better to go
> >with the ValueContainer as the base implementation.
> 
> I think it's a matter of the most frequent use. I used to be a staunch supporter 
> of values for containers, until Walter revealed to me that in STL you have value 
> containers to constantly worry about adding the "&" everywhere. Implicitly 
> copying containers is 95% of cases an error in C++ code. Witness all that advice 
> about pass by reference etc. So why make that the default, one might ask? Better 
> go with the flow and make the default case the easy case (reference), and if 
> someone does want a value, have them write Value!Container.

Another point for ref containers is that they allow to have a class
hierarchy of containers. I guess you can have it too using compile-time
"concepts", like ranges, but being able to do that with interfaces could
be nice (and you can still have the compile-time with classes too).
I don't know if the interfaces approach would be useful though...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
We're rotten fruit
We're damaged goods
What the hell, we've got nothing more to lose
One gust and we will probably crumble
We're backdrifters



More information about the Digitalmars-d mailing list