C++ Logo


Advanced search

Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability

From: JeanHeyd Meneide <phdofthehouse_at_[hidden]>
Date: Mon, 9 Mar 2020 15:55:03 -0400
Dear Tooling/EWG/LEWG,

On Mon, Mar 9, 2020 at 3:36 PM Steve Downey via Ext
<ext_at_[hidden]> wrote:
> In particular, I'd like to see, and measure, the costs of having large overload sets present before committing to a module the size of `std` as opposed to smaller ones where I can exclude parts I am uninterested in.

     I echo Steve's concern here. "import std;" can possibly lead to a
lot of suboptimal overload resolution. For example, clang-format
accidentally brought in extra overload sets related to std::locale and
tanked someone's performance just because of the order of includes:

     C++ is incredibly sensitive to what entities are available. Since
we do not have a selection syntax (e.g., import std with { vector,
string, find_if, ... }), then our only way to control visibility --
and thus, overload resolution -- is with carefully crafted module
buckets. While there is probably no harm in having "import std;" exist
in general, we should be mindful of the problems that already exist
with "expose all the functions and types, ever" for existing and new
code. Therefore, I think both "import std;" as well as more targeted
library buckets should be considered.


Received on 2020-03-09 14:58:00