About overloaded constructor

Hi guys,

I want to make a program but I wanted to know that when should we use overloaded constructor?

Code:

class Vehicle

{

 private:

 string Name;
 int reg_no;
 
public:

 Vehicle()
 void getName();
 void setName();
  
~Vehicle() 

};

The default constructor can do the job?

The default constructor automatically initializes an object which is created ,so what is the use of overloaded constructor?

Also have I written the constructor correctly?



I hope I am clear

Thanks

Originally Posted by student111

I want to make a program but I wanted to know that when should we use overloaded constructor?

When it makes sense

Originally Posted by student111

The default constructor can do the job?

Possibly. But perhaps it may make sense to create a constructor that can initialise the Name with a sensible value. In fact, if each Vehicle must have a Name that is not an empty string, it may even make sense to not provide a default constructor, and check in setName that the argument is not an empty string (of course, setName must take an argument).

Originally Posted by student111

Also have I written the constructor correctly?

You forgot the terminating semi-colon, and you did not actually define the constructor in the example code. Besides what I highlighted about setName, getName should be a const member function that returns a std::string.

It makes sense to overload a constructor if parameters of differing types can potentially used to create a whole object.

Let's say int makes sense to construct an object from an integral value in some circumstances, and from a string of characters in other circumstances. Generally, it would then make sense to create two constructors, one that accepts an int, and one that accepts a const char *. I've illustrated this using constructors that only accept one argument, but the principle works if you need to construct objects from multiple items of data (i.e. multiple parameters to the constructor).

I don't know whether it makes sense in your Vehicle class. In what ways does it make sense to construct a Vehicle?

I wouldn't supply a default constructor for a class, unless it makes sense to create an object based on nothing (no parameters required).

Don't read on unless you like technical pedantry. Technically, unless copy constructors (that create an object from an existing object of the same type) are disabled, all constructors are overloaded. The compiler will generate a copy constructor if the programmer doesn't, and it can. It doesn't make sense to have a copy constructor unless there is some other way to create an object to be copied - which means another overloaded constructor must exist. The only exceptions to this are if copy constructors are specifically suppressed.

Or perhaps if you had some kind of matrix class that by default created an 8x8 array when constructed. If you only actually wanted a 3x4 array, or you wanted a 30x40 array, then using a constructor that allowed you to provide the height and width would be an advantage over allocating an 8x8 array first then throwing that away when you call some kind of resize function, and allocating a differently sized one.

The default constructor automatically initializes an object which is created ,so what is the use of overloaded constructor?

Default constructor does not initialize primitive types (POD). Even though default constructor exists for POD's but compiler don't call them unlike it does for object members.

Code:

Sample a; //Default or NO construction
Sample b; = Sample(); //construction with data member value initialization

Originally Posted by maven

Default constructor does not initialize primitive types (POD). Even though default constructor exists for POD's but compiler don't call them unlike it does for object members.

That is not true.

The definition of POD forbids user-declared constructors. However, compiler generated default and copy constructors are permitted and, if they are generated, they will be invoked when default-constructing or copy-constructing an object, respectively.

C++-11 relaxed a lot of the rules related to POD (and introduced more specific concepts like trivial and standard-layout classes) but this principle still holds.

Great!! I was not aware of it. But people must have to use compiler which supports c++11 to get the advantages.

Originally Posted by maven

Great!! I was not aware of it. But people must have to use compiler which supports c++11 to get the advantages.

This was not the point. Ordinarily, POD types aren't constructed at all. But the compiler can generate constructors for them, and you are allowed to use them.

Code:

#include <iostream>
#include <sstream>
#include <string>

using namespace std;

class point 
{
   private:
      float _x;
      float _y;
   public:
      point() : _x(), _y() {}
      
      string toString() const
      {
          stringstream result;
          result << '(' << _x << ',' << _y << ')';
          return result.str();
      }
};

int main ()
{
   point origin;
   cout << origin.toString() << endl; // (0,0)
   return 0;
}

C++11 support is not necessary.

My context was for implicit default constructors.
I said "Default constructor does not INITIALIZE primitive types (POD)". This states true except when object is in static or global scope.
Initialization is a different process performed while creating an object.
So the fact remains is implicit default constructor do not initialize primitive types (POD) for a object which is created in a local scope.

Originally Posted by maven

My context was for implicit default constructors.
I said "Default constructor does not INITIALIZE primitive types (POD)". This states true except when object is in static or global scope.
Initialization is a different process performed while creating an object. So the fact remains is implicit default constructor do not initialize primitive types (POD) for a object which is created in a local scope.

The reason we had this discussion is because a default constructor is just a constructor that can be called without any arguments. If discussion was productive, you already know why that's wrong. Now that you've added context I've got no problem, compiler generated constructors are worthless