Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 04:47:24PM +0100, Diggory Hardy wrote: > What's wrong with sticking with convention here? E.g. C++'s `string` and > `vector` are objects containing two or three pointers. D's arrays and > `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought > of the same way (if one avoids thinking of them as pointers). This question got me thinking. I wrote up a blog post exploring it: http://smallcultfollowing.com/babysteps/blog/2013/11/14/treating-vectors-like-any-other-container/ The takeaway for me right now is sort of "Yes, we could do it that way. It makes some things simpler but a number of other features harder, some of which we really have to figure out how to resolve." regards, Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 12 Nov 2013, at 10:21 am, Gaetan wrote: > - as a typicial rust programmer, will i see the usage of "str" or "~str" as > logic or will i have to copy paste some sample code each time "because it > works this way in rust” This is what I thought at first, but once you use it for a while it will become natural, and you will find the distinction very useful. Just give it a chance before you jump to conclusions - you won’t regret it! :) > - the boilder plates theory. Can i avoid them? I think a good modern language > should allow me to avoid writing useless code, each time the same things. > That is the real mess with C++. They are not useless - `~str`, `&str`, `&'a str` and `&'static str` all convey extremely important semantic information both to the programmer and to the compiler. Changing `~str` to `str` would cause more inconsistencies (what about the borrowed pointers?) with a loss of the afore mentioned semantic information. ~Brendan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Mon, Nov 11, 2013 at 3:21 PM, Gaetan wrote: > Just an humble opinion. > > I kind of like saying that the code i write must be beautiful. The langage > should allow to write "beautiful" code. It is more than a personnal point of > view, it is also very important. if it is a pain in the ... to use an > essential feature, or if i will never remember how to do it without copy > paste because there is no "logic" behind it, i will have a bad opinion on > the langage itself. Of course, "beauty" is subjective. Personally, I see it as language-independent, and don't find it any harder to write beautiful code in Rust than in any other language I know. It's certainly easier than in some languages, since I don't have to spend as much time debugging run-time errors and can spend that time making my code aesthetically better. > > The real question are: > - as a typicial rust programmer, will i see the usage of "str" or "~str" as > logic or will i have to copy paste some sample code each time "because it > works this way in rust" Once you gain experience with Rust, this will seem natural. You reason about whether you're passing data by value or by reference (i.e. borrowed pointer) anyway, and Rust just makes that distinction more explicit. > - the boilder plates theory. Can i avoid them? I think a good modern > language should allow me to avoid writing useless code, each time the same > things. That is the real mess with C++. I'm not sure what your question is here, sorry. Cheers, Tim > > Gaetan > > > Le samedi 9 novembre 2013, spir a écrit : > >> On 11/09/2013 06:43 AM, Kevin Ballard wrote:> On Nov 8, 2013, at 9:38 PM, >> Daniel Micay wrote: >>> >>> On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > I know that many people don't like the fact that, syntactically, > vectors and strings have a sigil in front of them, but please consider > that > there are many design constraints here. What works for another language > may > not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. >>> >>> >>> Well no, you can't assume that the absence of a sigil means the absence >>> of heap storage. But for types that are possibly not stored on the heap, >>> such as str (which can be &'static str) and [T] (which can be a fixed-size >>> stack-allocated vector), the ~ is a useful distinction. >>> >>> -Kevin >> >> >> Can we, then, even consider the opposite: having a sigil for static data >> (mainly literal strings stored in static mem, I'd say) or generally non-heap >> data (thus including eg static arrays stored on stack)? The advantage is >> that this restores coherence between all heap of heap data. >> I'd use '$'! (what else can this sign be good for, anyway? ;-) >> >> [But where should the sigil go? In front of the data literal, as in >> let stst = $"Hello, world!"; >> let nums = $[1,2,3]; >> or in front of the type, or of the id itself?] >> >> Also, is it at all possible, in the long term maybe, to consider letting >> the compiler choose where to store, in cases where a possible pointer is >> meaningless, that is it does not express a true reference (shared object, >> that a.x is also b.y), instead is used for technical or efficiency reasons >> (that memory is not elastic!, for avoiding copy, etc...)? >> >> Denis >> ___ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > -- > - > Gaetan > > > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "If you are silent about your pain, they'll kill you and say you enjoyed it." -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Just an humble opinion. I kind of like saying that the code i write must be beautiful. The langage should allow to write "beautiful" code. It is more than a personnal point of view, it is also very important. if it is a pain in the ... to use an essential feature, or if i will never remember how to do it without copy paste because there is no "logic" behind it, i will have a bad opinion on the langage itself. The real question are: - as a typicial rust programmer, will i see the usage of "str" or "~str" as logic or will i have to copy paste some sample code each time "because it works this way in rust" - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. Gaetan Le samedi 9 novembre 2013, spir a écrit : > On 11/09/2013 06:43 AM, Kevin Ballard wrote:> On Nov 8, 2013, at 9:38 PM, > Daniel Micay wrote: > >> >> On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: >>> On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: >>> >>> I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. >>> >>> Personally, I find it great that they have a sigil in front of them. It >>> reminds me that they're stored in the heap. >>> >>> -Kevin >>> >>> Since library containers, smart pointers and other types don't have >>> them, I don't think it's helpful in that regard. >>> >> >> Well no, you can't assume that the absence of a sigil means the absence >> of heap storage. But for types that are possibly not stored on the heap, >> such as str (which can be &'static str) and [T] (which can be a fixed-size >> stack-allocated vector), the ~ is a useful distinction. >> >> -Kevin >> > > Can we, then, even consider the opposite: having a sigil for static data > (mainly literal strings stored in static mem, I'd say) or generally > non-heap data (thus including eg static arrays stored on stack)? The > advantage is that this restores coherence between all heap of heap data. > I'd use '$'! (what else can this sign be good for, anyway? ;-) > > [But where should the sigil go? In front of the data literal, as in > let stst = $"Hello, world!"; > let nums = $[1,2,3]; > or in front of the type, or of the id itself?] > > Also, is it at all possible, in the long term maybe, to consider letting > the compiler choose where to store, in cases where a possible pointer is > meaningless, that is it does not express a true reference (shared object, > that a.x is also b.y), instead is used for technical or efficiency reasons > (that memory is not elastic!, for avoiding copy, etc...)? > > Denis > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Thanks for the clarification. The current design actually makes sense to me after re-reading about dynamically sized types. On Friday 08 November 2013 09:29:37 Patrick Walton wrote: > On 11/8/13 7:47 AM, Diggory Hardy wrote: > > What's wrong with sticking with convention here? E.g. C++'s `string` and > > `vector` are objects containing two or three pointers. D's arrays and > > `string` act the same way. Even C's dynamic arrays (`int x[]`) can be > > thought of the same way (if one avoids thinking of them as pointers). > > Because: > > * We need slices in the language. They're important for soundness. > > * We need dynamically sized types in the language in order to be sound > around first-class trait objects. > > * Given that we need slices, and we need dynamically-sized types, we can > avoid introducing more concepts in the language by treating slices as > just a special case of a dynamically-sized type. That is, a slice is > nothing more than *a pointer to a dynamically-sized type*. > > * The pointer sigil is notated `&`, and the dynamically-sized type is > `[int]`. So the resulting notation is `&[int]`. > > You can see slices as just pointers with a length attached; i.e. a > pointer to multiple contiguous values. In fact, Cyclone called them "fat > pointers" instead of "slices". In Cyclone, you wrote a slice as `int > *fat`. (Notice the similarity to `&[int]`.) > > Note that not all of this is implemented today, which is leading to some > of the confusion in this thread. Felix Klock is currently working on it. > > Patrick > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 8:53 AM, spir wrote: > > Can we, then, even consider the opposite: having a sigil for static data > (mainly literal strings stored in static mem, I'd say) or generally > non-heap data (thus including eg static arrays stored on stack)? The > advantage is that this restores coherence between all heap of heap data. > I'd use '$'! (what else can this sign be good for, anyway? ;-) > > [But where should the sigil go? In front of the data literal, as in > let stst = $"Hello, world!"; > let nums = $[1,2,3]; > or in front of the type, or of the id itself?] > > Also, is it at all possible, in the long term maybe, to consider letting > the compiler choose where to store, in cases where a possible pointer is > meaningless, that is it does not express a true reference (shared object, > that a.x is also b.y), instead is used for technical or efficiency reasons > (that memory is not elastic!, for avoiding copy, etc...)? > > Denis All variables in Rust are stack-allocated values. A unique pointer is a pointer stored on the stack, and may be defined as a library type. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/09/2013 08:36 PM, Niko Matsakis wrote: See my other e-mail about choosing a representation for `*T`. I am currently thinking that the representation of `~T`, `&T`, and `*T` should be the same for all `T`. I think this addresses a number of issues and opens up new capabilities, though it does mean an unused "capacity" word for `&[T]` and `*[T]`. See issue #10295. Well, you may need it in fact. When I did implement slices for a trial (more or inspired by and copying D), I used this free word as a flag (with value 0) saying that extension is not allowed: one cannot push items into or concatenate a slice. Otherwise, arrays and slices are the same kind of thing; and in my case, there was a single type, as in D, arrays just are "original" slices, slices are arrays, except one cannot extend them. The remaining issue is, as in D again, the case of an array, of which slices exist, that later gets extended: in the general case (where extension requires realloc elsewhere), this invalids slices. Reason why I ended up concluding slices should only exist for fix-size thingies; anyway it's the case in practice afaik, since slices are extensively used (and a huge efficiency gain) on strings mainly. The D design, as I see it, thus brings a low level of safety; but their goal, on this point, is not to reach a level as high as Rust aims, I guess. Would be happy to read your thoughts on such topics. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 09, 2013 at 09:43:45AM +1100, Huon Wilson wrote: > This will make transmuting ~ to get a * (e.g., to allocate memory for > storage in an Rc, with automatic clean-up by transmuting back to ~ on > destruction) harder to get right, won't it? See my other e-mail about choosing a representation for `*T`. I am currently thinking that the representation of `~T`, `&T`, and `*T` should be the same for all `T`. I think this addresses a number of issues and opens up new capabilities, though it does mean an unused "capacity" word for `&[T]` and `*[T]`. See issue #10295. Anyway, I am not sure if I am making sense -- I'd say this calls for a long-winded blog post. Or more likely 2 or 3. I spent some time yesterday working out some of the details for supporting custom allocators as well as higher-kinded types, so I've got a lot to write about... Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 09, 2013 at 09:46:38AM +1100, Huon Wilson wrote: > Ah, of course. Presumably this means that `Rc` or `Rc` > would require a separate code-path? I've been thinking about this somewhat. I'm not sure if this is true. And in fact while both `Trait` and `str` are "dynamically sized types", they are not comparable and must be considered separately. 1. The type `Trait` is in fact not a type at all, it's shorthand for a type that the compiler "forgot" (jargon: an "existential type"). That is, every Every instance of `Rc` in fact began its life as a `Rc` for some known `T`, and the user "cast away" (pun intended) the `T` to make an object: Rc as Rc At runtime, this kind of cast (which, as an aside, I hope will no longer have to be explicit soon, it's quite tedious) pairs up the `Rc` with a vtable. So in fact `Rc` requires no "participation" on the part of `Rc`, but we will have to figure out some niggly details like how the compiler decides what type parameters can be changed from `T` to `Trait` and so forth. 2. True dynamically sized types like `[T]` and `str` are different, because they require fat pointers in place of thin ones. Until recently I was thinking we'd just (for now anyway) prohibit `Rc` and `Gc` etc from being instantiated with a DST. However, I was thinking recently that since `Rc` and `Gc` would build on `*T`, perhaps we can just define `*[T]` and `*str` to be the same sort of fat pointers, and things will work out rather nicely once everything is monomorphized. I have to think this over, but it's a promising idea. There are some complications for `Gc<[T]>`; when one traverses a pointer to this garbage-collected box, one must be sure to carry along the length information about the vector. But this doesn't seem unsolveable. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/09/2013 06:43 AM, Kevin Ballard wrote:> On Nov 8, 2013, at 9:38 PM, Daniel Micay wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be &'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $"Hello, world!"; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 10:55 PM, Corey Richardson wrote: Would you add default type parameters to the language or just use a separate type for allocator-aware containers? (The third option, have them *all* be allocator aware, makes for horrendous UI) Probably using a separate type, but I wouldn't rule out the first option. Mostly I just wanted to make it clear that allocators and small vector optimization *are* on the table for the Rust standard library. For one thing, these are important optimizations for Web browser engines, and I don't want to leave that performance on the table when we've come so far with the lifetime/borrowing system. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 1:52 AM, Patrick Walton wrote: > On 11/8/13 10:49 PM, Daniel Micay wrote: >> >> This is what I plan on implementing for rust-core, regardless of whether >> I convince anyone it's a good idea for the standard library. > > > I do think the Rust standard library should support allocators and small > vector optimization, for what it's worth. > Would you add default type parameters to the language or just use a separate type for allocator-aware containers? (The third option, have them *all* be allocator aware, makes for horrendous UI) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 10:49 PM, Daniel Micay wrote: This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. I do think the Rust standard library should support allocators and small vector optimization, for what it's worth. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 12:43 AM, Kevin Ballard wrote: > > Well no, you can't assume that the absence of a sigil means the absence of > heap storage. But for types that are possibly *not* stored on the heap, > such as str (which can be &'static str) and [T] (which can be a fixed-size > stack-allocated vector), the ~ is a useful distinction. > > -Kevin > Slices are just a view into some block of memory and are truly a low-level building block without any incentive for reimplementation. Rust's built-in vector/string types lack allocator support, so alternate implementations will end up being created. There's also a need for small vectors/strings, and perhaps reference-counted slices. LLVM is a good example of a modern, performance-concious C++ project. Here are the approximate counts for the various vector types: ArrayRef: 1276 (fixed-size vectors aren't used through a C++11-style template, the number is probably 10k or 20k) std::vector: 3078 SmallVector: 5076 std::string: 3648 StringRef: 4596 SmallString: 493 C++11 also supports reference counted slices of memory via `std::shared_ptr`, but I'm unsure if LLVM uses a similar type. This would be the following set of types: * &[T] * [T, ..N] * Vec * SmallVec * &str * Str * SmallStr * RcSlice * RcMutSlice With support for allocators like the C++ standard library, it's messier since Rust lacks default type parameters: * &[T] * [T, ..N] * Vec * SmallVec * &str * Str * SmallStr * RcSlice * RcMutSlice This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:11 PM, Daniel Micay wrote: The only way you could avoid pointer indirection is by making the element length part of the type, like fixed-size vectors. For strings, there's not really a clearly meaningful element length (bytes? code points? graphemes?). An alternate vector/string doing small string optimization makes more sense to me. I think it's worth thinking about how to allow for custom vector/string implementations in this scenario. There are a couple of directions I can see us going: 1. Keep `~[T]` as today and implement overloadable literal syntax for `SmallString`/`SmallVector`. Or: 2. Implement things like `SmallString`/`SmallVector` as custom smart pointers that know how to store elements of a vector inline. These kind of custom smart pointers would be hard-wired to particular kinds of DSTs. So, for example, we could imagine: let x: SmallVector<[int]> = new(SmallVector) [ 1, 2, 3, 4 ]; Option (2) is intriguing to me, because it allows us to possibly get away with not having literal syntax and taking advantage of DSTs to get us the benefits of custom vector/string representations. But it seems too good to be true :) There may be something I'm missing... Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Nov 8, 2013, at 9:38 PM, Daniel Micay wrote: > On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: > On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > > > I know that many people don't like the fact that, syntactically, vectors > > and strings have a sigil in front of them, but please consider that there > > are many design constraints here. What works for another language may not > > work for Rust, because of these constraints. > > Personally, I find it great that they have a sigil in front of them. It > reminds me that they're stored in the heap. > > -Kevin > > Since library containers, smart pointers and other types don't have them, I > don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be &'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: > On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > > > I know that many people don't like the fact that, syntactically, vectors > and strings have a sigil in front of them, but please consider that there > are many design constraints here. What works for another language may not > work for Rust, because of these constraints. > > Personally, I find it great that they have a sigil in front of them. It > reminds me that they're stored in the heap. > > -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > I know that many people don't like the fact that, syntactically, vectors and > strings have a sigil in front of them, but please consider that there are > many design constraints here. What works for another language may not work > for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 9 November 2013 00:15, Patrick Walton wrote:
> I don't see how you can without defeating separate compilation. If I am a
> function:
>
> fn f(s: ~str) {}
>
> It is `f`'s responsibility to free `s` at the end. That can't be done if
> this optimization has been performed.
This is about only optimizing fn f(t: &T) cases. Suppose one has a
custom 3-word struct with a destructor. Then with the current setup
one cannot hope that &T as a parameter would be just as efficient as
3-word ~str as the compiler uses an extra indirection. So the idea is
to say to the programmer: do not worry about this and always use &T as
a parameter type - the compiler will optimize it using the best mode
using internally pass-by-value if necessary.
With such optimization in place there would be no difference between
~str and struct MyStruct {s: ~str} as both ~str and &MyStruct as a
parameter generates exactly the same code.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:13 PM, Igor Bukanov wrote: > On 9 November 2013 00:08, Huon Wilson wrote: > > `&T` is pointer-sized but `T` isn't always. > > If the size of &T is not known, then obviously such optimization is > not applicable, The point is about &T where T is fixed-sized 1-4 word > thing. > > > > > (I believe that LLVM will optimise references to pass-by-value in certain > > circumstances; presumably when functions are internal to a compilation > > unit.) > > But what about declaring that such optimization is always valid and > even require it on the level of ABI? If you're using dynamic linking, the call overhead makes the cost of having an extra pointer in the CPU cache irrelevant. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:13 PM, Igor Bukanov wrote:
On 9 November 2013 00:08, Huon Wilson wrote:
`&T` is pointer-sized but `T` isn't always.
If the size of &T is not known, then obviously such optimization is
not applicable, The point is about &T where T is fixed-sized 1-4 word
thing.
(I believe that LLVM will optimise references to pass-by-value in certain
circumstances; presumably when functions are internal to a compilation
unit.)
But what about declaring that such optimization is always valid and
even require it on the level of ABI?
I don't see how you can without defeating separate compilation. If I am
a function:
fn f(s: ~str) {}
It is `f`'s responsibility to free `s` at the end. That can't be done if
this optimization has been performed.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 9 November 2013 00:08, Huon Wilson wrote: > `&T` is pointer-sized but `T` isn't always. If the size of &T is not known, then obviously such optimization is not applicable, The point is about &T where T is fixed-sized 1-4 word thing. > > (I believe that LLVM will optimise references to pass-by-value in certain > circumstances; presumably when functions are internal to a compilation > unit.) But what about declaring that such optimization is always valid and even require it on the level of ABI? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:06 PM, Igor Bukanov wrote: > On 8 November 2013 23:10, Oren Ben-Kiki wrote: > > Yes, the down side is another level of indirection. This could be > optimized > > away for &'static str, but not for &str. Good point. > > The level of indirection comes from passing strings as &str, not just > as a plain str. But this raises the question. For immutable values > implementing &T parameter as T should not be observable from the safe > code, right? If so why not to declare that &T as a parameter is not a > pointer but rather a hint to use the fastest way to pass an instance > of T to the function. Then one can use &str as a parameter without any > performance impact due to indirection even if str itself is > fixed-sized 3-word block pointing to the heap allocated data. > The only way you could avoid pointer indirection is by making the element length part of the type, like fixed-size vectors. For strings, there's not really a clearly meaningful element length (bytes? code points? graphemes?). An alternate vector/string doing small string optimization makes more sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 3:06 PM, Igor Bukanov wrote: On 8 November 2013 23:10, Oren Ben-Kiki wrote: Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. The level of indirection comes from passing strings as &str, not just as a plain str. But this raises the question. For immutable values implementing &T parameter as T should not be observable from the safe code, right? If so why not to declare that &T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use &str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. For one, you can pass substrings as `&str`. Those can't be optimized away so easily. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 09/11/13 10:06, Igor Bukanov wrote: On 8 November 2013 23:10, Oren Ben-Kiki wrote: Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. The level of indirection comes from passing strings as &str, not just as a plain str. But this raises the question. For immutable values implementing &T parameter as T should not be observable from the safe code, right? If so why not to declare that &T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use &str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev `&T` is pointer-sized but `T` isn't always. (I believe that LLVM will optimise references to pass-by-value in certain circumstances; presumably when functions are internal to a compilation unit.) Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 8 November 2013 23:10, Oren Ben-Kiki wrote: > Yes, the down side is another level of indirection. This could be optimized > away for &'static str, but not for &str. Good point. The level of indirection comes from passing strings as &str, not just as a plain str. But this raises the question. For immutable values implementing &T parameter as T should not be observable from the safe code, right? If so why not to declare that &T as a parameter is not a pointer but rather a hint to use the fastest way to pass an instance of T to the function. Then one can use &str as a parameter without any performance impact due to indirection even if str itself is fixed-sized 3-word block pointing to the heap allocated data. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 5:43 PM, Huon Wilson wrote: > > This will make transmuting ~ to get a * (e.g., to allocate memory for > storage in an Rc, with automatic clean-up by transmuting back to ~ on > destruction) harder to get right, won't it? > FWIW, the only reason to do that right now is to support the current managed pointer scheme. It could be replaced by a proper rooting API. Unique pointers don't support allocators, so any containers/pointers with allocator support already need to abandon managed pointer support. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:46 PM, Huon Wilson wrote: On 09/11/13 09:44, Patrick Walton wrote: On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I think. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Ah, of course. Presumably this means that `Rc` or `Rc` would require a separate code-path? Right. They'll have to be separate. Maybe we'll need an `UnsizedTrait` or `UnsizedVector` trait as well... we'll have to see. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 09/11/13 09:44, Patrick Walton wrote: On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I think. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Ah, of course. Presumably this means that `Rc` or `Rc` would require a separate code-path? Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I think. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 09/11/13 09:27, Patrick Walton wrote: On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "dynamically sized types" proposal... well, other than in passing in this thread, that is. Here's the stuff we have on dynamically sized types (DSTs): https://github.com/mozilla/rust/issues/6308 http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ http://smallcultfollowing.com/babysteps/blog/2013/05/13/recurring-closures-and-dynamically-sized-types/ Notice that the representation changes discussed in Niko's initial blog post are out of date. We aren't planning to do them, since there doesn't seem to be a soundness problem with having smart pointers like like `~` having different representations depending on what they point to. This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
No need to apologize. You are quite right, this is tricky and there's a good reason for the current design choices (perhaps there are better, but they are far from obvious). I wish I could put more time into deep thinking about this... which, of course, you can :-) On Sat, Nov 9, 2013 at 12:32 AM, Patrick Walton wrote: > On 11/8/13 2:19 PM, Brian Anderson wrote: > >> This thread is has been running off the rails a bit. Let's all please >> take a step back. This subject is one of the most subtle areas of Rust's >> type system, is in flux, and a lot of our plans about it are scattered >> across various places and passed around through informal conversation. >> It's understandable that there's confusion and debate here. >> > > Agreed, and again, my apologies. > > Patrick > > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:19 PM, Brian Anderson wrote: This thread is has been running off the rails a bit. Let's all please take a step back. This subject is one of the most subtle areas of Rust's type system, is in flux, and a lot of our plans about it are scattered across various places and passed around through informal conversation. It's understandable that there's confusion and debate here. Agreed, and again, my apologies. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "dynamically sized types" proposal... well, other than in passing in this thread, that is. Here's the stuff we have on dynamically sized types (DSTs): https://github.com/mozilla/rust/issues/6308 http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ http://smallcultfollowing.com/babysteps/blog/2013/05/13/recurring-closures-and-dynamically-sized-types/ Notice that the representation changes discussed in Niko's initial blog post are out of date. We aren't planning to do them, since there doesn't seem to be a soundness problem with having smart pointers like like `~` having different representations depending on what they point to. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:10 PM, Oren Ben-Kiki wrote: Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. I apologize for snapping at you. This thread has become not particularly productive. I'm welcome to alternative suggestions, but I'd like to suggest that any proposal needs to accommodate: 1. A coherent story for smart pointers to existential types in which the size is not known (e.g. `~Trait`). 2. Accommodation for extending the language for custom smart pointers. 3. A story for vectors, including custom ones. 4. Garbage-collected vectors and strings. 5. Lifetime-bounded pointers to array slices. Array slices must not allow access outside the bounds of the slice, even if those elements are within the original array. 6. C-like levels of efficiency for vectors and arrays, without extra levels of indirection. 7. The ability to push onto a unique array if capacity is available without copying all the elements. 8. Constant strings stored in static memory, without life-before-main. 9. Memory safety. 10. Unicode safety for strings: ensuring that all strings have valid UTF-8 in them at all times. There are probably more, but that's my initial list. I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Note that I *am* open to other possibilities :) I don't mean to shut people down! But the design space here is very limited. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 02:06 PM, Patrick Walton wrote: On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) No! Read the thread! You need `&str and `&'static str` for performance as well as `~str`. This thread is has been running off the rails a bit. Let's all please take a step back. This subject is one of the most subtle areas of Rust's type system, is in flux, and a lot of our plans about it are scattered across various places and passed around through informal conversation. It's understandable that there's confusion and debate here. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "dynamically sized types" proposal... well, other than in passing in this thread, that is. On Sat, Nov 9, 2013 at 12:09 AM, Patrick Walton wrote: > On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: > >> >> I don't follow. ~Trait is a pointer, and therefore its size is fixed. >> There are checks in place to prevent using a trait as a type (there's a >> nice error message from the compiler saying "using trait as a type" >> :-)... So the Trait in ~Trait isn't a _type_, right? :-) >> > > No, the `Trait` in `~Trait` is a type under the dynamically sized types > proposal. It is a type, just a dynamically sized one. > > Patrick > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. On Sat, Nov 9, 2013 at 12:06 AM, Patrick Walton wrote: > On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: > >> Also, str != ~[u8] (for good reason). The internal array is hidden >> anyway, so pretending to be a smart pointer to it doesn't make a lot of >> sense to me. Of course there's a very related issue of whether we see a >> vector as a smart pointer or as an object, so even if str was == ~[u8] >> it would probably still make sense to view it as an object :-) >> > > No! Read the thread! You need `&str and `&'static str` for performance as > well as `~str`. > > Patrick > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying "using trait as a type" :-)... So the Trait in ~Trait isn't a _type_, right? :-) No, the `Trait` in `~Trait` is a type under the dynamically sized types proposal. It is a type, just a dynamically sized one. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying "using trait as a type" :-)... So the Trait in ~Trait isn't a _type_, right? :-) On Sat, Nov 9, 2013 at 12:04 AM, Patrick Walton wrote: > On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: > >> So, the core question is whether we think of str as an object or as a >> pointer. Either we see it as an object (with fixed size, 3 words), which >> internally holds a nested pointer to a dynamically-sized region of >> characters; or we see it as a direct smart pointer to this array. >> >> The "physics" of str seem to be the former, but the abstraction >> presented to the programmer is the latter. Of course, there's also value >> in providing clean abstractions, but this is a leaky one. For example, >> it isn't very clean to have a concrete type T which allows ~T, &T, @T, >> *T but forbids having a simple T (unless one is talking about a trait, >> which str isn't). It is weird and causes all sort of edge cases when >> trying to write generic code. >> > > You're arguing that we shouldn't have dynamically sized types, but I ask > what your solution to `~Trait` is then. > > Patrick > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) No! Read the thread! You need `&str and `&'static str` for performance as well as `~str`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: So, the core question is whether we think of str as an object or as a pointer. Either we see it as an object (with fixed size, 3 words), which internally holds a nested pointer to a dynamically-sized region of characters; or we see it as a direct smart pointer to this array. The "physics" of str seem to be the former, but the abstraction presented to the programmer is the latter. Of course, there's also value in providing clean abstractions, but this is a leaky one. For example, it isn't very clean to have a concrete type T which allows ~T, &T, @T, *T but forbids having a simple T (unless one is talking about a trait, which str isn't). It is weird and causes all sort of edge cases when trying to write generic code. You're arguing that we shouldn't have dynamically sized types, but I ask what your solution to `~Trait` is then. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
So, the core question is whether we think of str as an object or as a pointer. Either we see it as an object (with fixed size, 3 words), which internally holds a nested pointer to a dynamically-sized region of characters; or we see it as a direct smart pointer to this array. The "physics" of str seem to be the former, but the abstraction presented to the programmer is the latter. Of course, there's also value in providing clean abstractions, but this is a leaky one. For example, it isn't very clean to have a concrete type T which allows ~T, &T, @T, *T but forbids having a simple T (unless one is talking about a trait, which str isn't). It is weird and causes all sort of edge cases when trying to write generic code. Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so even if str was == ~[u8] it would probably still make sense to view it as an object :-) In general, in a system language, one wants the low-level abstractions (such as "str") to be close to the "physics", so people would be able to easily reason about the code behavior. This would also lend support to the proposal of seeing str as a struct and not as a pointer. On Fri, Nov 8, 2013 at 11:22 PM, Patrick Walton wrote: > On 11/8/13 11:33 AM, Oren Ben-Kiki wrote: > >> Now I'm confused; doesn't this mean str is fixed size, so the proposal >> to just use "str" for the 3-word struct and have ~str and &str just be >> the normal thing makes sense after all? >> > > No, `str` is not fixed-size. An *owned pointer* to a string is fixed-size > (as all pointers are), but the string *itself* is dynamically sized. > > The size of pointers changes based on the kind of thing they point to. > > Patrick > > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 11:33 AM, Oren Ben-Kiki wrote: Now I'm confused; doesn't this mean str is fixed size, so the proposal to just use "str" for the 3-word struct and have ~str and &str just be the normal thing makes sense after all? No, `str` is not fixed-size. An *owned pointer* to a string is fixed-size (as all pointers are), but the string *itself* is dynamically sized. The size of pointers changes based on the kind of thing they point to. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
> Except I cannot find them. The dynamically-sized type posts are sort of scattered all over Niko's blog. You can start here: http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ for a general overview. On Fri, Nov 8, 2013 at 1:38 PM, spir wrote: > On 11/08/2013 07:20 PM, Patrick Walton wrote: > >> Because then `str` would not be a dynamically sized type. >> > > (I'm not convinced --yet-- strings *must* have dynamic size at all, as I > never need this feature even if I do quite a lot of text processing. When > generating runtime produced strings, I'd rather concat all bits at once at > the very end, thus knowing the final size. No support for this is needed: > one never writes into a growable string buffer, instead always concat all > at once. But this may be another, distinct story. And there may be use > cases I'm unaware of, even common ones.) > > > Please read the blog posts on dynamically sized types. >> > > All right, I'll do. > PS: Except I cannot find them. > Don't seem listed in the list of blog post at https://github.com/mozilla/ > rust/wiki/Docs > Also not in the archives of your own blog at: http://pcwalton.github.io/ > blog/archives/ > > Denis > > spir wrote: >> >>> On 11/08/2013 09:53 AM, Daniel Micay wrote: >>> It couldn't be called `str`, because `&str` is a slice. >>> >>> Why couldn't str be slices? (eg somewhat like arrays are slices in D) >>> Also, i don't understand literals in Rust currently. Same for static >>> arrays. >>> >>> Denis >>> ___ >>> >>> Rust-dev mailing list >>> Rust-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> ___ > > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Now I'm confused; doesn't this mean str is fixed size, so the proposal to
just use "str" for the 3-word struct and have ~str and &str just be the
normal thing makes sense after all?
On Fri, Nov 8, 2013 at 8:56 PM, Marvin Löbel wrote:
> On 11/08/2013 07:50 PM, Igor Bukanov wrote:
>
>> On 8 November 2013 18:35, Patrick Walton wrote:
>>
>>> But Daniel did some performance measurements and found that this had
>>> suboptimal performance characteristics when compared to:
>>>
>>> struct ~str {
>>> char *ptr;
>>> int size;
>>> int cap;
>>> }
>>>
>>> So we're changing to the latter.
>>>
>> Does this mean that when ~str is passed as a parameter the compiler
>> copies 3 words and that makes things faster?
>>
> According to https://github.com/mozilla/rust/issues/8981, yes and yes
> apparently. :)
>
> You rarely pass around a ~[T] directly anyway, usually you work with
> slices to them, which right now consist of exactly two words. (Though that
> might change to three words too for unrelated consistency reasons)
>
> Other speed improvements come from the fact that empty vectors no longer
> allocate, and that you no longer need to dereference a pointer into heap
> memory to get the size of an vector.
>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 07:50 PM, Igor Bukanov wrote:
On 8 November 2013 18:35, Patrick Walton wrote:
But Daniel did some performance measurements and found that this had
suboptimal performance characteristics when compared to:
struct ~str {
char *ptr;
int size;
int cap;
}
So we're changing to the latter.
Does this mean that when ~str is passed as a parameter the compiler
copies 3 words and that makes things faster?
According to https://github.com/mozilla/rust/issues/8981, yes and yes
apparently. :)
You rarely pass around a ~[T] directly anyway, usually you work with
slices to them, which right now consist of exactly two words. (Though
that might change to three words too for unrelated consistency reasons)
Other speed improvements come from the fact that empty vectors no longer
allocate, and that you no longer need to dereference a pointer into heap
memory to get the size of an vector.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 8 November 2013 18:35, Patrick Walton wrote:
> But Daniel did some performance measurements and found that this had
> suboptimal performance characteristics when compared to:
>
> struct ~str {
> char *ptr;
> int size;
> int cap;
> }
>
> So we're changing to the latter.
Does this mean that when ~str is passed as a parameter the compiler
copies 3 words and that makes things faster?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 07:20 PM, Patrick Walton wrote: Because then `str` would not be a dynamically sized type. (I'm not convinced --yet-- strings *must* have dynamic size at all, as I never need this feature even if I do quite a lot of text processing. When generating runtime produced strings, I'd rather concat all bits at once at the very end, thus knowing the final size. No support for this is needed: one never writes into a growable string buffer, instead always concat all at once. But this may be another, distinct story. And there may be use cases I'm unaware of, even common ones.) Please read the blog posts on dynamically sized types. All right, I'll do. PS: Except I cannot find them. Don't seem listed in the list of blog post at https://github.com/mozilla/rust/wiki/Docs Also not in the archives of your own blog at: http://pcwalton.github.io/blog/archives/ Denis spir wrote: On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `&str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Because then `str` would not be a dynamically sized type. Please read the blog posts on dynamically sized types. spir wrote: >On 11/08/2013 09:53 AM, Daniel Micay wrote: >> It couldn't be called `str`, because `&str` is a slice. > >Why couldn't str be slices? (eg somewhat like arrays are slices in D) >Also, i don't understand literals in Rust currently. Same for static >arrays. > >Denis >___ >Rust-dev mailing list >Rust-dev@mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `&str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer -- explicit specification
On 11/08/2013 09:43 AM, Gaetan wrote:
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: Option,
host: ~str,
port: Option<~str>,
path: ~str,
query: Query,
fragment: Option<~str>
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: &str, c: char) -> (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~"");
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: Option,
host: str,
port: Option,
path: str,
query: Query,
fragment: Option
}
pub type Query = [(str, str)];
fn split_char_first(s: &str, c: char) -> (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), "");
}
}
KISS !
-
Gaetan
Sure! I'd strongly support that (exactly the changes you propose).
But I thought the obligation to explicitely specify the pointer type was a
side-effect of the variety of pointer "kinds" in Rust: If in Rust one is to able
to choose which kind of pointer is used, then, well, we must write it down
somewhere somehow, no?
Some of the strings or arrays above (or more generally structured data), may be
shared, referenced from other structured thingies, in which case we'd need a
"non-owned" pointer (probably @). Or do I misunderstand?
Somewhat related but distinct, I thought we could get rid of specifying the
pointer type for function input: seems to be always &, no? Or &mut when changed
inside the func, but the compiler can probably tell that; also, if the param is
not changed, having &mut does not affect the semantics anyway... Or, if pointed
function input is not always & / &mut, systematically, in current Rust code,
could it be anyway, without exaggerated semantic constraint or efficiency loss?
Still related but distinct, what other uses for & (and &mut) than function
input?
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 9:38 AM, Benjamin Striegel wrote: > I would like to take steps to move to that world post Rust 1.0. I'd be interested to read more about this, and the reasons why it must be deferred until after 1.0. Is it just "too much work to do right now", or does it require some broader ambitious feature (HKT, etc)? IIRC Niko mentioned that it requires higher kinded types. I hadn't thought too much about the precise definition of the smart pointer trait. But it's also too much work to do right now, and doesn't seem like it's going to get us into much trouble regarding backwards compatibility. Having one ultra-common smart pointer type built into the language seems rather harmless. After all, in C++ there is a default `operator new`, and having to say `new(Unique)` would be pretty annoying for the commonest type of pointer. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
> I would like to take steps to move to that world post Rust 1.0.
I'd be interested to read more about this, and the reasons why it must be
deferred until after 1.0. Is it just "too much work to do right now", or
does it require some broader ambitious feature (HKT, etc)?
On Fri, Nov 8, 2013 at 12:35 PM, Patrick Walton wrote:
> On 11/8/13 9:26 AM, spir wrote:
>
>> What are the present implementations of strings and arrays in Rust? And
>> what about fixed size (esp for strings)?
>>
>
> struct RustString {
> int size;
> int cap;
> char ptr[]
> };
>
> typedef *RustString ~str;
>
> (If `~` were a valid identifier character in C, that is.) ;)
>
> But Daniel did some performance measurements and found that this had
> suboptimal performance characteristics when compared to:
>
> struct ~str {
> char *ptr;
> int size;
> int cap;
> }
>
> So we're changing to the latter.
>
> By the way, I agree with Daniel that in an ideal world none of this would
> be baked into the compiler (except syntactically), and I would like to take
> steps to move to that world post Rust 1.0. However, given that we have
> dynamically sized types and as a result we have to define `~str` to mean
> *something*, we have to build in some representation into the compiler.
>
> Patrick
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 9:26 AM, spir wrote:
What are the present implementations of strings and arrays in Rust? And
what about fixed size (esp for strings)?
struct RustString {
int size;
int cap;
char ptr[]
};
typedef *RustString ~str;
(If `~` were a valid identifier character in C, that is.) ;)
But Daniel did some performance measurements and found that this had
suboptimal performance characteristics when compared to:
struct ~str {
char *ptr;
int size;
int cap;
}
So we're changing to the latter.
By the way, I agree with Daniel that in an ideal world none of this
would be baked into the compiler (except syntactically), and I would
like to take steps to move to that world post Rust 1.0. However, given
that we have dynamically sized types and as a result we have to define
`~str` to mean *something*, we have to build in some representation into
the compiler.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/8/13 7:47 AM, Diggory Hardy wrote: What's wrong with sticking with convention here? E.g. C++'s `string` and `vector` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). Because: * We need slices in the language. They're important for soundness. * We need dynamically sized types in the language in order to be sound around first-class trait objects. * Given that we need slices, and we need dynamically-sized types, we can avoid introducing more concepts in the language by treating slices as just a special case of a dynamically-sized type. That is, a slice is nothing more than *a pointer to a dynamically-sized type*. * The pointer sigil is notated `&`, and the dynamically-sized type is `[int]`. So the resulting notation is `&[int]`. You can see slices as just pointers with a length attached; i.e. a pointer to multiple contiguous values. In fact, Cyclone called them "fat pointers" instead of "slices". In Cyclone, you wrote a slice as `int *fat`. (Notice the similarity to `&[int]`.) Note that not all of this is implemented today, which is leading to some of the confusion in this thread. Felix Klock is currently working on it. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/08/2013 05:47 PM, Igor Bukanov wrote:
C++'s `string` and `vector` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose it could help to think about
strings in Rust similar to variable-sized structs in C like:
struct MyString {
unsigned int bytelength;
unsigned int data[];
};
As in Rust such struct cannot be instantiated and one typically uses
malloc/alloca to allocate instances and then just pass around the
resulting pointers.
I like this version precisely for the reason it avoids double indirection. I use
it whenever I need "weighted strings" in C (strings that know their weight,
Pascal strings in fact) [1]. It works fine, is easy on the implementation side,
just terribly annoying w/o syntactic support. Same for arrays, both fixed (but
variable, in the sense of not predefined) and dynamic size.
It's all fine in my view for a language like Rust, provided it remains an
implementation choice. Meaning, whether the representation of say a static array
is a {p, n} struct or such a variable-sized structs is transparent on the
language side.
What are the present implementations of strings and arrays in Rust? And what
about fixed size (esp for strings)?
Denis
[1] Actually, I rather just use a pointer, with the size written before the
first string byte or array item, like true Pascal strings, but the result is the
same.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
> C++'s `string` and `vector` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose it could help to think about
strings in Rust similar to variable-sized structs in C like:
struct MyString {
unsigned int bytelength;
unsigned int data[];
};
As in Rust such struct cannot be instantiated and one typically uses
malloc/alloca to allocate instances and then just pass around the
resulting pointers.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree - Gaetan 2013/11/8 Diggory Hardy > On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: > > I am not sure why Daniel says that a `~str` or `~[]` is not an "owned > > box". I guess he's using the term in some specific way. I consider > > `~str` and `~[]` to be exactly the same as any other `~T` value in > > usage and semantics. They are allocated on the same heap, moved from > > place to place, and freed at the same time, etc. > > > > The difference between a type like `str` or `[T]` and other types is > > that `str` and `[T]` are actually a series of values: `u8` bytes and > > `T` values respectively. This entails a change in representation and > > is also the reason that one *must* use a pointer to refer to them, > > because the number of values is not known and hence the compiler can't > > calculate the size of the value. > > > > Note that we are to some extent evolving how we handle dynamically > > sized types like `str` and `[]`. Right now they are quite second class > > (you can't impl them etc) but that will change. Nonetheless, it will > > remain true that you can never have a *value* of type `str` or `[]`, > > but most always use a pointer (either `~[]` or `&[]`). > > > > Also note that a type like `~[T]` is in fact going to be represented > > not as a single pointer but rather three pointers, thanks to work by > > Daniel in fact. > > What's wrong with sticking with convention here? E.g. C++'s `string` and > `vector` are objects containing two or three pointers. D's arrays and > `string` act the same way. Even C's dynamic arrays (`int x[]`) can be > thought > of the same way (if one avoids thinking of them as pointers). > > So why not consider `str` and `[T]` conglomerates of a fixed size > containing > the pointers (start, length and capacity or whatever) needed? Semantically > it's the same while syntactically it's simpler. > > Slices will need new names of course, but I think the resulting decrease in > confusion will be worth it. (D's developers tried to go the other way, with > all arrays and slices being effectively copy-on-write slices, before > realising > that discrete array/slices types _were_ needed.) > > DH > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: > I am not sure why Daniel says that a `~str` or `~[]` is not an "owned > box". I guess he's using the term in some specific way. I consider > `~str` and `~[]` to be exactly the same as any other `~T` value in > usage and semantics. They are allocated on the same heap, moved from > place to place, and freed at the same time, etc. > > The difference between a type like `str` or `[T]` and other types is > that `str` and `[T]` are actually a series of values: `u8` bytes and > `T` values respectively. This entails a change in representation and > is also the reason that one *must* use a pointer to refer to them, > because the number of values is not known and hence the compiler can't > calculate the size of the value. > > Note that we are to some extent evolving how we handle dynamically > sized types like `str` and `[]`. Right now they are quite second class > (you can't impl them etc) but that will change. Nonetheless, it will > remain true that you can never have a *value* of type `str` or `[]`, > but most always use a pointer (either `~[]` or `&[]`). > > Also note that a type like `~[T]` is in fact going to be represented > not as a single pointer but rather three pointers, thanks to work by > Daniel in fact. What's wrong with sticking with convention here? E.g. C++'s `string` and `vector` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thinking of them as pointers). So why not consider `str` and `[T]` conglomerates of a fixed size containing the pointers (start, length and capacity or whatever) needed? Semantically it's the same while syntactically it's simpler. Slices will need new names of course, but I think the resulting decrease in confusion will be worth it. (D's developers tried to go the other way, with all arrays and slices being effectively copy-on-write slices, before realising that discrete array/slices types _were_ needed.) DH signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 06:46:37AM -0500, Daniel Micay wrote: > I don't think the need to do micro-optimizations like this is *common* > though. I honestly don't know how common or uncommon various scenarios are. All I was doing in my e-mail was highlighting scenarios where indirection is a good idea. I agree with you that, like anything else, it carries cost and should not be used universally. > It gets to the point where you're optimizing for the > characteristics of a specific allocator because they use different size > class buckets so trusting a profiler on one platform isn't enough. It can get to that point, but it can easily be the case that structures are just plain too big. As an example of *not* doing it right, consider `ast::Expr` -- this type is currently *124 bytes* big! This is for *every expression* in the compiler. (No wonder our memory use is high.) I feel pretty confident we could use more indirection in there even without having consulted the allocator bucket sizes. In any case, the bottom line is: there is no single answer, you will have to experiment. As a rule of thumb, I'd say that you should use indirection (`~`) when data is "optional" -- as in, Option or just one variant of many -- so as to reduce the size for the other case. But if the data is always present, you're *probably* better off avoiding the `~` pointer. But both rules have exceptions. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 07:39:59AM -0500, Daniel Micay wrote:
> By owned box I just mean a type you can pass to `fn foo(x: ~T) { }`
> rather than something that's owned and has a heap allocation.
Once the DST work is done, you will be able to pass a ~[T] to a
function like `fn foo(x: ~T) { }`.
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:33 AM, Niko Matsakis wrote:
> On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote:
> > It's so confusing. If it's not owned box, why not remove ~? Make "str"
> > default be dynamic should OK.
>
> I am not sure why Daniel says that a `~str` or `~[]` is not an "owned
> box". I guess he's using the term in some specific way. I consider
> `~str` and `~[]` to be exactly the same as any other `~T` value in
> usage and semantics. They are allocated on the same heap, moved from
> place to place, and freed at the same time, etc.
>
> The difference between a type like `str` or `[T]` and other types is
> that `str` and `[T]` are actually a series of values: `u8` bytes and
> `T` values respectively. This entails a change in representation and
> is also the reason that one *must* use a pointer to refer to them,
> because the number of values is not known and hence the compiler can't
> calculate the size of the value.
>
> Note that we are to some extent evolving how we handle dynamically
> sized types like `str` and `[]`. Right now they are quite second class
> (you can't impl them etc) but that will change. Nonetheless, it will
> remain true that you can never have a *value* of type `str` or `[]`,
> but most always use a pointer (either `~[]` or `&[]`).
>
> Also note that a type like `~[T]` is in fact going to be represented
> not as a single pointer but rather three pointers, thanks to work by
> Daniel in fact.
>
>
>
> Niko
>
By owned box I just mean a type you can pass to `fn foo(x: ~T) { }`
rather than something that's owned and has a heap allocation. Most of the
other containers (hashmap, treemap, trie, ringbuf, priority_queue) are also
owned, sendable and have a destructor.
In my opinion, it would be better to have stronger support for library
containers and only have vector/string slices built-in to the language.
Stronger support would entail generic container literals, overloading
auto-slicing and a rooting API for the GC (when we get one).
There are good reasons to write another vector type, such as allocator
support, optimizing for small vectors or ABI compatibility with a foreign
library's vector type to avoid copying between the API boundary.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 6:24 AM, Niko Matsakis wrote:
> On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote:
> > Owned boxes shouldn't be commonly used. There's close to no reason to use
> > one for anything but a recursive data structure or in rare cases for an
> > owned trait object.
>
> I don't really agree with this statement. I agree that those are the
> two cases an owned pointer is mandatory, and that the choice between
> `T` and `~T` is a matter of optimization, and hence something that
> should be measured.
>
> However, I don't think it's *so* unusual that one might want
> pointer-sized values. Off the top of my head, here are some more
> scenarios where owned pointers certainly make sense:
>
> 1. Options, particularly those that are frequently none.
>`Option<~HashMap<...>>` is a single word in size. If it is
>`None`, that's just a NULL pointer.
>
> 2. Enum variants. The size of an enum is the size of its largest
>variant. If you have:
>
>enum Foo {
>Opt1(uint),
>Opt2(HashMap<...>),
>Opt3(uint, uint, uint),
>}
>
>You are potentially wasting a lot of space, unless `Opt1` is very
>rare. You'd be better off doing something like:
>
>enum Foo {
>Opt1(uint),
>Opt2(~HashMap<...>),
>Opt3(~Opt3)
>}
>
>struct Opt3 { uint, uint, uint }
>
>
>
>
> Niko
>
I don't think the need to do micro-optimizations like this is *common*
though. It gets to the point where you're optimizing for the
characteristics of a specific allocator because they use different size
class buckets so trusting a profiler on one platform isn't enough.
There's a very real cost to the indirection, extra pointers in the CPU
cache, and all the landing pad stuff that ends up generated. I don't deny
that indirection can be useful for optimization, but it's unintuitive and
often not a portable improvement.
In the Boxes section I wrote for the tutorial, it includes this:
> In uncommon cases, the indirection can provide a performance gain or
memory reduction by making values smaller. However, unboxed values should
almost always be preferred.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 07, 2013 at 08:40:27PM -0500, Jason Fager wrote: > Let me ask another way: what's wrong with thinking of ~ just as meaning > "allocate to the heap and subject to move semantics"? When would that > simplification bite me in the ass regarding owned boxes vs strs/vecs? I don't consider that to be a simplification, really. It sounds about right to me. Of course a `~` pointer is not the only way to have move semantics; any destructor will do. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote: > It's so confusing. If it's not owned box, why not remove ~? Make "str" > default be dynamic should OK. I am not sure why Daniel says that a `~str` or `~[]` is not an "owned box". I guess he's using the term in some specific way. I consider `~str` and `~[]` to be exactly the same as any other `~T` value in usage and semantics. They are allocated on the same heap, moved from place to place, and freed at the same time, etc. The difference between a type like `str` or `[T]` and other types is that `str` and `[T]` are actually a series of values: `u8` bytes and `T` values respectively. This entails a change in representation and is also the reason that one *must* use a pointer to refer to them, because the number of values is not known and hence the compiler can't calculate the size of the value. Note that we are to some extent evolving how we handle dynamically sized types like `str` and `[]`. Right now they are quite second class (you can't impl them etc) but that will change. Nonetheless, it will remain true that you can never have a *value* of type `str` or `[]`, but most always use a pointer (either `~[]` or `&[]`). Also note that a type like `~[T]` is in fact going to be represented not as a single pointer but rather three pointers, thanks to work by Daniel in fact. Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote:
> Owned boxes shouldn't be commonly used. There's close to no reason to use
> one for anything but a recursive data structure or in rare cases for an
> owned trait object.
I don't really agree with this statement. I agree that those are the
two cases an owned pointer is mandatory, and that the choice between
`T` and `~T` is a matter of optimization, and hence something that
should be measured.
However, I don't think it's *so* unusual that one might want
pointer-sized values. Off the top of my head, here are some more
scenarios where owned pointers certainly make sense:
1. Options, particularly those that are frequently none.
`Option<~HashMap<...>>` is a single word in size. If it is
`None`, that's just a NULL pointer.
2. Enum variants. The size of an enum is the size of its largest
variant. If you have:
enum Foo {
Opt1(uint),
Opt2(HashMap<...>),
Opt3(uint, uint, uint),
}
You are potentially wasting a lot of space, unless `Opt1` is very
rare. You'd be better off doing something like:
enum Foo {
Opt1(uint),
Opt2(~HashMap<...>),
Opt3(~Opt3)
}
struct Opt3 { uint, uint, uint }
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 4:05 AM, Gaetan wrote: > I think a clear paragraph on these cases (~ and ~[]) will help a lot the > understanding of this subtlety... > > - > Gaetan > Here are the changes: https://github.com/mozilla/rust/pull/10354 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I think a clear paragraph on these cases (~ and ~[]) will help a lot the understanding of this subtlety... - Gaetan 2013/11/8 Daniel Micay > On Fri, Nov 8, 2013 at 3:46 AM, Gaetan wrote: > >> >> // An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, >> BlizzardBlue, Blue"; >> >> >> can you clarify us? >> >> thx! >> - >> Gaetan >> > > I suggest ignoring the string/vector section in the tutorial because it's > misleading and in some places incorrect. > > I'll send in a pull request removing the incorrect information. > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 3:46 AM, Gaetan wrote: > // An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, > BlizzardBlue, Blue"; > > > can you clarify us? > > thx! > - > Gaetan > I suggest ignoring the string/vector section in the tutorial because it's misleading and in some places incorrect. I'll send in a pull request removing the incorrect information. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Fri, Nov 8, 2013 at 3:43 AM, Gaetan wrote:
> I agree, I don't understand the syntax here.
>
> Look at the Url class:
>
>
> pub struct Url {
> scheme: ~str,
> user: Option,
> host: ~str,
> port: Option<~str>,
> path: ~str,
> query: Query,
> fragment: Option<~str>
> }
>
> pub type Query = ~[(~str, ~str)];
>
> fn split_char_first(s: &str, c: char) -> (~str, ~str) {
> ...
> if index+mat == len {
> return (s.slice(0, index).to_owned(), ~"");
> }
> }
>
>
> Isn't simpler, and easier to read, if we write it
>
>
> pub struct Url {
> scheme: str,
> user: Option,
> host: str,
> port: Option,
> path: str,
> query: Query,
> fragment: Option
> }
>
> pub type Query = [(str, str)];
>
> fn split_char_first(s: &str, c: char) -> (str, str) {
> ...
> if index+mat == len {
> return (s.slice(0, index).to_owned(), "");
> }
> }
>
>
> KISS !
>
It couldn't be called `str`, because `&str` is a slice.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
// An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, BlizzardBlue, Blue"; can you clarify us? thx! - Gaetan 2013/11/8 Daniel Micay > On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager wrote: > >> Can you speak a little to the practical differences between owned boxes >> and ~[T]/~str? How does the difference affect how I should use each? > > > I wrote the section on owned boxes in the tutorial currently in master, so > I would suggest reading that. It's very rare for there to be a use case for > an owned box outside of a recursive data structure or plugin system (traits > as objects). > > The coverage in the tutorial of vectors/strings is not only lacking in > depth but is also *incorrect*, so I understand why there's a lot of > confusion about them. > > Vectors/strings are containers, and aren't connected to owned boxes any > more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar > didn't exist and we just had generic container literals, because it seems > to end up causing a lot of confusion. > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: Option,
host: ~str,
port: Option<~str>,
path: ~str,
query: Query,
fragment: Option<~str>
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: &str, c: char) -> (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~"");
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: Option,
host: str,
port: Option,
path: str,
query: Query,
fragment: Option
}
pub type Query = [(str, str)];
fn split_char_first(s: &str, c: char) -> (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), "");
}
}
KISS !
-
Gaetan
2013/11/8 Jason Fager
> Can you speak a little to the practical differences between owned boxes
> and ~[T]/~str? How does the difference affect how I should use each?
>
>
> On Thursday, November 7, 2013, Daniel Micay wrote:
>
>> On Thu, Nov 7, 2013 at 6:32 PM, Liigo Zhuang wrote:
>>
>>> > Owned boxes shouldn't be commonly used. There's close to no reason to
>>> use one for anything but a recursive data structure or in rare cases for an
>>> owned trait object.
>>> >
>>> > http://static.rust-lang.org/doc/master/tutorial.html#boxes
>>> >
>>> > It's important to note that ~[T] and ~str are not owned boxes. They're
>>> just sugar for dynamic arrays, and are common containers.
>>> >
>>> It's so confusing. If it's not owned box, why not remove ~? Make "str"
>>> default be dynamic should OK.
>>>
>>
>> It wouldn't be okay for every string literal to result in a heap
>> allocation.
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 8:40 PM, Jason Fager wrote: > Let me ask another way: what's wrong with thinking of ~ just as meaning > "allocate to the heap and subject to move semantics"? When would that > simplification bite me in the ass regarding owned boxes vs strs/vecs? > > I get that I should very rarely want that for things that aren't dynamic > containers or recursive data structures. But beyond that, am I ever going > to get myself in trouble not remembering the details of the difference > between how ~T works vs ~[T]? The heap allocation is a means to an end rather than a useful property. There are lots of types in the standard library with destructors, including most of the containers. There's a deeper connection between TreeMap and an owned box than between owned vectors and owned boxes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] About owned pointer
Let me ask another way: what's wrong with thinking of ~ just as meaning "allocate to the heap and subject to move semantics"? When would that simplification bite me in the ass regarding owned boxes vs strs/vecs? I get that I should very rarely want that for things that aren't dynamic containers or recursive data structures. But beyond that, am I ever going to get myself in trouble not remembering the details of the difference between how ~T works vs ~[T]? On Thursday, November 7, 2013, Daniel Micay wrote: > On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager wrote: > >> Can you speak a little to the practical differences between owned boxes >> and ~[T]/~str? How does the difference affect how I should use each? > > > I wrote the section on owned boxes in the tutorial currently in master, so > I would suggest reading that. It's very rare for there to be a use case for > an owned box outside of a recursive data structure or plugin system (traits > as objects). > > The coverage in the tutorial of vectors/strings is not only lacking in > depth but is also *incorrect*, so I understand why there's a lot of > confusion about them. > > Vectors/strings are containers, and aren't connected to owned boxes any > more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar > didn't exist and we just had generic container literals, because it seems > to end up causing a lot of confusion. > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager wrote: > Can you speak a little to the practical differences between owned boxes > and ~[T]/~str? How does the difference affect how I should use each? I wrote the section on owned boxes in the tutorial currently in master, so I would suggest reading that. It's very rare for there to be a use case for an owned box outside of a recursive data structure or plugin system (traits as objects). The coverage in the tutorial of vectors/strings is not only lacking in depth but is also *incorrect*, so I understand why there's a lot of confusion about them. Vectors/strings are containers, and aren't connected to owned boxes any more than HashMap/TreeMap/TrieMap. I would prefer it if the syntactic sugar didn't exist and we just had generic container literals, because it seems to end up causing a lot of confusion. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Can you speak a little to the practical differences between owned boxes and ~[T]/~str? How does the difference affect how I should use each? On Thursday, November 7, 2013, Daniel Micay wrote: > On Thu, Nov 7, 2013 at 6:32 PM, Liigo Zhuang > > > wrote: > >> > Owned boxes shouldn't be commonly used. There's close to no reason to >> use one for anything but a recursive data structure or in rare cases for an >> owned trait object. >> > >> > http://static.rust-lang.org/doc/master/tutorial.html#boxes >> > >> > It's important to note that ~[T] and ~str are not owned boxes. They're >> just sugar for dynamic arrays, and are common containers. >> > >> It's so confusing. If it's not owned box, why not remove ~? Make "str" >> default be dynamic should OK. >> > > It wouldn't be okay for every string literal to result in a heap > allocation. > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 6:32 PM, Liigo Zhuang wrote: > > Owned boxes shouldn't be commonly used. There's close to no reason to > use one for anything but a recursive data structure or in rare cases for an > owned trait object. > > > > http://static.rust-lang.org/doc/master/tutorial.html#boxes > > > > It's important to note that ~[T] and ~str are not owned boxes. They're > just sugar for dynamic arrays, and are common containers. > > > It's so confusing. If it's not owned box, why not remove ~? Make "str" > default be dynamic should OK. > It wouldn't be okay for every string literal to result in a heap allocation. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
> Owned boxes shouldn't be commonly used. There's close to no reason to use one for anything but a recursive data structure or in rare cases for an owned trait object. > > http://static.rust-lang.org/doc/master/tutorial.html#boxes > > It's important to note that ~[T] and ~str are not owned boxes. They're just sugar for dynamic arrays, and are common containers. > It's so confusing. If it's not owned box, why not remove ~? Make "str" default be dynamic should OK. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Thu, Nov 7, 2013 at 5:03 AM, Gaetan wrote: > Hello > > I really the concept of owned pointers, and I'm wondering if it could be > the default. > > I mean, the more I use it, the more I tend to use it everywhere, and it > seem any "average" user-code (ie, not the rust compiler itself) will have a > lot of "~var" anywhere, "let i=~5", ..., more than the other variable > initialization. Look at the unit tests for libstd or libextra. > > Why not having the default syntax be owned pointers, and the ~ syntax (or > another one) be the syntax for creating variable on the heap? > > let i=5; // owned pointer > let j=~5; // heap value > > Regards, > - > Gaetan > Owned boxes shouldn't be commonly used. There's close to no reason to use one for anything but a recursive data structure or in rare cases for an owned trait object. http://static.rust-lang.org/doc/master/tutorial.html#boxes It's important to note that ~[T] and ~str are not owned boxes. They're just sugar for dynamic arrays, and are common containers. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
Don't worry, our pointers _are_ more confusing compared to many other languages after all. :) Am 07.11.2013 11:25 schrieb "Marvin Löbel" : > On 11/07/2013 11:03 AM, Gaetan wrote: > >> I mean, the more I use it, the more I tend to use it everywhere, and it >> seem any "average" user-code (ie, not the rust compiler itself) will have a >> lot of "~var" anywhere, "let i=~5", ..., more than the other variable >> initialization. Look at the unit tests for libstd or libextra. >> > The unit tests are not necessary good code examples. In actual good rust > code, you'd almost never need to use a heap allocated ~T if you can use a T > on the stack. > There is also no problem with that: A ~T behaves almost exactly like a T, > the only exceptions being that ~T is always pointer sized, and that ~T > always has a destructor, which means it always gets moved around instead of > possibly being implicitly copied. > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On 11/07/2013 11:03 AM, Gaetan wrote: I mean, the more I use it, the more I tend to use it everywhere, and it seem any "average" user-code (ie, not the rust compiler itself) will have a lot of "~var" anywhere, "let i=~5", ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. The unit tests are not necessary good code examples. In actual good rust code, you'd almost never need to use a heap allocated ~T if you can use a T on the stack. There is also no problem with that: A ~T behaves almost exactly like a T, the only exceptions being that ~T is always pointer sized, and that ~T always has a destructor, which means it always gets moved around instead of possibly being implicitly copied. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
sorry for the confusion - Gaetan 2013/11/7 Robert Knight > > Why not having the default syntax be owned pointers, and the ~ syntax > (or another one) be the syntax for creating variable on the heap? > > ~ does allocate on the heap. Without ~ you allocate on the stack. > > Regards, > Rob. > > On 7 November 2013 10:03, Gaetan wrote: > > Hello > > > > I really the concept of owned pointers, and I'm wondering if it could be > the > > default. > > > > I mean, the more I use it, the more I tend to use it everywhere, and it > seem > > any "average" user-code (ie, not the rust compiler itself) will have a > lot > > of "~var" anywhere, "let i=~5", ..., more than the other variable > > initialization. Look at the unit tests for libstd or libextra. > > > > Why not having the default syntax be owned pointers, and the ~ syntax (or > > another one) be the syntax for creating variable on the heap? > > > > let i=5; // owned pointer > > let j=~5; // heap value > > > > Regards, > > - > > Gaetan > > > > > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
> Why not having the default syntax be owned pointers, and the ~ syntax (or > another one) be the syntax for creating variable on the heap? ~ does allocate on the heap. Without ~ you allocate on the stack. Regards, Rob. On 7 November 2013 10:03, Gaetan wrote: > Hello > > I really the concept of owned pointers, and I'm wondering if it could be the > default. > > I mean, the more I use it, the more I tend to use it everywhere, and it seem > any "average" user-code (ie, not the rust compiler itself) will have a lot > of "~var" anywhere, "let i=~5", ..., more than the other variable > initialization. Look at the unit tests for libstd or libextra. > > Why not having the default syntax be owned pointers, and the ~ syntax (or > another one) be the syntax for creating variable on the heap? > > let i=5; // owned pointer > let j=~5; // heap value > > Regards, > - > Gaetan > > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] About owned pointer
Hello I really the concept of owned pointers, and I'm wondering if it could be the default. I mean, the more I use it, the more I tend to use it everywhere, and it seem any "average" user-code (ie, not the rust compiler itself) will have a lot of "~var" anywhere, "let i=~5", ..., more than the other variable initialization. Look at the unit tests for libstd or libextra. Why not having the default syntax be owned pointers, and the ~ syntax (or another one) be the syntax for creating variable on the heap? let i=5; // owned pointer let j=~5; // heap value Regards, - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
