Code and Data size of a class

I'm trying to optimize a library for space usage.

Is there a way to get the code size and data size of a class at compile time?

there is a tool for dumping the symbol table called avr-objdump that should do what you want.

Google arduino avr-objdump for tips on how to use it.

mem: there is a tool for dumping the symbol table called avr-objdump that should do what you want.

Google arduino avr-objdump for tips on how to use it.

Thx I found another one avr-nm -Sg Test.elf outputs a more compact list of sizes.

That’s a better choice if you only want the symbol table. The more verbose avr-objdump also provides a disassembly listing which can be useful if you want to explore why the code is a big as it is.

wdl1908: I'm trying to optimize a library for space usage.

If you're looking to reduce space, then there's only so much you can do with the class itself unless you plan to rewrite the code. So looking at static, global and class storage, and how much each takes in space is important. For that, you can take a rough estimate by looking at the code - char/int/long sizes and where they are used. Of course, for finer control the suggestions already made are more accurate.

[quote author=David Pankhurst link=topic=66207.msg485443#msg485443 date=1310372789]

wdl1908: I'm trying to optimize a library for space usage.

If you're looking to reduce space, then there's only so much you can do with the class itself unless you plan to rewrite the code. So looking at static, global and class storage, and how much each takes in space is important. For that, you can take a rough estimate by looking at the code - char/int/long sizes and where they are used. Of course, for finer control the suggestions already made are more accurate. [/quote]

Yes code review and choosing the proper type has already resulted in a lot of code reduction. Using bit fields instead of boolean types has also reduced a lot even in the code. Rearranging bit fields has some surprising effects some bad some good.

FYI, a few hints for making your code as tiny as possible:

a) avoid floating point.

b) use the smallest sized integer you can get away with. If your loop goes from 1 to 100, don’t use anything bigger than a ‘char’ for the loop variable.

c) minimize use of ‘if’ blocks. Use conditional expressions when practical (they compile a bit smaller from what I can tell).

d) consolidate repeated operations, even trivial ones, into utility functions.

e) avoid ‘inline’ except for uber-trivial things. A function call doesn’t take that many instructions. Inlining, however, can add up bytes pretty fast.

f) avoid lots of parameters to functions that are called a lot. Use global variables or pass a pointer to a structure. Depending on how often the function is called, and what it takes to use a struct or gobals in lieu of parameters, you can get about 2 bytes’ savings for every byte of parameter you avoid.

g) don’t be afraid to use ‘goto’ regardless of how ugly it makes your code look. If the goal is tiny code, deal with it. Duplicating code or having multiple exit points is likely to cost you in size. Or not, depending.

h) get familiar with code-base memory for string data (aka PSTR). constants are initialized at boot time, and eat up RAM space as well as program memory space. See <avr/pgmspace.h> and related docs like this:
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array