Scott Meyers wrote:
>
> May user-defined conversion functions be static?

   According to the common sense they should not be static...
   I didn't find an explicit statement about staticness/staticlessness
of conversion functions but 12.3-1 start with:

         Type conversion of class objects can be specified
         by constructors and by conversion functions. [...]

   Can this statement be interpreted in a way that since a conversion
function is to deal with an _object_ then it cannot be static as far as
static functions can be called without any object?
   BTW, maybe it is worth to make an explicit note about this unclear
subject in the standard.

Igor

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Scott Meyers wrote:

> On Thu,  5 Jul 2001 22:59:07 GMT, Matvei Brodski wrote:
> > Mostly because it does not follow 12.3.2 form for the conversion function.
>
> What form does it violate?  12.3.2 simply says it is a member function with a
> particular naming convention.  I don't see where it says it must be a non-
> static member function.

Oops, sorry. I misread the grammar. 12.3.2 is not enough by itself.
Now, I was thinking this way:
12.3.2(1):"Neither parameter type nor return type can be specified.
           The type of a conversion function (8.3.5) is 'function
           taking no parameter..."

In your example:

Widget w;
if ( w ) { ... } // or if ( (bool)w ) { ... }

Compiler must see this code as:

Widget w;
if ( w.operator bool() ) { ... }

Which, if we are to declare operator bool static, is [in this case
somewhat] equivalent to:

if ( Widget::operator bool() ) { ... }

That seems ok. There is no explicit requirement to treat this conversion
as a unary operator, so we [I guess] may call it without any parameter
at all (including "this"). Also, conversion functions are not associated
with the other "operator" member functions by anything more then use of
the word "operator" (those functions are, on one hand, specified to be
non-static, on the other, it is specified not generally, but on a case
by case basis - why?)
Grammar rules do not forbid it either.
So, I would say - you are right. Does not look like standard explicitly
forbids making conversion functions static. However one can see what
amounts to "legislative intent" to make them non-static: importantly,
use of the word "operator" which implies at least one operand,
ergo - parameter. Also, since there would be no way for a static conversion
function to refer to any object of the associated type, it would be somewhat
inconsistent with:
12.3(1): "Type conversions of *class objects* can be specified by
          constructors and by conversion functions".

While not enough in a strict mathematical sense, it was apparently clear
to most (all?) compiler writers.

Matvei



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.15ad8d3551e95bd698968d@news.hevanet.com...
> May user-defined conversion functions be static?  That is, should this
> compile?
>
> class Widget {
> public:
>   static operator bool() { return true; }
> };
>
> All my compilers hate it.  I hate it, too.  However, I don't see anything
> in 12.3.2 that makes it illegal.  Is this a prohibition that arises from
> the grammar, i.e., the grammar doesn't allow "static" to be followed by a
> conversion-function-id in a member function declaration?  Or am I just
> overlooking something obvious that forbids static conversion functions?

The grammar listed in Appendix A certainly permits the above class
definition. However, as it says:

"It is not an exact statement of the language. In particular, the grammar
described here accepts a superset of valid C++ constructs. Disambiguation
rules (6.8, 7.1, 10.2) must be applied to distinguish expressions from
declarations. Further, access control, ambiguity, and type rules must be
used to weed out syntactically valid but meaningless constructs."

In other words, such a class definition might be syntactically valid (it
is), but meaningless (I think it is, you think it is, but does the standard
say so?).

The standard says (9p7): "The decl-specifier-seq is omitted in constructor,
destructor, and conversion function declarations only."

Which implies "static" is not permitted on conversion function declarations,
since it is a "decl-specifier" (in particular, a "storage-class-specifier").

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Fri,  6 Jul 2001 18:48:44 GMT, "Anthony Williams"
<anthwil@nortelnetworks.com> wrote:

> The standard says (9p7): "The decl-specifier-seq is omitted in constructor,
> destructor, and conversion function declarations only."
>
> Which implies "static" is not permitted on conversion function
> declarations,
> since it is a "decl-specifier" (in particular, a
> "storage-class-specifier").

I like that logic; however, virtual is also a decl-specifer and a
conversion function (or destructor) may be virtual.  Explicit and
inline are also decl-specifers.

I guess the "is" should be read as "is allowed to be".

Clause 13 makes several references to the implied parameter of the
conversion function.  Seems like the intent is clear if not the
letter.

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.research.att.com/~austern/csc/faq.html                ]

In article <3b46764e.52918919@news.csrlink.net>, John Potter
<jpotter@falcon.lhup.edu> writes
>Clause 13 makes several references to the implied parameter of the
>conversion function.  Seems like the intent is clear if not the
>letter.

So perhaps, if it can be specified simply without great linguistic
contortions we need a DR. Actually as a DR can become just a request for
definitive interpretation that would seem the right way to go.


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.research.att.com/~austern/csc/faq.html                ]

May user-defined conversion functions be static?  That is, should this
compile?

class Widget {
public:
  static operator bool() { return true; }
};

All my compilers hate it.  I hate it, too.  However, I don't see anything
in 12.3.2 that makes it illegal.  Is this a prohibition that arises from
the grammar, i.e., the grammar doesn't allow "static" to be followed by a
conversion-function-id in a member function declaration?  Or am I just
overlooking something obvious that forbids static conversion functions?

Thanks,

Scott

--
Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/
Also check out "Effective STL," http://www.aw.com/estl/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <MPG.15ad8d3551e95bd698968d@news.hevanet.com>, Scott Meyers
<smeyers@aristeia.com> writes
>All my compilers hate it.  I hate it, too.  However, I don't see anything
>in 12.3.2 that makes it illegal.  Is this a prohibition that arises from
>the grammar, i.e., the grammar doesn't allow "static" to be followed by a
>conversion-function-id in a member function declaration?  Or am I just
>overlooking something obvious that forbids static conversion functions?

Well clearly they should not work because a static member function has
no 'this' argument so there is nothing to be converted (well perhaps
there is we allow classes to have metatypes, but that would mean that we
should return a type, not a value/object.

I hope the grammar prohibits it, but if it does not we should look at
amending it so to do.



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.research.att.com/~austern/csc/faq.html                ]

Scott Meyers wrote:

> May user-defined conversion functions be static?  That is, should this
> compile?
>
> class Widget {
> public:
>   static operator bool() { return true; }
> };

How do you plan to call it?

Matvei.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu,  5 Jul 2001 19:28:03 GMT, Matvei Brodski wrote:
> > class Widget {
> > public:
> >   static operator bool() { return true; }
> > };
>
> How do you plan to call it?

I can imagine calling it in the usual way,

  Widget w;
  if (w) ...          // invokes implicit conversion

but that doesn't matter.  I'm not lobbying for this, I'm just asking where
in the standard it is forbidden.  Five compilers reject it.  I just want to
know the basis for their rejection.

Scott

--
Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/
Also check out "Effective STL," http://www.aw.com/estl/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Scott Meyers wrote:

> On Thu,  5 Jul 2001 19:28:03 GMT, Matvei Brodski wrote:
> > > class Widget {
> > > public:
> > >   static operator bool() { return true; }
> > > };
> >
> > How do you plan to call it?
>
> I can imagine calling it in the usual way,
>
>   Widget w;
>   if (w) ...          // invokes implicit conversion
>
> but that doesn't matter.

Uhmm... Could you possibly use non-static operator bool() here:

class Widget {
    public:
    operator bool() { return true; }
};

It does not look like the usual way to call static member function.


> I'm not lobbying for this, I'm just asking where
> in the standard it is forbidden.  Five compilers reject it.

Mostly because it does not follow 12.3.2 form for the conversion function.


> I just want to know the basis for their rejection.

Conversion function can not operate on class (you can not convert class
Widget to a value of bool type), but it does operate on an object of a
class (you can convert an object of type Widget) - ergo, it got to be a
non-static memeber (see 12.3.2).

Personally, in your example case I would rather use something like:

if ( w.isValid() ) {
    ...
}

Matvei.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu,  5 Jul 2001 22:59:07 GMT, Matvei Brodski wrote:
> Mostly because it does not follow 12.3.2 form for the conversion function.

What form does it violate?  12.3.2 simply says it is a member function with a
particular naming convention.  I don't see where it says it must be a non-
static member function.

Scott

--
Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/
Also check out "Effective STL," http://www.aw.com/estl/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B44E62E.1EE3B920@bear.com>, Matvei Brodski
<mbrodski@bear.com> writes
>Conversion function can not operate on class (you can not convert class
>Widget to a value of bool type), but it does operate on an object of a
>class (you can convert an object of type Widget) - ergo, it got to be a
>non-static memeber (see 12.3.2).
>
>Personally, in your example case I would rather use something like:
>
>if ( w.isValid() ) {
>    ...
>}

Please quote something from the Standard that support our belief. I am
certain Scott does not want static conversion operators (he has as good
as said so) so most of your response ignores the question.


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.research.att.com/~austern/csc/faq.html                ]