Why to C over C++?

[yyrkoon 250]

Well I was just talking with Rick via IRC, and showed him my C implementation, where he mentioned that C++ will aways try to inline functions where C has to be told.

 

So after adding inline to the C implementation . . .

-------------- Build: Debug in test (compiler: GNU GCC Compiler for MSP430)---------------

msp430-gcc.exe   -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=msp430g2553    -c main.c -o obj\Debug\main.o
msp430-gcc.exe  -o bin\Debug\test.elf obj\Debug\main.o   -Os -Wl,-gc-sections,-u,main -mmcu=msp430g2553  
Output size is 9.21 KB
Running target post-build steps
C:\HighTec\msp430\bin\msp430-size D:\projects\Ctest\bin\Debug\test.elf
   text	   data	    bss	    dec	    hex	filename
    216	      0	      2	    218	     da	D:\projects\Ctest\bin\Debug\test.elf
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)
 

 

The code compiles down to the same exact size. That is for a single print statement of "hello world\r\n".

 

@@chicken, I never use ram unless absolutely necessary. I prefer to leave it for the calling stack.

[Rickta59 589]

So for a "reasonable" use case, these 6 PWM drivers will use about 150 bytes of flash and 20 bytes of RAM. On the C side, I could fix this stuff with only 50 bytes of flash and 12 bytes of RAM.

It would be interesting to see this fleshed out in 'C' so some real comparisons can be made.

 

-rick

[yyrkoon 250]

More testing . . . I was *thinking* that with multiple calls to the print methods of each of these implementations that C would take a slight lead. But I was wrong. C++ actually comes in much smaller. However, because the difference is once again fairly big, I suspect there may be some optimization that can be done here.

 

Each implementation calls print->string method 5 times( two calls are "\r\n" ), and print->number 2 times. Test again are using the GNU toolchain.

 

C implementation:

 

-------------- Build: Debug in test (compiler: GNU GCC Compiler for MSP430)---------------

msp430-gcc.exe   -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=msp430g2553    -c main.c -o obj\Debug\main.o
msp430-gcc.exe  -o bin\Debug\test.elf obj\Debug\main.o   -Os -Wl,-gc-sections,-u,main -mmcu=msp430g2553  
Output size is 11.04 KB
Running target post-build steps
C:\HighTec\msp430\bin\msp430-size D:\projects\Ctest\bin\Debug\test.elf
   text	   data	    bss	    dec	    hex	filename
    600	      0	      2	    602	    25a	D:\projects\Ctest\bin\Debug\test.elf
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)

 

C++ implementation.

 

-------------- Build: Debug in msp430 (compiler: GNU GCC Compiler for MSP430)---------------

msp430-g++.exe   -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=msp430g2553    -c main.cpp -o obj\Debug\main.o
msp430-gcc.exe  -o bin\Debug\msp430.elf obj\Debug\main.o   -Os -Wl,-gc-sections,-u,main -mmcu=msp430g2553  
Output size is 9.99 KB
Running project post-build steps
C:\HighTec\msp430\bin\msp430-size D:\projects\msp430\bin\Debug\msp430.elf
   text	   data	    bss	    dec	    hex	filename
    440	      0	      2	    442	    1ba	D:\projects\msp430\bin\Debug\msp430.elf
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)

 

The difference is as you can see exactly 160 bytes on target( estimated ). What exactly needs to be done to bring the difference down on the C implementation, I am not sure, but to be honest I really do not care. At this point, I am tired of baby sitting C, and would use C++ just for less hassle. With that said though, there is nothing stopping me from writing the code as C, and compiling it as C++( naming the file *.cpp may be enough for the compiler to handle most things ). We'll see, I will test that in a bit.