New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow creating Bytes from any AsRef<[u8]> by copying or taking ownership of it #276

Merged
merged 2 commits into from Dec 11, 2017

Conversation

Projects
None yet
3 participants
@sdroege
Member

sdroege commented Dec 10, 2017

See individual commit messages

sdroege added some commits Dec 10, 2017

Allow creating Bytes from any AsRef<[u8]> by taking ownership of it w…
…ithout copying

This for example allows creating a Bytes from a Vec<[u8]>,
a &'static [u8], a hyper Chunk or similar types without copying.
@@ -42,7 +42,8 @@ glib_wrapper! {
impl Bytes {
/// Copies `data` into a new shared slice.
fn new(data: &[u8]) -> Bytes {
fn new<T: AsRef<[u8]>>(data: T) -> Bytes {

This comment has been minimized.

@sdroege

sdroege Dec 10, 2017

Member

This is also something we should teach GIR about

This comment has been minimized.

@EPashkin

EPashkin Dec 10, 2017

Member

Not sure that we need transfer ownership in this case

This comment has been minimized.

@sdroege

sdroege Dec 10, 2017

Member

We don't, you can still pass any reference, see the unit test. Only if it was 'static it would always pass ownership (or require that it's a static reference).

/// Takes ownership of `data` and creates a new `Bytes` without copying.
pub fn from_owned<T: AsRef<[u8]> + Send + 'static>(data: T) -> Bytes {
let data: Box<Box<AsRef<[u8]>>> = Box::new(Box::new(data));

This comment has been minimized.

@EPashkin

EPashkin Dec 10, 2017

Member

Maybe we should use data: Box<Box<T>> here?

This comment has been minimized.

@sdroege

sdroege Dec 10, 2017

Member

Doesn't really make a difference. We only have the box to keep around the data and free it later when needed. If we would make it a specific box instead of a trait object, a new drop function would have to be created by the compiler for each possibly type passed in here.

This comment has been minimized.

@EPashkin

EPashkin Dec 10, 2017

Member

In current case each from_owned will not have own copy of drop_box?

This comment has been minimized.

@sdroege

sdroege Dec 10, 2017

Member

No, there's only a single function that drops a box that contains a trait object. It's not a generic function

This comment has been minimized.

@EPashkin

EPashkin Dec 10, 2017

Member

Thanks, I thought that it created for any instance of outer generic function

This comment has been minimized.

@sdroege

sdroege Dec 10, 2017

Member

Defining a plain function inside another function only makes it invisible from outside the function, it's a way of hiding. Try using any of the outer functions generic types in the inner function, the compiler will complain that it can't do that :)

Same thing with static variables that you define inside a function btw

@EPashkin

This comment has been minimized.

Member

EPashkin commented Dec 11, 2017

Ping and 👍

@sdroege

This comment has been minimized.

Member

sdroege commented Dec 11, 2017

Ping whom? @GuillaumeGomez ?

@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Dec 11, 2017

Yes, me. :)

Thanks!

@GuillaumeGomez GuillaumeGomez merged commit ee29175 into gtk-rs:master Dec 11, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment