mfc, VC++ Question - obj file

by **Kelly C.** » Sun, 23 Nov 2003 03:21:07 GMT

This is a VC++ question ...

I used "cl.exe" to build a hello world program, the object file and the exe
file are different every time for the same source code ("fc" command was
used to comparisons). Why is that?

Thanks.

by **Kelly C.** » Sun, 23 Nov 2003 08:09:55 GMT

My test program has just these lines:

#include <iostream.h>
int main()
{
cout << "hello, world!";
return 0;
}

===========
To demonstrate the test using VC++ 6.0:

cl /Fetest1.exe test.cpp
cl /Fetest2.exe test.cpp

fc test1.exe test2.exe

by **Joseph M. Newcomer** » Sun, 23 Nov 2003 17:15:41 GMT

(a) that is a silly thing to do. There is a nice IDE that makes it unnecessary to
explictly run cl.exe
(b) why do you care?
(c) it is probably some internal timestamp. (This assumes you have invoked it identically
each time you invoke it)

[There are some things in the world that are completely unworthy of worrying about. I've
been programming with Microsoft compilers for on the order of 20 years and it never once
occurred to me that there would be any value in comparing the object files or executables
for two identical runs. And I'm still not sure why there would be any value)
joe

Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

by **Mihajlo Cvetanovic** » Sun, 23 Nov 2003 17:35:10 GMT

Time stamps inside exes...

by **Adrian Kole** » Tue, 25 Nov 2003 03:23:24 GMT

I have run into this same exact problem before. IIRC, this didn't always
used to be the case; I think the compiler did indeed generate identical
object/executable code for any run.

unnecessary to

Sometimes it makes sense to provide a simple make file as it is a quick way
of 1) ensuring the exact commands used and 2) to communicate to someone else
the exact procedure without providing a project file.

When ensuring quality of an application, it can sometimes be very useful to
compare the executables before and after doing things that, in theory,
should have no impact but, in reality, do. For example when making
broad-sweeping changes to macros that impact allot of files. I personally
have found this helpful. Years ago, I did this when using MASM and it
helped me identify flaws in the source code. It duplicates, to a degree,
what ASSERT() does in the code--tests an assertion that would be impractical
to do with manual intervention.

worrying about. I've
it never once
or executables
value)

Don't you think this is a little harsh, Joe?

mfc, VC++ Question - obj file

mfc >> VC++ Question - obj file

mfc >> VC++ Question - obj file

mfc >> VC++ Question - obj file

VC++ Question - obj file

VC++ Question - obj file