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] Remove workaround for copy_backward


Matt Austern <austern@apple.com> writes:

| On Sep 28, 2003, at 10:41 AM, 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?".
| > It think the dispatcher does a pretty good job here, even though I
| > think it should not depend overload resolution.
| >
| > There are probably other components that can benefit from enable-if,
| > though.
| 
| The obvious answer to objection #2 is to use enable-if internally.  That
| makes constructors more of a nuisance, but even then we can use the
| same trick we're using already: dispatch to a helper function that does
| all the real work.

The whole benefit of using enable-if at the constuctor signature level
is to eliminate the infamous constructor from the set overload.  If
enable-if can't be used at that level, then I do not believe it brings
much benefit compared to current dispatching approach.

-- gaby


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