> 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.ing...@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