"Graeme Prentice" <gp1@paradise.net.nz> wrote in message
news:fbtp2vg13aabiknfdlstg23ed932dv0hfu@4ax.com...
> [...]
> I'm not sure I understand you.  If the class definition is not visible
> then it's an incomplete type so can't be looked up in the scope of the
> class.  For the following code, the Borland compiler gives a compile
> time error (undefined structure c1),  Comeau 4.3.0.1 gives a
> catastrophic failure (seems to be a problem in the Borland backend, so
> the "front end" probably thinks it's valid) and GCC 3.2 compiles with no
> errors.  If this code is intended to be valid, I think 13.3.1.2 should
> say that if the class T1 is an incomplete type then the set of member
> candidates is empty  - or else it should say that T1 must be a complete
> type.  The way 13.3.1.2  is currently written leaves it open to
> interpretation IMO.  Since some compilers treat it as valid code, it's
> probably best to allow an incomplete type, to avoid breaking existing
> code, if nothing else.
>
> class c1;
> extern c1 o1;
> void operator<<( c1&, int );
>
> int main()
> {
>     o1 << 23;
> }
>
I thought that the C++ standard should say that in contexts in which
incomplete type is involved the program should not change its meaning if the
type was complete but I found no evidence for such rule although it seems to
be in the spirit of the ODR.
For example:
struct B {};
struct D;

int f(void *);
int f(B*);

D *dp;
int  x1 = f(dp); // selects f(void*)

struct D : B {};
int x2 = f(dp);  // oops - selects f(B*);

In general, lookup might be change when type becomes complete.
I found few places where the rule I mentioned is explicitly specified, For
example:
5.3.1/4 - classes that declares operator&()
14.3.3/2 - visibility of partial specialization (another form of
completeness)

Rani


---
[ 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                       ]

llewelly.@@xmission.dot.com (llewelly) writes:

> gp1@paradise.net.nz (Graeme Prentice) writes:
>
> F> On Mon, 20 Jan 2003 23:53:22 +0000 (UTC), llewelly.@@xmission.dot.com
> > (llewelly) wrote:
> >
> > >gp1@paradise.net.nz (Graeme Prentice) writes:
> > >
> > >> Regarding the expression a @ b where @ is an operator such as << and a
> > >> has type T1
> > >>
> > >> 13.3.1.2 para 3 bullet 1 says
>
> Now I notice that 13.3.1.2/3 begins with 'For a unary operator ...'
>     and 13.3.1.2/5 is 'For all other operators, no such restrictions
>     apply' Maybe 13.3.1.2/3 does not apply to the example you present
>     below. However I believe:
[snip]

Oops. 13.3.1.2/3 goes on to include binary operators. So it does apply
    to Graeme's operator<< example.

---
[ 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                       ]

On Mon, 20 Jan 2003 23:53:22 +0000 (UTC), llewelly.@@xmission.dot.com
(llewelly) wrote:

>gp1@paradise.net.nz (Graeme Prentice) writes:
>
>> Regarding the expression a @ b where @ is an operator such as << and a
>> has type T1
>>
>> 13.3.1.2 para 3 bullet 1 says
>>
>> If T1 is a class type, the set of member candidates is the result of the
>> qualified lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of
>> member candidates is empty.
>>
>> Does this mean that the class definiiton of T1 has to be visible or does
>> it mean that if the lookup fails for whatever reason, the set of
>> candidates is empty.
>>
>> For example if you write cout << "hello"; does the class definition for
>> the type of cout have to be visible.
>
>3.4.3.1/1 (Qualified name lookup, Class members):
>
># If the nested-name-specifier of a qualified-id nomintates a class,
># the name specified after the nested-name-specifier is looked up in
># the scope of the class (10.2) ... [sniped]
>
>The paragraph then continutes to specify 3 exceptions, applying to
>    destructors, conversion-type-ids, and template-ids, none of which
>    seem relevant to your question.
>
>So combining 13.3.1.2/3 with 3.4.3.1/1, I think the operator will be
>    looked up in the scope of the class, whether it is 'visible' or
>    not.


I'm not sure I understand you.  If the class definition is not visible
then it's an incomplete type so can't be looked up in the scope of the
class.  For the following code, the Borland compiler gives a compile
time error (undefined structure c1),  Comeau 4.3.0.1 gives a
catastrophic failure (seems to be a problem in the Borland backend, so
the "front end" probably thinks it's valid) and GCC 3.2 compiles with no
errors.  If this code is intended to be valid, I think 13.3.1.2 should
say that if the class T1 is an incomplete type then the set of member
candidates is empty  - or else it should say that T1 must be a complete
type.  The way 13.3.1.2  is currently written leaves it open to
interpretation IMO.  Since some compilers treat it as valid code, it's
probably best to allow an incomplete type, to avoid breaking existing
code, if nothing else.

class c1;
extern c1 o1;
void operator<<( c1&, int );

int main()
{
    o1 << 23;
}

Graeme

---
[ 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                       ]

gp1@paradise.net.nz (Graeme Prentice) writes:

F> On Mon, 20 Jan 2003 23:53:22 +0000 (UTC), llewelly.@@xmission.dot.com
> (llewelly) wrote:
>
> >gp1@paradise.net.nz (Graeme Prentice) writes:
> >
> >> Regarding the expression a @ b where @ is an operator such as << and a
> >> has type T1
> >>
> >> 13.3.1.2 para 3 bullet 1 says

Now I notice that 13.3.1.2/3 begins with 'For a unary operator ...'
    and 13.3.1.2/5 is 'For all other operators, no such restrictions
    apply' Maybe 13.3.1.2/3 does not apply to the example you present
    below. However I believe:

class c1;
extern c1 o1;
void operator++(c1&);

int main()
{
    ++o1;
}

    raises the same question, and (I think) falls under 13.3.1.2/3 . This
    code compiles with no errors using gcc 3.2.1. I put:

class c1
{
public:
  void operator++(){}
};

c1 o1;

void operator++(c1&){}

    in a second translation unit, and it linked without errors. Some
    tracing couts revealed the non-member void operator++ was used. I
    don't know what the standard thinks of this code. If the set of
    member canidates is empty when the type is incomplete, the meaning
    of a simple expression may change depending on whether the class
    definiton is availible. However, requiring the operator to be
    looked up in the scope of the class in this example seems to
    require postponing overload resolution to link time. I don't
    imagine implementors would care for that, especially those who
    support shared libraries.

> >>
> >> If T1 is a class type, the set of member candidates is the result of the
> >> qualified lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of
> >> member candidates is empty.
> >>
> >> Does this mean that the class definiiton of T1 has to be visible or does
> >> it mean that if the lookup fails for whatever reason, the set of
> >> candidates is empty.
> >>
> >> For example if you write cout << "hello"; does the class definition for
> >> the type of cout have to be visible.
> >
> >3.4.3.1/1 (Qualified name lookup, Class members):
> >
> ># If the nested-name-specifier of a qualified-id nomintates a class,
> ># the name specified after the nested-name-specifier is looked up in
> ># the scope of the class (10.2) ... [sniped]
> >
> >The paragraph then continutes to specify 3 exceptions, applying to
> >    destructors, conversion-type-ids, and template-ids, none of which
> >    seem relevant to your question.
> >
> >So combining 13.3.1.2/3 with 3.4.3.1/1, I think the operator will be
> >    looked up in the scope of the class, whether it is 'visible' or
> >    not.
>
>
> I'm not sure I understand you.  If the class definition is not
> visible

I failed to relate 'not visible' to 'incomplete'; I didn't understand
    *you*.

> then it's an incomplete type so can't be looked up in the scope of the
> class.  For the following code, the Borland compiler gives a compile
> time error (undefined structure c1),  Comeau 4.3.0.1 gives a
> catastrophic failure (seems to be a problem in the Borland backend, so
> the "front end" probably thinks it's valid) and GCC 3.2 compiles with no
> errors.  If this code is intended to be valid, I think 13.3.1.2 should
> say that if the class T1 is an incomplete type then the set of member
> candidates is empty  - or else it should say that T1 must be a complete
> type.  The way 13.3.1.2  is currently written leaves it open to
> interpretation IMO.

Maybe you should file a defect report. Prior to your post, I would
    have assumed that if T1 was incomplete, the set of member
    candidates would be empty. I don't see that in the standard,
    however.

> Since some compilers treat it as valid code, it's
> probably best to allow an incomplete type, to avoid breaking existing
> code, if nothing else.

I agree. However I'd really like to hear from someone (in addition to
    you) who understands overloading better than me.

> class c1;
> extern c1 o1;
> void operator<<( c1&, int );
>
> int main()
> {
>     o1 << 23;
> }
[snip]




---
[ 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                       ]

Regarding the expression a @ b where @ is an operator such as << and a
has type T1

13.3.1.2 para 3 bullet 1 says

If T1 is a class type, the set of member candidates is the result of the
qualified lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of
member candidates is empty.

Does this mean that the class definiiton of T1 has to be visible or does
it mean that if the lookup fails for whatever reason, the set of
candidates is empty.

For example if you write cout << "hello"; does the class definition for
the type of cout have to be visible.

Graeme

---
[ 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                       ]

gp1@paradise.net.nz (Graeme Prentice) writes:

> Regarding the expression a @ b where @ is an operator such as << and a
> has type T1
>
> 13.3.1.2 para 3 bullet 1 says
>
> If T1 is a class type, the set of member candidates is the result of the
> qualified lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of
> member candidates is empty.
>
> Does this mean that the class definiiton of T1 has to be visible or does
> it mean that if the lookup fails for whatever reason, the set of
> candidates is empty.
>
> For example if you write cout << "hello"; does the class definition for
> the type of cout have to be visible.

3.4.3.1/1 (Qualified name lookup, Class members):

# If the nested-name-specifier of a qualified-id nomintates a class,
# the name specified after the nested-name-specifier is looked up in
# the scope of the class (10.2) ... [sniped]

The paragraph then continutes to specify 3 exceptions, applying to
    destructors, conversion-type-ids, and template-ids, none of which
    seem relevant to your question.

So combining 13.3.1.2/3 with 3.4.3.1/1, I think the operator will be
    looked up in the scope of the class, whether it is 'visible' or
    not.

---
[ 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                       ]