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
