Forum

for reasons that aren’t worth explaining, I came across the following "inline" member functions defined in ExtColorCtrl.h

struct cell_t::CRect GetRect() const:
>10 lines, has loop, even if it gets unrolled

struct cell_t::void OnDraw(CDC & dc,CPalette * pPalette,bool bFocused)
>40 lines, with multiple funtion calls, etc


It is debatable that even an extremely aggressive compiler will inline GetRect, but OnDraw has no chance of being inlined by a compiler. It is far too big. All that will be accomplished is that there will be local static copies in every object file that includes the file. I’m not exactly sure how this is managed with if <Prof-UIS.h> is in the precompiled header, but still, it can’t help.

Is it still like this in later versions of the lib?

>We agree with you. The CExtColorCtrl::cell_t::OnDraw() method is moved into the CPP file.

In the current release, or an upcoming one?

Had you made some determination (through profiling or assembler examination) that cell_t::CRect GetRect() actually benefits from being inlined, or was it never looked at? I’d leave well enough alone, but we are #defining NOMINMAX globally, and it’s code won’t compile as part of the header file without annoying workarounds involving undesireable namespace usage (std::) in stdafx.h, so if it makes no difference, it’s better for me if the definition is not in the header, and just part of the compiled lib.

I’m wondering whether you already know whether or not there is a performance hit for making it a non-inlined member function (i.e, it was tried and rejected for the current way). If you have, it would save me the trouble of trying; if you don’t know, I’ll find out for myself.

We have already moved the OnDraw() into the CPP file (for the next release). We can also move any other files. The performance of any of Prof-UIS controls does not visually depend on if all functions are inline or non-inline.

We agree with you. The CExtColorCtrl::cell_t::OnDraw() method is moved into the CPP file.