public inbox for
 help / color / mirror / Atom feed
From: "P.J. Plauger"  <>
Subject: wide streams in EC++
Date: Wed, 30 Sep 1998 09:56:00 -0000	[thread overview]
Message-ID: <> (raw)

Date: Sun, 27 Sep 1998 05:38:38 +0200
From: (Valentin Bonnard)
Subject: wide streams in EC++

>[pjp]  Bet you didn't know that a fully conforming Standard C++ Library defines
>*four* wide-stream objects in <iostream>,

Well, I know that, but I also know that you weren't talking to me.

[pjp]  I thought I was.

>along with the four better-known
>char-based stream objects. And given the bizarre initialization requirements
>for these eight objects, it's rather difficult to eliminate all code for these objects
>*even if they're not used in the program.*

Well, it's certainly possible for the compiler to deal with that but
I trust you that w/o any compiler support it might be quite difficult
for the library writer.

[pjp]  It is.

 Why didn't you relaxed the 'bizarre' initialisation rules instead
of removing wios and all (ok, I know, you didn't _removed_ anything,
you didn't made wios mandatory) ?

[pjp]  Because it wasn't for me to decide. I implemented a specification
worked out by the Embedded C++ Technical Committee, over many
months and after considerable thought. If it were left to each of us to
develop the subset we thought best, we would have mayhem, not a
coherent specification that appears to meet many needs.

It seems to me that:
- many (not all of course) embeded devices can be/are localised
- wchar_t makes it possible or at least easier to write portable
  localised applications

[pjp]  That may be, but people with more experience on this topic than
I decided to omit nearly all wchar_t support from the EC++ library.

P.J. Plauger

             reply	other threads:[~1998-09-30  9:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-09-30  9:56 P.J. Plauger [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-09-26 20:38 Valentin Bonnard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).