• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 294
  • Last Modified:

Inline functions

Is there some kind of a problem with inline functions when using MFC?

I have written a class which manages arrays and it has several inline functions. For example, the operator [] is inline.

First of all, if the header and the body of a function are in different files and the function is declared inline, the program does not link! If I put the body inside the class declaration (which is supposed to make it automatically inline), the program links. However, there is no difference from the not-inline function. I measured times and realized that a simple array (straightforward memory usage) works far more quickly than a class which has a simple array as its data member and uses inline [] operator!

Am I doing something wrong? If so, please point it out. If not, could someone explain to me, what is the point of writing a class for managing arrays when it wastes tons of time?
0
Lescha
Asked:
Lescha
  • 2
1 Solution
 
fl0ydCommented:
Whenever using inline functions the function has to reside in the header file. It doesn't matter whether you use automatic inlining or define the function after the class definition. A violation to this rule will result in code that doesn't compile, no matter what compiler you are using.

When you say "there is no difference" did you look at the produced code? I doubt that you can measure a difference in time unless actually measuring the clock cycles with rdtsc. If you use the 'inline'-keyword with msvc it is not guaranteed to be inlined. Msvc decides whether inlining does improve the speed of code or not, no matter if you specified an inline-keyword or not. It usually beats the developer at deciding properly. If you are *ABSOLUTELY SURE* that you need to inline a function you can use __forceinline to override the compiler's decision.

I'm not sure what exactly you compared to find out that an array is far more quickly than a class containing an array. First of all, object oriented programming wasn't invented for speed, but rather safety and managability of code. Obviously, if there is more code to execute it will most likely not be faster. But...

#define DIMENSION 100

class array_class {
    unsigned char _array[DIMENSION];
public:
    unsigned char& operator [] ( int index ) { return _array[index]; }
} A;

unsigned char a = A[10];

shouldn't be noticably slower than

unsigned char B[DIMENSION];
unsigned char b = B[10];

if it is slower at all.
0
 
LeschaAuthor Commented:
Yes, well, the problem is I work with dimensions on the scale of 1000000 rather than 100...

As for how I measured: with GetCountTick or something like that (returns elapsed ms). And I didn't even need the function to measure, it is _noticeably_ slower!
0
 
fl0ydCommented:
Did you try my source with millions? There should be no difference in release build. If you want to be sure you will have to look at the compiler output -- turn on assembly listing generation for the files in question and you will see much clearer what's going on.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now