On 09/12/2010 21:55, Simon Buerger wrote:
On 08.12.2010 23:45, Jonathan M Davis wrote:
On Wednesday, December 08, 2010 14:14:57 Simon Buerger wrote:
For Every lib its a design descision if containers should be value- or
reference-types. In C++ STL they are value-types (i.e. the
copy-constructor does a real copy), while in tango and phobos the
descision was to go for reference-types afaik, but I would like to be
able to write value-types too, which isn't possible (in a really good
way) currently. Following points would need some love (by-value
containers are probably not the only area, where these could be useful)
It's extremely rare in my experience that it makes any sense to copy a
container
on a regular basis. Having an easy means of creating a deep copy of a
container
or copying the elements from one container to another efficiently
would be good,
but having containers be value types is almost always a bad idea. It's
just not
a typical need to need to copy containers - certainly not enough to
have them be
copied just because you passed them to a function or returned them
from one. I
think that reference types for containers is very much the correct
decision.
There should be good ways to copy containers, but copying shouldn't be
the
default for much of anything in the way of containers.
I would go further than that actually, it seems to me that the idea of
by-value containers is completely idiotic. I was *hesitant* to say this
because it goes against conventional C++ "wisdom" (or rather, C++
mentality), and I'm just a random junior programmer on a web forum, and
I am saying it in a somewhat inflammatory way... But frankly, I've been
thinking about it for the last few days (the issue came up earlier, in
the "Destructors, const structs, and opEquals" thread), and I could not
change my mind. For the love of life, how can anyone think this is a
good idea? I'm struggling to find even one use-case where it would make
sense. (a non-subjective use-case at least)
From a pragmatic viewpoint you are right, copying containers is rare.
But on the other hand, classes imply a kind of identity, so that a set
is a different obejct then an other object with the very same elements.
Yeah, classes have identity, but they retain the concept of equality.
So what's wrong with that? Equality comparisons would still work the
same way as by-value containers.
That feels wrong from an aesthetical or mathematical viewpoint.
Aesthetics are very subjective (I can say the exact same thing about the
opposite case). As for a mathematical viewpoint, yes, it's not exactly
the same, but first of all, it's not generally a good idea to strictly
emulate mathematical semantics in programming languages. So to speak,
mathematical "objects" are immutable, and they exist in a magical
infinite space world without the notion of execution or side-effects.
Trying to model those semantics in a programming language brings forth a
host issues (most of them performance-related). But more important, even
if you wanted to do that (to have it right from a mathematical
viewpoint), mutable by-value containers are just as bad, you should use
immutable data instead.
Furthermore, if you have for example a vector of vectors,
vector!int row = [1,2,3];
auto vec = Vector!(Vector!int)(5, row);
then vec should be 5 rows, and not 5 times the same row.
Then instead of "Vector" use a static-length vector type, don't use a
container.
--
Bruno Medeiros - Software Engineer
