fwd
>
>
> On 6/13/12 7:50 PM, Bennie Kloosteman wrote:
>
> let mut v = [];
> for some loop { v += [elt]; }
>
> Now, often, such loops can (and should) be written using a higher-order
> function (e.g., map, filter). But sometimes not. In such cases, under the
> new regime, the recommended idiom would be:
>
> let dv = dvec();
> for some loop { v.push(elt); }
> let v = dvec::unwrap(dv); // if necessary, convert to a vector
In User programs in most cases you would just leave it as dynamic
vector ( or better yet some form of collection or enumerable
interface depending on whether it will be frequently changed by the
user). For hard core systems programming you would often stick to the
arrays .
>
> Actually the name `dvec()` (dynamic vector) will probably change—perhaps
> to
> vecbuf? mvec? suggestions welcome—but you get the idea. The same would
> eventually apply to building up strings.
What about Java or C# style
Array = immutable array ( I would use ArrayValue or ArrayCopy for
non ref arrays)
Vector or List<T> /ArrayList for dynamic vectors. Note the list
name here matches the IList interface .
These are all standard types so any decent editor will autoexpand so
no need to shorten the names
Note here if your doing a lot of string parsing you are much better of
working on the char arrays / dynamic vectors . This is a bit different
because other languages with string builder like Java and C# don't
really use char arrays much .
> Basically, the idea is that we have "builder" types for vectors and
> strings.
> These builder types will overallocate and use dirty tricks to achieve
> reasonable performance. Using convenience operators like `+` will not do
> such things.
>
> *Details*
>
> The actual implementation strategy is that the representation of vectors
> will stay mostly the same as it is now. However, when the compiler
> allocates
> vectors, it will always do so for precisely the size they need to be
> (fill
> == alloc, in our vector rep). There will be internal functions
> (vec::alloc_empty_with_capacity() or something) that allocate an empty
> vector but with a large capacity and unsafe functions that can be used to
> set the length.
Why bother ? ArrayList / StringBuilder just builds an array of space
internally and tracks its own capacity which the user can optionally
set in a constructor. When they run out of space which the user didn't
allow for you just create a new array of double the size. No need for
system functions here.
However rust doesn't have encapsulation so the internal type being
build is accessible , not sure if this is an issue ?
> These can be used by dvec-like classes but also by routines
> like `vec::map()`. Most of this exists today. The only real thing that
> changes is that we take *away* the tricks the compiler does for `+=`.
There was a discussion the bitC list of still allowing stream
operators like<< as under some conditions they are better. I cant
remember the exact details but I think the biggest issue was
formatting eg<< "Write this number ""<< intvalue<<"Today" vs
str.format("write this number {1} today" , intvalue ) , with
str.format requiring some form of var args which bitc did not have and
more indexing..
> *Motivation*
>
> Part of the motivation for this change is that when you have task-local
> vectors, the tricks we play now where we treat vectors both as values and
> as
> things that can be updated in place don't work so well (this is precisely
> why the move was made to unique vectors in the first place, as I
> understand
> it). However, task-local vectors are good for a number of reasons
> (cheaper
> copies; easier to ensure memory safety), so I expect we'll wind up using
> them a fair amount: to obtain reliably good performance, then, a builder
> like `dvec` can be used that encapsulates the task-local vector pointer
> until construction is complete, making it safe to append to it in place.
Would you want single and multi threaded versions of the builders
stringbuilder/ArrayList or just a multi threaded one ? Not much time
is spend in builders.
BTW how do you encapsulate the pointer in rust ?
Performance should be much better with fixed size arrays , still
eliminating bounds checks we have discussed and is about a a 14%
program wide difference ( and you cant trust LLVM for it - mono with
LLVM has poor bounds check removal - java relies on the JIT ) .
Ben
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
