This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] PR 8761 and 7076, take 2


[I have a small time of connectivity so I may not be able to conduct a
full discussion on this ]

Nathan Myers <ncm-nospam@cantrip.org> writes:

| On Wed, Jan 22, 2003 at 01:33:19AM -0600, Benjamin Kosnik wrote:
| > On Thu, 16 Jan 2003 11:03:37 -0800
| > Nathan Myers <ncm-nospam@cantrip.org> wrote:
| > 
| > >> +  // NB: Of the two parameters, _CharT can be deduced from the
| > >> +  // function arguments. The other (_Traits) has to be explicitly specified.
| > >> +
| > >> +  template<typename _CharT, typename _Traits>
| > >> +    struct __pad [... ]
| > >
| > >I don't see how arguments to a struct template can be deduced.  
| > >A better comment would explain why __pad is a struct at all.
| > 
| > This comment is misleading, and hasn't been updated since the switch to
| > a struct. I'll try to come up with something better tomorrow.
| > 
| > This cannot be a function template (with these parameters, at least)
| > because this function is shared by class templates of one and two
| > parameters (char and or traits). There is no way for the compiler to
| > deduce, from the arguments to the _S_pad function, what the traits-type
| > is, yet it is used in the function. Thus it has to be a struct, so that
| > invocations can be like:
| > 
| > _pad<char, _Traits>::_S_pad
| 
| It seems to me that it can just as well be a function template, with the
| template argument order reversed.  
| 
|   template <typename _Traits, typename _CharT>
|     int _Pad([stuff involving _CharT]) { ... }
| 
| Then, it would be called as
| 
|   _Pad<_Traits>(...)
| 
| Then we can delete the comment.

I seem to recall that we have been through this in the past -- when
__pad became a struct --- that what you're suggesting doesn't scale.
The point being (if I recall correctly) that we wanted to partially
specialize the function (no, we didn't want an overload), so we had no
choice.  Maybe the comment is not accurate, but what I said is my
recollection. 

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]