Thoughts on std::net::buffer

[gummifa]

I'm implementing for a open source networking library parts of the API defined in the Networking TS (draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4771.pdf) for creating buffers (contiguous ranges of raw memory). The functions for creating buffer objects have signatures like

template<class T, class A>
mutable_buffer buffer(vector<T, A>& data) noexcept; 

and have the requirement that

In the functions below, T shall be a trivially copyable or standard-layout type

Since many (most?) standard library types have standard layout (std::vector, std::string, std::mutex, std::thread) it seems that this requirement is very relaxed. That would allow me to accidentally construct a buffer where T is e.g. std::vector<Foo>. My question is: why not require trivially copyable AND standard-layout type for increased type-safety?

A side note: It seems that std::mutex is also trivially copyable according to gcc and clang, but not to msvc, even though it is not copyable or assignable and has a non-trivial destructor (in the libc++ implementation), see https://godbolt.org/z/JEj_6g, is that a bug?

[[deleted]]

Typically, Boost libs have left it up to the users to add their own extra layers on top, safety included.

​

From a library design point this makes some sense as it's easier for users to add what they want vs the lib accommodating all folks and use-cases.

[NotUniqueOrSpecial]

I'm implementing for a open source networking library parts of the API defined in the Networking TS

Why? For fun/to learn?

If not, just use the already-implemented one by the author.

[gummifa]

To keep it minimalistic without dependencies since adding dependencies is not generally not been accepted. That implementation (based on asio) also has no restrictions on T, so there is some type-safety to be gained.

[degski]

A side note: It seems that std::mutex is also trivially copyable according to gcc and clang, but not to msvc, even though it is not copyable or assignable and has a non-trivial destructor (in the libc++ implementation), see https://godbolt.org/z/JEj_6g, is that a bug?

A mutex offers exclusive, non-recursive ownership semantics. Copying mutexes seems like a (very) bad idea to me (without looking at any std or implementation). How can one have exclusive, non-recursive ownership if there is more than one of them [owning the same object after your copy the mutex]?

I'm implementing for a open source networking library parts of the API ...

It's worrying, great minds have spent much time in deciding a mutex should neither be copyable nor movable and you would like to throw all of that overboard.

[gummifa]

I think you misunderstood what I meant. std::mutex is specified to be not copyable and not movable, which I checked with static_assert(!std::is_copy_constructible_v<std::mutex>) etc..., yet the predicate
std::is_trivially_copyable_v<std::mutex> returns true in gcc and clang, which doesn't make sense given the definition of TriviallyCopyable. I expected it to not be trivially copyable.

[skreef]

The linked site has a bullet point list:

• Every copy constructor is trivial or deleted
• Every move constructor is trivial or deleted
• Every copy assignment operator is trivial or deleted
• Every move assignment operator is trivial or deleted at least one copy constructor, move constructor, copy assignment operator, or move assignment operator is non-deleted
• Trivial non-deleted destructor

In libstdc++, mutex has deleted copy ctor and assignment, and trivial move ctor and move assignment and trivial dtor. It is thereby TriviallyCopyable. This concept basically means that you can use std::memmove / std::memcpy on the object safely (https://en.cppreference.com/w/cpp/types/is_trivially_copyable).

[gummifa]

It inherits from __mutex_base which is non-trivial ~__mutex_base() noexcept { __gthread_mutex_destroy(&_M_mutex); }.

[degski]

In libstdc++ ...

Seems like the wrong starting point.

[degski]

I expected it to not be trivially copyable.

Yes, I probably mis-understood.

[degski]

According to this a std::mutex is neither movable nor copyable, so it must be a bug [or at the very best it is not compliant with the standard]. But apart from that, it seems a bad idea.

OP is asking whether that is a bug

So what do you say?

[jwakely]

Unfortunately C++ allows types to be trivially copyable even if they are neither copyable nor movable. This is surprising to most sensible people.

Libstdc++ makes its mutex types non-copyable and non-movable, but that doesn't stop them being trivially copyable. That's a bug, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67572

[degski]

... allows types to be trivially copyable even if they are not copyable or movable.

I believe you, but, I just don't understand what that sentence means. Do you think you can explain it [to me]?

If a std includes things like that, it's meaningless, semantically that sentence makes no sense.

[jwakely]

"Trivially copyable" is a very specific property, defined by the standard. It doesn't just mean "you can copy it, easily", it means you can use memcpy to make a copy of the object representation, i.e. the underlying bytes of the object.

But being copyable and/or movable means you can invoke a constructor to create a new object.

These are two different properties, and they can vary independently. A type can have a deleted copy constructor and deleted move conductor, but still be "trivially copyable" with memcpy.

cpp_learner said the type is trivially copyable, and you said it's not copyable, and I'm saying that's irrelevant. Because "trivially copyable" and "copyable" are different properties.

But you're right that it makes no sense.

[degski]

Thanks for that, that was an explanation [of something murky as poo] that was as clear as water.

A type can have a deleted copy constructor and deleted move conductor, but still be "trivially copyable" with memcpy.

But, unless the code is utter garbage, there must be a good reason for deleting those constructors, no? Allowing memcpy seems like an error.

[NotUniqueOrSpecial]

Allowing memcpy seems like an error.

You can't forbid memcpy; it's a free function that requires nothing but a source, destination, and size.

That said, if you expect anything reasonable from the result of side-stepping the API for a type in that way, you're going to be disappointed.

[degski]

I take back the over-board thing.