The 20 lines of shame

While rice is cooking, I remembered a curious case that happened to me early in his career, involving memory management in C + +. At that time I was much more. Younger, faster, more arrogant and more newbie ...

A more experienced co-worker was explaining to another less experienced colleague that for every new there must be a corresponding delete. Otherwise the object will persist in memory and there may be memory leaks.

At this point I interrupted him and said "not necessarily because it is sufficient that the object out of scope so the destructor is automatically called.."

Since then rolled a 10 min debate with arguments and counter arguments, and the whole team still watching. In the end, half the team agreed with him and the other half with me, and at that point nobody had in mind a way to check to see. Look on the Internet was not an option.

As I had all the answers, after all already programmed in PHP, Java and C + + was to show later that I was right.

Days later, one of those philosophical moments, I remembered that a memory address is a number, and you can either convert an address to a common number, and go the other way, although the latter is usually useless.

Then I devised a way to prove my theory: It would create an object in a scope restricted to allocating new. Save the address of this object as a common number in a long out of the restricted scope, expect to finalize the restricted scope, the destructor of obejto be called and then the outer scope, use the number representing the address of the object to access that area of memory showing that receive a SIGSEGV (segmentation fault) by trying to access an invalid memory area. Then I generated the code below.

  A
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20

  # Include
 # Include <string>

 using namespace std;

 int argc, char ** argv ) { int main (int argc, char ** argv) {
     0 ; unsigned long a = 0;

     {
         new string ( "Hello World!!!" ) ; * str = new String ("Hello World!");
         unsigned long ) str ; a = (unsigned long) str;

         "str: " << str << endl ; court <<"str:" <<str <<endl;
         "num: " << num << endl ; court <<"num:" <<a <<endl;
     }

     * ( ( string * ) num ) << endl ; court <<* ((* ​​string) a) <<endl;

     ; return 0;
 } 

Behold, to my surprise the program did not explode in my face. He worked correctly pointing out that in fact I was the one who was wrong.

Searching more I realized that yes, there should be new for each one and only delete, and more for each new [] must be one and only one delete []. What I thought I knew about memory management and scope, it was probably some confusion between different languages.

When I started the discussion day before, I made all the basic mistakes that a newbie commits:

1. Meddle where it was called.
2. Swearing standing by what is right without evidence.
3. Underestimate the knowledge of someone more experienced.
4. Think you have all the answers just because they just see it in class.
5. To think that just because they know the basics of several languages, then you have all the answers.

Like any good member of the species Homo sapiens , talked shit. My reaction to this discovery was to take the whole team and I was wrong, apologize for speaking nonsense and show these twenty lines of code used to demonstrate this. Moreover, I showed all sources I have checked and even brought out other details about memory management that we were escaping, like circular references . This led to a re-desing of some parts of the project.

My 20 lines cógigo became known as "The 20 lines of shame" and natual so I was screwed. Every time anyone had any doubts spoke "there is 20 lines of vegonha for testing." The meaning was something like "there is a simple test to not be embarrassed later."

The most important thing is that my post-shit attitude was well received and brought benefits to the team. If I had shied away sooner or later someone would prove I was wrong in front of everyone, or worse, behind the scenes. Admit mistakes and learn from it showed that I was prepared to be challenged. In addition to this team showed that the more I seemed arrogant (I look like more than I am ...), I knew it was an ordinary human who made mistakes like everyone else, I do not think more than anyone. This paved the way for other team members feel free to do the same and we become a more cohesive team.

Comments

• Translator

  

• Goal

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

• Categories

  • Bla Bla Bla (49)
    • Blog (5)
    • Cinema (2)
    • Tales (1)
    • Events (5)
    • Holiday (5)
    • Magic (1)
    • Opinion (9)
    • Pearl (3)
  • Tips (5)
  • Technology (40)
    • Database (1)
      • MySQL (1)
    • Eee (3)
    • Git (1)
    • Linux (7)
    • Open Office (1)
    • Programming (29)
      • C / C + + (14)
      • Perl (14)
      • Qt (7)
      • VIM (1)
      • Web (1)
      • YATK (1)
    • Subversion (5)