Steven Schveighoffer wrote:
You are correct, setCapacity ensures that *at least* the given number of
elements will be available for appending.
I planned on making the function a property (but a bug would not allow
that), the original intended usage was:
a.capacity = 10000;
Reserve doesn't work in this context. Can you come up with a name that
does?
I'll bring up reserve (as a function) as an alternative on the phobos
mailing list, and see what people say. I kind of liked the
setter/getter idea, but you make a good point.
-Steve
Sorry if resurrecting this thread is against netiquette, but it caught
my eye, and this is my first newsgroup post in years. ;)
Anyway, is there any compelling reason why setCapacity or modifying
a.capacity should allocate a nondeterministic amount of storage?
Depending on the application, programmers might require strict control
over memory allocation patterns and strict accounting for allocated
memory. Game programmers, especially console game programmers, tend to
strongly prefer deterministic allocation patterns, and nondeterminism is
one of the [several] common complaints about the C++ STL
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html is a
good resource on these kind of issues). In the case of D (which I'm
considering learning), this is especially important for dynamic arrays,
partly because they're so useful by themselves, and partly because they
may form the backbone of custom containers.
Whereas it's easy to add "smart nondeterministic" behavior to a
deterministic setCapacity function by providing a wrapper, ordinary
language users can't do the opposite. Because of this, and because
dynamic arrays are so central to the D language, a nondeterministic
setCapacity function may deter game programmers, especially console
programmers, from adopting D.
Assuming you see this post, what are your thoughts here?
