From mfc@medoc.ec.bull.fr Mon Feb 18 18:44:37 1991 Received: from inria.inria.fr by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA05415; Mon, 18 Feb 91 18:44:37 +0100 Received: from bull.bull.fr by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA26897; Mon, 18 Feb 91 18:47:13 +0100 (MET) Received: from ecbull.ec.bull.fr by bull.bull.fr; Mon, 18 Feb 91 18:44:41 +0100 (MET) Received: from medoc by ecbull.ec.bull.fr; Mon, 18 Feb 91 18:44:23 +0100 (MET) Received: by medoc.ec.bull.fr; Mon, 18 Feb 91 18:47:10 +0100 (MET) From: mfc@medoc.ec.bull.fr (Matt.Caprile) Message-Id: <9102181747.AA20487@medoc.ec.bull.fr> Subject: Re: (i18n 73) Re: paper presented to WG11 (#20) To: i18n@dkuug.dk Date: Mon, 18 Feb 91 18:47:05 MET Reply-To: Return-Path: Organization: Bull S.A. (Echirolles) X-Mailer: ELM [version 2.3 PL8] X-Charset: ASCII X-Char-Esc: 29 I gess I missed some of the discussion, since I can't find the mail that Kim refers to. But (as usual) that won't stop me from making some comments. The mail in question is: * Subject: (i18n 73) Re: paper presented to WG11 (#20) * Date: 13 Feb 91 12:04:38 MET (Wed) * From: storm@texas.dk (Kim F. Storm) * Cc: i18n@dkuug.dk * * I agree with Keld that using the names in the charmap is an excellent * way to write portable strings (provided we can agree on the character * names to use in the charmap). * * The problem with introducing these general strings is how to merge * them into existing languages and utilities. Keld uses the example * * "sndag" * * which would need some currently unspecified functions to interpret * (e.g. for printing or pattern matching). * * Let us take this a step further and play with the idea of using the * following syntax in C: * * char *str = "s\ndag"; [...] * 3. Compile the \< token into an otherwise unused character * code and use that at run-time to trigger "on the fly" * substitution in all STANDARD routines operating on strings, * e.g. strcpy and printf. * * 4. Forget the whole thing, and write a complete new set of * functions to operate on "portable strings". * * as long as it works...), I would prefer solution #3. Any reason not to define the above ideas in the wchar_t functions that the ISO C working group is coming out with ? It seems that it would be rather trivial to "reserve" the escape mechanism to define the references to the symbolic names found in the charmap file. Then just define the strings as (wchar_t *) and specify that the compiler do whatever is necessary so that it will be interpreted at run-time, not at compile time. This has several advantages: 1- new feature is associated with new functions/data types. You don't have to worry about breaking existing programs. 2- Using the wchar_t type for what it was designed for : portable international applications, indepedant of encoded character set and the size of the representation of characters in the codeset. 3- This will encourage programmers to use these new functionalities, thus increasing the number of internationalised (or intl-able) applications. Am I missing something here ? It can't REALLY be that easy. matt. --------------------------------------------------------------------------- ---- Matt Caprile phone : +33 7639 7752 fax: +33 7639 7518 ---- ---- Matthew.Caprile@ec.bull.fr -or- m.caprile@xopen ----