MSVC++ Standard not inline functions?

Started by
19 comments, last by crazemanx 22 years, 5 months ago
Reading the documentation for MS Visual C++ it implies that inlining of functions is not supported in the Standard edition, only the Professional and Enterprise... is this correct? If so it sucks! Edited by - crazemanx on November 5, 2001 8:41:05 AM Edited by - crazemanx on November 5, 2001 8:41:43 AM
Advertisement
Can''t you simply do it that way?
e.g.
#define getrandom( min, max ) (( rand() % (int)((( max ) + 1 ) - ( min ))) + ( min ))
Huh??
yyy: That''s not inlining a function.. that''s defining a macro (which is very similar, but not exact). The only benifit of inline''s over macros (that i''ve found, and besides looks) is that you can overload an inlined function (aka, what if you want the same function for floats & ints and the ints version to use shifts, while the float version has to use muls/divs).

#define Div2i(num) (num>>1) //int version
#define Div2f(num) (num/2) //Float version

inline int Div2(int num)
{
return num>>1;
}

inline float Div2(float num)
{
return num/2;
}

As you can see, the inline is much simpler, because no matter what you''re working with, you can just call Div2, and not have to worry about ints or floats. Also, the format of inline functions is identical to regular functions (except for the "inline" part). Macros can be really good too though... because if you have 2 different structs (or classes) with the same members... you can use a single macro without overloading it. So, having the inlines can be/is important depending on how you look at it.

Billy
quote:Original post by yyy
Can''t you simply do it that way?
e.g.
#define getrandom( min, max ) (( rand() % (int)((( max ) + 1 ) - ( min ))) + ( min ))

Yes, but then you lose all the benefits of inline functions, such as typechecking (which can be the cause of major bugs). You also note the number of parentheses needed to ensure that a macro is properly interpreted? Inline functions are a little clearer in that regard.

quote:Original post by crazemanx
Reading the documentation for MS Visual C++ it implies that inlining of functions is not supported in the Standard edition, only the Professional and Enterprise... is this correct? If so it sucks!

What did you expect? It''s a commercial product and there have to be incentives for you to buy the more expensive versions. If you want to write production code, you wouldn''t be using Standard version anyway (Pro''s not that expensive).

And if that still pisses you off, you can use one of the free compilers.
The standard Edition supports inlining. It just doesn''t support the fancy optimizations.

If you don''t believe me, try inlining a function and look at the generated asm.

The standard version even expands some of the std C functions inline (e.g. memcpy, strcpy, etc), which is kinda cool.

All in all, the standard version isn''t too bad.
==========================================In a team, you either lead, follow or GET OUT OF THE WAY.
One of the bigger advantages of inlining a function over using a macro is the ability to use curly braces and still return a value.

Try doing a while loop with curly braces in a macro and have it return a value.

However, you can do macros with multiple statements that return values. Here''s an example:

#define SetVec(V,x,y,z) (V[0] = x, V[1] = y, V[2] = z, V)

___________________________________

_______________________________
"To understand the horse you'll find that you're going to be working on yourself. The horse will give you the answers and he will question you to see if you are sure or not."
- Ray Hunt, in Think Harmony With Horses
ALU - SHRDLU - WORDNET - CYC - SWALE - AM - CD - J.M. - K.S. | CAA - BCHA - AQHA - APHA - R.H. - T.D. | 395 - SPS - GORDIE - SCMA - R.M. - G.R. - V.C. - C.F.
quote:Original post by NuffSaid
The standard Edition supports inlining. It just doesn''t support the fancy optimizations.

If you don''t believe me, try inlining a function and look at the generated asm.


Maybe I am barking up the wrong tree here, but here goes... My main concern here is in access functions obtaining private member variables from a class.

Here is a bit of example code:
  class MyClass{private:	int A;public:	int B;	int GetA() { return A; }} C;void main(){	int MyInt;	MyInt = C.GetA();	MyInt = C.B;}  


That is the complete source file, created as an empty Win32 Console Application. Compiling using the default Win32 Release configuration, with the added flag /FAs to generate asm code gives this:

; *** code ommitted by me; 13   : 	MyInt = C.GetA();	mov	ecx, OFFSET FLAT:?C@@3VMyClass@@A	call	?GetA@MyClass@@QAEHXZ	    ; MyClass::GetA	mov	DWORD PTR _MyInt$[ebp], eax; 14   : 	MyInt = C.B;	mov	eax, DWORD PTR ?C@@3VMyClass@@A+4	mov	DWORD PTR _MyInt$[ebp], eax; *** code ommitted by me?GetA@MyClass@@QAEHXZ PROC NEAR	; MyClass::GetA, COMDAT; 7    : 	int GetA() { return A; }	push	ebp	mov	ebp, esp	push	ecx	mov	DWORD PTR _this$[ebp], ecx	mov	eax, DWORD PTR _this$[ebp]	mov	eax, DWORD PTR [eax]	mov	esp, ebp	pop	ebp	ret	0?GetA@MyClass@@QAEHXZ ENDP	; MyClass::GetA; *** code ommitted 


It is my understaiding that functions defined within the class declaration are automatically expanded inline. Is this the case here? I dont know much about asm code but it appears to be making a function call here, and it is clearly much more expensive than simply accessing a data member directly.

Can anyone enlighten me as to why all this is needed just to return a variable?
Thanks, Nick.
Are you compiling a release build? Inlining''s disabled by default for a debug build.
Yup, definitely a release build.

This topic is closed to new replies.

Advertisement