Matthew Austern  <austern@research.att.com> wrote:
+
+ Suppose you write the following.  (Assuming you're on a system where
+ "es" and "de" are valid locale names.)
+
+   std::locale L1("es");
+   std::locale L2("de");
+   std::locale composite(L1, L2, std::locale::collate)
+   std::string s = composite.name();
+
+ The standard doesn't say what s should look like.  What it does say is
+ that s has to be a string such that std::locale(s) has the same
+ collate facet as the "es" locale, and the same ctype, monetary,
+ numeric, time, and messages facets as the "de" locale.

Right, that's how I started...


+ The C++ library implementor has to decide on some consistent format
+ for the names of composite locales.  (And note that the C library
+ is included in this.  std::setlocale has to use the same naming
+ convention as std::locale.)
+
+ On IRIX, s happens to be "/de/de/de/es/de/de".

...and this is good to know.  There've been two examples in this thread,
which give me a good idea of where we need to go.  Your response elsewhere in
this thread, regarding setlocale to merge names, was really helpful as well.

Thanks, all!

Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

When a locale is constructed from parts of two named locales, the standard
is clear on the point that the resulting locale has a name, cf [22.1.1]/8
and [22.1.1.2]/11,15.

But I can't find anything stating what that resulting name should be.  Given

    locale  newlocale (locale_A, locale_B, some_category);

does newlocale.name() == locale_A.name() or locale_B.name()?

I didn't see this mentioned in the current public library issues list.
What is the intention of the designers?


Much thanks,
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi,
Phil Edwards (pedwards@dmapub.dma.org) wrote:
: When a locale is constructed from parts of two named locales, the standard
: is clear on the point that the resulting locale has a name, cf [22.1.1]/8
: and [22.1.1.2]/11,15.

: But I can't find anything stating what that resulting name should be.

This is correct and intentional: Nothing is stated about how the name
is supposed to look like. I think it is not even implementation
specified, ie. the implementation does not have to choose how the name
looks like.  For my implementation this is one of the areas where I
don't have everything implementation but the naming conventions are
likely to be relatively simple:

- A named locale where all facets are drawn from one convention will
  just use the corresponding name, ie. something like "en_US" or
  "de_DE".  This is a likely string a user might try to use (even these
  names are not standardized).

- A named locale with facets drawn from different conventions will use
  a tuple with six entries, corresponding to the six named facets, eg.
  "en_US;de_DE;de_CH;en_UK;es_AR;de_DK". What this exactly means, ie.
  in which order the facet names are put into this name, is up to my
  implementation.

: Given

:     locale  newlocale (locale_A, locale_B, some_category);

: does newlocale.name() == locale_A.name() or locale_B.name()?

In general no: locales with the same name are supposed to be identical.
A combination of two locales thus cannot have the name of one of the
locales except, of course, the locales are identical. Ie.

  newlocale.name() == locale_A.name()
  || newlocale.name() == locale_B.name()

is true if and only if "locale_A.name() == locale_B.name()".

: I didn't see this mentioned in the current public library issues list.

It is not a defect: The names of locales are not defined in anyway
except that there is a locale with the name "C" which supports the
definitions of the traditional (ie. non-localized) C library.

: What is the intention of the designers?

Ask Nathan.
--
<mailto:dietmar_kuehl@yahoo.de>
<http://www.fmi.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dietmar Kuehl <dietmar_kuehl@yahoo.com> wrote:
+ Phil Edwards (pedwards@dmapub.dma.org) wrote:
+ : When a locale is constructed from parts of two named locales, the standard
+ : is clear on the point that the resulting locale has a name, cf [22.1.1]/8
+ : and [22.1.1.2]/11,15.
+
+ : But I can't find anything stating what that resulting name should be.
+
+ This is correct and intentional: Nothing is stated about how the name
+ is supposed to look like.

Crumbs, I was afraid of that.


+ I think it is not even implementation
+ specified, ie. the implementation does not have to choose how the name
+ looks like.

Interesting.  How is the name supposed to be set, then, if the implementation
isn't going to set it?  /Something/ has to decide; the presence of a name
is required under those conditions.


--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dietmar Kuehl <kuehl@ramsen.informatik.uni-konstanz.de> wrote in message news:8uf30u$2f9$1@news.BelWue.DE...

> It is not a defect: The names of locales are not defined in anyway
> except that there is a locale with the name "C" which supports the
> definitions of the traditional (ie. non-localized) C library.
>
> : What is the intention of the designers?
>
> Ask Nathan.

Well, the rules for locale name formation derive from Standard C.
The C++ Standard introduces the possibility of a ``nameless'' locale,
whose name is reported as "*". But any time you construct a locale
that can be named in C, it has a name in C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi,
Phil Edwards (pedwards@dmapub.dma.org) wrote:
: Dietmar Kuehl <dietmar_kuehl@yahoo.com> wrote:
: + I think it is not even implementation
: + specified, ie. the implementation does not have to choose how the name
: + looks like.

: Interesting.  How is the name supposed to be set, then, if the implementation
: isn't going to set it?  /Something/ has to decide; the presence of a name
: is required under those conditions.

Sorry for giving false information although I was thinking of the right
thing. I should have said this: The implementation is not restricted in
how the name looks like. It is free to choose whatever it consideres to
be suitable.

It is probably a good idea to use the same name as a corresponding
locale would have in the C library on the same platform (ie. in the
libstdc++-v3 implementation you might want to use the naming
conventions used by glibc).  However, I don't think that the
implementation is required to do so...

You might want to have a look at the SGI implementation of locales
which uses an abstraction of the underlying C locales library to
implement the C++ library: This is intended for better portability of
the C++ library to different C libraries. Of course, this is departing
somewhat from the [IMO severly flawed] idea of relying on glibc-2.* to
implement the C++ library but it might be worth looking into it...
--
<mailto:dietmar_kuehl@yahoo.de>
<http://www.fmi.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]