The compiler is to blame

Many programmers like to blame the compiler for various errors. Let's talk a little about it.

Was there a boy?

When a programmer says that the compiler is the cause of the error, in 99% of cases, he lies. When a detailed study of a problem begins, the reasons are usually as follows:

• going beyond the array;
• uninitialized variable;
• typo;
• synchronization error in a parallel program;
• the use of a non-volatile variable, where appropriate;
• written code that leads to undefined behavior;
• and so on.

Many went through the correction of such errors. Read a lot about them. However, this does not prevent again and again blaming the compiler for mortal sins. Each time, it seems that now it is he who is to blame.

Of course, the compiler may also contain errors. But if you do not use an exotic compiler for the microcontroller, then this probability is very low. For many years of working with Visual C ++, I only once saw it generate incorrect assembly code.

Small recommendation

Before you blame the compiler and write about it in the code or on the forum, conduct a detailed investigation. First of all, this will fix the error in your code faster. Secondly, you will not look silly in the eyes of other programmers who point to your blunders.
')

What prompted me to write this note

Today I was extremely amused by a piece of code from the ffdshow project. Here he is:

TprintPrefs::TprintPrefs(IffdshowBase *Ideci, const TfontSettings *IfontSettings) { memset(this, 0, sizeof(this)); // This doesn't seem to // help after optimization. dx = dy = 0; isOSD = false; xpos = ypos = 0; align = 0; linespacing = 0; sizeDx = 0; sizeDy = 0; ... } 

Looking at the comment, I can imagine how resentful the programmer is. Ah, that obnoxious compiler! In the Debug version, all variables are equal to 0. In the release version, due to idle optimization, there is garbage in them. This mess! Bad, bad compiler!

Having scolded the compiler, the programmer leaves an accusing comment. And he writes the code below, which individually resets each member of the class. The victory of courage over the forces of evil.

And most importantly, this person will remain confident that he has met a bug in the compiler. And he will tell you how he suffered.

If someone did not understand the whole humor of the situation, then I will explain. The memset () function does not work due to the simplest error. The third argument calculates the size of the pointer, and not the structure at all. The correct call should look like this: “memset (this, 0, sizeof (* this));”.

By the way, the memcpy () function also works poorly with this programmer. I am sure that he considers compiler developers to be curved creatures.

 void Assign(const AVSValue* src, bool init) { if (src->IsClip() && src->clip) src->clip->AddRef(); if (!init && IsClip() && clip) clip->Release(); // make sure this copies the whole struct! //((__int32*)this)[0] = ((__int32*)src)[0]; //((__int32*)this)[1] = ((__int32*)src)[1]; memcpy(this,src,sizeof(this)); } 

From the comments it is clear that he tried to copy the memory with alternative methods. However, then I left the 'memcpy ()' function after all. Perhaps she worked for him in a 64-bit program. There pointer size is 8 bytes. Namely, 8 bytes, he wants to copy.

Error again in the third argument. The sizeof (* this) should be written.

That's how legends are born about buggy compilers and brave programmers who fight them.

Conclusion

If something is wrong, look for an error in your code.