I, David R Tribble, dumped on M$ by writing:
>> Leave it to Microsoft to come up with a different, and inherently
>> worse, solution.  ...

Scott Meyers wrote:
> I like dumping on Microsoft (or IBM or Sun or HP...) as much as
> anybody, because, well, because it's fun to pick on companies.
> However, I got the impression from Pietrek's article that Microsoft
> made its decision based on the kinds of technical considerations Steve
> described for Sun and you described for DEC.
>
> From Matt's article:
>   The second scenario for a 64-bit type model is ... leave the int as
>   32 bits while using 64 bits for longs and pointers.  This is the
>   model that 64-bit Unix implementations use.  For Unix, [this] is a
>   good choice from the portability perspective, since most Unix APIs
>   use int parameters, rather than longs.

Many of those 'int' parameters are cleverly disguised as typedefs
(such as 'size_t', 'time_t', and 'pid_t').

>   Windows, on the other hand, uses lots of types that ultimately
>   resolve down to a long, and hence would be 64 bits in this model.

Many of those 'long' parameters are cleverly disguised as typedefs
(such as 'WORD', 'DWORD', and 'LPARAM').  In fact, MOST of the Win32
API parameters are declared using typedef names; it's rare to see
a regular 'int' or 'char *' in <winbase.h>.

>   For this reason, a [64-bit long] Windows implementation would have
>   many of the same problems as the [64-bit int] model.

Of course, they could easily fix it by adding something like this to
their header files:
    #if _WIN_64BIT
    typedef int     DWORD;
    #else
    typedef long    DWORD;
    #endif

They seem to have a history of doing this to some extent already,
e.g., '#ifdef _X86_' and '#ifdef _M_ALPHA_'.

>   In addition,
>   code that currently gets away with assuming that ints and longs are
>   equivalent would break under [the 32-bit int, 64-bit long] model.

This is true in either world (where world #1 has sizeof(long) == 32
and world #2 has sizeof(long) == 64).  This kind of bad coding usually
shows up when porting to a different word-sized environment,
regardless of the O/S involved.

> Of course, it's possible that this seemingly-technical justification
> is a smokescreen crafted by Chris Carter and his X-File cronies to
> hide the REAL reason for doing things this way, but then again, maybe
> not.

Har har.  So what IS the real reason they can't change the typedef
for 'DWORD' so that it works in a 64-bit environment?  They've gone
to so much trouble to make the parameter and variable declarations
use those hideous typedef names (and pushing us to use them), why
don't they put them to good use now?

-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:
>
> David R Tribble wrote:
> > Leave it to Microsoft to come up with a different, and inherently
> > worse, solution.  I believe that they think of themselves as being
>
> I like dumping on Microsoft (or IBM or Sun or HP...) as much as anybody,
> because, well, because it's fun to pick on companies.  However, I got the
> impression from Pietrek's article that Microsoft made its decision based on
> the kinds of technical considerations Steve described for Sun and you
> described for DEC.  From Matt's article:
>
>   The second scenario for a 64-bit type model is ... leave the int as 32
>   bits while using 64 bits for longs and pointers.  This is the model that
>   64-bit Unix implementations use.  For Unix, [this] is a good choice from
>   the portability perspective, since most Unix APIs use int parameters,
>   rather than longs.
>
>   Windows, on the other hand, uses lots of types that ultimately resolve
>   down to a long, and hence would be 64 bits in this model.  For this

So change the typedefs when providing an implementation for such a
model.

>   reason, a [64-bit long] Windows implementation would have many of the
>   same probams as the [64-bit int] model.  In addition, code that currently
>   gets away with assuming that ints and longs are equivalent would break
>   under [the 32-bit int, 64-bit long] model.

Good - defective code should be caught as soon as possible. You can
combine the fixes with your Y2K fixes, if necessary.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Leave it to Microsoft to come up with a different, and inherently
> worse, solution.  I believe that they think of themselves as being

I like dumping on Microsoft (or IBM or Sun or HP...) as much as anybody,
because, well, because it's fun to pick on companies.  However, I got the
impression from Pietrek's article that Microsoft made its decision based on
the kinds of technical considerations Steve described for Sun and you
described for DEC.  From Matt's article:

  The second scenario for a 64-bit type model is ... leave the int as 32
  bits while using 64 bits for longs and pointers.  This is the model that
  64-bit Unix implementations use.  For Unix, [this] is a good choice from
  the portability perspective, since most Unix APIs use int parameters,
  rather than longs.

  Windows, on the other hand, uses lots of types that ultimately resolve
  down to a long, and hence would be 64 bits in this model.  For this
  reason, a [64-bit long] Windows implementation would have many of the
  same probams as the [64-bit int] model.  In addition, code that currently
  gets away with assuming that ints and longs are equivalent would break
  under [the 32-bit int, 64-bit long] model.

Of course, it's possible that this seemingly-technical justification is
a smokescreen crafted by Chris Carter and his X-File cronies to hide the
REAL reason for doing things this way, but then again, maybe not.

Scott

--
Scott Meyers, Ph.D.                  Voice: 503/638-6028
C++ Consulting and Training          Fax:   503/638-6614
Author of "Effective C++"            Email: smeyers@aristeia.com
  and "More Effective C++"           WWW:   http://www.aristeia.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers <smeyers@aristeia.com> writes:

>In the latest MSJ (July), Matt Pietrek explains why 64-bit Windows NT will
>use 64-bit pointers and 32-bit longs.  Believe it or not, it's not just to
>make life miserable for Unix developers :-)

I haven't seen the article, but we at Sun agonized for a long
time over the sizes of basic types in 64-bit Solaris (Sun's
version of Unix).

Pointers had to be 64 bits, since even 32-bit Solaris supports
64-bit file sizes, and files can be mapped into the memory space
of a program.  Beyond that, Sun makes desktop computers with more
than 4 Gb of main memory, and servers with much more than that.

Type int could (and should) remain at 32 bits. Sun C and C++
already had the common extension of type "long long" at
64 bits. Making it 128 bits was a possibility, but leaving
it at 64 bits would reduce program porting problems. It
also meant we didn't have to implement 128-bit arithmetic.

Type long was the problem child. On the one hand, gobs of
existing code (ours and customers') assumes that int and long
are the same size.  On the other hand, gobs of existing code
assumes that pointers and long are the same size. (On the
gripping hand, some code foolishly assumes that pointers and
int are the same size. Too bad.)

Add into the mix that 64-bit Solaris supports creating and
executing 32-bit programs directly, and we didn't want to force
programmers to customize application programs on the basis of
whether code would be compiled in 32-bit or 64-bit mode.

We came to the conclusion that it was better to break the
compatibility of int and long and allow a standard integer
type (instead of only a language extension) to be the same
size as pointers. Existing 32-bit programs will usually
continue to work if they assume int and long value ranges are
compatible. Programs that assume int and long use the same
amount of storage will break in 64-bit mode.

Evidently Microsoft evaluated their tradeoffs differently.

--
Steve Clamage, stephen.clamage@sun.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers <smeyers@aristeia.com> writes:
>> In the latest MSJ (July), Matt Pietrek explains why 64-bit Windows NT
>> will use 64-bit pointers and 32-bit longs.  Believe it or not, it's
>> not just to make life miserable for Unix developers :-)

Steve Clamage wrote:
> I haven't seen the article, but we at Sun agonized for a long
> time over the sizes of basic types in 64-bit Solaris (Sun's
> version of Unix).
> ...
> We came to the conclusion that it was better to break the
> compatibility of int and long and allow a standard integer
> type (instead of only a language extension) to be the same
> size as pointers. Existing 32-bit programs will usually
> continue to work if they assume int and long value ranges are
> compatible. Programs that assume int and long use the same
> amount of storage will break in 64-bit mode.

Digital did the same thing for their 64-bit Alpha CPU.  They
decided that 'int' would stay as 32 bits, and 'long' would be 64
bits wide.  (Pointers were 64 bits wide.)  They also did a few
things to make the transition of old code easier.

For instance,
    printf("%d %ld %p %d", 123L, 123, &x, &y)
produces the correct results even though the arguments are wrong
because all function arguments are pushed onto the stack as 64-bit
values.  So "%d" and "%ld" really mean the same thing, and int
args are silently promoted to long.

Another thing they did was to write-protect the entire lower 4GB
of virtual memory, so that if you convert an int into a pointer
you'll get an invalid address that would SEGV upon indirection.
When we updated our code to support the Alpha, we only had to fix
about 1% of our code (and that code was fishy to begin with),
leaving us with the impression that they did the Right Thing.

> Evidently Microsoft evaluated their tradeoffs differently.

Leave it to Microsoft to come up with a different, and inherently
worse, solution.  I believe that they think of themselves as being
so big and proud that they entirely ignore the technological
lessons learned by others.  Or maybe they're just bad engineers,
and still think that an 'int' ahould be 16 bits.  This is yet one
more example of the way Microsoft forces you to buy into their
world far more than you want to when you port to them - they
don't want you going back to Unix.

-- 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.ff8310778f1abb3989b36@news.rmi.net>, jcoffin@taeus.com
says...

[ sorry to follow up to my own post, but... ]

> Unless you're dealing with multiple inheritance, this doesn't really
> affect the pointer itself -- it only affects how you interpret what
> the pointer points AT.  You can always convert a pointer to a derived
> type to a pointer to its base type without problems.

Actually, "always" here may have been overstating things.  With
normal, public inheritance, you can assign a pointer to a derived
object to a pointer to the base object without a cast, which was the
case I was really trying to point out.

When/if you're dealing with private inheritance, you have to use a
cast, if memory serves (though I don't remember ever having done this
to test it.)

However, I doubt that this ever (or more than extremely rarely) has
anything to do with the sizes of the pointers involved -- mostly it's
done by the compiler to enforce the type system rather than having to
do with pointer sizes.  Even implementations that make all pointers
the same size, the compiler still won't let you assign a pointer to a
privately derived object to a pointer to base object without a cast.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
| No. Pointers are bigger than ints on a number of popular
| architectures, and are bigger than ints on all the 64-bit
| architectures I am familiar with. It is common for pointers
| to be the same size as longs, but the C and C++ standards
| do not require that any integer type be the same size as
| a pointer. Indeed, on the AS/400 architecture that is the
| case. AS/400 pointers are 48 bits, and it has no 48-bit
| integer type as far as I know.

In the latest MSJ (July), Matt Pietrek explains why 64-bit Windows NT will
use 64-bit pointers and 32-bit longs.  Believe it or not, it's not just to
make life miserable for Unix developers :-)

Scott

--
Scott Meyers, Ph.D.                  Voice: 503/638-6028
C++ Consulting and Training          Fax:   503/638-6614
Author of "Effective C++"            Email: smeyers@aristeia.com
  and "More Effective C++"           WWW:   http://www.aristeia.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn6oqcgp.lfi.sbnaran@bardeen.ceg.uiuc.edu>,
  sbnaran@uiuc.edu wrote:
> [X] Do all pointers have the same size?  This
> makes sense because a pointer of any type is
> just a memory addresss.

It makes sense, but it ain't neccesarily so.  For instance, on Intel 16-bit
platforms, the size of a pointer to a function can be different than the
size of a pointer to any data type, depending on the memory model used.
There are 4-6 different ways to compile a program (depending on which
vendor you use), and for at least 2 of them, the size of a pointer to any
function doesn't equal the size of a pointer to any data item.  I think
that every vendor I used made sizeof(void*) the larger of the two, but
I wouldn't swear to that anymore (it's been a while).

> [X] But what about inheritance where one pointer
> can really be two pointers?  For example, if
> class D derives from class B, the a pointer to
> a B can also possibly be a pointer to a D.

A pointer only points to one object at a time.  A B* either points to a B
object, or to a B sub-object of something derived from B.  If class D is
also in scope, and it's possible to convert from a B* back to a D*, then
the compiler will know how.  In any case, I __would__ expect a pointer to
a B to be the same size as a pointer to a D.

> [X] The business of casting is just a compile
> time check on the correctness of our code.
> Correct?
Not at all.  In fact, the best check you can make for type correctness is
to avoid casts like the plague.  If the expression
    ptr->func();
compiles correctly with no casts, then ptr must have been a pointer to a class
that has a member function named func.  If you have to put a cast in there,
or even if you don't need one but you're in the habit of doing so anyway,
then you stand a chance of introducing a brand new bug that the compiler
can't warn you about.  Even when done "correctly" this is bad style.

Casting can be used where you have more information than the compiler does.
For instance:
    struct B { };
    struct C { };
    struct D : public B { };
    int f(void*z,char t) {
        switch (t) {
        case 'B': {   // z is really a B*
            B*b = (B*)z;
            return b->foo();
        }
        case 'C': {   // z is really a C*
            C*c = (C*)z;
            return c->foo();
        }
        case 'D': {   // z is really a D*
            D*d = (D*)z;
            return d->foo();
        }
        default:
            return 0;
        }
    }
This is horrible, but legal, C++ code.  The function accepts a void*, which
can point to any data type in the whole system.  But the compiler can't know
what it really points to.  Here, the programmer calculates the real data
type, casts it to the correct pointer type, and uses it as needed.

There are much better ways to do this, however.  The best way is probably
with the use of function overloading.  If we can add class C to the class
heirarchy, we can use virtual functions.  If all else fails, we can use
Run-Time Type Checking and/or dynamic_cast<>.

> (2) Can we assume that sizeof(pointer)=sizeof(int)?
Absolutely not!  The two __ARE__ the same size on many platforms, but if
you're trying to be portable you must forget this now, and work to keep
forgetting it tomorrow.

Sometimes, forgetting something that happens to be true -- today -- can
be much harder than it sounds.  That's why the industry is having so much
trouble with the year 2000.  Programmers try to forget that all years are
between 1900 and 1999, inclusive, but if they forget for a moment, the
program still works.  For now.

All you can know about sizeof() is:
    sizeof(char) == 1
    sizeof(char) <= sizeof(short int) <= sizeof(int) <= sizeof(long int)
    sizeof(float) <= sizeof(double) <= sizeof(long double)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony Cook has already answered most of this; I'll just add a few more
points.

Siemel Naran wrote:
>
> (1)
>
> [X] Do all pointers have the same size?  This
> makes sense because a pointer of any type is
> just a memory addresss.

It need not be just a memory address. If an implementation chooses to
implement run-time array bounds checking, the necessary information may
be included in the pointer. There are also a lot of different virtual
memory schemes out there, some of which require complicated pointers.

> [X] But what about inheritance where one pointer
> can really be two pointers?  For example, if
> class D derives from class B, the a pointer to
> a B can also possibly be a pointer to a D.

It can be, but it needn't be. Casts within a class hierarchy can be
highly non-trivial.

> [X] The business of casting is just a compile
> time check on the correctness of our code.
> Correct?

No. Among other things, casting a pointer to a new type will generally
include changing its value, as needed, to match the alignment
restrictions of the new type.

> (2) Can we assume that sizeof(pointer)=sizeof(int)?

No. In fact, there is no guarantee than any integer type is large enough
to store a pointer; not even unsigned long.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn6oqcgp.lfi.sbnaran@bardeen.ceg.uiuc.edu>,
sbnaran@bardeen.ceg.uiuc.edu says...
> (1)
>
> [X] Do all pointers have the same size?  This
> makes sense because a pointer of any type is
> just a memory addresss.

No -- pointers to different things may have different sizes.  A
pointer to void is guaranteed to be able to hold a pointer to any
other object type, and you can convert it back to a pointer to the
object type without loss of information though.  (Here I'm using
"object" in the sense it's used in the C standard, not particularly
restricted to an instantiation of a class.)  However, this does NOT
apply to things like pointers to functions, especially pointers to
member functions, which are typically considerably different from
other pointers.

> [X] But what about inheritance where one pointer
> can really be two pointers?  For example, if
> class D derives from class B, the a pointer to
> a B can also possibly be a pointer to a D.

Unless you're dealing with multiple inheritance, this doesn't really
affect the pointer itself -- it only affects how you interpret what
the pointer points AT.  You can always convert a pointer to a derived
type to a pointer to its base type without problems.

> [X] The business of casting is just a compile
> time check on the correctness of our code.
> Correct?

Rather the opposite: as far as code correctness goes, a cast
_prevents_ the compiler from doing testing that it might otherwise do.
However, a cast can also involve the generation of code -- things like
casting from a floating point type to an integer type, or doing a
dynamic_cast are both likely to generate actual code.  In addition, a
cast may result in constructing an object of the specified type, via a
call to a constructor, which may involve more or less arbitrary
amounts of code.

> (2) Can we assume that sizeof(pointer)=sizeof(int)?

Not if you're at all interested in portability.  There are quite a few
environments in which this is not the case right now, and likely to be
more in the future.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

(1)

[X] Do all pointers have the same size?  This
makes sense because a pointer of any type is
just a memory addresss.

[X] But what about inheritance where one pointer
can really be two pointers?  For example, if
class D derives from class B, the a pointer to
a B can also possibly be a pointer to a D.

[X] The business of casting is just a compile
time check on the correctness of our code.
Correct?



(2) Can we assume that sizeof(pointer)=sizeof(int)?


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran (sbnaran@bardeen.ceg.uiuc.edu) wrote:
: (1)

: [X] Do all pointers have the same size?  This
: makes sense because a pointer of any type is
: just a memory addresss.

No, for example on a word addressed machine a pointer to an integer
may be maller than a pointer to a char, since the pointer to the char
may need to store extra information.

: [X] But what about inheritance where one pointer
: can really be two pointers?  For example, if
: class D derives from class B, the a pointer to
: a B can also possibly be a pointer to a D.

All pointers to class types are required to be the same size.

: [X] The business of casting is just a compile
: time check on the correctness of our code.
: Correct?

No.  In the case of derived classes there may be some adjustments,
which probably requires a runtime check against the null pointer.

: (2) Can we assume that sizeof(pointer)=sizeof(int)?

No. eg. 8086 large model usually has a 16-bit int and 32-bit
pointers.  AFAIK, there's no requirement that there is an integer type
available that a pointer will fit into.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:

>(1)
>[X] Do all pointers have the same size?  This
>makes sense because a pointer of any type is
>just a memory addresss.

No, pointers are not required all to have the same size.
It is common to find that pointers all have the same
size, but there is no such requirement in the C or C++
language defintion. It is required that void* and char*
be compatible, and it is pretty much necessary that a
pointer to any kind of struct be the same size as a
pointer to any other kind of struct.

Don't fall into the trap of "just a memory address". That
is mixing levels of abstraction. A pointer in C++ is a
programming-language construct that allows you to refer to
an object or function. A memory address is an implementation
detail. A C++ pointer might be more or less than just a
memory address. In addition, a pointer-to-member is in fact
a structured type which is completely incompatible with any
other kind of pointer or integer. You can't even cast a
pointer-to-member to an ordinary pointer or integer type.

>[X] But what about inheritance where one pointer
>can really be two pointers?  For example, if
>class D derives from class B, the a pointer to
>a B can also possibly be a pointer to a D.

I believe it is necessary for pointers to classes related
by inheritance all to have the same size. Since any two
classes might be related by inheritance someplace in
the program, I don't think an implementation could
reasonably wind up with class pointers of different
sizes. Pointer to non-class types might well have
different sizes.

I'm excluding architecture-specific features like "near"
and "far" pointers on Intel x86 architectures. They
represent an extension of the type system, and are not
covered by the C++ standard.

>[X] The business of casting is just a compile
>time check on the correctness of our code.
>Correct?

No. A cast is a way to get around type checking, or to
lie to the compiler. Any program using a cast must be
presumed to be unsafe, since all safe type conversions
(and some unsafe ones) are allowed without writing a cast.
An exception is the dynamic_cast, which is either known
to be safe at compile time or is checked at run time.


>(2) Can we assume that sizeof(pointer)=sizeof(int)?

No. Pointers are bigger than ints on a number of popular
architectures, and are bigger than ints on all the 64-bit
architectures I am familiar with. It is common for pointers
to be the same size as longs, but the C and C++ standards
do not require that any integer type be the same size as
a pointer. Indeed, on the AS/400 architecture that is the
case. AS/400 pointers are 48 bits, and it has no 48-bit
integer type as far as I know.

--
Steve Clamage, stephen.clamage@sun.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]