Topic: problem with const in signature


Author: Alexandre Oliva <oliva@dcc.unicamp.br>
Date: 1997/08/25
Raw View
Ron Burk writes:

> class A
>    {
>   public:
>    void operator>>(char* const t);   // const ptr
>    };

> // should not compile -- operator>>(char* t) is not member of A!
> void A::operator>>(char* t)

This is legal C++.  The outermost cv-qualifiers in formal arguments do
not affect the function signature, they only affect the
constness/volatileness of the actual argument.  Since the declaration
does not provide a body, that const is meaningless.  If, in the
definition, you had declared t as char*const, the only difference
would be that t would not be modifiable.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ 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
]





Author: Marcelo Cantos <marcelo@janus.mds.rmit.edu.au>
Date: 1997/08/26
Raw View
"Ron Burk" <70302.2566@compuserve.com> writes:

> class A
>    {
>   public:
>
>    void operator>>(char* const t);   // const ptr
>    };
>
> // should not compile -- operator>>(char* t) is not member of A!

What makes you say that?  operator>>(char*) most certainly is a member
of A.  Perhaps you're confusing it with the common paradigm of making
istream& operator>>(istream&, thing&) a friend of class thing because
it isn't a member, ie:

  class thing {
    friend istream& operator>>(istream&, thing&);
  };

  istream& operator>>(istream& is, thing& t) {
    // Output t...
    // ...
    return is;
  }


--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ 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                             ]





Author: "Ron Burk" <70302.2566@compuserve.com>
Date: 1997/08/25
Raw View
I had presumed the following code should not compile:

 ------------------------------
class A
   {
  public:

   void operator>>(char* const t);   // const ptr
   };

// should not compile -- operator>>(char* t) is not member of A!

void A::operator>>(char* t)
   {
   *t=0;
   }
  -------------------------

And that the fact that it compiled under Borland C++ v5.01 was a bug.
However,
I was surprised to note that Visual C++ changed its behavior in this regard
(4.2
failed this code, 5.0 accepts it), and now I'm wondering if they know
something
I don't. Is this code really legal C++ after all?

 Any help appreciated,
 Ron Burk, www.burklabs.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                             ]





Author: "Ron Burk" <70302.2566@compuserve.com>
Date: 1997/08/29
Raw View
Hi Hyman,

> See CD2 8.3.5 paragraph 3. Brief quote:
>
>  "Any cv-qualifier modifying a parameter type is deleted;
>   e.g., the type void(const int) becomes void(int)."

I'm sure I'm being really dense here, but I can't figure out why people
keep pointing me to the rules for determining a function signature, when
that (to me) has nothing to do with determining whether the following
clause
is being violated.

Same paragraph, but earlier (presumably taking precedence, therefore):

 > All declarations for a function with a given parameter list shall agree
exactly both in the
 > type of the value returned and in the number and type  of  parameters;
---
[ 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
]





Author: Marcelo Cantos <marcelo@janus.mds.rmit.edu.au>
Date: 1997/08/29
Raw View
"Ron Burk" <70302.2566@compuserve.com> writes:

>
> > > class A
> > >    {
> > >   public:
> > >
> > >    void operator>>(char* const t);   // const ptr
> > >    };
> > >
> > > // should not compile -- operator>>(char* t) is not member of A!
> >
> > What makes you say that?  operator>>(char*) most certainly is a member
> > of A.
>
> Well, operator>>(char* const) is undeniably a member of A, but whether or
> not operator>>(char*) is a member is the point of my question. It seems to
> me it is not, since it does not "agree exactly" in the number and type of
> arguments with that of the class declaration, and therefore qualifies
> as a redeclaration of a member function, which the standard says is
> illegal.

My apologies.  You are right.  I didn't spot the 'const'.


Cheers,
Marcelo

--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ 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
]





Author: Hyman Rosen <uunet!jyacc!calumny!hymie@ncar.UCAR.EDU>
Date: 1997/08/29
Raw View
"Ron Burk" <70302.2566@compuserve.com> writes:
> Hi Hyman,
> > See CD2 8.3.5 paragraph 3. Brief quote:
> >
> >  "Any cv-qualifier modifying a parameter type is deleted;
> >   e.g., the type void(const int) becomes void(int)."
>
> I'm sure I'm being really dense here, but I can't figure out why people
> keep pointing me to the rules for determining a function signature, when
> that (to me) has nothing to do with determining whether the following
> clause is being violated.
>
> Same paragraph, but earlier (presumably taking precedence, therefore):
>
> > All declarations for a function with a given parameter list shall
> > agree exactly both in the type of the value returned and in the
> > number and type of parameters;

As you say, the earlier sentence states the requirement. It then goes on
to say "The type of a function is determined using the following rules".
One of these rules is the removal of cv-qualifiers from parameters.
---
[ 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
]