It should not of itself add any significant overhead, but it may depend
on the options you have selected. Post your build log so we can see.

I just built your code for an LPC3180 (ARM9) device (because that is
what I had most immediately to hand), and ended up with 356 bytes as C
code, and 288 bytes as C++. Given that this was compiled with -O3, and
your code will likely optimise to an empty function, most of this code
size will be down to the crt0.s runtime start-up (which for an ARM9 is
generally larger than an ARM7, because of the MMU for example).

Note that the sizes I have quoited are for raw binary not hex. I have no
idea why C++ compilation made it smaller, but there is certainly no
reason for it to get larger.

If you use the C++ standard library, it is likely that your code will
get significantly larger, but for the code posted it should make little
or no difference.

Clifford

I used v4.0.2 for the record.

I've removed crt0.S from the build just to simplify my problem finding.
The Object files created by the C and C++ compilers are of comparable
sizes which leads me to think that I'm linking extra libraries.

I've been using the makefile which comes with WinARM and haven't changed
any of the flags that it defines.  Below is the build log:

Compiling C++: ../Source/main.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/main.lst
-Wcast-qual -MD -MP -MF .dep/main.o.d  ../Source/main.cpp -o main.o
Linking: Stage3.elf
arm-elf-g++  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=main.lst   -Wcast-qual -MD
-MP -MF .dep/Stage3.elf.d      main.o   --output Stage3.elf
-nostartfiles -Wl,-Map=Stage3.map,--cref -lc  -lm -lc -lgcc
-TADuC7020.ld
Creating load file for Flash: Stage3.hex
arm-elf-objcopy -O ihex Stage3.elf Stage3.hex
Creating Extended Listing: Stage3.lss
arm-elf-objdump -h -S -C Stage3.elf > Stage3.lss
Creating Symbol Table: Stage3.sym
arm-elf-nm -n Stage3.elf > Stage3.sym

--Stephen

Hi,

After lots of reading I came accross the "-nostdlib" option for linking.
After adding this the size of the reduced dramatically.

Thank you Clifford for your time and help.

--Stephen

I spoke to soon =O(  Although adding the "-nostdlib" option reduced the
size of the output significantly it also added a plethora of errors when
I link source which includes classes.  I'm guessing that some libraries
which were excluded when I add the "-nostdlib" option are actually
required.  Below is the build log:

Assembling (ARM-only): ../Source/startup.S
arm-elf-gcc -c -mcpu=arm7tdmi  -I. -x assembler-with-cpp -DDebug
-Wa,-adhlns=../Source/startup.lst,-gdwarf-2 ../Source/startup.S -o
startup.o
Compiling C (ARM-only): ../Source/irq.c
arm-elf-gcc -c -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/irq.lst
-Wcast-qual -MD -MP -MF .dep/irq.o.d -Wnested-externs  -std=gnu99
-Wmissing-prototypes  -Wstrict-prototypes -Wmissing-declarations
../Source/irq.c -o irq.o
Compiling C++: ../Source/main.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/main.lst
-Wcast-qual -MD -MP -MF .dep/main.o.d  ../Source/main.cpp -o main.o
Compiling C++: ../Source/uart.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/uart.lst
-Wcast-qual -MD -MP -MF .dep/uart.o.d  ../Source/uart.cpp -o uart.o
Compiling C++: ../Source/interrupts.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/interrupts.lst
-Wcast-qual -MD -MP -MF .dep/interrupts.o.d  ../Source/interrupts.cpp -o
interrupts.o
Linking: Stage3.elf
arm-elf-g++  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=startup.lst   -Wcast-qual
-MD -MP -MF .dep/Stage3.elf.d startup.o  irq.o   main.o uart.o
interrupts.o   --output Stage3.elf -nostartfiles
-Wl,-Map=Stage3.map,--cref -nostdlib -lc -lg  -lm -lgcc
-TADuC7020.ld
uart.o: In function `CUART::Instance()':
../Source/uart.cpp:8: undefined reference to `__cxa_guard_acquire'
../Source/uart.cpp:8: undefined reference to `operator new(unsigned
long)'
../Source/uart.cpp:8: undefined reference to `__cxa_guard_release'
../Source/uart.cpp:8: undefined reference to `__cxa_guard_abort'
../Source/uart.cpp:10: undefined reference to `__gxx_personality_sj0'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_RaiseException_Phase2':
rm -f ../Source/*.lst
../../gcc-4.1.1/gcc/unwind.inc:75: undefined reference to `abort'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_SjLj_Resume':
../../gcc-4.1.1/gcc/unwind.inc:238: undefined reference to `abort'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_SjLj_Resume_or_Rethrow':
../../gcc-4.1.1/gcc/unwind.inc:263: undefined reference to `abort'
collect2: ld returned 1 exit status

Thanks,

--Stephen

Stephen Roe wrote:
> After lots of reading I came accross the "-nostdlib" option for linking.
> After adding this the size of the reduced dramatically.

Yes, I have always used -nostdlib, although probably not for any other
reason than I copied it from a VxWorks build that I was migrating. I
have however found that it often overcomes problems people have with the
'wrong' standard library being selected based on other target options.
On the target I tested your code on, I had to rebuild the library to
support VFP hardware, so it was essential.

All that said, I am not sure why it would have linked any code that was
not explicitly called. Perhaps if you are still interested in getting to
teh bottom of this you could generate a map file and see what actually
got linked?

Clifford

> All that said, I am not sure why it would have linked any code that was
> not explicitly called. Perhaps if you are still interested in getting to
> teh bottom of this you could generate a map file and see what actually
> got linked?

I've attached the map file for the original example.  I've had to
compress it as it was too large to be attached in its native form.  I
don't see why
code is getting linked which isn't called.

--Stephen