From stdcxx-dev-return-5097-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Sep 19 19:55:40 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 2692 invoked from network); 19 Sep 2007 19:55:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Sep 2007 19:55:40 -0000 Received: (qmail 80268 invoked by uid 500); 19 Sep 2007 19:55:32 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 80253 invoked by uid 500); 19 Sep 2007 19:55:32 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 80242 invoked by uid 99); 19 Sep 2007 19:55:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2007 12:55:32 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2007 19:55:32 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l8JJsAe7003982 for ; Wed, 19 Sep 2007 19:54:10 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 13:54:07 -0600 Message-ID: <46F17E9F.1030507@roguewave.com> Date: Wed, 19 Sep 2007 13:55:11 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: do we still need rwstderr.rc? References: <7BDB2168BEAEF14C98F1901FD2DE6438F58196@epmsa009.minsk.epam.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 19:54:07.0057 (UTC) FILETIME=[D67A0C10:01C7FAF6] X-Virus-Checked: Checked by ClamAV on apache.org Travis Vitek wrote: > > > Farid Zaripov wrote: >> Subject: Re: do we still need rwstderr.rc? >> >> I agree that if gencat would accept .msg files instead of .rc files it >> would be great improvement. But then we need to decide how to deal >> with possible multiple sets in .msg file. The .rc file doesn't have >> the sets. We can encode set number and message number to ID in .rc >> file (0 <= ID <= 0xffff): >> >> ID = set * 0x100 + msg - 256 sets by 256 messages per set, or >> ID = set * 0x1000 + msg - 16 sets by 4096 messages per set >> > > This is a little off topic, but since it was just brought it up I figure > I should mention it. IMO, there is actually a pretty annoying > compatibility problem with this behavior. On windows, you cannot use > std::messages<>::get() as you would on non-windows platforms because the > set number is ignored on windows. > > You can see evidence of this issue in the tests [22.locale.messages.cpp > and 22.locale.messages.mt.cpp]. Those tests create a message catalog > with 5 sets of 5 messages. On a non-windows system, msgs.get (cat, 5, 5, > "") returns the fifth message in the fifth set, but on windows systems > it returns the fifth message in the _first_ set. The tests skirt around > this issue with a function named msg_id(). It takes a set number and a > message number and returns the actual message number using the scheme > mentioned above. > > If there is only one message set in the catalog, there is no problem. > The other frustrating thing is that I wasn't able to find anything in > the documentation that mentioned this limitation, or the workaround. The > example sidesteps the issue in another way, by giving each message a > unique id. > > Is this wrong, or am I just misinformed or confused? I know little about how the messages facet behaves on Windows but simply ignoring the set number definitely seems wrong. It doesn't look like the standard actually requires us to use it but ignoring it makes the implementation of the facet pretty poor quality. Martin