[boost] Re: Re: Formal Review: Assignment Library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-08 09:15:36

Hi Vladimir,

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:c53i71$4gs$1_at_sea.gmane.org...

> >> In fact,
> >>
> >>   using assignment::operator<<
> >>
> >> does not have this problem, though it's cumbersome.
> >
> > it had with my compilers.
>
> Hmm... strictly speaking,
>
>    using assignment::operator<<;
>
> should make this operator because as if it's declared in namespace where
> "using" appears, as far as name hiding is concerned.

you're right. I had a global using declaration. I'm still a bit confused,
though.

> true, but the compiler is not forced to inline it. So unless you are
> > talking about
> > requiring linking, I don't get it.
>
> The point is: making the function 'inline', either with explicit keyword
or
> by placing it in the class body *increases* the chances that it will be
> inlined. And since inlining here can cause code bloat, it's better not to
> increase those chances.

I agree I should investigate how my lib perform in this regard. I do think
that we wan't
all the inlining that we can get. For example,

vector<int> v;
v += 1,2;

should preferably be expanded to

vector<int> v;
v.push_back( 1 ); v.push_back( 2 );

I don't see any benefit of another layer of function-calls (except larger
code size:-)).

> I've just sketched an example which can be found at
>
>    http://zigzag.cs.msu.su:7813/inline
>
> There are two files -- one with in-class definition and one with
> out-of-class definition. Both are compiled with -O3 but the function is
> inlined only in the first example and the number of instructions needed to
> each call grows from 4 to 13. In a real example the difference might be
> smaller, but it also might be larger :-(

with vc7.1 and como4.3 the results are:

-rwxrwxrwx    1 nesotto  None       135168 Apr  9 00:12 cl_inline.exe
-rwxrwxrwx    1 nesotto  None       135168 Apr  9 00:08 cl_inline2.exe
-rwxrwxrwx    1 nesotto  None       950272 Apr  9 00:07 como_inline.exe
-rwxrwxrwx    1 nesotto  None       950272 Apr  9 00:08 como_inline2.exe

> It was some time ago, so situation might have improved in gcc or in
> libstdc++, but generally, unnecessary inlining will still increase the
code
> size.

perhaps; except when it decreases code size. :-) Arguable it would be good
to see more what
other compilers do; and I would like to see your code optimized for size
(-O3 is for speed, right).

br

Thorsten