c ffi

[hanabi1224]

@michaelsproul Here is an implementation proposal with some basic APIs for demonstration, let me know your comments.

[michaelsproul]

I think this looks promising.

Do you think the use of a Trie<Vec<u8>, usize> is about as general as we can do? Obviously we can't allow arbitrary value types (like Trie<Vec<u8>, V>) because of C's lack of generics, but we can store pointers to data allocated on the C side, which is pretty good?

[michaelsproul]

Just a small thing, but it would be good if this was an optional dependency behind a feature flag, see: https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section

[hanabi1224]

What feature name would you suggest?

[michaelsproul]

ffi or c-bindings or c_bindings would probably be good

[michaelsproul]

We could optimise this (avoid a double allocation), by implementing TrieKey for CStr. Using a Vec<u8> as the key means that it gets cloned each time, see:

rust_radix_trie/src/keys.rs

Lines 85 to 89 in c34a167

	impl TrieKey for Vec<u8> {
	fn encode_bytes(&self) -> Vec<u8> {
	self.clone()
	}
	}

[hanabi1224]

Actually, I did this on purpose to tolerant unexpected string pointer deallocation from foreign languages, especially managed ones whose memory is not being handled explicitly, does that make sense?

[michaelsproul]

Yeah, I agree that we want that behaviour, but the current code copies the string twice. The .to_bytes().to_vec() call will copy everything into a Vec<u8>, and when that Vec<u8> gets inserted in the trie it will get cloned. Instead, if we generate the Vec<u8> in the TrieKey::encode_bytes function, the string will only get copied once, like:

impl TrieKey for CStr {
    fn encode_bytes(&self) -> Vec<u8> {
        self.to_bytes().to_vec()
    }
}

Maybe the compiler is smart enough to optimise the double-copy away, but it doesn't hurt to give it some help (and impl TrieKey for CStr is generally useful anyway)

[hanabi1224]

@michaelsproul yes exactly

[hanabi1224]

@michaelsproul Can you please take another look?

[michaelsproul]

Hi @hanabi1224! Sorry I missed your comment in September, I seemed to only get notified about it last week!

Anyway, I think the code is looking pretty good. I'm just wondering if you have tried using the API from a GC'd language like Python/Ruby/Haskell, and how that went?

[michaelsproul]

Duplicate import (delete this line)

[hanabi1224]

Fixed

[michaelsproul]

Duplicate, delete

[hanabi1224]

Fixed

[michaelsproul]

I think the trie_ptr argument to this function should be *mut Trie<CString, usize>, at least to convey the intent that it's a mutable pointer (and to allow us to remove some of the casting gunk)

[michaelsproul]

We also need to run rustfmt over the whole project before the build will pass, you can see the .travis.yml for how to set it up

Thanks!

[hanabi1224]

Fixed

[michaelsproul]

Thanks! You can remove the cast (trie_ptr as *mut Trie<CString, usize>) too

[hanabi1224]

Good catch! resolved