Sorry for the long delay in replying.
On 22/12/2010 12:04, Simon Buerger wrote:
On 21.12.2010 18:45, Bruno Medeiros wrote:
On 09/12/2010 21:55, Simon Buerger wrote:
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.
Identity is wrong, because if I pass th set {1,2,3} to a function, I
would like to pass exactly these three values, not some mutable object.
This may imply that the function-parameter should be const, which is
probably a good idea anyway. I want it to be mutable, I want to use
"out"/"ref", the same way as with the simple builtin-types.
I don't understand this, it doesn't seem to make sense. You say you
don't want the set to be "some mutable object", yet also say you "want
it to be mutable". Does "it" refer to something else? I don't get it.
Assuming just this text: " Identity is wrong, because if I pass th set
{1,2,3} to a function, I would like to pass exactly these three values,
not some mutable object. "
Then pass in some unmodifiable collection. Hard to suggest a better
alternative without a concrete example.
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.
You might be right that modeling mathematics is not perfect, at least in
C/C++/D/java. Though the functional-programming is fine with it, and it
uses immutable data just as you suggested. But I'm aware that thats not
the way to go for D.
Anyway, though total math-like behavior is impossible, but with
Why is it not the way to go for D?
Why is "total math-like behavior is impossible" ?
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.
Maybe you want to change that stuff later on, so static-length is no
option. Following example might demonstrate the problem more clearly. It
is intended to init a couple of sets to empty.
set!int[42] a;
version(by_reference_wrong):
a[] = set!int.empty; // this does not work as intended
version(by_reference_correct):
foreach(ref x; a)
x = set!int.empty;
version(by_value):
//nothing to be done, already everything empty
Obviously the by_value version is the cleanest.
Not the best comparison, since the by_reference_correct version could be
improved to something like:
applyFill(a, set!int.empty) // if the last parameter is lazy
or
applyFill(a, { set!int.empty }) // otherwise, param is delegate instead
but in any case this is just a very specific example. What about the
other cases where by value could would be more verbose than by
reference? (particularly when you want to avoid needless copies)
Replacing "set!int.empty" with "new set!int" doesnt change the
situation,but make it sound only more weird in my ears: "new vector"?
what was wrong with the old one? and I dont want "_an_ empty set", I
want "_the_ empty set". Every empty set is equal, so there is only one.
The only way to truly solve this problem for you is to use by-value
containers, and actually use them with value semantics all the time (ie,
don't turn them into by-ref by passing pointers or other references to
them) !
...Well, this does contradict a bit what I originally said that "how can
anyone think this is a good idea? " But note that I was talking about
within the context of C++. If you use by-value containers in the
described above (with actually value semantics usage) you will be sooner
or later incurring heavy performance costs such that it's no longer a
good idea to be using C++ in the first place.
--
Bruno Medeiros - Software Engineer