Misra C and other standards
The Misra C (http://www.misra.org.uk/) is a software development standard for the C language, created by the Motor Industry, aiming to facilitate the poartability and safety of the embedded codes.
In 2008, a version for C++ (called Misra C++) was published.
How much does it cost?
£10 for C, £15 for C++.
You don’t have money to buy it?
You could take a look in the free standard JSF++ (this is only for C++), that was created by the Joint Strike Fighter. It is almost as complete as Misra’s standard, and very useful even for non-embedded developers.
This document can be downloaded here:
http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc
Not enough?
Then take a look at the High Integrity C++:
http://www.codingstandard.com/HICPPCM/index.html
Three simple tricks to make your code more efficient
-
Declare your variables in the smallest possible scope
}
Notice that the object myString will only be used if x is greater than 10, but it is created in both situations. If x is smaller than or equal to 10, myString will be created and destroyed, but won’t be used anywhere.
A more efficient function follows:
}
In this case, if x is <= 10, myString will not be created.
-
Pass objects as const &
And it is called:
The function works fine, but when you pass myNums as a parameter to PrintVector, a new identical vector will be created. Depending on myNums’ size, this may consume a considerable time and memory size.
Wouldn’t it be better if we could use inside the function the same object that was created outside it?
That’s simple. All we have to do is to pass the object as a reference. For security reasons, this object shall be passed as a const. Like this:
-
Do not call unnecessary functions
This seems pretty obvions, but it is a commom mistake. Let’s go back to the previous example:
Notice that the function vector’s function size() is called for every iteration. This is not necessary, as we know that the size of the vector will not change inside the loop.
A better function would be:
x = x++
This is an undefined behavior (more or less). You write a code and falls in a rule that is not defined in the C or C++ standard. In this case, the compiler will do what it wants to do (yes, he is the owner of the game).
“So C++ is a shit!”
For example:
The result of this can be: x == 0, x == 1, x == 50 or your disk being formatted (ok, not the last one).
We don’t expect that a coder with some sanity will do this kind of crap, but there are some situations where you may fall in an undefined behavior unknowingly.
Let’s see more examples:
)
So you have:
What will be the value of “x”?
It looks simple. We know that an “unsigned char” can count from ZERO to 255. An “unsigned short” can count from zero to 65535. The value of 250 + 253 is 503. It will fit in “x”, so everything is correct, right?
No! The type of the result of an expression is defined by the operands. So, don’t be surprised if the result of “a + b” is 247 (and don’t be surprised if it is 503, as the rule says that the size of the return must be at least the size of the bigger operand).
And don’t try to do:
The correct way to do is to put at least one of the operands in the 16 bits base:
Or, in c++:
Integer Overflow
Have you ever seen a code like this?
You try it on Visual Studio and the result is -128. You compile it in a Linux platform using gcc and the result is -128. You try it on Mac and the result is -128.
Well, this happens because most of the compilers (if not all of them) just convert the ++x in pure Assembly increment, without checking if an overflow has happened or not, and most of the processors will proceed this way. But this is an undefined behavior and should be avoided. A new version of gcc may throw an exception if an integer overflow happens, for example.
}
}
}
}
This code may print “Hello World!!!!” or “WorldHello !!!!”, because the order of the function argument’s evaluation is not defined.
int main()
The “unbeliveable” result is:
num value=5 ref value=7
{
}
}
In this example, “Func()” creates a temporary array called data and returns a reference to it.
If this array was dynamically allocated, it wouldn’t be a problem (but the function’s caller would have to remember to delete it), but in the example, the data‘s memory will be freed when “Func()” is finished. So, helloWorld will be pointing to a region that may have anything.
The problems with allocation/deallocation mismatch
You have learned at school:
“If you have allocated it with malloc, deallocate it with free
if you have allocated it with new, deallocate it with delete
if you have allocated it with new[], deallocate it with delete[]“
All right, cool, you try to use it correct, but sometimes you forget and in the middle of your code you put:
…
delete data;
After a few years, you see the mistake. But this code was running for so long time and you have seen no errors related to this. So you decide to make a simple test:
while ( 1 )
{
data = new char[50];
delete data;
}
You run a memory manager with your program and you see that the ram consumption is not increasing. So it means that the delete is deleting correctly, even without the []!
Surprised, you make another test:
{
data = new char[50];
free( data );
}
And everything works fine! So maybe the compiler is smart enough? Or the story of “allocation/deallocation mismatch” is just a lot of bullshit?
Well my friend, the previous examples may work fine, but only for the basic data types (int, char, double…). The real problems will appear when you are working with C++ objects. And don’t expect that your compiler will help you those times.
Let’s see some examples where problems WILL appear:
malloc x new / free x delete
the malloc/free functions are C functions that just allocate and deallocate space in memory. New and delete are C++ functions with similar effects, but they also call the constructor/destructor of the objects.
If you are programming in C++, it is a good practice to always use new and delete, even if you are working with basic data types those don’t have a ctor/dtor.
Let’s see an example where a problem will appear.
You have the following class:
{
public:
X()
{
printf(“Inside the ctor\n”);
mpData = new char[20];
}
~X()
{
printf(“Destroying the object\n” );
delete[] mpData; //Very beautiful! []
}private:
char* mpData;
};
The allocation/deallocation of mpData if all right, but take a look at the following code:
{
X* obj = new X();
free( obj );
}
Your code compiles and func is executed, but the output is:
Inside the ctor.
The “Destroying the object” is not printed! It means that the delete[] mpData was not executed either, and the 20 allocated bytes will never be freed while the program is running. If you do:
{
func();
}
You’ll see that the memory used by the program will increase in each loop.
Now let’s suppose that you did:
delete obj;
You’ll see that the ctor is not called. When the delete[] is called in the dtor, your code will probably throw an exception, because mpData points to some junk memory.
And if you do:
free( obj );
“No allocation/deallocation mismatch! It is fine, isn’t it?”
Your code will work fine, but to use it like this is suicide. It is just reserving a space in the memory with the size of X to free it later, but X was not initialized. Any other function of the class you call will have great chances of failure, as no variable was initialized.
Let’s say that you have the function SetData:
{
assert( strlen( data) < 20 );
strcpy( mpData, data );
}
And you do:
obj->SetData( “abcde” );
free( obj );
You know what will happen, right?
For this reason, always use new and delete when programming in C++. Leave the malloc/free for C codes.
delete x delete[]
Ok, I’ve understood the problem with new/free, malloc/delete, but what’s the problem with new[] and delete (without the [])?
Using the same X class, do:
delete[] myArrayX;
What will the output be?
Inside the ctor
Inside the ctor
Inside the ctor
Inside the ctor
Inside the ctor
Destroying the object
Destroying the object
Destroying the object
Destroying the object
Destroying the object
Now try:
delete myArrayX;
This is what is called “undefined behavior”. In most of the compilers, the output will be:
Inside the ctor
Inside the ctor
Inside the ctor
Inside the ctor
Inside the ctor
Destroying the object
Only the dtor of the first object will be called. In some compilers, this code may crash.
You got it, right?
The Dynamic Arrays Magic!
Let’s create a dynamic array like this:
How can we know the size of this array later, in runtime?
“It is impossible!” – you say.
Well, we know that is is impossible. We’ve learned that in school. The books say that it is impossible. But…
Let’s say that your X class looks like this:
{
public:
X(){}
~X(){ printf(“Destructor\n” ); }
};
And then you write:
delete[] myArrayX;
Woah! This code has printed the word “Destructor” 10 times!
So, somehow, the program knows, in runtime, how many objects were allocated. What is the magic behind the delete[]?
Well, this is magic, really. It is not documented anywhere. But, after some reverse engineering, it is possible to find out what the program does.
I will be Mr. M now and I will show you the secret behind the two most used compilers: gcc and Ms Visual Studio.
What they to is to just write, before the fisrt element of the array, an integer that holds how many elements were created. Wanna see?
{
public:
X(){}
~X(){ printf(“Destructor\n” ); }
};
int main()
{
X* myArrayX = new X[20];
//let’s create a pointer that points to the 4 bytes
//before the array (I am in a 32 bits platform. I didn’t
//test it in 64 bits, but in this case you may have to
//go 8 bytes back).
int* p = (int*)( (char*)&myArrayX [0] – 4 );
printf(“Size of the array: %d\n”, *p );
delete[] myArrayX;
getchar();
return 0;
}
This is the magic =]
Just to remember you, this solution is not documented, it is not portable, it is not in C++ ISO and shouldn’t be used by anybody (unless you are a real underground programer, lol).
Twelve Days of Christmas
Here is one of the coolest codes I’ve ever seen (I’ve changed the argument’s declaration for it to compile in the new standard compilers):
LEAST LIKELY TO COMPILE SUCCESSFULLY:
Ian Phillipps, Cambridge Consultants Ltd., Cambridge, England
*/
#include <stdio.h>
int main( int t, int _, char* a)
{
return !0<t? t<3?
main(-79,-13,a+ main(-87,1-_,
main(-86, 0, a+1 )+a)):
1,
t<_?
main(t+1, _, a )
:3,
main ( -94, -27+t, a )
&&t == 2 ?_
<13 ?
main ( 2, _+1, “%s %d %d\n” )
:9:16:
t<0?
t<-72?
main( _, t,
“@n’+,#’/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#;\
#q#n+,/+k#;*+,/’r :’d*’3,}{w+K w’K:’+}e#’;dq#’l q#’+d’K#!/+k#;\
q#’r}eKK#}w’r}eKK{nl]’/#;#q#n’){)#}w’){){nl]’/+#n’;d}rw’ i;# ){nl]!/n{n#’; \
r{#w’r nc{nl]’/#{l,+’K {rw’ iK{;[{nl]’/w#q#\
\
n’wk nw’ iwk{KK{nl]!/w{%’l##w#’ i; :{nl]’/*{q#’ld;r’}{nlwb!/*de}’c ;;\
{nl’-{}rw]’/+,}##’*}#nc,’,#nw]’/+kd’+e}+;\
#’rdq#w! nr’/ ‘) }+}{rl#'{n’ ‘)# }’+}##(!!/”)
:
t<-50?
_==*a ?
putchar(31[a]):
main(-65,_,a+1) :
main((*a == ‘/’) + t, _, a + 1 ) :
0<t?
main ( 2, 2 , “%s”)
:*a==’/’||
main(0,
main(-61,*a, “!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry”)
,a+1);}
What does it do? It prints the song Twelve Days of Christmas.
Don’t you believe? Try it!
For more crazy stuff like this, check
http://www.ioccc.org/
So you know C? Here is an useless tip
So we have:
char whatever[] = "hello world";
printf( "%c", whatever[4] );
It will print the ‘o’ character (oh!)
But we know that whatever[4] is the same of *(whatever + 4), and this is the same of *(4 + whatever).
So, is it correct to say that whatever[4] is the same of 4[whatever]??
Yes, that is!
So go ahead and write:
char whatever[] = "hello world";
printf( "%c", 4[whatever] );
You may get a promotion for that.
(Or you’ll probably get fired)
Pretty cool, huh?
