From: Jonathan Wakely <jwakely@redhat.com>
To: gcc-patches@gcc.gnu.org
Cc: libstdc++@gcc.gnu.org
Subject: [PATCH] doc: Document that libstdc++ uses __STRICT_ANSI__
Date: Wed, 16 Dec 2020 13:27:48 +0000 [thread overview]
Message-ID: <20201216132748.GA1027090@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.
gcc/ChangeLog:
* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.
OK for trunk?
I'd also like to tell users they're not allowed to undefine the
macro, would that be acceptable, or is that supposed to work?
I don't see how it's possible to make it work with libstdc++ if users
do stupid things like:
#include <type_traits>
#undef __STRICT_ANSI__
#include <iterator>
This causes the library to be in an inconsistent (broken) state,
because some templates are defined according to strict ISO C++ rules
and then other templates are not, but assume the earlier definitions
are consistent.
We frequently see users doing -std=c++11 -U__STRICT_ANSI__ which makes
me smash my head on the table. Just use -std=gnu++11 and stop being
dumb.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1228 bytes --]
commit c516abe37ef82444e125b32933ea44a00a99d1ec
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Wed Dec 16 13:21:24 2020
doc: Document that libstdc++ uses __STRICT_ANSI__
Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.
gcc/ChangeLog:
* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 5dcd67259e3..c5cdd5cb069 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1996,8 +1996,8 @@ testing @code{@w{(__GNUC__ && __cplusplus)}}.
GCC defines this macro if and only if the @option{-ansi} switch, or a
@option{-std} switch specifying strict conformance to some version of ISO C
or ISO C++, was specified when GCC was invoked. It is defined to @samp{1}.
-This macro exists primarily to direct GNU libc's header files to use only
-definitions found in standard C.
+This macro exists primarily to direct libstdc++ and GNU libc's header files
+to use only definitions found in standard C and C++.
@item __BASE_FILE__
This macro expands to the name of the main input file, in the form
reply other threads:[~2020-12-16 13:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20201216132748.GA1027090@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@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: link
Be 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).