C++ constructors compilition

Question

I have problem with compiling of constructors, when I compile program on VC6 my constructors have memory allocation (sub esp, X), but when I compile on VC9 my constructor not have it.

Who know where problem? I think that problem in project settings, but where I dont know.

VC6 (Visual Studio 6 + SP3):

VC6 assembly

VC9 (Visual Studio 2008 + SP1):

VC9 assembly

Class:

class MyClass
{
public:
            MyClass();
    virtual ~MyClass();
    // ----
    BOOL    Function1(LPSTR Arg1);
    BOOL    Function2(LPSTR Arg1);
    BOOL    Function3(LPSTR Arg1);
    // ----
private:
    char    Member1[1000][20];
    int     Member2;
};

Code:

MyClass::MyClass()
{
    this->Member2 = 0;
}

MyClass::~MyClass()
{

}

Code are identical on VC6 and VC9

P.S.: Problem in different compilation for one code when need make identical result of compilation.

P.S.(2): @greatwolf - I'm pretty sure that problem not in VC6, problem in project settings, but i dont know where it option. Target - 100% identical assembled code (byte to byte). Project on VC6 and project on VC9 in debug mode, but apparently with different options.

Is this assembly generated with release or debug configuration? Make sure, you're looking at assembly without optimization first. — Sam, Nov 17 '13 at 01:20
You're not going to get identical results of compilation from two different compilers. Otherwise they wouldn't be different. NB Member initializations should use the syntax provided for the purpose, other you're doing it twice. — user207421, Nov 17 '13 at 01:21
I think the more interesting question would be (not that it's actually all that interesting): why did VC 6 allocate a bunch of memory on the stack that it didn't need or use? — Michael Burr, Nov 17 '13 at 01:22
This question seems fine to me as it stands now. The OP has illustrated what they've done, what they got and what the problem is. +1 from me. — quant, Nov 17 '13 at 01:25
@ausairman: I don't think the OP has really described the problem very well. There's no reason to expect different compilers to generate the same code (as EJP mentioned), so the OP should explain why having different code gen from different compilers is a problem for him. — Michael Burr, Nov 17 '13 at 01:30
@MichaelBurr Well I know I have often asked questions where I thought I had found an error but was told that this is what you would expect because . There's nothing wrong with being mistaken, important thing, IMO, is to outline what you've done, what you got and what you expected, that gives answerers enough to go on... — quant, Nov 17 '13 at 01:32
An example that I think is quite interesting of a C compiler generating different code because a local variable name changed from `sizeOfInput` to `sizeOfInputt`: http://stackoverflow.com/questions/4575697/unexpected-output-from-bubblesort-program-with-msvc-vs-tcc — Michael Burr, Nov 17 '13 at 01:34
@ausairman: I agree that wondering why something like this might happen (even if the answer is "for no particular reason"). However, the OP seems to indicate that this is more than curiosity and that it's a problem for some reason. I think it's reasonable for the question to have some background on why it's a problem. — Michael Burr, Nov 17 '13 at 01:38

score 1 · Answer 1 · answered Nov 17 '13 at 01:21

1

The disassembly above looks completely unoptimized. The extra stack allocation you are seeing probably just happens to be boilerplate code generated by VC6 in an unoptimized build.

I'd suggest building it as release and inspecting the disassembly again. You can put in an inline-assembly breakpoint so it's easier to locate in the debugger:

MyClass::MyClass()
{
  __asm { int 3 }
  this->Member2 = 0;
}

answered Nov 17 '13 at 01:21

greatwolf

20,287
13
71
105

There's no need for a debugger - just use the `/FAsc` or similar option and the compiler will generate assembly files for you. – Michael Burr Nov 17 '13 at 01:23
@MichaelBurr yes but in an optimized build you can expect the assembly code to be quite mangled and hard to interpret. With the hard-coded breakpoint above you can quickly zero in on the target location of interest. – greatwolf Nov 17 '13 at 01:26
If it's the same assembly code, why would it be any more or less hard to interpret? Also, I seem to remember that Microsoft's compilers turn off optimizations in functions that contain `asm` blocks. I'm not sure if this is true anymore with the current compilers, but you might be shooting yourself in the foot with the `asm` block if you're looking for optimized codegen. Not to mention that even a seemingly insignificant change in source code may cause surprising changes to the codegen - see my link to an old SO question about a bubblesort problem in the comments above. – Michael Burr Nov 17 '13 at 01:45
@MichaelBurr Very interesting point! I did not expect a change in variable name to have such an impact. But to be fair though that code had UB so pretty much anything goes. – greatwolf Nov 17 '13 at 01:59
@greatwoelf: the UB is what caused the guy to post a question about the behavior, but even if you remove the UB, the codegen difference based on the different variable names remains. So, the real takeaway is that as far as codegen goes, as long as it behaves according to spec you can't rely on any particular codegen (though you could complain about the quality if you wanted). – Michael Burr Nov 17 '13 at 02:35

C++ constructors compilition

1 Answers1