Default constructor

Hi,

Will the compiler provide a default constructor in the following code:

Code:

---

class C
{
private:
 int n;
 char *p;
};

void f()
{
 C obj;
}

---

Many thanks

Yes, but the value of n and p in obj will be undefined.
You'd better initialize p to 0 in the constructor.

The compiler will always provide a default constructor (and assignment and copy constructors also) unless you explicitly provide one yourself.

However, as D_Drmmr said, they won't usually do what you need them to (as the compiler isn't clever enough to know your intentions).

For safety's sake, it is normally a good idea to:
1) Provide an explicit constructor, and
2) Either provide correct copy constructor and assignment operators, or declare them as private methods to prevent their use.

Quote:

---

Originally Posted by D_Drmmr

Yes, but the value of n and p in obj will be undefined.

---

In this particular case, that is correct.
However, the OP should know that if obj has static storage duration, zero-initialization will be performed for you.

As others have stated, though, when dealing with non-POD objects, you should always perform the initialization explicitly.

Quote:

---

Originally Posted by Peter_B

The compiler will always provide a default constructor (and assignment and copy constructors also) unless you explicitly provide one yourself.

---

A little more precisely: if any constructor of the class is user declared, the compiler will not declare a default constructor.

Quote:

---

Originally Posted by Peter_B

However, as D_Drmmr said, they won't usually do what you need them to (as the compiler isn't clever enough to know your intentions).

---

From what I see, D_Drmmr did not say that since he/she merely pointed out that the member variables would not be properly initialised since they are of built-in types. If they were of class types, then they would have been default constructed.

Quote:

---

Originally Posted by Peter_B

For safety's sake, it is normally a good idea to:
1) Provide an explicit constructor, and
2) Either provide correct copy constructor and assignment operators, or declare them as private methods to prevent their use.

---

On the contrary, I'd say that with proper use of RAII, the compiler generated copy constructor and copy assignment operator will normally do the right thing, and in fact defining them yourself means that you need to maintain them. So, you should only implement them when you are implementing RAII, or need to do something extra.

Quote:

---

Originally Posted by Peter_B

However, as D_Drmmr said, they won't usually do what you need them to (as the compiler isn't clever enough to know your intentions).

For safety's sake, it is normally a good idea to:
1) Provide an explicit constructor, and
2) Either provide correct copy constructor and assignment operators, or declare them as private methods to prevent their use.

---

Actually, about 80%-90% of the time, it is indicative of a design flaw when the generated constructors do not work.


A classic example is in this vbery sample, where a raw pointer is being used instead of a smart pointer that automatically handles constructiohn, release, and copy operations internalls.

Quote:

---

Originally Posted by laserlight

Quote:

---

Originally Posted by Peter_B

The compiler will always provide a default constructor (and assignment and copy constructors also) unless you explicitly provide one yourself.

---

A little more precisely: if any constructor of the class is user declared, the compiler will not declare a default constructor.

---

Thanks for the clarification - the 'one' shown in red was intended to refer to any constructor, not a default constructor specifically.

Quote:

---

Originally Posted by laserlight

Quote:

---

Originally Posted by Peter_B

However, as D_Drmmr said, they won't usually do what you need them to (as the compiler isn't clever enough to know your intentions).

---

From what I see, D_Drmmr did not say that since he/she merely pointed out that the member variables would not be properly initialised since they are of built-in types. If they were of class types, then they would have been default constructed.

---

You are quite right - I misinterpreted what he/she said.

Quote:

---

Originally Posted by laserlight

Quote:

---

Originally Posted by Peter_B

For safety's sake, it is normally a good idea to:
1) Provide an explicit constructor, and
2) Either provide correct copy constructor and assignment operators, or declare them as private methods to prevent their use.

---

On the contrary, I'd say that with proper use of RAII, the compiler generated copy constructor and copy assignment operator will normally do the right thing, and in fact defining them yourself means that you need to maintain them. So, you should only implement them when you are implementing RAII, or need to do something extra.

---

The 'normally' refers to how classes are usually written in practice, i.e. using raw pointers for instance variables rather than smart/auto pointers. In this context, I think it can help to firstly declare the copy constructor and assignment operator as private (without an implementation). Doing this as a matter of course makes you have to at least think whether the compiler generated versions will be correct. If they aren't then you can choose whether to implement them or just disallow them entirely (after all, some classes shouldn't be copied, e.g. std::stringstream).

As for maintaining the copy constructor/assignment operator, I don't recommend defining them unless you actually need to, only declaring them as private to prevent inadvertent use until you have considered the matter properly.

Quote:

---

Originally Posted by TheCPUWizard

Quote:

---

Originally Posted by Peter_B

However, as D_Drmmr said, they won't usually do what you need them to (as the compiler isn't clever enough to know your intentions).

For safety's sake, it is normally a good idea to:
1) Provide an explicit constructor, and
2) Either provide correct copy constructor and assignment operators, or declare them as private methods to prevent their use.

---

Actually, about 80%-90% of the time, it is indicative of a design flaw when the generated constructors do not work.

A classic example is in this vbery sample, where a raw pointer is being used instead of a smart pointer that automatically handles constructiohn, release, and copy operations internalls.

---

So about 10%-20% of the time, the generated constructors do not work without there being a design flaw :)

I agree, of course, that smart pointers are better than raw pointers, and will make the generated copy constructor/assignment operator work in the majority of cases. My remarks were really referring to cases where people do use raw pointers, such as this one.

I forget to mention it in my previous posts, but just out of interest the C++ Portability Guide for the Mozilla project (i.e. Firefox/Thunderbird etc) mentions my point about either explicitly defining the copy constructor/assigment operator or declaring them private, though this is to prevent passing objects to functions by value:

https://developer.mozilla.org/index....nment_operator