From a12b971e9b6b14c3ad29dbd4f5a70bf1fc35c4a2 Mon Sep 17 00:00:00 2001 From: bkoz Date: Tue, 5 Jan 2010 20:51:05 +0000 Subject: 2010-01-05 Benjamin Kosnik * doc/xml/manual/evolution.xml: Update for 4.4 and 4.5 releases. * doc/html: Regenerate. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@155661 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/doc/html/manual/messages.html | 62 +++++++++++++++--------------- 1 file changed, 31 insertions(+), 31 deletions(-) (limited to 'libstdc++-v3/doc/html/manual/messages.html') diff --git a/libstdc++-v3/doc/html/manual/messages.html b/libstdc++-v3/doc/html/manual/messages.html index e21adac3025..6646aecbd83 100644 --- a/libstdc++-v3/doc/html/manual/messages.html +++ b/libstdc++-v3/doc/html/manual/messages.html @@ -1,10 +1,10 @@ -messages
messages
Prev Chapter 15. Facets aka Categories Next

messages

+messages

messages
Prev Chapter 15. Facets aka Categories Next

messages

The std::messages facet implements message retrieval functionality equivalent to Java's java.text.MessageFormat .using either GNU gettext or IEEE 1003.1-200 functions. -

Requirements

+

Requirements

The std::messages facet is probably the most vaguely defined facet in the standard library. It's assumed that this facility was built into the standard library in order to convert string literals from one @@ -53,7 +53,7 @@ be found, returns dfault. -6- Effects: Releases unspecified resources associated with cat. -7- Notes: The limit on such resources, if any, is implementation-defined. -

Design

+

Design

A couple of notes on the standard.

First, why is messages_base::catalog specified as a typedef @@ -85,7 +85,7 @@ It is implicitly assumed that the locale for the default message string in 'get' is in the "C" locale. Thus, all source code is assumed to be written in English, so translations are always from "en_US" to other, explicitly named locales. -

Implementation

Models

+

Implementation

Models

This is a relatively simple class, on the face of it. The standard specifies very little in concrete terms, so generic implementations that are conforming yet do very little are the @@ -96,11 +96,11 @@ other, explicitly named locales.

Three different mechanisms have been provided, selectable via configure flags: -

  • +

    • generic

      This model does very little, and is what is used by default. -

    • +

    • gnu

      The gnu model is complete and fully tested. It's based on the @@ -110,7 +110,7 @@ other, explicitly named locales. relatively straight-forward process and is lightly documented below, and fully documented in gettext's distributed documentation. -

    • +

    • ieee_1003.1-200x

      This is a complete, though untested, implementation based on @@ -126,7 +126,7 @@ A new, standards-conformant non-virtual member function signature was added for 'open' so that a directory could be specified with a given message catalog. This simplifies calling conventions for the gnu model. -

    The GNU Model

    +

    The GNU Model

    The messages facet, because it is retrieving and converting between characters sets, depends on the ctype and perhaps the codecvt facet in a given locale. In addition, underlying "C" @@ -138,38 +138,38 @@ model. Making the message catalogs can be initially tricky, but become quite simple with practice. For complete info, see the gettext documentation. Here's an idea of what is required: -

    • +

      • Make a source file with the required string literals that need to be translated. See intl/string_literals.cc for an example. -

      • +

      • Make initial catalog (see "4 Making the PO Template File" from the gettext docs).

        xgettext --c++ --debug string_literals.cc -o libstdc++.pot -

      • Make language and country-specific locale catalogs.

        +

      • Make language and country-specific locale catalogs.

        cp libstdc++.pot fr_FR.po

        cp libstdc++.pot de_DE.po -

      • +

      • Edit localized catalogs in emacs so that strings are translated.

        emacs fr_FR.po -

      • Make the binary mo files.

        +

      • Make the binary mo files.

        msgfmt fr_FR.po -o fr_FR.mo

        msgfmt de_DE.po -o de_DE.mo -

      • Copy the binary files into the correct directory structure.

        +

      • Copy the binary files into the correct directory structure.

        cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++.mo

        cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++.mo -

      • Use the new message catalogs.

        +

      • Use the new message catalogs.

        locale loc_de("de_DE");

        use_facet<messages<char> >(loc_de).open("libstdc++", locale(), dir); -

    Use

    +

Use

A simple example using the GNU model of message conversion. 

 #include <iostream>
@@ -191,9 +191,9 @@ void test01()
   cout << "thank you in german:" << s02 << '\n';
   mssg_de.close(cat_de);
 }
-

Future

  • +

Future

  • Things that are sketchy, or remain unimplemented: -

    • +

      • _M_convert_from_char, _M_convert_to_char are in flux, depending on how the library ends up doing character set conversions. It might not be possible to do a real character @@ -201,13 +201,13 @@ void test01() parameter for messages is not enough to instantiate the codecvt facet (1 supplied, need at least 2 but would prefer 3). -

      • +

      • There are issues with gettext needing the global locale set to extract a message. This dependence on the global locale makes the current "gnu" model non MT-safe. Future versions of glibc, i.e. glibc 2.3.x will fix this, and the C++ library bits are already in place. -

    • +

  • Development versions of the GNU "C" library, glibc 2.3 will allow a more efficient, MT implementation of std::messages, and will allow the removal of the _M_name_messages data member. If this is @@ -216,7 +216,7 @@ void test01() version of the "C" library is released, the marked parts of the messages implementation can be switched over to the new "C" library functionality. -

  • +

  • At some point in the near future, std::numpunct will probably use std::messages facilities to implement truename/falsename correctly. This is currently not done, but entries in @@ -225,7 +225,7 @@ void test01() configure/make hassles to make the installed library search its own catalog. Currently the libstdc++.mo catalog is only searched for the testsuite cases involving messages members. -

  • The following member functions:

    +

  • The following member functions:

    catalog open(const basic_string<char>& __s, const locale& __loc) const @@ -241,38 +241,38 @@ void test01() model. As of this writing, it is unknown how to query to see if a specified message catalog exists using the gettext package. -

Bibliography

+

Bibliography

The GNU C Library . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling, and 7 Locales and Internationalization - .

+ .

Correspondence - . Ulrich Drepper. Copyright © 2002 .

+ . Ulrich Drepper. Copyright © 2002 .

ISO/IEC 14882:1998 Programming languages - C++ - . Copyright © 1998 ISO.

+ . Copyright © 1998 ISO.

ISO/IEC 9899:1999 Programming languages - C - . Copyright © 1999 ISO.

+ . Copyright © 1999 ISO.

System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) . Copyright © 1999 The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. - .

+ .

The C++ Programming Language, Special Edition . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. Addison Wesley - .

+ .

Standard C++ IOStreams and Locales . Advanced Programmer's Guide and Reference . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. Addison Wesley Longman - .

+ .

Java 2 Platform, Standard Edition, v 1.3.1 API Specification . java.util.Properties, java.text.MessageFormat, java.util.Locale, java.util.ResourceBundle. - .

+ .

GNU gettext tools, version 0.10.38, Native Language Support Library and Tools. . -- cgit v1.2.3