Web lists-archives.com

Re: Why does -std=c++11 hide certain function calls




> 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@xxxxxxxxxxxxxxxxxx>
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