bluss / arrayvec Goto Github PK

ArrayString lacks any removal features. pop truncate remove etc would be nice.

All of these may be copied from std::String AFAIK.

I will implement these and more if requested. I've opened this issue to discuss because this seems too obvious to have been accidentally omitted?

In a library, I need to be generic over arrays, and since I'm anyway depending on arrayvec I thought it would make sense to use the Array trait for that.

However, the useful as_slice method is hidden in the extension trait that's not public. Since it's unsafe, it would make sense not to have to duplicate it. Is there a reason not to put that method on Array or make the extension trait public?

Planning for arrayvec 1.0

Prerequisites:

• Stable Manually Drop (Rust 1.20!)
• #127 Use ManuallyDrop if safe, else wait for stable MaybeUninit or equivalent union code
• With good model for why keeping uninitialized data in arrayvec is safe.
• Settle API issues (Result vs Option and when to panic) in #61 #163
• Const generics #172

Hi.

I want to a vec on stack.
It seems possible by your crate.
The documentation says "The vector is a contiguous value that you can store directly on the stack if needed."
How can I store an ArrayVec on stack?
"from" method?
(I could not understand the mechanism of "new" method of ArrayVec...)

How can i create an ArrayVec from a slice?
There is no ArrayVec::from(&[T])

The only reference to this crate is via the encode_utf8 function, which is now part of the standard library. IMHO it'd be better to use the stdlib version instead of that one.

The docs still say that use_union requires the nightly channel, but it looks like it no longer does? (Though it also sounds like there are some safety questions still open?)

Maybe arrvec! or arr_vec! ?

Are they marked with #[doc(hidden)] to consider them "unstable"?

I have a use-case in which using capacity would be very handy.

Want I want is this ArrayVec<[_; 36]>

What I'm using now ArrayVec<[_; 40]>

What should I do to make this work ?

I'm not sure if this is even possible but it would be great if ArrayVec::new() would be a const fn and hence could be called in places where only constant expressions are allowed (of course behind some feature-flag since const-fn is still unstable).

The reason I'd like this feature is that I work on embedded systems where it's typical to have all memory allocated statically, i.e. for a large buffer one would have something like

static mut BUFFER: [u8; 4096] = [0; 4096];

This works fine for arrays (and Copy types) but it would be great if I could also use an ArrayVec there. Again, not sure if it's even possible since mem::uninitialized() seems to not be a const-fn (although it should, I think) but maybe/hopefully I'm wrong. :)

lazy_static! will not work AFAIK because on first invocation of the initialization code the value gets constructed on the stack which typically will not be large enough to hold that value, even temporarily.

Thanks for considering this! :)

error[E0119]: conflicting implementations of trait `array::Array` for type `[_; 0]`:
  --> /Users/wez/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.4.5/src/array.rs:65:9
   |
65 |            unsafe impl<T> Array for [T; $len] {
   |   _________^
   |  |_________|
   | ||
66 | ||             type Item = T;
67 | ||             type Index = $index_type;
68 | ||             #[inline(always)]
...  ||
73 | ||             fn capacity() -> usize { $len }
74 | ||         }
   | ||         ^
   | ||_________|
   | |__________first implementation here
   |            conflicting implementation for `[_; 0]`
...
90 |    fix_array_impl_recursive!(u32, 1 << 16,);
   |    ----------------------------------------- in this macro invocation

error: aborting due to previous error

error: Could not compile `arrayvec`.

commenting out the 32-bit index case in array.rs:90 resolves this compilation error.

I'm not sure of the best way to resolve this otherwise I'd just submit a PR to do it :-/

ManuallyDrop is stable in Rust 1.20 (not yet released).

This is the official nodrop that arrayvec has been waiting a long time for; it's likely that we will use Rust 1.20 as the new required version from this point.

I assumed default() would create an array of len N and initialize all elements by calling their Default impl (mirroring normal arrays), but it just creates an empty ArrayVec.
It would make more sense to have default() initialize all N elements with their default, like this:

ArrayVec::from(array![Default::default(); N])

(Using array-macro here to demonstrate the desired semantics.)

It's already possible for a user to create this on their own:

fn cap_err<T>(val: T) -> CapacityError<T> {
    let mut av: ArrayVec<[T; 0]> = ArrayVec::new();
    av.try_push(val).unwrap_err()
}

I currently use a wrapper over ArrayVec for my own type and it'd be nice to create my own CapacityErrors without having to create my own type.

Hi,
I want to use ArrayString in rustc_hex::ToHex, this trait works on every type that implements FromIterator on Item=char.
But ArrayString is Item=u8.

Is there a reason this isn't Item=char?

A version bump would make this possible: This affects methods like push, insert, etc.: In order to easily assert or bubble up the error, it would be nice if these methods returned Results instead of Options. This way, you can both implement From to convert it to your own error type and use unwrap for an easy "this is a bug" marker. Additionally, it warns if the result is unused.

We can add arbitrary requested array sizes, if you need a lot of them they may be feature gated to not bloat the crate's default size too much, but ask away here!

So feel free to request sizes here; of course at some point in Rust's future we will have generics to cover this, and this kind of issue will be over!

Hi.

I have a fuction that returns large ArrayVec instance.
I guess that there are no return-value optimizations in release build and the instance is copied into stack every time when it returns.
(I am not quite sure since assemble code is complicated for me.)

Is my understanding right?
And if so, are there any ways for return-value optimizations?

Thanks.

Hi.

In order to avoid allocation, I am using your ArrayVec instead of Vec. Thanks.
I could certainly avoid allocation it seems that ArrayVec consumes time by memcpy when dropping.
Type of ArrayVec is integer(u8, usize), not structs using heap, so I wonder there is no need to clean up.

Is my understanding right?
and if so, can I avoid it?

I'm not sure, but I suspect having an append function that consumes another arrayvec and ptr::copys over all elements at once would be faster than using extending an iterator which ptr::writes per-item.

Please expose the macro so that user code can create an impl for a given N that doesn't already impl Array :)

IntoIter and ArrayVec need to be poisoned to prevent dropping before being drained; otherwise, if one of the elements panics on drop, it will be dropped twice. I've worked on a couple of solutions but they all have design tradeoffs so I figured I'd just let you fix it.

Drain doesn't have this issue because the ArrayVec's length is set to 0 when the Drain is initialized.

I'm considering using an ArrayVec<[_; 9]> as a small stack to keep track of pressed buttons on a mouse in conrod, however I noticed that it does not impl Copy. Seeing as it has a fixed-size, shouldn't deriving Copy be ok? Or is there some other boundary stopping this?

The function looks wrong for cases self.len() < index < self.capacity().

Integration with the generic-array crate was added but then reverted with the following message:

- It can be added back later if needed
- A public dependency implies version coupling, and we can't afford to
  have it for a niche use case.

It's not clear to me what is meant by the version coupling problem; can we clarify?

Stop using the nodrop crate in arrayvec.

We need (to replace nodrop with something) sound inclusion of uninitialized inline array values and soundness vs the Option Some/None issue.

Yesterday I had the need for ArrayVecDeque and today I need one for HashSet. So maybe it makes sense to have ArrayVec versions of all / most of the collections. Maybe just ArrayVecDeque if the other collections are too out of scope for this crate.

According to the git history commit 233df73 should be in v0.4.10. However downloading the crate from crates.io (https://crates.io/api/v1/crates/arrayvec/0.4.10/download and extract it with tar -xzvf arrayvec-0.4.10.crate) shows the code before the commit. Was outdated code uploaded to crates.io?

A version bump would make this change possible: Vec panics on out-of-bounds indices: Vec::remove.

Initially in an ArrayVec the memory is uninitialized: https://github.com/bluss/arrayvec/blob/master/src/lib.rs#L80.

This simply is UB in Rust for any types with invalid bit patterns (most notably references). Just creating an uninitialized value with these bit patterns is UB.

Even perfectly fine code that never actually reads or uses the uninitialized memory still has undefined behavior. I ran into this myself: https://stackoverflow.com/questions/52348277/vector-is-empty-after-cloning-struct-with-uninitialized-member.

There was a brief discussion about this on IRC. While doing so might be sound, it also will probably be weird.

I am just filling in this issue so that the IRC discussion can continue offline, even though this is probably only a mental exercise.

pinging: @nox @bluss

The title says it all: moving an ArrayVec has complexity O(capacity()) instead of O(len()). This is pretty bad.

It is trivial to construct examples that show a massive slowdown (100x's slower) with respect to C++'s boost::container::static_vector.

For example, moving an empty ArrayVec<[u64; 512]> involves memcpying 4104 bytes instead of just 8 bytes (the size of len). That's 513x more expensive than C++'s boost::container::static_vector.

I'm missing the resize functionality (similar to the std::vec::Vec::resize):

fn resize(&mut self, new_len: usize, value: T)

I have to fill some items in a random order, so first the array have to be resized with some default values before indexing can start.
I could use plain arrays, but I'd like to use ArrayVec for it's "virtual dynamic" size.

Is there a function for this I've missed?

Edit:
This is my workaround:

(0..count).for_each(|_| self.attributes.push(Attribute::new()));

I would love to use ArrayString, but it doesn't implement Ord which is a constraint for me (types in differential dataflow need to be Ord so they can be sorted for deduplication/consolidation).

It seems like it could be a pretty simple implementation, as String just derives Ord which means it gets the Vec<u8> implementation. I guess it would be similar here, except needing to manually slice the backing contents in the impl to avoid touching invalid data. It seems like ArrayVec could be similarly workable, for types T: Ord.

Edit: I'd be happy to do a PR, but I'm not sure I grok all of the index cleverness, and wouldn't want to mess things up. If you'd rather I take a stab first, let me know. :)

When possible, transition to the RangeBounds trait for .drain().

I am in the middle of replacing some std::vec::Vec uses with arrayvec::ArrayVec. I haven't actually started handling attempted insertion into a full ArrayVec yet, all I have done is replace types and use Default::default() to initialize the ArrayVecs.

After doing that, I ran cargo test just to see where I am at. I am getting the following segfault:

Process 12371 stopped
* thread #2: tid = 0x3a910, 0x00007fff956c0f49 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 41, name = 'cfi::tests::test_unwind_info_for_address_ok', stop reason = EXC_BAD_ACCESS (code=2, address=0x70000080c000)
    frame #0: 0x00007fff956c0f49 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 41
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
->  0x7fff956c0f49 <+41>: rep    
    0x7fff956c0f4a <+42>: movsb  byte ptr es:[rdi], byte ptr [rsi]
    0x7fff956c0f4b <+43>: pop    rbp
    0x7fff956c0f4c <+44>: ret    
(lldb) up
frame #1: 0x000000010000b1c7 gimli-aa1dbf6d337a8251`nodrop::imp::{{impl}}::new<[gimli::cfi::UnwindTableRow<gimli::endianity::BigEndian>; 16]>(value=gimli::cfi::UnwindTableRow<gimli::endianity::BigEndian> [16] @ 0x000070000086b0a0) + 183 at lib.rs:57
   54  	        /// Create a new **NoDrop**.
   55  	        #[inline]
   56  	        pub fn new(value: T) -> NoDrop<T> {
-> 57  	            NoDrop(Flag::Alive(value))
   58  	        }
   59  	
   60  	        /// Extract the inner value.
(lldb) up
frame #2: 0x000000010000910b gimli-aa1dbf6d337a8251`arrayvec::{{impl}}::new<[gimli::cfi::UnwindTableRow<gimli::endianity::BigEndian>; 16]> + 59 at lib.rs:118
   115 	    /// ```
   116 	    pub fn new() -> ArrayVec<A> {
   117 	        unsafe {
-> 118 	            ArrayVec { xs: NoDrop::new(new_array()), len: Index::from(0) }
   119 	        }
   120 	    }
   121 	
(lldb) up
frame #3: 0x000000010005114e gimli-aa1dbf6d337a8251`arrayvec::{{impl}}::default<[gimli::cfi::UnwindTableRow<gimli::endianity::BigEndian>; 16]> + 30 at lib.rs:776
   773 	
   774 	impl<A: Array> Default for ArrayVec<A> {
   775 	    fn default() -> ArrayVec<A> {
-> 776 	        ArrayVec::new()
   777 	    }
   778 	}
   779 	
(lldb) up
frame #4: 0x00000001000913a6 gimli-aa1dbf6d337a8251`gimli::cfi::{{impl}}::new<gimli::endianity::BigEndian,gimli::cfi::DebugFrame<gimli::endianity::BigEndian>> + 54 at cfi.rs:1349
   1346	{
   1347	    fn new() -> UnwindContext<'input, Endian, Section> {
   1348	        let mut ctx = UnwindContext {
-> 1349	            stack: Default::default(),
   1350	            is_initialized: false,
   1351	            initial_rules: Default::default(),
   1352	            phantom: PhantomData,
(lldb) 

This version of arrayvec, default features:

[dependencies]
arrayvec = "0.3.20"

OSX 10.11.6.

Am I doing something wrong here? Even if I was, I'd expect an explicit panic, not a segfault...

I can provide a (non-minimal, sorry) test case, if that would help, or also act a remote LLDB client ;)

Thanks!

I don't know that it should, but ArrayVec does, and String does. I just noticed that ArrayString does not, and while it isn't blocking for me (in fact it reminded me that I should remove the : Default requirements on some of my impls) I thought I should point it out!

It would be nice if ArrayVec/ArrayString had their optional serde Serialize and Deserialize implementations.

This crate doesn't work for no_std.
On of the reasons:

Any chance to get no_std support?

Constant generics is becoming more mature and soon will be in an usable state for complex projects.

struct ArrayVec<A> contains a field of type A::Index. This makes it invariant over A, for reasons described in rust-lang/rust#21726 (comment) and rustc_typeck::variance.

It would be nice for ArrayVec<A> to be covariant over A, so that for example an ArrayVec<[&'long T; N]> could be used where an ArrayVec<[&'short T; N]> is expected, if 'long: 'short. This would make it act more like [T] and Vec<T> and other standard library containers.

Fixing this might require getting rid of Array::Index as an associated type, and finding some other way to specify it.

I'm specifically talking about the remove and swap_remove methods, they both return T in Vec (panic if out of bounds), whereas this one returns Some(T) and None if out of bounds.

Another nit is that push returns an Option instead of a Result, so you can't use try! together with that. My suggestion would be to return an Result<(),ArrayVecFull<T>>, with an into_inner method for ArrayVecFull<T>.

I'd prepare a pull request if you'd like these changes.

Hello!

I noticed that the archive that is uploaded to crates.io does not include the MIT/Apache license files. This happened because 0.1.12 crate was published before these files were added in #88. Could a new version be published that includes these files? Thanks so much!