Re: C++ - inlining of functions returning an unwindable object

Roland Lei_a wrote:
> I tried your code with g++ 4.4.1 on amd64. g++ basically emits the
> same code for testsimple and testsimple2 and does not call the getter.
> I compiled with:
> g++ test.cpp -c -O3 -S
>


OK. So it's MSVC++ specific. An interesting other combination would
maybe be MinGW/32 ... may I'll get something running and compare that.


> Are you sure you turned on all optimizations? Perhaps declaring the
> getter as
> std::string get() const {
> return s_;
> }
> helps.


Oh, I specifically *haven't* enabled all optimizations. I only have
enabled inlining, which should be sufficient for this testcase. (Well,
it appears to be with MSVC++)


> Another important issue is the return value optimizatoin of C++.
> http://en.wikipedia.org/wiki/Return_value_optimization (though the
> article claims msvc++ supports this feature)
>


RVO is there with MSVC (it always is, no matter what optimization level).
This shouldn't have any bearing on inlining vs. not inlining I guess.


> Yet another thing one should not forget is that a language allowing
> pointers which may point to literally everywhere, pointer arithmetic
> and so on really makes headaches for compiler writers. C/C++
> enthusiasts often claim how fast pointers are but this is only the
> case if the compiler is _really_ smart. That's why Fortran is
> sometimes faster than C. And since std::string uses pointers
> internally this may be the reason why msvc++ is not able to inline the
> function.
>


Well. MSVC won't inline any function returning an unwindable object,
i.e. an object with a non-empty destructor, it doesn't have anything to
do with if the object has some pointer members.


The point I was making in my OP was that the generated assembly code
minus the call itself + semantics appear to be exactly the same with the
function inlined vs. not inlined, so it strange that MSVC++ will never
inline such functions.


cheers,
Martin

Return to the comp.compilers page.
Search the comp.compilers archives again.