David R Tribble wrote:
>
> Thomas A. Horsley <Tom.Horsley@worldnet.att.net> wrote:
> > ...  I only declare the member variable in
> > one place - why do I have to initialize it in every $#@!  constructor when I
> > just want it to be initialized to zero in all (or most) of 'em anyway?
> >
> > Has the standard committee considered any kind of new syntax for something
> > like a "default initializer", so I can give a member an initial value in the
> > class declaration which will be used if I don't provide a different
> > initializer in the constructor?
>
> I'm still of the opinion that member variables ought to be initialized
> to zero (0, 0.0, null) by default if they don't have explicit initializers
> in the class constructors.
>
> All the other object-oriented languages guarantee that every variable (and
> every reference) has a well-defined initial value, so why not C++?  How
> many times have people been bitten by uninitialized data?  When will the
> madness stop?

Not every other OOL I know of: Ada does not in any way innitialise
vars and Ada 95 is OO; in Ada it's even undefined behaviour to do
'x := x' or 'if x <> 0 then x := 0 endif' if x has not been explicitly
set to some value.

Also default innitialisations may not be OK for large arrays.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> David R Tribble wrote:
> > All the other object-oriented languages guarantee that every variable (and
> > every reference) has a well-defined initial value, so why not C++?  How
> > many times have people been bitten by uninitialized data?  When will the
> > madness stop?

Simple.  Performance.  If I have a 1 million element array that I
want to initialise to all ones, it could be very inefficient to
first initialise it to all zeros.

Furthermore, pointers within classes are usually assigned a non-
zero value, so zero assignment is almost always a waste of time.


--
___________________________________________________________________
Marcelo Cantos, Research Assistant
Multimedia Database Systems Group              Tel: +61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Australia   Fax: +61-3-9282-2490
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

After tracking down a bug, which for the 40 bazillionth time that turned out
to be a missing member variable initializer on 2 out of 3 constructors for a
class definition, it suddenly hit me: I only declare the member variable in
one place - why do I have to initialize it in every $#@!  constructor when I
just want it to be initialized to zero in all (or most) of 'em anyway?

Has the standard committee considered any kind of new syntax for something
like a "default initializer", so I can give a member an initial value in the
class declaration which will be used if I don't provide a different
initializer in the constructor?

This sure seems like it could eliminate one of the most common sources
of errors in C++ programming (and be *much* more useful than "const" :-).
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Thomas A. Horsley <Tom.Horsley@worldnet.att.net> wrote:
> ...  I only declare the member variable in
> one place - why do I have to initialize it in every $#@!  constructor when I
> just want it to be initialized to zero in all (or most) of 'em anyway?
>
> Has the standard committee considered any kind of new syntax for something
> like a "default initializer", so I can give a member an initial value in the
> class declaration which will be used if I don't provide a different
> initializer in the constructor?

I'm still of the opinion that member variables ought to be initialized
to zero (0, 0.0, null) by default if they don't have explicit initializers
in the class constructors.

All the other object-oriented languages guarantee that every variable (and
every reference) has a well-defined initial value, so why not C++?  How
many times have people been bitten by uninitialized data?  When will the
madness stop?

-- David R. Tribble, david.tribble@central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article fsf@worldnet.att.net, Tom.Horsley@worldnet.att.net (Thomas A. Horsley) writes:
>After tracking down a bug, which for the 40 bazillionth time that turned out
>to be a missing member variable initializer on 2 out of 3 constructors for a
>class definition, it suddenly hit me: I only declare the member variable in
>one place - why do I have to initialize it in every $#@!  constructor when I
>just want it to be initialized to zero in all (or most) of 'em anyway?
>
>Has the standard committee considered any kind of new syntax for something
>like a "default initializer", so I can give a member an initial value in the
>class declaration which will be used if I don't provide a different
>initializer in the constructor?

You don't need to ask for such a facility. It has always been the case
in C++ that if you don't provide a member-initializer in a constructor,
the data member gets its default initialization. For a class type,
the default initialization is the constructor that needs no arguments.
For simple types (int, pointer, etc) the default initialization is
no initialization, so you have to provide member initializers if you want
initialization to take place.

Maybe you would like all members of simple type to be automatically
initialized with zero, as is the case for static objects. That would require
every member of every object of every class in every program to pay the
price of initialization, even when it wasn't wanted. I don't think that
is likely to be adopted. (That would not necessarily be a bad language
design, but it doesn't fit with the C++ idea of not having to pay for
features you don't want.)

If you want something like "initialize any uninitialized members in this
class with this value", I can't think of a way to specify the feature so
that it is generally useful. Don't forget you have to cover cases like
members which are themselves classes, and base classes at different
depths, and virtual base classes, and so on. I also don't see how to
specify something like that for any value other than zero, given that
a class often has members of radically different kinds of type.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Thomas A. Horsley wrote:
>
> After tracking down a bug, which for the 40 bazillionth time that turned out
> to be a missing member variable initializer on 2 out of 3 constructors for a
> class definition, it suddenly hit me: I only declare the member variable in
> one place - why do I have to initialize it in every $#@!  constructor when I
> just want it to be initialized to zero in all (or most) of 'em anyway?
>
> Has the standard committee considered any kind of new syntax for something
> like a "default initializer", so I can give a member an initial value in the
> class declaration which will be used if I don't provide a different
> initializer in the constructor?
>
> This sure seems like it could eliminate one of the most common sources
> of errors in C++ programming (and be *much* more useful than "const" :-).

Hmmm...

class HowToTreatThis
{
  int count(default 0); // possible syntax
  double* array(default 0);
public:
  HowToTreatThis() {} // use default values
  HowToTreatThis(const HowToTreatThis& c):
      array(new double[c.count])  // oops, no initializer for count!
    {
      for(int i=0; i<count; i++)
        array[i]=c.array[i];
    }
};

Now: What should the copy constructor do with the omitted count?
1. Copy from c (this is what seems reasonable)
2. Initialize with 0 (like the other constructors do)

1 would make the behaviour more complex (one particular constructor
is treated different), while 2 would easily lead to nasty bugs as
soon as someone gets used to omit initializers on constructors,
if he doesn't treat them differently from default (where "default"
in the case of copy means s.th. different in his mind).

Even worse:

class WhatNow
{
  int count(default 0);
  int* i(default 0);
public:
  WhatNow(const WhatNow& other, bool flat=false):
     // ... implementation, omitting count initializer
};

Now the same constructor can be used as copy constructor and as
two argument constructor. Should those cases be treated different
(you could split them up into two constructors)?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Thomas A. Horsley wrote:

> a bug, which for the 40 bazillionth time that turned out
> to be a missing member variable initializer...

The initialization of members with built-in types that are normally
uninitialized has bit me as well.  A simple mechanism would be a
compiler option to initialize all built-in-type local and/or class
variables to zero.  I don't think that you always want this on for
performance reasons.

Without changing the language, you can still accomplish what you want
through some class wrappers.  I've done this for "ORed flag" classes to
(a) always initialize them (b) disallow copying to incompatible
classes.  You can implement e.g. a SmartInt:

class SmartInt {
public:
   SmartInt(int v_ = 0) : v(v_) {}
   operator int() const { return v; }
   // other conversion operators (mostly unneeded).

   SmartInt& operator=(const SmartInt&rhs) { v=rhs.v; return this; }
   SmartInt& operator=(const int&rhs) { v=rhs; return this; }
   // other assignment operators...
private:
   int v;
};


This is not perfect -- you lose some implicit conversion that you get
with real 'int' and you cannot specify that conversion to 'int' takes
priority over conversion to other types.  Performance is usually no
problem, since all methods are inline and trivial.  You also need to
write various expression operators.  In general, it's a big pain in the
butt.  But I've found that in many cases it is better to have the
guarantee of initialization and deal with the other headaches.

john lilley
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>If you want something like "initialize any uninitialized members in this
>class with this value", I can't think of a way to specify the feature so
>that it is generally useful.

I don't have any problem imagining a generally useful mechanism: Basically
every class member currently has syntax exactly like any other variable
declaration in the language, but initial values are not allowed. I can
easily imagine allowing initial values to be specified for members in the
class declaration which would be used in place of the initializer you might
normally specify on a constructor, but only if that constructor didn't
specify an initial value for that member. If you don't specify a default
value, you get exactly what happens today.

>Don't forget you have to cover cases like members which are themselves
>classes, and base classes at different depths, and virtual base classes,
>and so on.

But these are all cases that work one way or another when you provide
initializers at the constructor. If it is possible to initialize them at the
constructor, it is possible to provide a default initializer in the class
definition which, in the most simplistic possible iplementation would simply
act as a macro string which gets literally copied to the constructor as the
initializer for that member if the constructor did not otherwise provide
one.

I'm not saying its the best possible implementation, but it is an example of
something other than "just use zero" which can be described in a sensible
way :-).
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Thomas A. Horsley (Tom.Horsley@worldnet.att.net) wrote:

: Has the standard committee considered any kind of new syntax for something
: like a "default initializer", so I can give a member an initial value in the
: class declaration which will be used if I don't provide a different
: initializer in the constructor?

They not only considered it, it's in the language.  For builtin types,
it's a no-op.  For classes, it's the default constructor.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>Without changing the language, you can still accomplish what you want
>through some class wrappers.

I kind'a like this example, but it could get tedious real fast :-).
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John Lilley <jlilley@empathy.com> writes:

|>  Thomas A. Horsley wrote:
|>
|>  > a bug, which for the 40 bazillionth time that turned out
|>  > to be a missing member variable initializer...
|>
|>  The initialization of members with built-in types that are normally
|>  uninitialized has bit me as well.  A simple mechanism would be a
|>  compiler option to initialize all built-in-type local and/or class
|>  variables to zero.  I don't think that you always want this on for
|>  performance reasons.

This is a legal implementation today.  The fact that most compilers
don't do it would seem to indicate that the demand for it is not very
high.  (Which is either a sign that people aren't being bitten by
uninitialized variables, or that they don't care about program quality.
Or both.)

|>  Without changing the language, you can still accomplish what you want
|>  through some class wrappers.  I've done this for "ORed flag" classes to
|>  (a) always initialize them (b) disallow copying to incompatible
|>  classes.  You can implement e.g. a SmartInt:
|>
|>  class SmartInt {
|>  public:
|>     SmartInt(int v_ = 0) : v(v_) {}
|>     operator int() const { return v; }
|>     // other conversion operators (mostly unneeded).
|>
|>     SmartInt& operator=(const SmartInt&rhs) { v=rhs.v; return this; }
|>     SmartInt& operator=(const int&rhs) { v=rhs; return this; }
|>     // other assignment operators...
|>  private:
|>     int v;
|>  };
|>
|>
|>  This is not perfect -- you lose some implicit conversion that you get
|>  with real 'int' and you cannot specify that conversion to 'int' takes
|>  priority over conversion to other types.  Performance is usually no
|>  problem, since all methods are inline and trivial.  You also need to
|>  write various expression operators.  In general, it's a big pain in the
|>  butt.  But I've found that in many cases it is better to have the
|>  guarantee of initialization and deal with the other headaches.

I rather suspect that performance could be a problem, at least when
returning such types from a function.  All of the compilers I know will
return an int in a register, and none will return even the most trivial
class type in a register.

My own experience, however, would suggest that uninitialized variables
are not really a big problem.  Generally, it's one of the things that
the code reviewers systematically check for (where is x initialized?,
and if it is not in the definition, are we sure that it is initialized
in all possible program paths).  It is also standard policy to verify
that all variables in the class appear in the initialization list in the
constructor, in order, and to verify that those that don't really are of
class type and have a default constructor.

Of course, everyone makes mistakes: I will forget to initialize a
variable, and the code reviewers will forget to check a variable.  The
probability that this occurs on the same variable, however, becomes
practically infintesimal even with just two reviewers.  In practice, the
only errors that seem to get through a serious code review are of the
"special case that nobody thought of" type; initialization is hardly a
"special case".

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jodle wrote:
>
> Thomas A. Horsley (Tom.Horsley@worldnet.att.net) wrote:
>
> : Has the standard committee considered any kind of new syntax for something
> : like a "default initializer", so I can give a member an initial value in
> : the class declaration which will be used if I don't provide a different
> : initializer in the constructor?
>
> They not only considered it, it's in the language.  For builtin types,
> it's a no-op.  For classes, it's the default constructor.

Are those guaranteed to set the values to zero, or to a value specified
in the class definition? That is what Thomas requested.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I think he's asking for something like the old g++ feature

struct A {
  int a = 2;
  A() { }         // a is initialized to 2
  A(int i): a(i) { }    // a is initialized to i
  A(long l) { a = l; }  // a is initialized to 2 and then assigned from l
};

I don't think people use this feature much, however.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>Now: What should the copy constructor do with the omitted count?

I'm not sure how those examples are relevant to default initializers. I
can screw things up exactly the same way with or without a default
initializer :-). The answer in my proposal is:

>2. Initialize with 0 (like the other constructors do)
...
>while 2 would easily lead to nasty bugs as soon as someone gets used to
>omit initializers on constructors

The problem is that initializers *already* get omitted quite frequently.
Just because it is possible to contrive an example in which the default
initializer doesn't help doesn't mean there aren't examples where it does
help.

Actually, as an alternate proposal, I'd be perfectly happy if the language
simply made it an error to provide a constructor which does not *explicitly*
initialize each member (as long as there was a way to say "this member is
explicitly NOT initialized"). But I bet such a change would upset a tad
more people that providing a default initializer would :-). (Hmmm... maybe
we can add a compiler option to do this...).
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

John Lilley wrote:
>
> Without changing the language, you can still accomplish what you want
> through some class wrappers.  I've done this for "ORed flag" classes to
> (a) always initialize them (b) disallow copying to incompatible
> classes.  You can implement e.g. a SmartInt:
>
> class SmartInt {
> public:
>    SmartInt(int v_ = 0) : v(v_) {}
>    operator int() const { return v; }
>    // other conversion operators (mostly unneeded).
>
>    SmartInt& operator=(const SmartInt&rhs) { v=rhs.v; return this; }
>    SmartInt& operator=(const int&rhs) { v=rhs; return this; }
>    // other assignment operators...
> private:
>    int v;
> };
>
> This is not perfect -- you lose some implicit conversion that you get
> with real 'int'

You wrote the operator int and the ctor !

So the std conversions are still legal, but htey rae now user defined
conversions so other user defined are not possible to have annother
user defined:

void foo (complex<float>);

SmartInt i = 4;
foo (i);

This won't work, but work fine with plain int.

In others contexts, it will work fine.

> and you cannot specify that conversion to 'int' takes
> priority over conversion to other types.

It does

> Performance is usually no
> problem, since all methods are inline and trivial.

It is: the compiler assume that a struct is never trivial,
and method are sometimes not inlined.

> You also need to
> write various expression operators.

Not all of them:

SmartInt b, c;
SmartInt a = b + c;

will work;

b += c;

won't

> In general, it's a big pain in the
> butt.  But I've found that in many cases it is better to have the
> guarantee of initialization and deal with the other headaches.

I think it's better to innitialise explicitly.

Does anyone knows a compiler/tool to catch uninitialised vars ?

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze (james-albert.kanze@vx.cit.alcatel.fr) wrote:

: This is a legal implementation today.  The fact that most compilers
: don't do it would seem to indicate that the demand for it is not very
: high.  (Which is either a sign that people aren't being bitten by
: uninitialized variables, or that they don't care about program quality.
: Or both.)

It would be easy enough for compilers to issue warnings about failure to
initialize members of builtin-type.  This involves compile-time overhead,
but no runtime overhead.  I fear that like many other warnings, many
programmers would simply inhibit or ignore them.  It's my experience that
forgetting to initialize members is usually the result of some combination
of big classes (lots of members) and lots of constructors.  Let me offer
my $0.02 solution (which the same programmers will never use because it's
just as hard as doing it right by hand.

template <class T>
class MustInit
  {
  T t;
  MustInit();
  public:
  MustInit( T aT ) : t(aT) {}
  operator T&() {return t;}
  };

class BadClass
  {
  MustInit<const char*> p;
  public:
  BadClass( ) {} //  Error : 'MustInit<const char *>::MustInit()'
                 //  is not accessible
  };

//  or

class BadClass
  {
  MustInit<const char*> p;
  public:
  BadClass( ) : p(0) {} //  A-Okay
  };



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Jason Merrill <jason@cygnus.com> writes:

>I think he's asking for something like the old g++ feature
>
>struct A {
>  int a = 2;
>  A() { }         // a is initialized to 2
>  A(int i): a(i) { }    // a is initialized to i
>  A(long l) { a = l; }  // a is initialized to 2 and then assigned from l
>};
>
>I don't think people use this feature much, however.

... probably because it's non-standard.

Catch 22, of course: it's not in the standard because no-one uses it,
and no-one uses it because it's not in the standard.

(Of course, there are good reasons for being conservative about
accepting extension proposals.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]