Skip to content
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

Common template for inline vector implementation. #245

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lemur73
Copy link

@lemur73 lemur73 commented May 17, 2021

Allows simplier using inline vectors of different sizes and types.

Signed-off-by: Ostap Slavking [email protected]
If you like my commits cheer me with some chia here:
xch16es77qggpwgzucqmmvhvgcueckmt9g3e7exa46vhmucz7z8j2a2spm7c7e

@lgtm-com
Copy link

lgtm-com bot commented May 17, 2021

This pull request fixes 1 alert when merging 51a5eee into 632c9d7 - view on LGTM.com

fixed alerts:

  • 1 for Inconsistent definition of copy constructor and assignment ('Rule of Two')

@lgtm-com
Copy link

lgtm-com bot commented May 17, 2021

This pull request fixes 1 alert when merging 9fa9f9f into 632c9d7 - view on LGTM.com

fixed alerts:

  • 1 for Inconsistent definition of copy constructor and assignment ('Rule of Two')

@arvidn
Copy link
Contributor

arvidn commented May 18, 2021

this mostly looks like an improvement. However, when you make the element type a template argument I think you're going a bit too far. your InlineVector implementation does not support arbitrary element types. Fortunately, we don't need arbitrary types. I would suggest just leaving it hard coded as uint64_t.

One thing these classes need more urgently are tests though.

template <class item_type, class size_type_arg, unsigned capacity>
class InlineVector {
public:
typedef size_type_arg size_type;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the way this spells nowadays is:

Suggested change
typedef size_type_arg size_type;
using size_type = size_type_arg;

src/bits.hpp Outdated

SmallVector& operator=(const SmallVector& other)
{
InlineVector& operator=(const InlineVector& other) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while you're at it, this function should probably be ref-qualified.

Suggested change
InlineVector& operator=(const InlineVector& other) {
InlineVector& operator=(const InlineVector& other) & {

src/bits.hpp Outdated
typedef uint32_t size_type;

ParkVector() noexcept { count_ = 0; }
InlineVector& operator=(const std::vector<item_type>& other) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and so should this probably:

Suggested change
InlineVector& operator=(const std::vector<item_type>& other) {
InlineVector& operator=(const std::vector<item_type>& other) & {

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing these classes need more urgently are tests though.

Updated with fixes from your comments and test.
PTAL

src/bits.hpp Outdated

// A stack vector of length 2048, having the functions of std::vector needed for Bits.
// The max number of Bits that can be stored is 2048 * 64
typedef InlineVector<uint64_t, uint16_t, 2048> ParkVector;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the modern way (and more readable in my opinion) is to use a using declaration.

Suggested change
typedef InlineVector<uint64_t, uint16_t, 2048> ParkVector;
using ParkVector = InlineVector<uint64_t, uint16_t, 2048>;

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the modern way (and more readable in my opinion) is to use a using declaration.

Unfortunately, this doesn't work. Gives an error:

~/chiapos_up/src/bits.hpp:79: error: expected nested-name-specifier
 using InlineVector<uint64_t, uint8_t, 10> SmallVector;
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try this instead:

using ParkVector = InlineVector<uint64_t, uint16_t, 2048>;

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That worked, thanks.
Updated and uploaded.

@lemur73
Copy link
Author

lemur73 commented May 18, 2021

this mostly looks like an improvement. However, when you make the element type a template argument I think you're going a bit too far. your InlineVector implementation does not support arbitrary element types. Fortunately, we don't need arbitrary types. I would suggest just leaving it hard coded as uint64_t.

Well, I have some use of this template argument in my next commits. Just prefer to keep uploads smaller to make it easy to understand and review.

One thing these classes need more urgently are tests though.

I'll upload tests.

src/bits.hpp Outdated
size_type max_size() const { return capacity; }

private:
item_type v_[capacity];
size_type count_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you make this change, you don't have to define the constructor

Suggested change
size_type count_;
size_type count_ = 0;

@lgtm-com
Copy link

lgtm-com bot commented May 18, 2021

This pull request introduces 1 alert and fixes 1 when merging e94cf3f into 632c9d7 - view on LGTM.com

new alerts:

  • 1 for Comparison of narrow type with wide type in loop condition

fixed alerts:

  • 1 for Inconsistent definition of copy constructor and assignment ('Rule of Two')

@lgtm-com
Copy link

lgtm-com bot commented May 18, 2021

This pull request fixes 1 alert when merging 8c67004 into 632c9d7 - view on LGTM.com

fixed alerts:

  • 1 for Inconsistent definition of copy constructor and assignment ('Rule of Two')

@lgtm-com
Copy link

lgtm-com bot commented May 19, 2021

This pull request fixes 1 alert when merging c71e3eb into 632c9d7 - view on LGTM.com

fixed alerts:

  • 1 for Inconsistent definition of copy constructor and assignment ('Rule of Two')

SmallVector() noexcept { count_ = 0; }

uint64_t& operator[](const uint16_t index) { return v_[index]; }
template <class item_type, class size_type_arg, unsigned capacity>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's my argument against making item_type a template parameter:

As it stands in your patch, it's not correct. The template parameter cannot be an arbitrary type, since they're all constructed up-front they must be default constructable. In order to make this more correct, you would need something like:

static_assert(std::is_integral_t<item_type>, "InlineVector inly supports integral types");

Which brings me to my next point. We don't currently need this additional generality/complexity. I don't think it makes sense to make things more general/complex just for the sake of it (in fact, I would argue that keeping everything as specific as possible makes for easier-to-read programs).

Now, you say you'll need this template parameter in your next PR. So, let's punt this change until that PR.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The template parameter cannot be an arbitrary type, since they're all constructed up-front they must be default constructable.

Yeah, I figured that out already in my next patch. Let's see if you like it ;)
Added static assert for now.

@arvidn
Copy link
Contributor

arvidn commented May 20, 2021

I think everything looks good apart from my last comment

Allows simplier using inline vectors of different sizes and types.

Signed-off-by: Ostap Slavking <[email protected]>
If you like my commits cheer me with some chia here:
xch16es77qggpwgzucqmmvhvgcueckmt9g3e7exa46vhmucz7z8j2a2spm7c7e
@github-actions
Copy link

'This PR has been flagged as stale due to no activity for over 60
days. It will not be automatically closed, but it has been given
a stale-pr label and should be manually reviewed.'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants