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: Fwd: Re: [Patch] Remove workaround for copy_backward


Douglas Gregor <gregod@cs.rpi.edu> writes:

| On Sunday 28 September 2003 01:41 pm, Gabriel Dos Reis wrote:
| > Here is my take on the template constructror issue.  It is out of
| > question to add a dummy argument, because:
| >  (1) it an ABI breaking -- I do not have a strong opinion here;
| >  (2) it makes us potentially accept "invalid" constructs -- even though
| >      it may a harmless one.  For some reasons, people tend to use/depend
| >      on things we think harmless; I'm pretty sure we'll get questions
| >      like: "why does not vector<> use by nth argument?".
| 
| Good point. We should use the allocator parameter instead, e.g.,
| 
|     template <class _InputIterator>
|       list(_InputIterator __first, _InputIterator __last,
|            typename __enable_if<const _Allocator&,
|                   (!__is_integral<_InputIterator>::value)
|                   >::_M_type __a = _Allocator());
| 
| The effective signature doesn't change, so it won't accept the invalid 
| constructs. Still changes the ABI in the presence of inlining, but otherwise 
| I can't see how these changes would affect the ABI.

If my memory serves me well, for some reasons the C++ front-end tends
to mangle type-expressions token-for-token in mangled-names.  I have
no idea of what is done with them.

-- Gaby


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