In article h08@everest.XAIT.Xerox.COM, alex@Redwood.XAIT.Xerox.COM (Alexis Layton) writes:
>
>If it is the case that C defines ``wchar_t'' as a typedef for an existing integral
>type, and C++ wants to preserve compatibility with the C standard and with the
>requirement that C++ users need to overload on wchar_t, then it seems to me
>the proposal to create a new type ``long char'' and typedef it to ``wchar_t''
>is MORE similar to the C standard than the proposal in the draft standard WP
>whereby ``wchar_t'' is a unique type onto itself.

Well, yes, and my original question remains: Why does anyone care? The usual
complaints come down to:
1. wchar_t is too ugly a name
2. introducing a new reserved word might break programs

It seems to me that if wchar_t is so ugly, no one is using it in programs
as other than the C typedef, so no otherwise valid programs will be broken.

And why is it an advantage to introduce yet another built-in type which
merely duplicates the functionality of an existing type name?

Can we have a count of the number of programs that have been broken by
changing wchar_t to a reserved word? Are there any?

If there is some important reason to introduce a new intrinsic type
and preserve wchar_t as only a typedef, that can be done. We are now in
the public comment period. If you feel strongly about this, submit a
comment to ANSI with persuasive reasons why wchar_t should be changed.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article apj@hpsystem1.informatik.tu-muenchen.de, schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:
>
>In article <3q4v9c$70h@rover.village.org>, imp@village.org (Warner Losh) writes:
>[..]
>|> wchar_t springs to mind.
>
>A propos: There once has been the call to name it "long char".
>Did this idea make it to the committee? Why was it rejected?
>
>I still see the three pros:
>- *_t usually are typedefed names
>  (for compatibility we could have "typedef long char  wchar_t" in types.h).
>- long char avoids the introduction of a new keyword
>- and most important: wchar_t is so uggly ;-)

This is one of those historical warts that, I am afraid, will not be changed
any time soon (if ever).

Going back in time, the C Committee decided to make the wide character
type a typedef rather than a built-in type.  The reason was that wchar_t
in C was not intended to be a *distinct* type, but merely a synonym for
one of the existing integral types.  Given that it was merely a synonym,
the Committee saw no point in introducing a new *language* type: a typedef
was sufficient.

Now, this was clearly *insufficient* for C++, because a C++ user would
want the ability to overload on wchar_t, which you could not do if wchar_t
was merely a synonym for one of the other existing types.  So, the C++
Committee made wchar_t a built-in type.  In some ways, this is a wart,
since things ending in '*_t' LOOK LIKE typedefs.  However, it has long
been the policy of C++ to avoid gratuitous incompatibilities with C, and
so it made sense simply to make wchar_t a built-in type and be done with
it.

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com The opinions I express are no one's but mine!

shepherd@debussy.sbi.com writes:
>Going back in time, the C Committee decided to make the wide character
>type a typedef rather than a built-in type.  The reason was that wchar_t
>in C was not intended to be a *distinct* type, but merely a synonym for
>one of the existing integral types.  Given that it was merely a synonym,
>the Committee saw no point in introducing a new *language* type: a typedef
>was sufficient.
>
>Now, this was clearly *insufficient* for C++, because a C++ user would
>want the ability to overload on wchar_t, which you could not do if wchar_t
>was merely a synonym for one of the other existing types.  So, the C++
>Committee made wchar_t a built-in type.

This was, unfortunately, not the best solution.  The C++ committee could
have specified that wide characters have the type "long char", and that,
for C compatibility, the wchar_t typedef would be defined to "long char"
for C++ programs.  No gratuitous incompatibility with C would be
introduced.  The types of all wide characters would still be wchar_t, and
no portable ANSI C program would be able to tell the difference.  If
anything, compatibility with C would be smoother: wchar_t would always
be a typedef, rather than a builtin type in one case and a typedef in
the other case.  The C committee might even be persuaded to accept "long
char" in the future, since it would break nothing.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

If it is the case that C defines ``wchar_t'' as a typedef for an existing integral
type, and C++ wants to preserve compatibility with the C standard and with the
requirement that C++ users need to overload on wchar_t, then it seems to me
the proposal to create a new type ``long char'' and typedef it to ``wchar_t''
is MORE similar to the C standard than the proposal in the draft standard WP
whereby ``wchar_t'' is a unique type onto itself.

Just another $0.02.

--
Alexis Layton    XSoft Advanced Information Technology
alex@XAIT.Xerox.COM   Xerox Corporation
+1 617 499-4443    Four Cambridge Center
     Cambridge, MA  02142-1494

In article <3qd190$3lq@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
|> "wchar_t" is the name used in Standard C, so the C++ committee
|> used the same name. You would have to ask the C committee why they
|> chose wchar_t instead of long char, and why they chose to use a
|> typedef instead of a new built-in type.
|>
|> In C++ we had to make wchar_t a built-in type to allow portable
|> overloading on wchar_t.

But if you establish a new built-in type called "long char", and typedef
wchar_t to it, you can *still* overload on wchar_t (aka on long char).

No existing code can be overloading on long char, since it doesn't exist,
so the effect is pretty much identical, except no new keyword is needed.

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

In article <3q4v9c$70h@rover.village.org>, imp@village.org (Warner Losh) writes:
[..]
|> wchar_t springs to mind.

A propos: There once has been the call to name it "long char".
Did this idea make it to the committee? Why was it rejected?

I still see the three pros:
- *_t usually are typedefed names
  (for compatibility we could have "typedef long char  wchar_t" in types.h).
- long char avoids the introduction of a new keyword
- and most important: wchar_t is so uggly ;-)


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
email: schuenem@informatik.tu-muenchen.de

schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:

>|> wchar_t springs to mind.

>A propos: There once has been the call to name it "long char".
>Did this idea make it to the committee? Why was it rejected?

"wchar_t" is the name used in Standard C, so the C++ committee
used the same name. You would have to ask the C committee why they
chose wchar_t instead of long char, and why they chose to use a
typedef instead of a new built-in type.

In C++ we had to make wchar_t a built-in type to allow portable
overloading on wchar_t.
--
Steve Clamage, stephen.clamage@eng.sun.com

In article <3qcjp9$apj@hpsystem1.informatik.tu-muenchen.de>
           schuenem@informatik.tu-muenchen.de "Ulf Schuenemann" writes:

>In article <3q4v9c$70h@rover.village.org>, imp@village.org (Warner Losh)
> writes:
>[..]
>|> wchar_t springs to mind.
>
>A propos: There once has been the call to name it "long char".
>Did this idea make it to the committee? Why was it rejected?

My proposal was circulated, but has not yet been voted on. So officially
it has not yet been rejected. I am resubmitting it for the next meeting,
which should see a resolution one way or t'other. I realise it's getting
late in theday for changes, but I would argue that this is a correction
not an extension :-)

>I still see the three pros:
>- *_t usually are typedefed names

_Usually_, but note that size_t and ptrdiff_t can legitimately be
implemented as macros according to ISO C. I was caught out by this in
the original wording for the proposal.

>  (for compatibility we could have "typedef long char  wchar_t" in types.h).

<types.h> is not part of any standard. The place to put this typedef is in
the same places that it is placed in the C standard.

>- long char avoids the introduction of a new keyword

Yes, that was part of the the motivation...

>- and most important: wchar_t is so uggly ;-)

... and that was most of the rest :-) Orthogonality and teachability were
two other guiding principles.

+-----------------------------+-------------------------------------+
| Kevlin A P Henney           | Can you secure Christmas with an    |
|   kevlin@spuddy.mew.co.uk   | approximation only eighteen million |
| Westinghouse Systems Ltd    | seconds left of the original old    |
|   kevlin@wslint.demon.co.uk | red chimney?         - Jack Kerouac |
+-----------------------------+-------------------------------------+

In article <3prf9j$dv0@giga.bga.com>, Jamshid Afshar <jamshid@ses.com> wrote:
>
>By choosing "bool" the committee has made matters no better for the
>C++ programmers who are already battling conflicting boolean type
>definitions, and as in your case they have made things a real mess for
>some people who were innocently and correctly using the identifier
>"bool".

The committee was aware of the use of "bool" in the curses library, but
not of any other common use of that identifier.  I would be grateful if
people could tell me about other widely used libraries that use "bool".

The committee deliberately decided to take the pain during a transition
period.  When things have settled down there will be one Boolean type
with a known name: bool.  That will make life easier.

     -- Dag Bruck

--
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden

In article <3q3ust$l03@nils.ideon.lth.se>,
Dag Bruck <dag@net.dynasim.se> wrote:
>The committee deliberately decided to take the pain during a transition
>period.  When things have settled down there will be one Boolean type
>with a known name: bool.  That will make life easier.

Why wasn't bool_t chosen?  Since most of the other types that have
been added to C and C++ end in _t, I kinda expected bool to as well.
wchar_t springs to mind.  Or is that reserved exclusively for things
that are typedef'd?

Warner
--
Warner Losh  "VMS Forever"  home: imp@village.org
Cyberspace Development, Inc   work: imp@marketplace.com
Makers of TIA, The Internet Adapter.  http://marketplace.com/