C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Wide character support for exceptions missing?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
Frank A. Uepping
Guest





PostPosted: Sat Apr 23, 2005 5:24 pm    Post subject: Wide character support for exceptions missing? Reply with quote



Hi,

C++ has wide character support. For example, for strings we can do
basic_string<wchar_t>.

But if we try to throw a standard exception with a wide string as
parameter we get an error, e.g.:
throw logic_error(basic_string<wchar_t>(L"foo"));

Unfortunately, the standard does not support wide characters for
standard exceptions (i.e., we can not do something like this:
throw logic_error<wchar_t>(basic_string<wchar_t>(L"foo"));

Why is this so designed, and how are standard exceptions usually
used in wide character applications?
Do we really need to convert wide strings to ASCII before usage
with standard exceptions?

Thanks
FAU

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Alf P. Steinbach
Guest





PostPosted: Sun Apr 24, 2005 9:23 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote



* Frank A. Uepping:
Quote:

Why is this so designed, and how are standard exceptions usually
used in wide character applications?
Do we really need to convert wide strings to ASCII before usage
with standard exceptions?

You shouldn't use the 'what' string to convey exception arguments. The
'what' string is a programmer/technician-readable general description,
preferably in English, the lingua franca (heh) of computer science, i.e.
no need for wide characters. Use a std::runtime_error subclass to add
further arguments.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Ivan Vecerina
Guest





PostPosted: Sun Apr 24, 2005 3:44 pm    Post subject: Re: Wide character support for exceptions missing? Reply with quote



"Alf P. Steinbach" <alfps (AT) start (DOT) no> wrote

Quote:
* Frank A. Uepping:
Why is this so designed, and how are standard exceptions usually
used in wide character applications?
Do we really need to convert wide strings to ASCII before usage
with standard exceptions?

You shouldn't use the 'what' string to convey exception arguments. The
'what' string is a programmer/technician-readable general description,
preferably in English, the lingua franca (heh) of computer science, i.e.
no need for wide characters. Use a std::runtime_error subclass to add
further arguments.

And/or use the string returned by what() to look-up a translated
wide-character string in a localization table.


Regards -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Alberto Barbati
Guest





PostPosted: Sun Apr 24, 2005 8:22 pm    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Frank A. Uepping wrote:
Quote:
Hi,

C++ has wide character support. For example, for strings we can do
basic_string<wchar_t>.

But if we try to throw a standard exception with a wide string as
parameter we get an error, e.g.:
throw logic_error(basic_string<wchar_t>(L"foo"));

Unfortunately, the standard does not support wide characters for
standard exceptions (i.e., we can not do something like this:
throw logic_error<wchar_t>(basic_string<wchar_t>(L"foo"));

Why is this so designed, and how are standard exceptions usually
used in wide character applications?
Do we really need to convert wide strings to ASCII before usage
with standard exceptions?


This question periodically re-appears on this NG. You may want to google
the archives for that. The most interesting point I captured from past
discussions is that it is usually a bad idea to have what() return the
final formatted message. One possibile approach is to make what()
returns a key (in string form) into some message catalog. With this
approach, the fact that what() is restricted to non-wide chars is no
impediment, as it's the message catalog that will contain messages in
wide-chars (or in whatever fancy encoding you need). This approach is
especially powerful in multilingual scenarios, as the code that throws
the exception will thus become language-independent. The selection of
the right language and the final formatting can easily be done at the
catch site (as opposed to the throw site) which is usually a better
place for that, for a lot of reasons.

Alberto

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Maxim Yegorushkin
Guest





PostPosted: Mon Apr 25, 2005 1:19 pm    Post subject: Re: Wide character support for exceptions missing? Reply with quote

On Mon, 25 Apr 2005 00:22:41 +0400, Alberto Barbati
<AlbertoBarbati (AT) libero (DOT) it> wrote:

[]

Quote:
This question periodically re-appears on this NG. You may want to google
the archives for that. The most interesting point I captured from past
discussions is that it is usually a bad idea to have what() return the
final formatted message. One possibile approach is to make what()
returns a key (in string form) into some message catalog. With this
approach, the fact that what() is restricted to non-wide chars is no
impediment, as it's the message catalog that will contain messages in
wide-chars (or in whatever fancy encoding you need). This approach is
especially powerful in multilingual scenarios, as the code that throws
the exception will thus become language-independent. The selection of
the right language and the final formatting can easily be done at the
catch site (as opposed to the throw site) which is usually a better
place for that, for a lot of reasons.

I'm pretty sure that was not the original intent of std::exception
designers. If it was they should have made what() return void*.

Also, GNU standard library implementation as well as Dinkum accept
std::string in std::exceptions constructors, which makes you do ugly
things like:

size_t const key = whatever;
throw std::runtime_error(std::string(reinterpret_cast<char const*>(&key),
sizeof(key)));

to throw the key. I don't think it's practical. It's much more easier and
nicer to derive your own exceptions from standard ones and make them do
whatever you need.

--
Maxim Yegorushkin

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Allan W
Guest





PostPosted: Tue Apr 26, 2005 8:56 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Quote:
Frank A. Uepping wrote:
Unfortunately, the standard does not support wide characters for
standard exceptions (i.e., we can not do something like this:
throw logic_error<wchar_t>(basic_string<wchar_t>(L"foo"));

Alberto Barbati wrote:
Quote:
This question periodically re-appears on this NG.

Yes. It should be an FAQ.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Alberto Barbati
Guest





PostPosted: Tue Apr 26, 2005 9:30 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Maxim Yegorushkin wrote:
Quote:
On Mon, 25 Apr 2005 00:22:41 +0400, Alberto Barbati
[email]AlbertoBarbati (AT) libero (DOT) it[/email]> wrote:

This question periodically re-appears on this NG. You may want to google
the archives for that. The most interesting point I captured from past
discussions is that it is usually a bad idea to have what() return the
final formatted message. One possibile approach is to make what()
returns a key (in string form) into some message catalog. With this
approach, the fact that what() is restricted to non-wide chars is no
impediment, as it's the message catalog that will contain messages in
wide-chars (or in whatever fancy encoding you need). This approach is
especially powerful in multilingual scenarios, as the code that throws
the exception will thus become language-independent. The selection of
the right language and the final formatting can easily be done at the
catch site (as opposed to the throw site) which is usually a better
place for that, for a lot of reasons.

I'm pretty sure that was not the original intent of std::exception
designers. If it was they should have made what() return void*.

??? Why void*?

Maybe I wasn't clear enough, a code snippet might help:

int foo()
{
throw std::runtime_error("not_implemented");
}

int main()
{
// maps char keys to wide-char messages
typedef std::map<std::string, std::wstring> catalog_type;

catalog_type catalog;

catalog["not_implemented"]
= L"A feature has not been implemented yet."; // wide-chars!

// other messages here

try
{
foo();
}
catch(const std::exception& e)
{
catalog_type::iterator msg = catalog.find(e.what());
if(msg != catalog.end())
std::wcout << msg->second << std::endl; // localized message
else
std::wcout << e.what()<< std::endl; // unlocalized fallback
}
}

This is a just an example, of course. You can extend it by using
multiple languages, parameter substitution, etc...

Anyway this is *one possibile approach*, that has been proposed. I never
said that this is the way standard exceptions are to be used!

Quote:

Also, GNU standard library implementation as well as Dinkum accept
std::string in std::exceptions constructors, which makes you do ugly
things like:

size_t const key = whatever;
throw std::runtime_error(std::string(reinterpret_cast sizeof(key)));

to throw the key. I don't think it's practical. It's much more easier and
nicer to derive your own exceptions from standard ones and make them do
whatever you need.


Sure you can do that, but why would you do it? I just said that one
possibile approach is to use the keys *in string form*, not integers. If
you want to use integer keys, then I agree you might be better off
designing you own class.

Alberto

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
kanze@gabi-soft.fr
Guest





PostPosted: Tue Apr 26, 2005 5:00 pm    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Maxim Yegorushkin wrote:
Quote:
On Mon, 25 Apr 2005 00:22:41 +0400, Alberto Barbati
[email]AlbertoBarbati (AT) libero (DOT) it[/email]> wrote:

[]

This question periodically re-appears on this NG. You may
want to google the archives for that. The most interesting
point I captured from past discussions is that it is usually
a bad idea to have what() return the final formatted
message. One possibile approach is to make what() returns a
key (in string form) into some message catalog. With this
approach, the fact that what() is restricted to non-wide
chars is no impediment, as it's the message catalog that
will contain messages in wide-chars (or in whatever fancy
encoding you need). This approach is especially powerful in
multilingual scenarios, as the code that throws the
exception will thus become language-independent. The
selection of the right language and the final formatting can
easily be done at the catch site (as opposed to the throw
site) which is usually a better place for that, for a lot of
reasons.

I'm pretty sure that was not the original intent of
std::exception designers. If it was they should have made
what() return void*.

It may or may not have been the original intent; it is definitly
the way to go in a large application today.

Quote:
Also, GNU standard library implementation as well as Dinkum
accept std::string in std::exceptions constructors,

As the standard requires.

Quote:
which makes you do ugly things like:

size_t const key = whatever;
throw std::runtime_error(std::string(reinterpret_cast<char
const*>(&key),
sizeof(key)));

What on earth? That looks like a pretty good way to get a core
dump, and nothing else.

The usual solution is to define a number of predefined strings
with the error codes. Error codes which are generally
mnemonically identifiable, sort of like symbol names.

Typically, at least on Unix systems, I expect that a two phased
lookup would be used -- the symbolic name is used to lookup a
default output string, which is then used as the key for gettext
to get the localized string.

Quote:
to throw the key. I don't think it's practical. It's much more
easier and nicer to derive your own exceptions from standard
ones and make them do whatever you need.

That's pretty much standard procedure as well. It's not usually
very logical to try and pass all of the error information in the
form of a string.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Maxim Yegorushkin
Guest





PostPosted: Tue Apr 26, 2005 5:05 pm    Post subject: Re: Wide character support for exceptions missing? Reply with quote

On Tue, 26 Apr 2005 13:30:01 +0400, Alberto Barbati
<AlbertoBarbati (AT) libero (DOT) it> wrote:

[]

Quote:
Also, GNU standard library implementation as well as Dinkum accept
std::string in std::exceptions constructors, which makes you do ugly
things like:

size_t const key = whatever;
throw std::runtime_error(std::string(reinterpret_cast<char
const*>(&key),
sizeof(key)));

to throw the key. I don't think it's practical. It's much more easier
and
nicer to derive your own exceptions from standard ones and make them do
whatever you need.


Sure you can do that, but why would you do it? I just said that one
possibile approach is to use the keys *in string form*, not integers. If
you want to use integer keys, then I agree you might be better off
designing you own class.

Sorry, that was just my misunderstanding based on that if you know the
keys at compile time you will probably not bother with using string keys
where an integer is just fine.

--
Maxim Yegorushkin

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Peter Dimov
Guest





PostPosted: Wed Apr 27, 2005 8:17 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Maxim Yegorushkin wrote:
Quote:
Sorry, that was just my misunderstanding based on that if you know the
keys at compile time you will probably not bother with using string
keys where an integer is just fine.

Integers are prone to collisions. It's much easier to use string keys with
library/module/logical unit prefixes (and they can be more descriptive).



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Kim, Seungtai
Guest





PostPosted: Thu Apr 28, 2005 1:06 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

"Peter Dimov"
Quote:
Integers are prone to collisions. It's much easier to use string keys with
library/module/logical unit prefixes (and they can be more descriptive).

I cannot understand why integers are more prone to collision than
the strings. If we just use allowable range of the integer format for
key value, I think that there is no problem. Could you explain more
why you thought on that?

And, in front of view for protecting system, the key should be secretive
rather than descriptive. So, I think that there are some trade off on what
sort of key is more suitable.

--
S Kim <stkim (AT) yujinrobot (DOT) com>



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Edmund McConnell
Guest





PostPosted: Thu Apr 28, 2005 1:07 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Quote:
On Tue, 26 Apr 2005 13:30:01 +0400, Alberto Barbati
[email]AlbertoBarbati (AT) libero (DOT) it[/email]> wrote:

[]

Also, GNU standard library implementation as well as Dinkum accept
std::string in std::exceptions constructors, which makes you do ugly
things like:

size_t const key = whatever;
throw std::runtime_error(std::string(reinterpret_cast<char
const*>(&key),
sizeof(key)));

to throw the key. I don't think it's practical. It's much more easier
and
nicer to derive your own exceptions from standard ones and make them do
whatever you need.


if you really want to include the string rather than some indirect reference,
you could use wcstombs()
i.e. Wide Char String To Multi Byte String to convert to an 8-bit string and
then pass that and convert
back using mbstowcs() at the catch site..

i believe both calls are in <cstdlib>.

regards,
ed.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Maxim Yegorushkin
Guest





PostPosted: Thu Apr 28, 2005 1:09 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

On Wed, 27 Apr 2005 12:17:36 +0400, Peter Dimov <pdimov (AT) gmail (DOT) com> wrote:

Quote:
Maxim Yegorushkin wrote:
Sorry, that was just my misunderstanding based on that if you know the
keys at compile time you will probably not bother with using string
keys where an integer is just fine.

Integers are prone to collisions. It's much easier to use string keys
with
library/module/logical unit prefixes (and they can be more descriptive).

String literals for that purpose are prone to runtime table misses. Choose
you poison.

--
Maxim Yegorushkin

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Maxim Yegorushkin
Guest





PostPosted: Fri Apr 29, 2005 1:45 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

On Thu, 28 Apr 2005 05:06:24 +0400, Kim, Seungtai <stkim (AT) yujinrobot (DOT) com>
wrote:

Quote:
"Peter Dimov"
Integers are prone to collisions. It's much easier to use string keys
with
library/module/logical unit prefixes (and they can be more descriptive).

I cannot understand why integers are more prone to collision than
the strings. If we just use allowable range of the integer format for
key value, I think that there is no problem.

Agreed. String literals are prone to typing errors, which no compiler
complains about. OTOH, one can have a message table in some format in a
file and use a generator program to build a corresponding header file with
#define's that map integer keys to preprocessor symbols or with a huge
enum if you like that does just that providing stronger type safety and
range checking at compile time.

--
Maxim Yegorushkin

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Peter Dimov
Guest





PostPosted: Fri Apr 29, 2005 8:22 am    Post subject: Re: Wide character support for exceptions missing? Reply with quote

Maxim Yegorushkin wrote:
Quote:
On Wed, 27 Apr 2005 12:17:36 +0400, Peter Dimov wrote:

Maxim Yegorushkin wrote:
Sorry, that was just my misunderstanding based on that if you know
the keys at compile time you will probably not bother with using
string keys where an integer is just fine.

Integers are prone to collisions. It's much easier to use string keys
with library/module/logical unit prefixes (and they can be more
descriptive).

String literals for that purpose are prone to runtime table misses.

I don't understand what you mean by that.



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.