public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95609] New: span<T> could have better layout Date: Tue, 09 Jun 2020 16:23:41 +0000 [thread overview] Message-ID: <bug-95609-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609 Bug ID: 95609 Summary: span<T> could have better layout Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s_gccbugzilla at nedprod dot com Target Milestone: --- I would assume that the ABI ship has sailed, as usual, but if libstdc++'s span<T> could instead have the layout: { T *p; size_t l; } ... then a span<byte> would be layout-compatible with struct iovec, which would save libstdc++ having to reimplement span<> with a struct iovec compatible layout for any future std::file_handle::buffer_type, if that gets standardised. I put notice of this out onto lib-ext last year requesting this of span<T> implementations. libc++ heeded my request, MSVC have very kindly undone their initial implementation to meet the pointer + size layout plus add standard layout, so they'll be on that too going forth. In the end, this request is about as unimportant for right now as you can get. It's purely for saving you, Jonathan, avoidable work later on. Niall
next reply other threads:[~2020-06-09 16:23 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-09 16:23 s_gccbugzilla at nedprod dot com [this message] 2020-06-09 20:46 ` [Bug c++/95609] " redi at gcc dot gnu.org 2020-06-11 12:10 ` s_gccbugzilla at nedprod dot com 2020-06-11 13:37 ` redi at gcc dot gnu.org 2020-10-28 12:32 ` [Bug libstdc++/95609] " cvs-commit at gcc dot gnu.org 2020-10-28 12:32 ` redi at gcc dot gnu.org 2020-10-28 14:16 ` s_gccbugzilla at nedprod dot com 2021-08-23 13:35 ` redi at gcc dot gnu.org 2021-08-23 13:51 ` s_gccbugzilla at nedprod dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-95609-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).