Why does -std=c++11 hide certain function calls
John Selbie
jselbie@gmail.com
Thu Sep 6 06:45:00 GMT 2018
> For Unixy builds, just don't specify -std. Only specify -std if you want
to ensure that builds will work with earlier standards, compilers, or
libraries, or for -std=c* without any special language or library features,
in which case you may also want to add -pedantic or more restrictive
options.
Ahhhh…. that was my mistake. I had erroneously assumed that not specifying
-std would result in the oldest version of C++. A quick check:
$ g++ foo.cpp -c -dM -E | grep cplus
#define __cplusplus 201402L
I was compiling with C++ 14 the whole time. And it appears that when -std
is used, the GNU defines are taken out, which ultimately influence how
POSIX_VISIBLE Is defined within <features.h>.
I'm not sure if I agree that -std should hide the functions from unix
headers. (tldr: unix headers are explicitly outside the c++ standard, so
the moment they are included, you might as well assume the developer wants
it all...)
But at last now I'm unblocked. Thanks everyone.
jrs
On Wed, Sep 5, 2018 at 1:41 PM Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
wrote:
> On 2018-09-05 13:36, John Selbie wrote:
> > On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Bröker wrote:
> >> Am 05.09.2018 um 07:55 schrieb John Selbie:
> >>> With this: g++ foo.cpp -c -std=c++11
> >>> It compiles fine everywhere else, except CygWin. Output on Cygwin:
> >> I'm afraid that may mean everywhere else is wrong.
> >>> Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the
> >>> command line works.
> >>> But I don't understand why the need to enforce these extensions to get
> >>> access to some of the most common unix libraries?
>
> >> Because that's what std=c++11 is meant and documented to do. It turns
> >> off all extensions to the standard language. And yes, that does include
> >> extensions to the standard libary, up to and including POSIX-specific
> >> content.
> >> For what you want to do, std=c++11 is simply the wrong setting.
>
> > But why is getaddrinfo (and its associated struct types and flag values)
> > considered a "language extension" and hidden via the __POSIX_VISIBILE
> > define when other function declarations in netdb.h (such as
> getservbyname)
> > are not?
> > I don't believe C++ has any formal support for networking. So it's
> > surprising to see one networking function hidden "because its an
> > extension", but the other very related functions are not. Can you
> elaborate
> > on the decision process that makes it this way? I honestly don't see
> how a
> > header file qualifies as a language extension, but instead just see it as
> > the interface for a pre-compiled library.
> > Is it because modern C++ is defined to support older POSIX functions, but
> > not newer ones? Where is that in the standard?
> > As I said before, I'm wanting to be educated on this, because it could
> > influence how I view the writing and building of portable code now and in
> > the future. But saying, "everywhere else but here is wrong" and because
> ",
> > doesn't help.
>
> Depends on how standards compliant the implementation and the developer
> are.
> Some(/all?) BSDs specify nothing, but POSIX and other standards specify
> feature
> test macros to enable access to those functions be defined for every C
> source
> module that requires them before any includes e.g. for Linux/GLIBC
> getaddrinfo(3):
>
> "Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>
> getaddrinfo(), freeaddrinfo(), gai_strerror():
> _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE"
>
> so to be guaranteed access to those functions, you should define and set
> one of
> those symbols, in each source file, build command line, or makefile, which
> -std=gnu* (or no -std flag) does for you. For Unixy builds, just don't
> specify
> -std. Only specify -std if you want to ensure that builds will work with
> earlier
> standards, compilers, or libraries, or for -std=c* without any special
> language
> or library features, in which case you may also want to add -pedantic or
> more
> restrictive options.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin
mailing list