[lib.locale]:

1 Class locale implements a type-safe polymorphic set of facets, indexed
  by facet type.  In other words, a facet has a dual role: in one sense,
  it's just a class interface; at the same time, it's an  index  into  a
  locale's set of facets.

My question is: As it seems, the locale facility implements a kind of
type-safe polymorphic container class. Why was it decided to
specifically craft this to the use with locales, why wasn't the
container specified separately as a genuine generic container (like
vector<> is), and then specify the locale facility in terms of that
container? I would think a generic polymorphic type-safe set is a great
utility. The way it's done currently prevents me from using it as a
generic container component. Specifically, there are definitions for
locale categories, convenience interface(s) (operator()), name() and
locale static members that are of no use with a generic container.  If
these were separated from the locale class (and the class should be
renamed), I'd think it could be used as a generic polymorphic set.

My point: To me it seems [lib.locale] and [lib.locale.facet] through to
[lib.locale.operators], if (the class were) renamed, would better belong
to the container section of the draft. Is there some reason this wasn't
done?
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi
Pulkkinen Esa (esap@cs.tut.fi) wrote:
: 1 Class locale implements a type-safe polymorphic set of facets, indexed
:   by facet type.  In other words, a facet has a dual role: in one sense,
:   it's just a class interface; at the same time, it's an  index  into  a
:   locale's set of facets.

: My point: To me it seems [lib.locale] and [lib.locale.facet] through to
: [lib.locale.operators], if (the class were) renamed, would better belong
: to the container section of the draft. Is there some reason this wasn't
: done?

Actually, 'locale' is, in its role as "polymorphic container", not much
more than a 'map<int,facet*>' (or something similar; the exact
representation depends, of course, on the design decisions of the
implementor, the declaration of the 'id' member, etc.): The whole trick
about typesafety lays in the implementation of 'use_facet' which can
basically look something like this:

  template <class Facet>
  Facet &use_facet(locale const &loc)
  {
    return dynamic_cast<Facet&>(*loc.facets[Facet::id]);
  }

That's it. Together with the definition of 'locale' which has to
contain a member 'facets' which maps an 'id' to a 'facet*' this is not
that much to implement. However, there are two severe constraints on
the types whose objects are stored in the 'locale':

- there has to be a static member called 'id' of type 'locale::id'
  which has to be publically accessible
- the class has to be derived from 'locale::facet'

While the former may be acceptable, the latter is definitely not
acceptable for a general polymorphic type: Whatever class is choosen as
base class, it would imply some limitations. Of course, the type of the
id and the type of the base class could be made template arguments of
the general polymorphic container (I don't think that the name 'id' or
whatever could be made to be parameterized) but I think this would
increase the complexity of the description severely. Since it is
reasonably easy to implement a specialized polymorphic container
similar to 'locale', I don't think that it would be worth adding such a
container to the standard.

Also note, that the class 'locale' is designed for some specific
operations which are hardly desired in a general purpose container:
'locale's are immutable after they are constructed. There are neither
members to add new facets nor are there members to remove them. To
generate a 'locale' different from a given 'locale' in some respect,
you use this 'locale' and add/replace specific facets. Thus, defining a
reasonable generally useful interface would potentially be a though
quest.

Finally, there is another thing worth noting: Currently, I haven't seen
a compiler allowing a [complete] standard conformant implementation of
the locale stuff! The problem is basically the implementation of
'use_facet': I don't know whether there is a compiler which allows
providing the template arguments to function explicitly, like in

  template <class T> T f() { return T(); }
  int main() { f<int>(); return 0; }

At least, I haven't seen such a compiler yet. Thus, there is
[potentially] no way to test the definition of the general polymorphic
container... (well, OK, it would be possible to use the same
work-arounds like for locales).
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]