Re: empty function optimizations

[Joe Buck <jbuck at racerx dot synopsys dot com>]

> > Ideally, the STL we provide should use a lot more partial specialization;
> > for example
> 
> Fair enough, and the Stroustrup pointer will come in handy, but I think we
> have a difference in philosophy on this.  If I end up with duplicate code
> for whatever reason, I'd like the linker to catch it.  In RL programmers
> don't always have complete control over the templates they play with
> (including STL), and in RL programmers leave creeping bloat well enough
> alone (there are 2854 "simple functions" in Linux).

I agree with you that this is a problem, but believe that the appropriate
fix isn't in the linker, but is to improve STL instead to use partial
specialization.  The results would be better than you would be able to
get by trying to use the linker to remove duplicate code.

To really do a great job, we would need one compiler change: the ability
to auto-generate type_traits specializations in an SGI-compatible manner.
But we could then have almost no bloat at all for vector<T> or list<T>
where T is a POD type.

I really wish I had some time to work on this, because it would be
extremely cool.  It's possible to go beyond just optimizing PODs, and
also specialize for classes that can be relocated by a bitwise copy,
even though they have nontrivial copy constructors and assignment
operators.  The idea is to make insert or push_back for, for example,
vector<string> or vector<vector<T> > much faster.

> I also don't like void* solutions as a general rule, but I'll admit hiding
> it up in a type-safe template library is probably a reasonable exception.

Exactly.  It should be done once, correctly, and the user of the class
need not see it.

> > > say comparing function pointers for equality is in pretty bad taste
> > > (entirely IMHO).

It does happen.  You might want to check to see whether a signal handler
or a callback has been set to point to a particular handler function.

> > That's the least of the problems.  You seem to want the compiler or linker
> > to figure out for you that, say, vector<unsigned> and vector<float> can
> > share the same code for the copy constructor, because on your platform,
> > both are four bytes and it's just data movement.
> 
> If float and int assignment are treated differently by the arch, then I
> don't expect anything.  I *do* expect that operations on node pointers that
> happen to contain an int or float to get combined if it results in the same
> code.  Or at least it would be nice :-).

Well, if someone wants to code up what you want and contribute it, I
have no objection.