-
Notifications
You must be signed in to change notification settings - Fork 45
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
Remove ExactSizeIterator
constraint from SimpleSmt::with_leaves()
#228
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thank you! Let's resolve the merge conflict (which appeared after I merged #224), squash the commits, and merge.
src/merkle/simple_smt/mod.rs
Outdated
} | ||
// compute the max number of entries. We use an upper bound of depth 63 because we consider | ||
// passing in a vector of size 2^64 infeasible. | ||
let max_num_entries = 2usize.pow(tree.depth.min(63).into()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor nit: we usually write 2_usize
instead of 2usize
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Kudos, SonarCloud Quality Gate passed! |
…#228) * Change InvalidNumEntries error * max computation * remove length check * remove ExactSizeIterator constraint * fix InvalidNumEntries error condition * 2_usize
…#228) * Change InvalidNumEntries error * max computation * remove length check * remove ExactSizeIterator constraint * fix InvalidNumEntries error condition * 2_usize
The
ExactSizeIterator
constraint forces the caller to instantiate iterators into, say, aVec
, which leads to useless memory allocations. The signature of the function is now cleaner as well.The one downside of this approach is that in the unlikely case that the collection indeed has more than 2^63 elements, then we will do a lot of processing before figuring that out. However, this will almost never happen, and we should optimize for the case where the iterator doesn't have too many elements.