public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: c++0x and locale_t
Date: Sun, 02 Oct 2016 17:59:00 -0000	[thread overview]
Message-ID: <be9be35f-578e-b1f3-226a-50d02ea3eb33@cornell.edu> (raw)
In-Reply-To: <d62d5b0c-3702-62f5-f1c9-d470404fae94@SystematicSw.ab.ca>

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

      reply	other threads:[~2016-10-02 15:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-01 14:58 Ken Brown
2016-10-01 15:52 ` Brian Inglis
2016-10-02 17:59   ` Ken Brown [this message]

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=be9be35f-578e-b1f3-226a-50d02ea3eb33@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin@cygwin.com \
    /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).