PlayerTypes to CvPlayer* and vice versa

Hello
I have wrote this code:
I think it will work (this have a type of CvPlayer*).
I just wonder if there are more convinient ways to do this
e.g. some function that gets CvPlayer by PlayerTypes or such.

if (pLoopUnit->getOwnerINLINE() == this->getID()) should work, but I'm not certain what getID returns and I haven't tested it.

Edit: A C++ question for anybody that knows. - What is the diference between getOwner() and getOwnerINLINE()? And why is getOwnerINLINE() used most, if not all of the time.

"INLINE" means it is a macro rather than a function call. If you were to find the macro definition in the header files, the text would look rather messy. But, calling a function adds a little bit of runtime overhead. The macro runs a little faster, even if only by a few machine instructions. But for functions which are called very very often, this adds up. It is a small runtime improvement.

"INLINE" means it is a macro rather than a function call. If you were to find the macro definition in the header files, the text would look rather messy. But, calling a function adds a little bit of runtime overhead. The macro runs a little faster, even if only by a few machine instructions. But for functions which are called very very often, this adds up. It is a small runtime improvement.

Click to expand...

That makes sense, thanks.

davidlallen said:

"INLINE" means it is a macro rather than a function call.

Click to expand...

Actually, INLINE means that the function call is marked "inline" which is a hint to the compiler to place the instructions making up the function's body inline wherever that function is called.

Normally when you define a function its instructions are turned into machine code and placed in one place in the program/library. Every place that calls the function jumps to the function's memory address, executes its instructions, and jumps back (returns) to the caller. The overhead of performing these jumps is small but noticeable if done frequently or in a small loop.

Making a function inline tells the compiler that it is okay to copy the compiled instructions to wherever the function is called. You pay a cost in larger memory/file size for duplicating the instructions, but for small functions it can be worth it.

Notice that the definition for CvPlot::getOwnerINLINE() is omitted if _USRDLL is not defined.


This is used throughout the DLL, and I don't quite know why. My guess is that these same header files are used to build the EXE, and since the EXE will access the code via the DLL mechanism no inline functions are available. The thing is, that doesn't make much sense. There's no technical reason the EXE should be barred from directly accessing the objects created by the DLL, but then I'm not an experienced Windows programmer and only know a little about how DLLs work.

I can see a logical reason to keep SDK inline functions out of the EXE, and perhaps that's why they have it. Except all of the NUM_FOO_TYPES constant definitionsi n CvEnum.h are also guarded by this same mechanism, and I can't think of a reason for that unless it's to force the EXE to use getNumFooInfos(), but why?

Very informative, thanks. I was wondering what _USRDLL was used for. It looks like I don't need to waste my time searching the forum for an answer, since it's probably not there.

Just out of curiosity. Where is _USRDLL defined? In my SDK source, which was heavily modified before I got my hands on it, _USRDLL was used to determine how MAX_CIV_PLAYERS was defined and the code looked like it wouldn't work if USRDLL was not defined. To be on the safe side I commented it out and just defined MAX_CIV_PLAYERS myself.

Edit: Never mind. EmperorFool all ready answered my question here.

http://forums.civfanatics.com/showthread.php?t=347203&highlight=_usrdll

EmperorFool said:

There's no technical reason the EXE should be barred from directly accessing the objects created by the DLL. . . . Except all of the NUM_FOO_TYPES constant definitionsi n CvEnum.h are also guarded by this same mechanism, and I can't think of a reason for that unless it's to force the EXE to use getNumFooInfos(), but why?

Click to expand...

I'll go ahead and answer my own question. All of the #define'd constants and those inline functions would be compiled into the EXE. This would break if a DLL redefined any of them. Thus the EXE must go through getNumFooInfos() and not use inline functions.

BTW, _USRDLL is defined in the makefile using /D_USRDLL. If you use Code::Blocks or VS 2003 you must make sure to add it to your project's definition.