On Monday, July 08, 2013 10:56:31 H. S. Teoh wrote: > On Sun, Jul 07, 2013 at 01:55:16PM -0700, Jonathan M Davis wrote: > > On Sunday, July 07, 2013 14:30:12 Iain Buclaw wrote: > > > On 6 July 2013 22:41, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > > > > On Saturday, July 06, 2013 14:13:29 H. S. Teoh wrote: > > > >> Shouldn't the frame pointer be generated only if f() actually > > > >> tries to access something outside of the definition of T? > > > > > > > > Probably, but that's arguably an optimization. Regardless, marking > > > > it as static will force the issue. > > > > > > An optimization that is on similar boundaries as virtual by default. > > > > > > :) > > > > Indeed, though the compiler has a much better chance of determining > > that a nested function can be made static than determining that a > > virtual function can be made non-virtual. > > [...] > > I may be remembering incorrectly, but my impression was that TDPL states > that the context pointer is only added where necessary. So having to > explicitly state 'static struct' to suppress the context pointer was a > bit surprising for me.
Well, I don't think that there's much question that it would be nicer if the compiler made it static when it could, but it doesn't surprise me that it doesn't manage it. It wouldn't hurt to open a bug report for it though. - Jonathan M Davis