Tag Archives: C++

To all my dear pure C developers

I’ve spent quite some time integrating a lot of C code from different people to turn it into production-ready software. It is surprisingly interesting, but the first few days are usually quite painful for these reasons:

Logs

Many C developers have done hundreds of projects, they always need logging but when an error occurred they still like to do some standard fprintf(stderr, ... );. I use something similar to this. But you should at least insert the __FILE__ and __LINE__ macros. It will save lots of people hours of debugging.

Use the warnings

On gcc, you should always have -Wall -Werror (and -Wextra when possible) enabled. This will avoid a lot of bugs.

Error code

Do not reinvent your own error codes. Use the the POSIX error codes.

Error handling (and logging)

Check the return codes, log the abnormal ones.
Sample code that can make you lose quite some time:

1
2
3
FILE * f = fopen("logs.txt","w");
if ( ! f )
   goto end;

THIS IS WRONG, we should have something like this:

1
LL_WARNING("Could not open log file !");

using this kind of macro.

Dirty numbers

You know how to count in bytes, how pointer and offsets work, that’s great. But you should also know that you can always replace this by a sizeof(). That way, we won’t have to be as smart as you to read your code (and fix it).

Great POSIX standard headers and libraries

The standard errors code already cover a lot of cases you could encounter.
You can use booleans including stdbool.h, it’s even standard.
Argument parsing is standard, don’t make your own strange argument parsing code that won’t even (fully) document.

Great non standard libraries

Like json-c to serialize your data, or zeromq to handle network communication.

Bad memory management

Leaks and buffer overflow can happen. And so as many other issues out there. This is why you should use valgrind frequently.

“It worked fine on my computer” is never a good excuse, but on C it makes lot less sense. There are many memory mistakes that you will miss on a 64bits Linux with 8GB of RAM and that you will definitely see on a 32bits Linux with 128MB of RAM (which is high-end in the embedded world).

Malloc is not your (only) friend

In most cases, allocating things on the stack is enough. A lot of developers seem to forget it. And it’s usually the same who forget to free their mallocated pointers.

A lot of people seem to forget that you have the right to allocate arrays dynamically on the stack. Declaring an array like that is ok:

1
uint8_t bin[strlen(hex)/2];

Use a debugger

Debugger will make you save a lot of time especially when they are well integrated in IDEs like netbeans. You can just immediately know why something crashed or why the programmed stalled for no apparent reasons.

Tiny note on debugging: If you have strange issues and can’t seem to get a correct stacktrace, it’s probably a stack-smashing issue. Compile your code with the -fstack-protector flag, this will report the stack smashing (most probably a buffer overflow) as soon as it occurs.

Optimization

In most of the cases, your compiler will do a great job. Don’t use inline, prefetching or any other crazy optimization unless you really know what you do.

Don’t re-create unreadable network protocols

Use something simple readable like JSON over zeromq. It’s easier to create, debug, monitor. Please don’t create a new binary protocol.

Learn other languages

There are many scenarios where using something else (like python or go) will give you a huge productivity boost, it will probably run slower and produce bigger binaries but in most of the cases it really doesn’t matter. When making network servers, python, go, node.js (java in some ways) make the job a lot easier.

Makefile

Use standard tools like autoconf, automake or create a simple and easy to maintain Makefile like this one.

IDEs

Spend the time to learn how to use a an IDE like netbeans or take the full advantage of vim.

Stupid C++ vs C# performance comparison

I found out that there is real test than the little one i did here. In fact the main interest of the post is this spreadsheet :

I recently did a simple and stupid comparison test between C++ (g++) and C# .Net (mono).

My point here is that C# can actually be considered as a very fast language. It allows automatic hardware-specific optimization. The only real drawback you have in the .Net framework is the garbage collector. It prevents the C# .Net it from being a realtime language/framework. But does it really matter for you ?

The purpose of the following test is to show that C++ isn’t faster than C# “as is”. I KNOW C# can not be faster than C++ because C# can do few hardware specific optimizations when you can do all of them in C++, because all the systems calls have to be done in C/C++ and because there’s no such thing like Template and forced inlining in C#.

But if you’re searching for arguments to choose C# .Net over native C++, you should also consider these :

SO ! Here is the test…

I wrote these two sample programs :

One in C++ :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <iostream>
using namespace std;
 
long stupidThing( long nb ) {
	long out = 1;
	while( nb > 0 )
		out *= nb--;
 
 
	return out;
}
 
int main() {
 
	long total = 0;
 
	for( int i = 0; i < 1000000; ++i )
		for( long l = 0; l < 100; ++l )
			total += stupidThing( l );
 
	cout << "Total : " << total << endl;
 
	return 0;
}

One in C# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
using System;
 
namespace test {
        class Program {
                static long stupidThing( long nb ) {
                        long ret = 1;
                        while ( nb > 0 )
                                ret *= nb--;
                        return ret;
                }
 
                static void Main( string[] args ) {
 
                        long total = 0;
 
                        for ( int i = 0; i < 1000000; ++i )
                                for ( long l = 0; l < 100; ++l )
                                        total += stupidThing( l );
                        Console.WriteLine( "Total : {0}", total );
                }
        }
}

First of all, I open a shell in real-time priority, because I don’t want my other processses to mess with my tests :

1
# rtprio 99 bash

Then I compile the two programs :

1
2
# gmcs test.cs
# g++ -O4 test.cpp -o test

And then I launch my test :

On a 64 bits host :

1
Kernel : 2.6.9-023stab051.3-smp #1 SMP Wed Nov 4 18:36:34 MSK 2009 x86_64 x86_64 x86_64 GNU/Linux
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# time ./test ; time ./test ; time ./test ; time mono test.exe ; time mono test.exe ; time mono test.exe
Total : -6192109806162068864
 
real    0m12.433s
user    0m12.394s
sys     0m0.049s
Total : -6192109806162068864
 
real    0m12.415s
user    0m12.411s
sys     0m0.014s
Total : -6192109806162068864
 
real    0m12.430s
user    0m12.411s
sys     0m0.026s
Total : -6192109806162068864
 
real    0m10.311s
user    0m10.287s
sys     0m0.029s
Total : -6192109806162068864
 
real    0m10.254s
user    0m10.247s
sys     0m0.011s
Total : -6192109806162068864
 
real    0m10.250s
user    0m10.255s
sys     0m0.012s

C# clearly beats C++ here. Well

On a 32 bits host :

1
Kernel : 2.6.30-2-686 #1 SMP Fri Dec 4 00:53:20 UTC 2009 i686 GNU/Linux
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# time ./test ; time ./test ; time ./test ; time mono test.exe ; time mono test.exe ; time mono test.exe
Total : 100461056
 
real    1m10.927s
user    1m7.376s
sys     0m0.056s
Total : 100461056
 
real    1m12.590s
user    1m8.976s
sys     0m0.020s
Total : 100461056
 
real    1m13.279s
user    1m9.532s
sys     0m0.056s
Total : -6192109806162068864
 
real    2m22.492s
user    2m15.260s
sys     0m0.136s
Total : -6192109806162068864
 
real    2m23.002s
user    2m15.760s
sys     0m0.104s
Total : -6192109806162068864
 
real    2m25.102s
user    2m17.709s
sys     0m0.144s

C++ beats C# here, but in 32 bits C++ use other types whereas C# use the same. In C# long is always 64 bits, in C++ it can be 64 bits or 32 bits (depending on the current architecture).