Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

The big Question?

Function wouldn´t go inline

This topic is 6918 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a little (big) problem in my code, because some of my member-functions wouldn´t go inline. (I get a warning) Im using MSVC 6 and have tried the following: To use
__forceinline  
instead of
inline  
. I have also tried with
#pragma inline_depth (255)  
and
#pragma inline_recursion (on)  
, but nothing helps ): The function itself is short and simple. Here is some pseudo code:
///////////////////////////////
// Drawing class

class CDraw
{
  void DrawFast()
  ..
};


inline void CDraw::DrawFast()
{
  pDDraw->FastBlt(..)
}

/////////////////////////////////
// Other class

class CBall
{
  void DrawBall();
 ...
 CDraw*  pDraw;
};


inline void CBall::DrawBall()
{
  pDraw->DrawFast()
}
  
Now a compiler-warning tells me the function can´t be inlined, why? This is simple code with only two nested inline statments, can´t C++ handle that? Hope somebody can help... Edited by - The big Question? on 5/10/00 2:22:40 PM

Share this post


Link to post
Share on other sites
Advertisement
You must declare it inline from inside the class declaration. You should declare it like this:


class CDraw
{
public:
inline void DrawFast();
};

inline void CDraw::DrawFast()
{
pDDraw->FastBlt(...);
}



Keep in mind that the function body for inline functions must be in the .h file with the class declaration, because the compiler needs a copy of the function every time it goes through the header file, while with ordinary functions it just uses the identifier name (i.e., CDraw::DrawFast()) so it would be okay for the function to be in a different file from the class declaration.

Also, you should never force a function inline. If the compiler outlines it (yes, that''s the technical term), then it is because the increase in size does not justify the increase in speed. Let the compiler optimize it; it will work something like taking the ratio of the time it takes to jump to the function code over the time it takes to execute the function code. Also, if you are calling the function from within a loop (where the calling time would become more important), the compiler will pick up on this and inline it.

Let the compiler play around with it.

(If it helps you to know, the C++ standard allows the compiler to choose which functions should be inlined, even though you specify the inline keyword. "inline" is what is called an optimization hint, which is like waving a flag saying "hey you! this could be optimized!" but might still be incorrect.)




- null_pointer
Sabre Multimedia

Share this post


Link to post
Share on other sites
Declaring it as inline is meaningless. The compiler will only make a function inline if it does not call any other functions. If the compiler sees a function call within an inline function it just turns the inline function into a regular function basicaly ignoring the inline completly. Anyway it''ll work but it''s no faster than using a regular function call.

Share this post


Link to post
Share on other sites
Well I know inline is only a hint and __forceinline is a STRONG hint. And the functions are naturally declared in the header (I forgot to tell that).

But to me it seems stupid that the compiler can´t inline two nested inline functions.
These aren´t normal function-calls, just a kind of C++ macros with type-checking.

But if the compiler can´t figure this out, I have to force this in a plain C macro, which is very ugly in the middle of nice class.
But speed is more important (to me) than clean code, so I guess this is the way, I have to go.

Share this post


Link to post
Share on other sites
I''m wondering what the magic would be in avoiding one function call overhead with a pointer dereference in it. Time-wise, it''s going to be negligible compared to the time taken to actually perform the function ~ inlining the draw function would make more sense.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

Share this post


Link to post
Share on other sites
quote:

inlining the draw function would make more sense.



What do you mean?
My drawing-function is already inline, all I want the compiler to is something like this:


void CGame::Run()
{
// In my main game-function:
Draw();
}


inline void CGame::Draw()
{
// m_pDDraw points to my DDraw wrapper class.
// FastBlt is an inline function which calls
// IDirectDrawSurface7´s Fastblt-method.
m_pDDraw->FastBlt(.. the params..)
}



All in all when the compiler has inlined all the code, it should end up looking like this:


void CGame::Run()
{
// Actual code.
IDirectDrawSurface7::FastBlt(.. params ..);
}


But the compiler wouldn´t accept this,
so I have to use macros instead.

By the way thanks to all of you, who tried to help.

Edited by - The big Question? on May 11, 2000 8:13:46 AM

Share this post


Link to post
Share on other sites
What kind of parameters are you passing? The compiler can will often not perform the inlining of member functions when too many parameters are being passed that are member variables. Actually, sometimes it just won''t inline certain combinations of parameter types. Also it''s more likely to inline the functions if you place the function in the class declaration, rather than declaring the member function and defining it separately.

Share this post


Link to post
Share on other sites
quote:
Original post by SiCrane
What kind of parameters are you passing? The compiler can will often not perform the inlining of member functions when too many parameters are being passed that are member variables.


Well none in the first inline statement:


CGame::Run()
{
Draw();
}


And in my inline FastBlt-method (which calls IDirectDrawSurface7::FastBlt) the params go like this:


CDDraw::FastBlt(INT nX, INT nY, LPDIRECTDRAWSURFACE7 lpSource, RECT* prc, UINT uParams =NULL);


That´s it.
By the way my FastBlt-methode contains a small while-loop, but that shouldn´t affect the compiler.

Share this post


Link to post
Share on other sites
Actually, the compiler is extremely unhappy about inlining functions that contain any kind of loop. Even small innocent-looking while loops.

Share this post


Link to post
Share on other sites
Well that could be the problem, but I got it working with the good old C-macros.

Still I think this is weird, that the compiler won´t inline my functions, because I´m only using them as a kind of lazy-macros, so I won´t have to write the same code more than once.
And DrawFast() looks much more clean than:


while (TRUE)
{
hr = m_ddraw->FastBlt(..)

if (FAILED(hr))
{
..bla bla
}
}


But bad luck, I guess..

PS: Thanks SiCrane.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!