Do any of you, have any tricks on minimizing code object files? Or do you know of any compiler that particularly good at this job? I am not concerned with the size of the final executable, but rather with the sizes of the individual object files themselves. Normally I use VC6++, and i have set the optimization settings for the release version to minimize, but compared to the actual code written, the object files still seem bloated (because I know how small they could be written i assembly ). If it matters, I use C++ and rely heavily on abstract classes and inheritance hierachies. Thanks in advance for any help Regards Gorm

I'm a little curious: Why does it matter?
Not to imply that your question is stupid or irrelevent

[BEGIN FLAME-BAIT]
This is what I do know: ( I think )
C is a higher level language geared for system level programming. It still provides you with a "close to the metal" feeling so one could say for every line of C code you can see the amount of clock cycles being used much like assembly. Let's agree to disagree and move on if you don't like this...
C++ is higher level langauge with it's roots based in C with emphasis being placed on a different design model. C++ was designed to be able to compete with C but you no longer have the ablility to "see every clock cycle" being used in every line of C++ because of the abstraction tools it provides. This is C++ strongest and weakest point. Much like a double edged sword. And of course having the ability to slip in and out C++ to C/ASM creates much of the arguments that my reply is likely to generate (Like C++ being as fast as C/ASM and using C/ASM in an object oriented manner - depends on how you go about it)

OOP with C++ is not geared for "This line has this many clock cycles being used". That's what C is for. When C can't do it, that's what ASM is for. C++ is geared for high level design while being competitive with C/ASM, not a replacement.

So with my perspective in mind:
[END FLAME-BAIT]
To reduce object file size, don't use C++

(What I don't know is how to spell! lol)


Edited by - deadlinegrunt on May 5, 2001 9:07:24 PM

I would use small object files for a variety of reasons. Two examples which I have in mind is for online games, in which you want to transport code across the net (and not using java for speed), and since i have designed everything with platform independence in mind, the right type of code could even be sent. The second use could be for 64k intros, since I am an old scener, gone active again.
The recent application is for my procedural texture generator. I want the code that drive the textures to be as small as possible, so they don''t take so much space.
As for C++ and C. Although C is more lowlevel in design, since C is a subset of C++ you get exactly the same amount of control. Also, having implemented a compiler in university I think that a C++ program, of course, generating more code, should not generate so much extra code. Also, I have made a toolbox of C procedures. Even these take up much space.
I hope that answered any questions, and that some people will still be able to help.

Regards


Gorm

First off, thanks for the explination. I see where you are coming from now and where you are going. (I think)

I''m not trying to take your post off topic but what I''m not quite sure about is this: The object files produced are going to be vendor specific to the compiler used. Being that C++ has *standard definitions and rules* regarding language use, they are a bit more vague as far as implementation goes under the hood for the vendors to make things work i.e. MSVC vs Borland vs GCC etc. So perhaps when you are done with your project you could educate some of us by submitting an article on how you would use an object file directly. In the mean time I will do some research on my own to educate myself on this topic.

I realize you came here for an answer, not to teach me a subject. Thanks for the input.

YAP-YFIO,
deadlinegrunt

Object file sizes will indeed be compiler dependent, but there are some general rules:

The order of class members in memory is the same as in the class definition. Coupled with the fact that some datatypes are aligned on a certain n-byte boundary.

Consider the following example:

#include <iostream>class A{public: char a_; unsigned int b_; char c_;};class B{public: char a_; char b_; unsigned int c_;};int main(){ A a; B b; std::cout << "sizeof(a): " << sizeof(a) << std::endl; std::cout << "sizeof(b): " << sizeof(b) << std::endl; return 0;}

When I compile this simple program with VC++ 6 with default options, I get the following output:

sizeof(a): 12
sizeof(b): 8

This means that the order of your data members is important!

First results:

VC++ and Cygwin''s port of GCC produce code of comparable size. Borland''s free command line compiler, produce much slimmer code. In some cases the object files are even under half the size of those of cygwin and VC++.

Hi gorm,

I had the same thoughts regarding object sizes when I was first programming with DJGPP (GCC for DOS). The solution was: There were all the debug symbols in the object file!!!!

If you compile with gcc, simply add the option "-s" to prevent any debug-symbols from beeing linked in!

If you have "binutils" then you can do "strip xxx.o" where xxx is your object file after compilation to strip out any symbols.

Second point on object size is the standard library. For C++, it relies on templates that are beeing inlined, not function calls. If you program in C, then all standard function calls like "printf" are already in the DLL "msvcrt.dll" so the compiler doesn''t need to add them to your code. Also the windows GCC compiler uses "msvcrt.dll". The cool thing is that you can program in C++ but don''t ever #include but use "printf" instead you can have a c++ program the size of a c program! A small "hello world" program goes from 8k size to 80k size by a merely #include ...

Ah yeah,

I mean #include <iostream>, of course!