Attila Feher schrieb:
> Nice, nice... however if you try to call a virtual function of your NULL
> pointer you crash _before_ it could reach your code. :-(((  Meaning that
> this isn't a solution.

true.

>  What I would do is to create a handle class, which
> hides all the pointer issues.  A class, which makes sure it cannot be
> allocated dynamically

just out of curiosity: how would you ensure that?

>  as well as hides the pointer to the real
> implementation.  With this "trick" you get PIMPL "for free" and you can
> ensure that your fellow programmers will just be unable to dereference a
> NULL pointer.

it depends, but i doubt that it is worth the effort if you only
want to hide the pointers.  if the handler classes support the
full interface, then it's different.  i think rogue wave does it
this way with their libraries.  although i'm not sure about their
motivation, i think it is more the protection of intellectual
properties (you can get no idea about the implementation classes
because pointers are all void*).

regards

 robert

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <JGoXVoEILzC9EwMy@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>But that just detects one of many possible ways of having an invalid
>value for 'this' Why should it be worth fixing?

Because it's easy to detect, so why *not* fix it?

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen schrieb:
>
> Robert Klemme wrote:
> > Hyman Rosen schrieb:
> >>This can not be null; for it to be so, code must dereference
> >>a null pointer, which causes undefined behavior.
> > is that so?  a non virtual method that does not do any member
> > access does not need this at all, i think.
>
> I meant in a formal sense, not in an implementation sense.

ok, understand and agree.  the semantics of a member method
executing for no (i.e. NULL) object is at least doubtful.  maybe
compilers should prevent this altogether, but i guess they did
not bother to check this because of performance reasons.  the
case does not seem to be very common.

regards

 robert

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Evensen" <thenospam@esolutions.no> wrote:

> Hello, we are experimenting a little on safe handling of null pointers.
>
> We have tested, and succeded, on adding a small handler checking if the
> "this" pointer is null. The beneath examples seem to be working.
[SNIP]

Nice, nice... however if you try to call a virtual function of your NULL
pointer you crash _before_ it could reach your code. :-(((  Meaning that
this isn't a solution.  What I would do is to create a handle class, which
hides all the pointer issues.  A class, which makes sure it cannot be
allocated dynamically as well as hides the pointer to the real
implementation.  With this "trick" you get PIMPL "for free" and you can
ensure that your fellow programmers will just be unable to dereference a
NULL pointer.

A


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <GzqO8.8561$Dn3.50610@dfw-read.news.verio.net>, Jonathan H
Lundquist <jhl@sssonline.com> writes
>While I agree that if 'this' is null you are already in the land of
>undefined behavior, but that doesn't change that fact that 'this' can in
>fact, in real life, be null; at least with the compiler I use.  All you have
>to do is invoke a member function through a null pointer, and you get a null
>'this'.  Therefore, I think it's perfectly reasonable in a debug build to
>assert 'this' != null.  Better to have detected undefined behavior than
>undetected undefined behavior.

But that just detects one of many possible ways of having an invalid
value for 'this' Why should it be worth fixing?

mytype mt_ptr = new mytype;
delete mt_ptr;
mt_ptr -> somemember();


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Robert Klemme wrote:
> Hyman Rosen schrieb:
>>This can not be null; for it to be so, code must dereference
>>a null pointer, which causes undefined behavior.
> is that so?  a non virtual method that does not do any member
> access does not need this at all, i think.

I meant in a formal sense, not in an implementation sense.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello, we are experimenting a little on safe handling of null pointers.

We have tested, and succeded, on adding a small handler checking if the
"this" pointer is null. The beneath examples seem to be working.

The question is whether it is defined behaviour to check the "this" pointer
inside a class represented by a null pointer or not. In what cases wouldn't
/ shouldn't it be working?

The "this" pointer should work as a reference to where the object is
located, and not a member, and should therefore be acceptable for this use.

Also any created objects or variables inside a method are created wither on
the stack or the heap, therefore this should not create any problems either.

See the following example for some ideas.



#include <iostream>
using namespace std;

class NullPtr {
public:
    void foo()
    {
        if (!this)
                        throw "hello stupid, you are accessing me as a null
pointer";
    }

    bool nullPtr()
    {
                return (this == 0);
        }

};

int main()
{
        try
        {
                NullPtr *p = 0;
//              p = new NullPtr;
                if (p->nullPtr())
                        cout << "object was null" << endl;

                p->foo();
                cout << "foo was OK" << endl;
        }
        catch (const char *sz)
        {
                cout << "caught exception: " << sz << endl;
                return 1;
        }

        return 0;
}

Sincerely,
Thomas Evensen

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Evensen wrote:
> The question is whether it is defined behaviour to check the "this" pointer
> inside a class represented by a null pointer or not.

This can not be null; for it to be so, code must dereference
a null pointer, which causes undefined behavior. I would
expect a high-quality compiler to optimize all (this == 0)
to false in order to reduce code size by eliminating code
which could execute only after undefined behavior was invoked,
since many people apparently write such code under the mistaken
impression that it's meaningful.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:

> This can not be null; for it to be so, code must dereference
> a null pointer, which causes undefined behavior. I would
> expect a high-quality compiler to optimize all (this == 0)
> to false in order to reduce code size by eliminating code
> which could execute only after undefined behavior was invoked,
> since many people apparently write such code under the mistaken
> impression that it's meaningful.

In fact it's a famous urban legend that it's used as a quick "fix"
to get broken code to run: I would say of the examples that are extant,
most authors were aware it was undefined behaviour.

Thankfully I've never seen code that does this; perhaps I'm just
lucky.

regards
john

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen says...
> Thomas Evensen wrote:
> > The question is whether it is defined behaviour to check the "this" pointer
> > inside a class represented by a null pointer or not.
>
> This can not be null; for it to be so, code must dereference
> a null pointer, which causes undefined behavior.

What is the chain of statements in the standard that justifies this
remark?

There are a number of notes that state that dereferencing a null pointer
produces undefined behavior, but the notes are non-norminative, right?

I know, this topic has been almost covered to death, I've been digging
through the Deja archives and the standard for a couple hours without
making any progress.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

This actually got a bit interesting as I dug though the spec. The spec sa=
ys:

---
1.9.4
Certain other operations are described in this International Standard as
undefined (for example, the effect of dereferencing the null pointer).
[Note: this International Standard imposes no requirements on the behavio=
r
of programs that contain undefined behavior. ]
---

The note is further supported by:
---

8.3.2.4 There shall be no references to references, no arrays of referenc=
es,
and no pointers to references. The declaration of a reference shall conta=
in
an initializer (8.5.3) except when the declaration contains an explicit
extern specifier (7.1.1), is a class member (9.2) declaration within a cl=
ass
declaration, or is the declaration of a parameter or a return type (8.3.5=
);
see 3.1. A reference shall be initialized to refer to a valid object or
function. [Note: in particular, a null reference cannot exist in a
Well defined program, because the only way to create such a reference wou=
ld
be to bind it to the =B3object=B2 obtained by dereferencing a null pointe=
r,
which causes undefined behavior. As described in 9.6, a reference cannot =
be
bound directly to a bitfield. ]

---

However, "dereference" is never defined. And:

---
5.2.8.2

When typeid is applied to an lvalue expression whose type is a polymorphi=
c
class type (10.3), the result refers to a type_info object representing t=
he
type of the most derived object (1.8) (that is, the dynamic type) to whic=
h
the lvalue refers. If the lvalue expression is obtained by applying the
unary * operator to a pointer [62] and the pointer is a null pointer valu=
e
(4.10), the typeid expression throws the bad_typeid exception (18.5.3).

[62] If p is an expression of pointer type, then *p, (*p), *(p), ((*p)),
*((p)), and so on all meet this requirement.
---

This would imply that *p does not necessarily constitute a dereference. A=
nd
5.3.1.1 describes the unary * as performing an "indirection", also not us=
ing
the term dereference.

Now - _my_ definition of a "dereference" has always been "an operation th=
at
causes a read from, or write to, memory referred to by a pointer, either
directly or indirectly." But that definition is in conflict with 8.3.2.4.
However, just applying the * operator to a null pointer can't constitute
undefined behavior as noted in 5.2.8.2.

I believe early versions of C++ relied on the fact that "this" could be
null. If I remember correctly (and I don't have my old C++ book with me s=
o I
may not be remembering clearly here) this was used to implement new as a
member function.

Something in this tangle deserves a defect report - but I'm not certain w=
hat
it should say or recommend. I do believe it is fairly common practice
(however obnoxious and/or undefined that practice may be) to allow
non-virtual member functions to invoked through a null pointer so long as
they don't access member data or virtual functions. All compilers that I'=
m
aware of simply invoke the member function with a null this pointer.

Sean

in article 3D096437.3000301@compsoc.man.ac.uk, John Levon at
moz@compsoc.man.ac.uk wrote on 6/13/02 8:42 PM:

> Hyman Rosen wrote:
>=20
>> This can not be null; for it to be so, code must dereference
>> a null pointer, which causes undefined behavior. I would
>> expect a high-quality compiler to optimize all (this =3D=3D 0)
>> to false in order to reduce code size by eliminating code
>> which could execute only after undefined behavior was invoked,
>> since many people apparently write such code under the mistaken
>> impression that it's meaningful.
>=20
> In fact it's a famous urban legend that it's used as a quick "fix"
> to get broken code to run: I would say of the examples that are extant,
> most authors were aware it was undefined behaviour.
>=20
> Thankfully I've never seen code that does this; perhaps I'm just
> lucky.
>=20
> regards
> john
>=20
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>=20

--=20
Sean Parent
Sr. Computer Scientist II
Advanced Technology Group
Adobe Systems Incorporated
sparent@adobe.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sean Parent wrote:
> However, "dereference" is never defined.

The index and 5.3.1 very clearly indicate that "dereference"
is the same as "indirection", and is the application of unary
* to a pointer. Then 5.2.5/3 says that for a pointer p to a
class type, p->m is the same as (*p).m, and therefore applying
-> to a pointer also causes indirection or dereferencing.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Danil wrote:
> Hyman Rosen says...
>>This can not be null; for it to be so, code must dereference
>>a null pointer, which causes undefined behavior.
>
> What is the chain of statements in the standard that justifies this
> remark?
>
> There are a number of notes that state that dereferencing a null pointer
> produces undefined behavior, but the notes are non-norminative, right?

1.9/4 says this, and not in a note.
5.3/1 and the index equate the terms "indirection" and "dereferencing" as
the application of unary * to a pointer.
5.2.5/3 equates class member acces p->m to (*p).m, which therefore also
dereferences the pointer.

So (*(T *)0).f() and ((T *)0)->f() both dereference a null pointer and
cause undefined behavior.

There does appear to be a tiny loophole when it comes to ->*. Reading
5.5/3, we do not see p->*pm dereferences p, so given a suitable pointer
to member, it appears that ((T *)0)->*pm is not illegal by this paragraph.

5.5/4 says in its entirety
     If the dynamic type of the object does not contain the member to
     which the pointer refers, the behavior is undefined.

This (almost) clearly rules out using a null pointer with pointer to
member access, because a null pointer has no dynamic type. But the funny
thing about this paragraph is that "the object" that it talks about has
no antecedent in 5.5! (That is, nothing in 5.5 explains what "the object"
in 5.5/4 is, although it's clearly meant to be the left operand of .* or
the dereference of the left operand of ->*, which would then be undefined.)

Make of this what you will.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Evensen" <thenospam@esolutions.no> wrote in message news:<lW7O8.1823$yj7.30484@news4.ulv.nextra.no>...

> The question is whether it is defined behaviour to check the "this" pointer
> inside a class represented by a null pointer or not. In what cases wouldn't
> / shouldn't it be working?

It's perfectly defined behavior to test 'this' against NULL. It's about
as useful as testing 'false' though. As long as no previous undefined
behavior has happened, this!=NULL and true!=false. After undefined behavior,
this could be NULL, false could equal true, and your monitor might be on
fire.

The point is that there is no useful code in which this==NULL is acceptable.
IIRC some real-world compilers don't even emit code for it (GCC?), while
others (intel?) crash on the preceding null-pointer dereference.

Disallowing this "feature" also means that the this-pointer adjustment in
MI doesn't have to take into account the possibility that the pointer
adjusted could be 0. So there are real benefits to making this undefined
behavior.

Regards,
--
Michiel Salters

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen says...
> 1.9/4 says this, and not in a note.
> 5.3/1 and the index equate the terms "indirection" and "dereferencing" as
> the application of unary * to a pointer.
> 5.2.5/3 equates class member acces p->m to (*p).m, which therefore also
> dereferences the pointer.
>
> So (*(T *)0).f() and ((T *)0)->f() both dereference a null pointer and
> cause undefined behavior.

Does 9.3.1 include the case above?

"If a nonstatic member function of a class X is called for an object that
is not of type X, or of a type derived from X, the behavior is
undefined."

Danil

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

This actually got a bit interesting as I dug though the spec. The spec sa=
ys:

---
1.9.4
Certain other operations are described in this International Standard as
undefined (for example, the effect of dereferencing the null pointer).
[Note: this International Standard imposes no requirements on the behavio=
r
of programs that contain undefined behavior. ]
---

The note is further supported by:
---

8.3.2.4 There shall be no references to references, no arrays of referenc=
es,
and no pointers to references. The declaration of a reference shall conta=
in
an initializer (8.5.3) except when the declaration contains an explicit
extern specifier (7.1.1), is a class member (9.2) declaration within a cl=
ass
declaration, or is the declaration of a parameter or a return type (8.3.5=
);
see 3.1. A reference shall be initialized to refer to a valid object or
function. [Note: in particular, a null reference cannot exist in a
Well defined program, because the only way to create such a reference wou=
ld
be to bind it to the =B3object=B2 obtained by dereferencing a null pointe=
r,
which causes undefined behavior. As described in 9.6, a reference cannot =
be
bound directly to a bitfield. ]

---

However, "dereference" is never defined. And:

---
5.2.8.2

When typeid is applied to an lvalue expression whose type is a polymorphi=
c
class type (10.3), the result refers to a type_info object representing t=
he
type of the most derived object (1.8) (that is, the dynamic type) to whic=
h
the lvalue refers. If the lvalue expression is obtained by applying the
unary * operator to a pointer [62] and the pointer is a null pointer valu=
e
(4.10), the typeid expression throws the bad_typeid exception (18.5.3).

[62] If p is an expression of pointer type, then *p, (*p), *(p), ((*p)),
*((p)), and so on all meet this requirement.
---

This would imply that *p does not necessarily constitute a dereference. A=
nd
5.3.1.1 describes the unary * as performing an "indirection", also not us=
ing
the term dereference.

Now - _my_ definition of a "dereference" has always been "an operation th=
at
causes a read from, or write to, memory referred to by a pointer, either
directly or indirectly." But that definition is in conflict with 8.3.2.4.
However, just applying the * operator to a null pointer can't constitute
undefined behavior as noted in 5.2.8.2.

I believe early versions of C++ relied on the fact that "this" could be
null. If I remember correctly (and I don't have my old C++ book with me s=
o I
may not be remembering clearly here) this was used to implement new as a
member function.

Something in this tangle deserves a defect report - but I'm not certain w=
hat
it should say or recommend. I do believe it is fairly common practice
(however obnoxious and/or undefined that practice may be) to allow
non-virtual member functions to invoked through a null pointer so long as
they don't access member data or virtual functions. All compilers that I'=
m
aware of simply invoke the member function with a null this pointer.

Sean

in article 3D096437.3000301@compsoc.man.ac.uk, John Levon at
moz@compsoc.man.ac.uk wrote on 6/13/02 8:42 PM:

> Hyman Rosen wrote:
>=20
>> This can not be null; for it to be so, code must dereference
>> a null pointer, which causes undefined behavior. I would
>> expect a high-quality compiler to optimize all (this =3D=3D 0)
>> to false in order to reduce code size by eliminating code
>> which could execute only after undefined behavior was invoked,
>> since many people apparently write such code under the mistaken
>> impression that it's meaningful.
>=20
> In fact it's a famous urban legend that it's used as a quick "fix"
> to get broken code to run: I would say of the examples that are extant,
> most authors were aware it was undefined behaviour.
>=20
> Thankfully I've never seen code that does this; perhaps I'm just
> lucky.
>=20
> regards
> john
>=20
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>=20

--=20
Sean Parent
Sr. Computer Scientist II
Advanced Technology Group
Adobe Systems Incorporated
sparent@adobe.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen schrieb:
> This can not be null; for it to be so, code must dereference
> a null pointer, which causes undefined behavior.

is that so?  a non virtual method that does not do any member
access does not need this at all, i think.

#include <iostream>

class Foo {
public:
  void foo() {  std::cout << "sic!" << std::endl; }
  void bar() {  std::cout << ((void*) this) << std::endl; }

};

this *can* work - i'm not sure whether the std allows it.

regards

 robert

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

While I agree that if 'this' is null you are already in the land of
undefined behavior, but that doesn't change that fact that 'this' can in
fact, in real life, be null; at least with the compiler I use.  All you have
to do is invoke a member function through a null pointer, and you get a null
'this'.  Therefore, I think it's perfectly reasonable in a debug build to
assert 'this' != null.  Better to have detected undefined behavior than
undetected undefined behavior.

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D0916A0.6070807@mail.com...
> Thomas Evensen wrote:
> > The question is whether it is defined behaviour to check the "this"
pointer
> > inside a class represented by a null pointer or not.
>
> This can not be null; for it to be so, code must dereference
> a null pointer, which causes undefined behavior. I would
> expect a high-quality compiler to optimize all (this == 0)
> to false in order to reduce code size by eliminating code
> which could execute only after undefined behavior was invoked,
> since many people apparently write such code under the mistaken
> impression that it's meaningful.
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Danil wrote:
> Does 9.3.1 include the case above?

Sure enough looks like it. One of the most annoynig things
about the C++ standard is the fact that nuggets are scattered
all over, and have to be pieced together like this. It reminds
me of my old Talmudic studies.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]