C++ Logo


Advanced search

Re: [wg14/wg21 liaison] Fwd: native_handle_type

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Mon, 19 Aug 2019 17:50:04 +0300
On Mon, 19 Aug 2019 at 17:38, pete--- via Liaison
<liaison_at_[hidden]> wrote:
> > You make an excellent point that one of the union options ought to be
> > pthread_t.
> That's not my point at all.
> As it currently stands, native_handle_type has no mandatory semantics. That means that the implementation does whatever is necessary to make it work, for some unspecified meaning of "work".
> There's nothing in the standard that prevents an implementation from using a union, but that doesn't address the Windows issue. Under Windows you need (needed?) two different things, depending on what function you're calling. That's not a union; it's a struct with two elements.
> I don't see where requiring a discriminated union is better than allowing implementations to do what they need.
> >
> > Be aware that nobody is proposing that std::thread::native_handle_type
> > be immediately changed. This would break ABI. However it may become
> > changed if a toolchain breaks ABI.
> Changed to what? That's why I asked: I don't know what the goal here is. If the intention is to provide portable semantics for native_handle_type, I think that's a mistake. We already have std::thread, std::mutex, etc. for portable code. The non-portable stuff, which is entirely implementation-defined, is done with native_handle_type.

I don't quite follow what this message thread is about. All the
proposal is proposing is the addition of a nested native_handle_type
and getters for such into iostreams types. There's no universal handle
type being proposed, and whether it's a union seems completely
irrelevant. It's not a portable-semantics native handle type either.
All it does is that it allows me to get a native handle from, say,
and pass that handle along to, say fcntl. Why it should deal with any
unions or pthread_t is completely beyond me.

Received on 2019-08-19 09:52:17