resolving type of params in template member function

[joel reed]

may i ask why you believe that if egcs has the choice between the
following to versions of basic_string::end() that it shouldn't try to
choose the most restrictive of the two? 

iterator end();
const_iterator end() const;

i am under the impression that when faced with the choice of resolving
which version of end() i am calling that it should try the most
restricted (most const) version first. thanks for your feedback
Alexandre.

joel



---Alexandre Oliva <oliva@dcc.unicamp.br> wrote:
>
> On Jan 14, 1999, joel reed <joelreed@yahoo.com> wrote:
> 
> > using latest egcs snapshot and libstdc++-2.90.3 the following code
> > snippet won't compile...
> 
> > std::string str = "a test string";
> > std::string::const_iterator i = std::find(str.begin(), str.end(),
'e');
> > std::string foo(i, str.end());
> 
> > however, if i make the iterator a non-const iterator, or if i make
str
> > const it will compile. the error message for the above frag is "no
> > matching function call for ... (const char*&, char*)". 
> 
> > it seems to me that the compiler should be picking up the const
> > version of string::end() but is instead picking up the non-const
> > version & choking.
> 
> Why should it?  The error message is correct, from the point of view
> of egcs, but you should complain to the developers of libstdc++-v3
> that there should be a conversion from string::iterator to
> string::const_iterator, and this conversion might be used in your
> example.  I'm not sure it should, though.
> 
> -- 
> Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
> oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
> Universidade Estadual de Campinas, SP, Brasil
> 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com