不同的C ++编译器exec。大小 [英] Different C++ compiler exec. sizes
问题描述
出于好奇，我想测试来自不同编译器的相同
程序的可执行文件大小...
我测试的2个编译器（两个老的，故意的）是Borland C ++ 3.1
和DJGPP 2.03 ...
这个程序只不过是一个简单的hello world程序，使用的是
iostream头文件......
我用这两个不同的
编译器编译和链接（两个副本）... Borland c ++ 3.1编译器给了我一个可执行文件，其中
大小，如20-30KB（我不记得），DJGPP给了我一个可执行文件
，大小为220-240KB。 ..
我可以在这里假设两件事...... DJGPP可以产生更多的东西
复杂的可执行文件（有点奇怪）或DJGPP的标题文件
包含有点不同的信息....
有人见过类似的东西吗？有谁知道为什么？
" Chris Mantoulidis" <厘米**** @ yahoo.com>在留言新闻中写道：a8 ************************** @ posting.google.c om ...
我可以在这里假设两件事......要么DJGPP产生更多的混合可执行文件（虽然有点奇怪）或者DJGPP的头文件
包含有点不同的信息...... / blockquote>
不，很可能与可执行代码
和头文件没有任何关系。我怀疑在一个案例中，您的库代码包含在可执行文件中的
，另一个案例中它们位于单独的运行时文件（DLL或共享库）中。
在一些简单的程序中，运行时库的大小使用户代码相形见绌。
>出于好奇，我想测试来自不同编译器的相同程序的可执行文件大小...
我测试的两个编译器（旧的，故意的）是Borland C ++ 3.1
和DJGPP 2.03 ......
这个程序只不过是一个使用
iostream头文件的简单的hello world程序...
我用这两个不同的编译器编译和链接（两个副本）... Borland c ++ 3.1编译器给了我一个大小如20-30KB（我不记得了）和DJGPP的可执行文件给了我一个大小如220-240KB的可执行文件......
我可以在这里假设两件事...要么DJGPP产生更多的
复杂的可执行文件（有点奇怪的）或DJGPP的头文件
包含有点不同的信息....
任何人都看到过类似的东西？任何人都知道为什么？
可以解释你所看到的差异的一件事是，一个
编译器将调试信息存储在可执行文件本身中而
其他将调试信息存储在一个单独的文件中。如果您使用两个编译器进行优化构建而没有
调试信息，那么您可能会获得更明智的数字。
对于小型甚至中型程序，运行时库通常会占可执行文件大小的很大一部分。使用小程序
你自己的代码只占总b / b
可执行文件大小的一小部分（如果它超过200，我会被高估）
字节）。因为您只使用一个小程序进行测试，所以很重要的是，
意识到您找到的可执行文件大小并非必要，而b $ b代表大型程序。如果你使用大量的b $ b（非平凡）程序进行相同的测试，那么两个
编译器之间的差异可能会变小。是否静态或动态地链接运行时库可以产生很大的不同。使用不同的
运行时库可以大大减少小型
程序的可执行文件大小。我已经能够使用libtinyc运行时库生成MSVC小到
2.5 KB的可执行文件（与带有
标准运行时库的28KB相比）。
链接器的质量和链接器设置也可能对可执行文件大小产生一些影响。最后，
编译器的优化设置也可能产生（小）差异。
如果你真的有兴趣使你的可执行文件小到
可能，你会发现这个页面是一个有趣的读物：
http://freespace.virgin.net/james.br...als/minexe.htm
-
Peter van Merkerk
peter.van.merkerk（at）dse.nl
文章< a8 ***** *********************@posting.google.com>，
cm **** @ yahoo.com 说...出于好奇，我想测试来自不同编译器的相同
程序的可执行文件大小。 ..
我测试过的两个编译器（旧的，故意的）是Borland C ++ 3.1
和DJGPP 2.03 ...
BC ++ 3.1生成本机DOS可执行文件。 DJGPP为DOS扩展器生成可执行文件
，这基本上是一个小而简单的操作系统，可以将
链接到您的可执行文件中。您在DJGPP
可执行文件中看到的大部分内容都是DOS扩展程序代码。
DOS扩展程序主要允许程序访问大量
内存直接与BC ++ 3.1程序相比，即使你的机器有数百兆字节的内存，也只限于
到640K。
-
后来，
杰瑞。
宇宙是自己想象的虚构。 br />
Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...
The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...
The program was nothing but a simple hello world program using the
iostream header file...
I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don''t remember) and DJGPP gave me an executable
with size like 220-240KB...
I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP''s header files
contain kinda different info....
Anyone seen anything like that? Anyone know why?解决方案
"Chris Mantoulidis" <cm****@yahoo.com> wrote in message news:a8**************************@posting.google.c om...
I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP''s header files
contain kinda different info....
Nope, most likely the different has nothing to do with the executable code
nor the header files. I suspect in one case you have the library code included
in the executable and in another they are in seperate runtime file (DLL or shared library).
On little trivial programs the size of the runtime libraries dwarf the user code.
> Out of curiosity, I wanted to test executable file sizes of the sameprogram from different compilers...
The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...
The program was nothing but a simple hello world program using the
iostream header file...
I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don''t remember) and DJGPP gave me an executable
with size like 220-240KB...
I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP''s header files
contain kinda different info....
Anyone seen anything like that? Anyone know why?
One thing that may explain the difference you are seeing is that one
compiler stores the debug information in the executable itself while the
other stores the debug information in a separate file. You are more
likely to get more sensible numbers if you do an optimized build without
debug information with both compilers.
For small and even medium sized programs the runtime library often
accounts for a large part of the executable size. With small programs
your own code accounts for only a very small fraction of the total
executable size (I would be surpriced if it would be more than 200
bytes). Because you only tested with a small program, it is important to
realize that the executable sizes you find are not necessarilly
representative for larger programs. If you do the same test with a large
(non-trivial) program, it is likely that the difference between the two
compilers has become smaller. Whether the runtime library is linked
statically or dynamically can make a big difference. Using a different
runtime library can dramatically reduce the executable size of small
programs. I have been able to produce executables with MSVC as small as
2.5 KB using the libtinyc runtime library (compared to 28KB with the
standard runtime library).
The quality of the linker and the linker settings may have some impact
on the executable size as well. Finally optimization settings of the
compiler may make a (small) difference too.
If you really are interested in making your executables as small as
possible, you may find this page an interesting read:
http://freespace.virgin.net/james.br...als/minexe.htm
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
In article <a8**************************@posting.google.com >,
cm****@yahoo.com says...Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...
The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...
BC++ 3.1 produces native DOS executables. DJGPP produces executables
for a DOS extender, which is basically a small, simple OS that gets
linked into your executable. Most of what you''re seeing in the DJGPP
executable is the DOS extender code.
The DOS extender primarily allows your program to access large amounts
of memory directly, compared to the BC++ 3.1 program, which is limited
to 640K, even if your machine has hundreds of megabytes of RAM.
--
Later,
Jerry.
The universe is a figment of its own imagination.
这篇关于不同的C ++编译器exec。大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
