Jon Stewart on 17 May 2003 01:14:02 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [ALACPP] Chris' stupid C++ trick of the week


> So, most compilers out there will not be able to inline an arbitrarily
> complex function. Indeed, the number of cases where they can't inline
> tend to be legion. Furthermore, inlining itself may prove to be a
> deoptimization of such biblical purportions that the micro-optimization
> of copying the object is completely blown out of the water.
> 
> Also, if you are using something like older versions of g++, for these
> difficult cases, the "inline" key world will sometimes force the
> compiler to do some of what you expect with inlining (avoid providing an
> exportable symbol in the object code) while at the same time doing some
> of the things that would make it tempting to use this optimization
> (still pushing a function call onto the stack).


Hmmm... what if you wrapped the function?

template<typename T>
void doFooImpl(T &foo)
{
	// do lots of stuff with/to foo
}

template<typename T>
inline T& doFoo(T &foo)
{
	doFooImpl(foo);
	return foo;
}


That way the compiler would be mighty tempted to heed your advice about 
inlining.


> > Pointers are cheesy, but they work (unlike references).
> 
> Yeah, more than cheesy, for me they alter the contract between caller
> and callee (typically object ownership). I'd rather avoid that at all
> costs.


Ah, yes. Pointer contracts. If only such contracts were legally binding...



Jon
-- 
Jon Stewart
stew1@xxxxxxxxxxx
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp