Skip to content

Add transparent access for internal buffer in LocalBuffer #6659

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.

Sign up for GitHub

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

Closed
maskit wants to merge 1 commit into from
Closed

Add transparent access for internal buffer in LocalBuffer #6659

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions include/tscpp/util/LocalBuffer.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,11 @@ template <class T = uint8_t, std::size_t EstSizeBound = 1024> class LocalBuffer
T *data() const;
std::size_t size() const;

T &operator[](std::size_t index);
const T &operator[](std::size_t index) const;

operator T *();
Copy link
Contributor

@masaori335 masaori335 Apr 15, 2020

Choose a reason for hiding this comment

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

Because of std::array, std::vector, and std::string don't have this, I'm wondering if there is any trap or not.

/cc @ywkaras @SolidWallOfCode

Copy link
Contributor

@ywkaras ywkaras Apr 15, 2020

Choose a reason for hiding this comment

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

Can you give examples where this would be useful?'

This is a conversion operator, which (without the explicit keyword) creates an implicit conversion. This, https://stackoverflow.com/questions/2346083/why-implicit-conversion-is-harmful-in-c , talks about implicit conversion due to constructors, but the issues also apply to conversion operators.

To give a simple example of how it's bad:

LocalBuffer<char> buf;
// ...
foo(buf);

It's ambiguous whether the prototype for foo() is foo(char *) or foo(LocalBuffer<char> &).

Copy link
Member Author

@maskit maskit Apr 16, 2020

Choose a reason for hiding this comment

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

The implicit conversion is to not introduce additional code, which you can find on the existing unit tests and #6536.

uint8_t *buf = local_buffer.data();

As you can see on the unit tests I added, you would be able to pass a LocalBuffer to memcpy (and functions that expects a pointer for an array).

My understanding of the intent of using LocalBuffer is achieving code like below.

char buf[max(1024, given_dynamic_size)];

So making LocalBuffer usable just like an array without additional code or explicit conversion makes sense to me. I don't think we will want functions that receives LocalBuffer.

Copy link
Contributor

@ywkaras ywkaras Apr 16, 2020

Choose a reason for hiding this comment

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

Note that the partial specialization of std::unique_ptr can be used for variable sized buffers. But the designers of this chose not to make it implicitly convert to a raw pointer. https://godbolt.org/z/ozKPso

Copy link
Member Author

@maskit maskit Apr 16, 2020

Choose a reason for hiding this comment

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

I guess it's because implicit conversion can easily break the concept of ownership.

Copy link
Member

@SolidWallOfCode SolidWallOfCode Jan 28, 2021

Choose a reason for hiding this comment

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

Yes. I have to agree with removing the implicit conversion and requiring a call to data(). That makes it consistent with the other types of containers (e.g. string_view, string, etc.).

If you want to pass directly to things like memcpy I would overload such functions to take advantage of knowing the size implicitly.


private:
T _buf[EstSizeBound];
T *const _ptr;
Expand Down Expand Up @@ -69,4 +74,19 @@ LocalBuffer<T, S>::size() const
return _size;
}

template <class T, std::size_t S> inline T &LocalBuffer<T, S>::operator[](std::size_t index)
{
return data()[index];
}

template <class T, std::size_t S> inline const T &LocalBuffer<T, S>::operator[](std::size_t index) const
{
return data()[index];
}

template <class T, std::size_t S> inline LocalBuffer<T, S>::operator T *()
{
return data();
}

} // namespace ts
20 changes: 20 additions & 0 deletions src/tscpp/util/unit_tests/test_LocalBuffer.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,4 +108,24 @@ TEST_CASE("LocalBuffer", "[libts][LocalBuffer]")
CHECK(local_buffer.size() == 4096);
}
}

SECTION("Transparent access")
{
const size_t len = 1024;
ts::LocalBuffer local_buffer1(len);
ts::LocalBuffer local_buffer2(len);

memset(local_buffer1, 0xAA, len);
local_buffer1[len - 1] = 0xBB;

CHECK(local_buffer1[0] == 0xAA);
CHECK(local_buffer1[len - 1] == 0xBB);
CHECK(local_buffer1.size() == 1024);

memcpy(local_buffer2, local_buffer1, local_buffer2.size());

CHECK(local_buffer2[0] == 0xAA);
CHECK(local_buffer2[len - 1] == 0xBB);
CHECK(local_buffer2.size() == 1024);
}
}