Re: [Patch] Fix libstdc++/7744

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Sun, Mar 09, 2003 at 11:49:56PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> 
> >My only remark on this round is that, again, I am uncomfortable with 
> >overloading standard member names.  I'd rather see a _M_ prefix on 
> >those, at least.
>
> Just to be sure: you prefer, for instance:
> 
>   __basic_file<char>::_M_xsgetn(char* __s, streamsize __n)
> 
> right?

It depends.  If this is an inherited function signature, implementing 
a standard virtual function, then of course you have no choice about 
the name.  If it's presenting a different interface from a standard
inherited function, then it's bad form for it to have the same name.
It means a reader of the code has to carefully inspect the argument 
list to figure out what is being called, and whether it's calling a 
virtual.  We should restrict overloading to places where it's necessary,
such as implementing the function-equivalent of partial specialization.

> (*) Nathan, basing a comment of yours of a few days ago I had believed
> this was not really an issue:
> 
> http://gcc.gnu.org/ml/libstdc++/2003-03/msg00031.html
> 
> In particular:
> 
> >> >Finally, mustn't these members' names be uglified, e.g. _M_no_block
> >> >etc.?
> >> >
> >> The other members of __basic_file<char> aren't and I followed the
> >> existing practice. Should we change all of them?

It really depends on whether these names come in with a standard header 
file.  If they do, then all the names have to be uglified.  My previous
posting assumed that these classes were only visible if users explicitly
included the file they appear in, but now it appears that they come in
with <iostream>.

Nathan Myers
ncm-nospam at cantrip dot org