Re: Something about std::list<> member functions.

[Dhruv Matani <dhruvbird at gmx dot net>]

On Sat, 2003-08-09 at 22:32, Gabriel Dos Reis wrote:
> Gawain Bolton <gbolton@free.fr> writes:
> 
> | Dhruv Matani wrote:
> | 
> | >I was wondering why in std::list<>, the functions merge, unique, sort,
> | >... are implemented twice, once for the less than operator, and once for
> | >the template argument one. Why can't it be coded just once for the more
> | >general version, and pass std::less<> to then more general one, when the
> | >less general one is called?
> | >
> | Good question!   But this kind of thing is not limited to the
> | std::list class, the generic algorithms in stl_algobase.h and
> | stl_algo.h also currently have duplicated code for functions with and
> | without comparison objects or predicate objects as they're sometimes
> | called.
> | 
> | Unless there is a good reason for not doing this, I would be happy to
> | submit a patch for std::list.
> 
> Nearly a year ago -- at the last Santa Cruz meeting -- Benjamin and I
> elaborated on that issue.  Basically
> 
>    1) I introduced function objects (implemented in our internal
>       namespace) for the usual comparisons
> 
>    2) I made the less specific functions forward to most general ones
>       by adding an instance of the function objects.
> 
> That substantially reduced the duplications you find here and there.
> 
> Then, I discovered that our lovely compiler is not always inlining
> those pretty trivial function objects.  Then I didn't apply the
> patches. 
> 
> So the only reason for the current situation is GCC not always honouring
> inline request in those simple situations.  Code duplication removal
> in this case will not be interesting if it means lees efficient library.

I suspected something like that, after reading Alex Stepanov's interview
on the SGI STL pages, where he mentioned that he carefully (and
painfully!!!) went through the assembly output generated by compilers
for different optimizations, and that's how he has coded the STL
originally, so I guessed that this had something to do with it. I have
trouble coping with the AT&T syntax, so I'm not trying to do something
like that, unless I get MingW or something that generated Intel Syntax
form At&T syntax, but I thought (and still do think) that compiler
technology should have evolved by now so as to optimize such stuff into
nothingness...... And, looking at g++ optimizations, I definitely
thought that it could (at least now) optimize away the layer.



-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/