Something about std::list<> member functions.

[Gabriel Dos Reis]

Jerry Quinn <jlquinn@optonline.net> writes:

| Gabriel Dos Reis writes:
|  > Nathan Myers <ncm-nospam@cantrip.org> writes:
|  > 
|  > | On Sat, Aug 09, 2003 at 08:55:16PM +0200, Gabriel Dos Reis wrote:
|  > | > Dhruv Matani <dhruvbird@gmx.net> writes:
|  > | > 
|  > | > [...]
|  > | > 
|  > | > | 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.
|  > | > 
|  > | > See recent discussions on gcc@gcc.gnu.org about inlining.
|  > | 
|  > | Without consulting those, I recall Jason Merrill mentioning that
|  > | you can get enormous optimization improvements just from declaring
|  > | the inline functions' arguments "const", unnecessarily.  Is that 
|  > | advice still current?  Since it doesn't affect the ABI or standard 
|  > | conformance, that seems worth doing where it makes a difference.
|  > 
|  > We already pass the arguments by const reference.
| 
| If I remember right, the issue isn't passing by const ref.

Here is what I meant:

   struct less {
      template<class T>
       bool operator()(const T& a, const T& b) const
       { return a < b; }
   };

the arguments are passed by const reference.  Is that different fro
what you intend below?  If yes, please elaborate because I can't see
the difference. 

|  It's that
| early on in parsing(?) the input, when the argument itself isn't
| const, the compiler fails to see that inlining is OK.  Which means you
| would have to have something like:
| 
| int function(const T& x const)
| 
| in order to work around the problem.  Even though declaring x const is
| silly.
| 
| Richard Henderson was the one who told us about it.  It came up when
| looking at performance problems in std::copy.

-- Gaby