I concur that the message facet is a low-level interface that is
unsuitable for using in C++ programs because an exception may be
thrown between open and close.  What is the higher-level interface
recommended for using?  I think such an interface should be in the
standard and ready to use.  Neither STLSoft nor Boost seem to contain
anything relevant, although I am not an expert at either.

Christopher Yeleighton

U   ytkownik "Nathan Myers" <n...@nospam.cantrip.org> napisa    w
wiadomo   ci news:6jqfec$p63$1@shell7.ba.best.com...
>
> It [the catalog type] needs to be a type that users can handle, because they can
> derive from std::messages<> and they need something they can
> return.  Thus, an opaque type like FILE would be unsuitable,
> because only standard functions can make them.
>
> "int" was minimal, and sufficient.  Admittedly it's not as type-safe
> as it might have been; an enum specified to be "large enough" might
> have been better.  However, the messages<> facet (like all the
> standard facets) is low-level, intended to support a higher-level
> interface.  I would not expect the catalog type to escape from
> such an interface, just as the file descriptor does not escape
> from a (standard-conforming) iostream interface.
>
> --
> Nathan Myers
> n...@nospam.cantrip.org  http://www.cantrip.org/
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]
>


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Valentin Bonnard <bonnardv@pratique.fr> wrote:
>I have one question about a particular facet, messages.
>
>In FDIS 22.2.7.1 [lib.locale.messages] I read:
>
>| typedef int catalog;
>
>It means that the catalog (the value which identify a set
>of messages) is an integer.
>
>Not only there is a risk to mix it with other unrelated
>integers in an expression, but it also restricts the
>implementor freedom.
>
>It's like the C FILE* vs the Un*x int file_descriptor; the
>FILE solution is more flexible (for the implementor). So
>my question is: why can't it be a class type ?

It needs to be a type that users can handle, because they can
derive from std::messages<> and they need something they can
return.  Thus, an opaque type like FILE would be unsuitable,
because only standard functions can make them.

"int" was minimal, and sufficient.  Admittedly it's not as type-safe
as it might have been; an enum specified to be "large enough" might
have been better.  However, the messages<> facet (like all the
standard facets) is low-level, intended to support a higher-level
interface.  I would not expect the catalog type to escape from
such an interface, just as the file descriptor does not escape
from a (standard-conforming) iostream interface.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

First, let me say that the localization library is great;
I have one question about a particular facet, messages.

In FDIS 22.2.7.1 [lib.locale.messages] I read:

| typedef int catalog;

It means that the catalog (the value which identify a set
of messages) is an integer.

Not only there is a risk to mix it with other unrelated
integers in an expression, but it also restricts the
implementor freedom.

This is especially surprising with all the typedefs to
implementation defined types in the iostream library (like
for ex. streamoff).

It's like the C FILE* vs the Un*x int file_descriptor; the
FILE solution is more flexible (for the implementor). So
my question is: why can't it be a class type ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]