to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS-Studio license for Microsoft MVP specialists
** By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
** By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
** By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
Wade not in unknown waters. Part one

Wade not in unknown waters. Part one

Jan 27 2012
Author:

We decided to write several small posts on how C/C++ programmers play with fire without knowing it. The first post will be devoted to an attempt to explicitly call a constructor.

Programmers are lazy creatures. That's why they tend to solve a task using minimal code amount. This aim is praiseworthy and good. But the main point is not get too involved in the process and stop at the right time.

For example, programmers are too lazy to create a single initialization function in a class so that it could be called from various constructors later. They think: "What for do I need an extra function? I'd rather call one constructor from the other". Unfortunately, sometimes programmers can't solve even such a simple task. It is to detect such unsuccessful attempts that I'm implementing a new rule in PVS-Studio. Here is, for instance, a code sample I have found in the eMule project:

class CSlideBarGroup
{
public:
  CSlideBarGroup(CString strName,
    INT iIconIndex, CListBoxST* pListBox);
  CSlideBarGroup(CSlideBarGroup& Group);
  ...
}

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(), Group.GetListBox());
}

Let's examine more attentively how the last constructor is implemented. The programmer decided that the code

CSlideBarGroup(
  Group.GetName(), Group.GetIconIndex(), Group.GetListBox());

simply calls the other constructor. Nothing of the kind. A new unnamed object of the CslideBarGroup type is created and destroyed right after here.

It appears that the programmer has actually called the other constructor. But he/she has done not quite the same thing he/she intended: the class fields remain uninitialized.

Such errors are just half the trouble. Some people do know how to call the other constructor really. And they do it. I wish they didn't know :)

For instance, the above given code could be rewritten in this way:

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  this->CSlideBarGroup::CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(), Group.GetListBox());
}

or in this way:

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  new (this) CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(),
    Group.GetListBox());
}

Now one data initialization constructor is really calling the other constructor.

If you see a programmer doing this, deal him/her one flick on his/her forehead for yourself and one more flick on my behalf.

The cited examples contain very dangerous code and you should understand well how they work!

Being written for the purpose of petty optimization (programmers are too lazy to write a separate function), this code might do more harm than good. Let's see more closely why such constructs sometimes work but most often don't.

class SomeClass
{
  int x,y;
public:
  SomeClass() { new (this) SomeClass(0,0); }
  SomeClass(int xx, int yy) : x(xx), y(yy) {}
};

This code will work correctly. It is safe and works well, since the class contains primary data types and is not a descendant of other classes. In this case, a double constructor call is harmless.

Let's consider another code where an explicit constructor call causes an error (the sample is taken from the discussion on the Stack Overflow website):

class Base 
{ 
public: 
 char *ptr; 
 std::vector vect; 
 Base() { ptr = new char[1000]; } 
 ~Base() { delete [] ptr; } 
}; 
 
class Derived : Base 
{ 
  Derived(Foo foo) { } 
  Derived(Bar bar) { 
     new (this) Derived(bar.foo); 
  } 
}

When we call the "new (this) Derived(bar.foo);" constructor, the Base object is already created and fields initialized. The repeated constructor call will cause double initialization. A pointer to the newly allocated memory area will be written into 'ptr'. As a result, we get memory leak. The result of double initialization of an object of the std::vector type cannot be predicted at all. But one thing is obvious: such code is inadmissible.

Conclusion

An explicit constructor call is needed only in very rare cases. In common programming practice, an explicit constructor call usually appears due to a programmer's wish to reduce the code's size. Don't do that! Create an ordinary initialization function.

This is how the correct code should look:

class CSlideBarGroup
{
  void Init(CString strName, INT iIconIndex,
            CListBoxST* pListBox);
public:
  CSlideBarGroup(CString strName, INT iIconIndex,
                 CListBoxST* pListBox)
  {
    Init(strName, iIconIndex, pListBox);
  }
  CSlideBarGroup(CSlideBarGroup& Group)
  {
    Init(Group.GetName(), Group.GetIconIndex(),
         Group.GetListBox());
  }
  ...
};

P.S. Explicit call of one constructor from the other in C++11 (delegation)

The new C++11 standard allows you to perform call of constructors from other constructors (known as delegation). It enables you to create constructors that use behavior of other constructors without added code. This is an example of correct code:

class MyClass {
  std::string m_s;
public:
    MyClass(std::string s) : m_s(s) {}
    MyClass() : MyClass("default") {}
};

Popular related articles
C++ subtleties: so, you've declared a class...

Date: Feb 07 2023

Author: Sergey Larin

Our team constantly encounters some C++ features that may be unknown to some developers. In this article, we're going to learn how a seemingly typical feature — class forward declarations — works.
Under the hood of SAST: how code analysis tools look for security flaws

Date: Jan 26 2023

Author: Sergey Vasiliev

Here we'll discuss how SAST solutions find security flaws. I'll tell you about different and complementary approaches to detecting potential vulnerabilities, explain why each of them is necessary, an…
Is there life without RTTI or How we wrote our own dynamic_cast

Date: Oct 13 2022

Author: Vladislav Stolyarov

There aren't many things left in modern C++ that don't fit the "Don't pay for what you don't use" paradigm. One of them is dynamic_cast. In this article, we'll find out what's wrong with it, and afte…
Why do arrays have to be deleted via delete[] in C++

Date: Jul 27 2022

Author: Mikhail Gelvih

This note is for C++ beginner programmers who are wondering why everyone keeps telling them to use delete[] for arrays. But, instead of a clear explanation, senior developers just keep hiding behind …
Intermodular analysis of C and C++ projects in detail. Part 2

Date: Jul 14 2022

Author: Oleg Lisiy

In part 1 we discussed the basics of C and C++ projects compiling. We also talked over linking and optimizations. In part 2 we are going to delve deeper into intermodular analysis and discuss its ano…


Comments (0)

Next comments next comments
close comment form
Unicorn with delicious cookie
Our website uses cookies to enhance your browsing experience.
Accept