[cfe-dev] [libcxx] Which headers must include other headers?

Eric Fiselier via cfe-dev cfe-dev at lists.llvm.org
Wed Mar 9 14:47:22 PST 2016


On Wed, Mar 9, 2016 at 3:20 PM, Craig, Ben via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> From the C++14 spec...
>
> 17.6.5.2 Headers [res.on.headers]
> 1 A C++ header may include other C++ headers. A C++ header shall provide
> the declarations and definitions
> that appear in its synopsis. A C++ header shown in its synopsis as
> including other C++ headers shall provide
> the declarations and definitions that appear in the synopses of those
> other headers.
>
>
> I'm not 100% sure I know what this means.  If a header (say...
> <system_error>) mentions a class (like std::string), is it required to
> provide the full definition for std::string, or is the forward declared
> template good enough?
>

According to the standard <system_header> does not need <string> even
though the synopsis mentions it. A forward declaration is good enough.
Although <system_header> mentions string, the synopsis for that header
doesn't declare or define std::string so [res.on.headers] doesn't apply.


> Right now, libcxx uses the forward declaration.  What about entities that
> have specializations scattered all over the place, like std::hash?  Is the
> unspecialized forward declaration good enough, or does the full bulk of all
> the std::hash specializations have to come along too?
>
>
>
I don't think all of the specialization need to come along. I'm not sure
what the QoI implications are though. Could you provide some motivation as
to why you asked this question?

> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160309/31655fec/attachment.html>


More information about the cfe-dev mailing list