Any difference in the binary?

[ninja9578]

class foo {
public:
   foo(void) : f1("test"), f2(5){}
private:
   string f1;
   int f2;
}

class bar {
public:
   bar(void) : f2(5), f1("test"){}
private:
   int f2;
   string f1;
}

Does the order make any difference in performance?


Also, any difference in this?

void * ptr = NULL;
if (ptr){  something }

...

if (ptr != NULL) { something }

different compilers warn about these things, but I'm almost certain all compilers would be smart enough to do the != NULL implicitly.

[ltcmelo]

Perhaps it's interesting to take a look at the code generated by your compiler?

There might be some peculiarities concerning alignment and padding depending on the types you use and their order of declaration (note that different std::string implementations can affect that).

[Chris_F]

If in doubt, test and find out.

sizeof(foo)

sizeof(bar)

[nuzzle]

You forgot to worry about which is faster, this

if (ptr != NULL) { something }

or this

if (NULL != ptr) { something }

[ninja9578]

Wait, there is a difference? They wont both boil both to

mov [ptr], ax
jcxz [whatever]

?

I thought ordee didn't matter for primitives?

[Speedo]

Does the order make any difference in performance?

In performance? I don't really see how it would. Member ordering can affect the object's size though, depending on compiler settings and so on (probably no difference for a simple case like that though). I know I have a game development book somewhere that talks about being aware of the impact of member ordering. I doubt it's worth worrying about unless you have strict memory constraints though.

[Eri523]

[...] They wont both boil both to

mov [ptr], ax
jcxz [whatever]

?

Well, no. Aside from the fact that these statements are 16-bit, they're completely unrelated.

My VC++ 2010 (with default release settings) generates something much more convoluted for that simple pointer comparison, even when I tried to isolate it as much as possible inside a tiny function while at the same time trying not to provoke the compiler to optimize it away. I didn't want to spend too much time fiddling around with that though.

[ninja9578]

Yes, I wrote that as an example. jcxz also works with cx, not ax :P

I see no difference.

#include <iostream>
#include <ctime>
#define COUNT 0xFFFFFFF

using namespace std;

int main(){
    volatile void * ptr = NULL;
    clock_t start = clock();
    for (volatile unsigned int x = 0; x < COUNT; ++x){
	   volatile bool temp = (ptr != NULL);
    }
    cout << "ptr != NULL: " << clock() - start << endl;
    
    
    start = clock();
    for (volatile unsigned int x = 0; x < COUNT; ++x){
	   volatile bool temp = (NULL != ptr);
    }
    cout << "NULL != ptr: " << clock() - start << endl;
    
    
    
    ptr = (void*)0xDEADBEEF;
    start = clock();
    for (volatile unsigned int x = 0; x < COUNT; ++x){
	   volatile bool temp = (ptr != NULL);
    }
    cout << "ptr != NULL: " << clock() - start << endl;
    
    
    start = clock();
    for (volatile unsigned int x = 0; x < COUNT; ++x){
	   volatile bool temp = (NULL != ptr);
    }
    cout << "NULL != ptr: " << clock() - start << endl;
}

ptr != NULL: 714833
NULL != ptr: 714846
ptr != NULL: 715109
NULL != ptr: 715322

[Eri523]

jcxz also works with cx, not ax :P

Yes. And that is why I wrote the two instructions are unrelated.

I sent your code from the last post through my VC++ as well, again with default release settings. The first surprise were the deviations in the results of the four loops I got on my P4 1.8 GHz:

ptr != NULL: 703
NULL != ptr: 813
ptr != NULL: 953
NULL != ptr: 969

But that may be the result of CPU load fluctuations during runtime of the test code that were unrelated to the code itself. (I only ran it once due to laziness... )

For those who are interested I have attached the code listing produced by the compiler. (I used the .gz format because I'm not sure about the .zip support on *nix.)

The funny thing with this is that the compiler obviously has optimized away the essential statement at all except for the constant write to temp (the mov BYTE PTR _temp$22336[esp+24], bl instruction). That may look like a violation of the volatile keyword (even after the MS definition) but IMO it not necessarily is: Is there any notion of local volatile variables at all? And even if there is: As long as no pointer to the local volatile variable gets passed outside the function owning the variable, the compiler has full control over that variable and can safely ignore the volatile, can't it?

Yet again that's one of the threads that looks like it's going to get much more complicated than it appeared to be originally...

[monarch_dodra]

The C/C++ standard mandates that the attributes inside a structure MUST be ordered the same as they are declared. The compiler is allowed to insert padding for alignment and optimization reasons.

As such, the size of your structure depends on the order you declare your attributes.

Now, given two orderings that give a structure of the same size, both should be equally fast. The ONLY way (I can think of) where there would be a difference would be on platforms that can't "deference a pointer+offset" in a single cycle, in which case, the first element of the struct would be accessed faster than other elements. That said, almost all platforms since the 8086 can do it.

So my answer is this:
As long as you correctly order your arguments (largest to smallest is a good rule of thumb), you should be fine. That said, even if you don't, I doubt you'd see a difference...