🚀 go-pugleaf

In article 100000@barney, mzhou01 <mzhou01@barney.poly.edu> writes:
>C++ standardization people,
>
>With all respect. I am not happy with the way the committe is 
>modifying the C++ language. I think you people are enlarging the language 
>by adding un-
>necessary keywords to it. For example the boolean type, true, false keywords. 
>I spoke to my university friends about this addendum and they feel the
>say way as I do. Why do we need in boolean type? If it was really
>necessary Dennis Ritchie would have put it in C in the place.

If classes were necessary, Ritchie would have put them into C. If
templates were necessary, ... and so on. That isn't much of an argument.
You can program in binary machine language, so even C isn't necessary.

In fact, the absence of a boolean type in C has been keenly felt and
remarked on by many writers about C. Its lack causes many programmers
to provide their own typedefs and #defines, all conflicting.

What do you do when two or more packages you want to use in the same
program all have conflicting typedefs or #defines? E.g.,
	typedef int bool;
	typedef short bool;
	typedef char bool;
	#define bool int;
	#define true 1
	#define false 0
	const int true = 1;
	const int false = 0;
	enum bool { false, true };
This is one reason why the boolean type was added to C++.

The other reason is that no user definition of a boolean type can
satisfy all the requirements to allow function overloading on a boolean
type. For example:
	f(bool b) { ... } //  when bool is not built in
	f(int b) { ... }
At this point, the code won't even compile if bool is a typedef for int.
Let's assume it is some other type.
	foo(int i)
	{
		bool b = i < 3;
		f(b); // calls f(bool)
		f( i < 3 ); // calls f(int) -- unexpected result
		...
	}

Only two real solutions are possible:
	1. Don't try to use a boolean type in C++, since it doesn't
		really exist, and the attempts to create a user-defined
		type cause more problems than they solve.
	2. Create a full-fledged boolean type built into the language.

Solution 1 was status quo, and was judged by a great many people to be
inadequate. Hence we adoped solution 2. (For most practical purposes,
putting a boolean type in the standard library instead would be equivalent.
It doesn't have any advantages over using keywords that I can see.)

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



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <Pine.SOL.3.91.951203010216.13007A-100000@barney> mzhou01 <mzhou01@barney.poly.edu> writes:

> I spoke to my university friends about this addendum and they feel the
> say way as I do. Why do we need in boolean type? If it was really
> necessary Dennis Ritchie would have put it in C in the place. He didn't  
> put it in because boolean can be easily create using the language itself, 
> ie: the #define or emum, and Stroustrup didn't added in his second editon.

It's true that C++ users can define a boolean type themselves; that's
not necessarily an argument against putting it in the language
standard, though.  C++ users can also define string classes
themselves, after all, and I hope none of us thinks that the standard
library would be better off without strings.

The argument for bool is a very pragmatic one: users and library
vendors were defining boolean types themselves, and they were all
doing it slightly differently.  When a feature is generally perceived
to be so useful that it's universally implemented, and when different
versions of the feature make interoperability a problem, then it ought
to be standardized.  This sort of thing is the whole reason we need a
standard in the first place.
-- 
  Matt Austern                             He showed his lower teeth.  "We 
  matt@physics.berkeley.edu                all have flaws," he said, "and 
  http://dogbert.lbl.gov/~matt             mine is being wicked."

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "m" == mzhou01  <mzhou01@barney.poly.edu> writes:
m> C++ standardization people,
m> With all respect. I am not happy with the way the committe is 
m> modifying the C++ language. I think you people are enlarging the language 
m> by adding un-
m> necessary keywords to it. For example the boolean type, true, false keywords. 
m> I spoke to my university friends about this addendum and they feel the
m> say way as I do. Why do we need in boolean type? If it was really

Some of my university friends don't :-P

m> necessary Dennis Ritchie would have put it in C in the place. He didn't  
m> put it in because boolean can be easily create using the language itself, 
m> ie: the #define or emum, and Stroustrup didn't added in his second editon.

You cannot expect Bjarne Stroustrup's book about the C++ language to
contain information about what was not yet part of the language when
he wrote the book. Read ``The Design and Evolution of C++'' for more
up-to-date information (and the whys of certain extensions); same
author.

m> I think your guys are forgetting what made the C language so popular. It 
m> is it's compactness, elegance and flexibility. I agree #define and emum 
m> are not type safe, but they again C/C++ aren't intended to be used by 
m> fools. Stop trying to add stuff to C++ to make it idiot-proof.

Note that C++ is not C. Also, number of keywords is not nearly a measure
of compactness, elegance or flexibility.

I've also heard many C programmers say that the one thing they like most
in C++ is type-safety. However, perhaps the two most compelling reasons
for built-in boolean types are:
	. it's standard: hopefully libraries needing some boolean type
	                 will easily be mixable in the future,
	. it's overloadable (so would a user-defined bool class or
	                     enum type, but that leads to strange
	                     contortions with built-in operators).

m> Basically I browsed the 57 C++ keywords web page and was disappointed. 
m> Well for those of you who has authority in setting the standard, keep in 
m> mind that C's success is due to its flexibility, compactness, and elegance. 
m> Let C inspire C++. Don't turn C++ back to Pascal or PL/I. 

I don't have that authority, but the number of keywords has never
been a problem to me.

m> Mike

m> P.S. Is Stroustrup on the stardardization team? Does he get the final
m>      say since it is his language?

Yes (team = ANSI X3J16 and ISO WG21). I don't think he gets the
`final say', but I'm quite sure his words are not taken lightly.

	Daveed



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <VANDEVOD.95Dec4121952@avs.cs.rpi.edu>,
   vandevod@cs.rpi.edu (David Vandevoorde) wrote:
>>>>>> "m" == mzhou01  <mzhou01@barney.poly.edu> writes:
>m> Basically I browsed the 57 C++ keywords web page and was disappointed. 
>
>the number of keywords has never been a problem to me.

Agreed, but in some places /naming consistency/ is still a big problem: e.g. 
for exception classes, the draft reads like a hodgepodge.  As a 
counterexample, I derive all my exception classes from ExBase (which is 
usually derived from the compiler's root exception class), and use consistent 
names that always start with "Ex"... simplicity itself, and you always know: 
a) which classes are exceptions; and b) what all the exception classes are 
('grep "class Ex" *.h' does it nicely).  Try that with the current draft... 
:-/

If this kind of consistency is going to make it into the standard, it's got to 
be done soon before we lose the window of opportunity simply because people 
start using the draft names and too much code would break.  In fact, we may 
already be past that point, but I'm hoping we're not.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                                       Connected Object Solutions
herbs@interlog.com                                     2228 Urwin, Suite 102
                                                  Oakville ON Canada L6L 2T2
http://www.interlog.com/~herbs/           (416) 618-0184  fax (905) 847-6019



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <49vplf$mvs@engnews2.Eng.Sun.COM>, clamage@Eng.sun.com (Steve Clamage) writes:

>The other reason is that no user definition of a boolean type can
>type. For example:

This is one of the biggest problems with C/C++.  Since typedef is
"transparent" you can't overload on it.  If C/C++ had a "type" which
is identical to "typedef" except that the type defined is opaque so
that overloading is possible then programming could be simplified in
many cases.  And would have made the bool type unnecessary because
it COULD have been defined in the language with that extension.

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

vandevod@cs.rpi.edu (David Vandevoorde) writes:

>m> P.S. Is Stroustrup on the stardardization team? Does he get the final
>m>      say since it is his language?

>Yes (team = ANSI X3J16 and ISO WG21). I don't think he gets the
>`final say', but I'm quite sure his words are not taken lightly.

Stroustrup is a member of the ANSI X3J16 committee. Because of who
he is and what he has done, and because he is smart and also a good guy,
his opinion carries considerable weight.

But he doesn't have veto power (nobody does), and he alone cannot
force an issue (nor can anyone else). He also doesn't always
get his way (nor does anyone else).

The joint committe works by consensus, and we try not to bring anything
to a vote unless it is clear that it has overwhelming support. Formal
votes are typically unanimous. A standard that doesn't have broad support
will be ignored. We want a standard that will be supported and used.
--
Steve Clamage, stephen.clamage@eng.sun.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Matt Austern (matt@cyclops5.berkeley.edu) wrote:

> The argument for bool is a very pragmatic one: users and library
> vendors were defining boolean types themselves, and they were all
> doing it slightly differently.

And worse, by doing this, you'd end up with collisions when you included
files from different packages together, so each library vendor would have
to cook up elaborate schemes to protect the various bool definitions from
each other (XtBool, SoBool, VkBool, etc. etc.)

This is the strongest argument for putting a universally used type into
the language itself..
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <Pine.SOL.3.91.951203010216.13007A-100000@barney> mzhou01 <mzhou01@barney.poly.edu> writes:

> With all respect. I am not happy with the way the committe is 
> modifying the C++ language. I think you people are enlarging the language 
> by adding un-
> necessary keywords to it. For example the boolean type, true, false keywords. 
> I spoke to my university friends about this addendum and they feel the
> say way as I do. Why do we need in boolean type? If it was really
> necessary Dennis Ritchie would have put it in C in the place. He didn't  
> put it in because boolean can be easily create using the language itself, 
> ie: the #define or emum, and Stroustrup didn't added in his second editon.

You are quite right: C does not need a built-in Boolean type.

But C++ does, mostly because of function overloading.  Function overloading
makes the types of expressions much more visible, because an expression with
an inappropriate type can cause the wrong function to be called.

So, in particular, if boolean were a library-defined class type, we might
be able to write

	void foo(int);
	void foo(bool);

but there would be no way to make foo(3<4) call foo(bool) instead of foo(int).

> P.S. Is Stroustrup on the stardardization team? Does he get the final
>      say since it is his language?

Stroustrup is on the committee.  He does not get final say,
nor does any other single individual.  People do listen to him, though.
-- 
				--Andrew Koenig
				  ark@research.att.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4a12d7$vps@mujibur.inmind.com> mfinney@inmind.com writes:

> This is one of the biggest problems with C/C++.  Since typedef is
> "transparent" you can't overload on it.  If C/C++ had a "type" which
> is identical to "typedef" except that the type defined is opaque so
> that overloading is possible then programming could be simplified in
> many cases.  And would have made the bool type unnecessary because
> it COULD have been defined in the language with that extension.

How would you arrange for the expression 3<4 to yield the right type?
-- 
				--Andrew Koenig
				  ark@research.att.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <DJAJ44.J5w@research.att.com>, ark@research.att.com (Andrew Koenig) writes:

>How would you arrange for the expression 3<4 to yield the right type?

   type unsigned char bool;

   inline bool operator<(int x, int y) {
      return bool(x < y); }

would probably do the trick.  Just because the definition of bool
is opaque for the purposes of typing, there shouldn't be any
problem casting a value to an opaque type because the compiler
could cast to the underlying type.  The only difference I see in
an opaque "type" vs transparent "typedef" is when matching
types.

Since I can overload on bool as defined above, I can define a
global operator (when necessary) to solve problems like this.
It should also be possible to solve the problem by...

   inline operator bool(int x) {return (bool)(unsigned char)x;}

Although this approach might be enhanced by something more
like...

   inline implicit operator bool(int x) {return (bool)(unsigned char)x;}

where the "implicit" keyword would put a user-defined type
conversion at the same level as that of the built-in type conversions.
Right now, when the user defines a type conversion it is really
a second class citizen compared to the "trivial" conversions and
the built-in conversions because of the rule that says only one
conversion can be applied.

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <MATT.95Dec13025435@Austern>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>In article <4alt1o$13a2@news.ccit.arizona.edu> jychen@aruba.ccit.arizona.edu (Joseph Y Chen) writes:
>
>> I have not objection to boolean type.  But those added key words like 
>> and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which 
>> has far too many key wods.  I agree that people using C/C++ aren't fools 
>> and they don't need those added key words.
>
>People using C++ aren't necessarily fools; also, though, they aren't
>necessarily Americans.  The alternative tokens (which aren't quite the
>same as keywords) were added to C++ because some C++ operators use
>characters that exist in ASCII but not in other national character
>sets.
>
>Alternative tokens, in other words, solve the same problem that
>trigraphs do.  Personally, though, I think that alternative 
>tokens are a much nicer solution.  I'd much rather read an 
>expression like "i < 0 or i >= n" than one like "i < 0 ??!??! i >= n".

I disagree.  In C++, already, identifiers are highly overloaded, since
there is nothing to distinguish typenames from variables (and, of
course, globals/locals/member variables aren't distinguished either).
Secondly, the C++ syntax is such that it is difficult to tell at first
glance the difference between an expression and a declaration,
especially since they can be freely intermixed.

something_or_other name = some < nasty_expression;
something_or_other_name = some < nasty_expression;

This is especially true when using templates, when the typename can be
rather complex itself.  In C++, it is important to have a style which
makes these things easy to pick out, or your code is hard to read.
Personally, I capitalize types, and tab declarations so they stand out:

SomethingOrOther 		name 		= some < nasty_expression;
something_or_other_name = some < nasty_expression;

Now back to the issue at hand.  Having lots of keywords makes this
problem even worse, unless you have an editor that can highlight them
automatically for you.  The are simply too hard to pick out by eye.
&& is much easier to see and recognize than 'and' is.

-- 
Tim Hollebeek      | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ.    | tim@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <4alt1o$13a2@news.ccit.arizona.edu>, jychen@aruba.ccit.arizona.edu (Joseph Y Chen) writes:
>I have not objection to boolean type.  But those added key words like 
>and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which 
>has far too many key wods.  I agree that people using C/C++ aren't fools 
>and they don't need those added key words.

I have defined "and", "or" and "not" in a project standard header
file for many years now.  I find the code is substantially more
readable than && || and ! and I don't consider myself a fool.  And I
would replace = by <- and == by = in a  heartbeat if the preprocessor
could handle it.  C/C++ has a lot of good features, but sometimes the
operators that were selected during language design are not exactly
the best in the world.

And, far more important than readablility at this level, is the problem
that C/C++ does not yet require Unicode support and so international
programs get really hairy if you have to use tri-graphs (or even the
new bi-graphs).

Michael Lee Finney


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Tim Hollebeek (tim@franck.Princeton.EDU) wrote:

    [Considering the new tokens "or", et al...]
|> Now back to the issue at hand.  Having lots of keywords makes this
|> problem even worse, unless you have an editor that can highlight them
|> automatically for you.  The are simply too hard to pick out by eye.
|> && is much easier to see and recognize than 'and' is.

But is ??!??! really more readable that or?  (I will admit that it is
easy to pick out:-).)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <...>, tim@franck.Princeton.EDU (Tim Hollebeek) wrote:

> In article <...>, Matt Austern <matt@physics.berkeley.edu> wrote:
...
> >Alternative tokens, in other words, solve the same problem that
> >trigraphs do.  Personally, though, I think that alternative 
> >tokens are a much nicer solution.  I'd much rather read an 
> >expression like "i < 0 or i >= n" than one like "i < 0 ??!??! i >= n".
> 
...
> Now back to the issue at hand.  Having lots of keywords makes this
> problem even worse, unless you have an editor that can highlight them
> automatically for you.  The are simply too hard to pick out by eye.
> && is much easier to see and recognize than 'and' is.

That's not the point. '&&' may be easier to pick out than 'and', and
'||' may easier to pick out than 'or' (although on a system with syntax
coloring, I would disagree with this), but if I am programming on a system
in which I _cannot_ _have_ '||', I would absolutely prefer 'or' over
'??!??!'. Trigraphs are simply abominable to read, IMHO.

Besides, having these keywords available to you does not force you
to use them. There's nothing wrong with establishing coding standards
which use an appropriate subset of the language. It's only when that
subset is chosen through fear and ignorance that you run into problems.

-- 
Scott Howlett, howlett@netcom.com
"Probably the earliest fly swatters were nothing more than some sort of 
striking surface attached to the end of a long stick."


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Tim Hollebeek (tim@franck.Princeton.EDU) wrote:
> Matt Austern <matt@physics.berkeley.edu> wrote:
> >
> >Alternative tokens, in other words, solve the same problem that
> >trigraphs do.  Personally, though, I think that alternative 
> >tokens are a much nicer solution.  I'd much rather read an 
> >expression like "i < 0 or i >= n" than one like "i < 0 ??!??! i >= n".
> 
> Now back to the issue at hand.  Having lots of keywords makes this
> problem even worse, unless you have an editor that can highlight them
> automatically for you.  The are simply too hard to pick out by eye.
> && is much easier to see and recognize than 'and' is.

I think you misssed Matt's point. He was not saying that 'or' was better
than '||'. We was saying that if you have a character set with no |
character, then 'or' is a far better alternative than the trigraphs ??!??!
If you've never seen trigraphs before, look them up. I think the ARM has a
list. They are truly ugly things.

-- 
[=======================================================================]
[ Kevin Lentin                   |      The Mighty Carlton Blues      | ]
[ K.Lentin@cs.monash.edu.au      |          1995 AFL Premiers         | ]
[ Macintrash: 'Just say NO!'     |CARLTON 21-15-141 d geelong 11-14-80| ]
[=======================================================================]


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

jychen@aruba.ccit.arizona.edu (Joseph Y Chen) wrote:

[ ... ] 
>I have not objection to boolean type.  But those added key words like 
>and, or, xor, etc,  just make C/C++ awful, reminding me of Basic which 
>has far too many key wods.  I agree that people using C/C++ aren't fools 
>and they don't need those added key words.

Rather than "fools", the keywords were added to help people whose
keyboards don't include all the punctuation to which those using English
are generally accustomed.  The previous attempt along this line was
trigraphs.  The real question is not whether:
	if (( x or y ) xor z)
is better than: 
	if ( (x || y) ^ z )
but whether it's better than: 
	if (( x ??!??! y ) ??' z )
which is how it comes out using trigraphs.  

I don't mean to insult anybody, but it's my opinion that anybody who
finds the trigraph version preferrable has serious mental problems.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "MA" == Matt Austern <matt@Austern.berkeley.edu> writes:

MA> People using C++ aren't necessarily fools; also, though, they aren't
MA> necessarily Americans.  The alternative tokens (which aren't quite the
MA> same as keywords) were added to C++ because some C++ operators use
MA> characters that exist in ASCII but not in other national character
MA> sets.

When the issue was raised in this forum two years ago, none of the
European contributers could think of any current software development
being done using the old national 7 bit character sets.

Everybody who needed national character support were using 8-bit
character sets (or better).  Has this changed meanwhile?


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
>When the issue was raised in this forum two years ago, none of the
>European contributers could think of any current software development
>being done using the old national 7 bit character sets.
>
>Everybody who needed national character support were using 8-bit
>character sets (or better).  Has this changed meanwhile?

My greatest problem is not to display the characters -- it's to type
them.  I have a so called national keyboard with funny extra
characters that are used in C and C++.  For example, | requires me to
press three keys simultaneously: Alt + Shift + <.  Some keys have 6
different symbols.

By the way, here is a quick test of character code compatibility.  If
the line below shows 4+4 letters, then 8-bit code works as advertised.

	edv| EDV\

The letters should be circle-a, umlaut-a, umlaut-o and umlaut-u; four
lower-case and four upper-case.

And if it doesn't work....

	The difference between theory and practice is greater
	in practice than in theory.

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                                URL:    http://www.dynasim.se



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]