I think there are several things you can do here.
The idea of the DList taking ownership of the pancakes seems a little
bizzare; if it takes ownership of the Pancakes, but only sees them as
circles, then just deconstruct your Pancakes into circles and pass those. I
believe you can even do something like:
fn as_box_circle(self) -> Box<Circle> { box self.circle }
(i.e. have the `self` parameter be moved rather than referenced).
If you want shared ownership (i.e. you still want to use the Pancake and
Circle parts from other areas of the code once the DList has the Circle
parts), use something like an Rc.
If you actually want to be able to use Pancakes as drop-in replacements for
Circles, then I believe you can do what Clark said, and implement
Deref<Circle>, and make your data structure can be a
DList<Box<Deref<Circle>>>. If you still want shared ownership, you can make
a DList<Rc<Deref<Circle>>>, or something like that.
Is any of that what you want?
The last two solutions obviously do incur some runtime cost. If you really
just want a DList that strongly *owns *all the circles (which implies to me
that the circles aren't being touched from anywhere else), maybe don't put
them in your Pancakes in the first place.
On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson <di...@ubuntu.com> wrote:
> Hmm, right. The as_* could probably useful to write a macro for.
>
> Coming from the C/Java side of things I have to figure out how this works
> in a bigger context, e g a DList or other structure owning objects
> implementing HasArea. This seems to compile, e g:
>
> impl Pancake {
> fn as_box_circle(&self) -> Box<Circle> { box self.circle }
> }
>
> fn make_pancake(dl: &mut DList<Box<HasArea>>) {
> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 },
> is_tasty: true };
> dl.push(p.as_box_circle());
> }
>
> But I'd assume that make_pancake would now make a copy of the pancake's
> circle, rather than taking ownership of the entire pancake, right? The
> pancake then gets dropped at function return.
>
> In this simple example perhaps this does not make that much of a
> difference though, but if you imagine a C struct like:
>
> struct list {
> list *next;
> circle *data;
> }
>
> You can now put a pointer to a pancake as data, use it as a circle, and
> when you finally free the list and the data that goes with it, the entire
> pancake will be freed. This you cannot do in rust...or can you?
>
>
> On 2014-10-17 07:59, Clark Gaebel wrote:
>
>> impl Pancake {
>> fn as_circle(&self) -> &Circle { &self.circle }
>> fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle }
>> }
>>
>> The compiler will optimize trivial functions, except cross-crate. In
>> those cases, use an #[inline] annotation.
>>
>>
>>
>> On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson <di...@ubuntu.com
>> <mailto:di...@ubuntu.com>> wrote:
>>
>> This is probably a previously asked question, but I couldn't find
>> it on
>> Google, so...
>>
>> Let's extend the Circle example from the guide a little:
>>
>> struct Circle {
>> x:f64,
>> y:f64,
>> radius:f64,
>> }
>>
>> trait HasArea {
>> fn area(&self)-> f64;
>> }
>>
>> impl HasArea for Circle {
>> fn area(&self)-> f64 {
>> std::f64::consts::PI * (self.radius * self.radius)
>> }
>> }
>>
>> struct Pancake {
>> circle: Circle,
>> is_tasty: bool,
>> }
>>
>>
>> ...now, what is the easiest way I can implement HasArea for
>> Pancake? I
>> could do this:
>>
>> impl HasArea for Pancake {
>> fn area(&self) -> f64 { self.circle.area() }
>> }
>>
>> ...but that means a lot of boiler-plate code, especially if
>> HasArea has
>> many methods. Hopefully rust will just inline/optimise the
>> redirection
>> away in most cases to avoid the runtime cost, but is there a
>> smarter or
>> more idiomatic way of doing this?
>>
>> // David
>>
>> _______________________________________________
>> 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
