* c++0x and locale_t @ 2016-10-01 14:58 Ken Brown 2016-10-01 15:52 ` Brian Inglis 0 siblings, 1 reply; 3+ messages in thread From: Ken Brown @ 2016-10-01 14:58 UTC (permalink / raw) To: cygwin I'm having an issue building icu, which boils down to the following test case: $ cat foo.cc #include <locale.h> locale_t foo; $ g++ -c --std=c++0x foo.cc foo.cc:2:1: error: âlocale_tâ does not name a type locale_t foo; ^ If I remove '--std=c++0x', the error goes away. I know nothing about C++ standards, so I don't know if this is expected behavior or if it indicates a bug in Cygwin's headers. Ken -- 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++0x and locale_t 2016-10-01 14:58 c++0x and locale_t Ken Brown @ 2016-10-01 15:52 ` Brian Inglis 2016-10-02 17:59 ` Ken Brown 0 siblings, 1 reply; 3+ messages in thread From: Brian Inglis @ 2016-10-01 15:52 UTC (permalink / raw) To: cygwin On 2016-10-01 07:30, Ken Brown wrote: > I'm having an issue building icu, which boils down to the following > test case: > $ cat foo.cc > #include <locale.h> > locale_t foo; > $ g++ -c --std=c++0x foo.cc > foo.cc:2:1: error: âlocale_tâ does not name a type > locale_t foo; > ^ > If I remove '--std=c++0x', the error goes away. I know nothing about > C++ standards, so I don't know if this is expected behavior or if it > indicates a bug in Cygwin's headers. For C POSIX locale_t support, you have to do one or both of: #define _XOPEN_SOURCE 700 #define _POSIX_C_SOURCE 200809L to support multiple dynamic C locales and related functions. This may be done automatically if you use the default -std=gnu++03, which may have been the intent in ICU and original interpretation by g++. g++ now interprets (and deprecates) c++0x to mean c++11. You could try changing it to explicitly c++03 and see if it works, without the GNU extensions. Otherwise you should change it to explicitly gnu++03, as c++0x is deprecated, and may be dropped; g++ also deprecates c++1y aka c++14 and c++1z which may be c++17, and their gnu++ counterparts. I don't understand why ICU C++ would use C locales, when C is now trying to add a subset of features C++ has supported better, more flexibly in <locale> for over a decade; see: https://sourceforge.net/p/msys2/discussion/general/thread/23e1b5ce/ for a similar problem to yours, and the solution in standard C++; and: http://stdcxx.apache.org/doc/stdlibug/24-3.html for an explanation of the differences between C++ and C locales. OTOH ICU comes from IBM, and may be more interested in consistency across languages: how else can you explain C++ methods called createInstance? But you may just be the packager, porter, and builder, so may be unable to fix the implementation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++0x and locale_t 2016-10-01 15:52 ` Brian Inglis @ 2016-10-02 17:59 ` Ken Brown 0 siblings, 0 replies; 3+ messages in thread From: Ken Brown @ 2016-10-02 17:59 UTC (permalink / raw) To: cygwin On 10/1/2016 10:58 AM, Brian Inglis wrote: > On 2016-10-01 07:30, Ken Brown wrote: >> I'm having an issue building icu, which boils down to the following >> test case: >> $ cat foo.cc >> #include <locale.h> >> locale_t foo; >> $ g++ -c --std=c++0x foo.cc >> foo.cc:2:1: error: âlocale_tâ does not name a type >> locale_t foo; >> ^ >> If I remove '--std=c++0x', the error goes away. I know nothing about >> C++ standards, so I don't know if this is expected behavior or if it >> indicates a bug in Cygwin's headers. > > For C POSIX locale_t support, you have to do one or both of: > > #define _XOPEN_SOURCE 700 > #define _POSIX_C_SOURCE 200809L > > to support multiple dynamic C locales and related functions. > This may be done automatically if you use the default -std=gnu++03, > which may > have been the intent in ICU and original interpretation by g++. > g++ now interprets (and deprecates) c++0x to mean c++11. > You could try changing it to explicitly c++03 and see if it works, > without the > GNU extensions. > Otherwise you should change it to explicitly gnu++03, as c++0x is > deprecated, > and may be dropped; g++ also deprecates c++1y aka c++14 and c++1z which > may be > c++17, and their gnu++ counterparts. > > I don't understand why ICU C++ would use C locales, when C is now trying > to add > a subset of features C++ has supported better, more flexibly in <locale> > for > over a decade; see: > > https://sourceforge.net/p/msys2/discussion/general/thread/23e1b5ce/ > > for a similar problem to yours, and the solution in standard C++; and: > > http://stdcxx.apache.org/doc/stdlibug/24-3.html > > for an explanation of the differences between C++ and C locales. > > OTOH ICU comes from IBM, and may be more interested in consistency across > languages: how else can you explain C++ methods called createInstance? > > But you may just be the packager, porter, and builder, so may be unable > to fix > the implementation. Thanks for the information. I've submitted a patch upstream. Ken -- 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-10-02 15:09 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-01 14:58 c++0x and locale_t Ken Brown 2016-10-01 15:52 ` Brian Inglis 2016-10-02 17:59 ` Ken Brown
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).