Why Constructor does not have a return type?

[sayantani]

I know its a very basic question- but I really don't know why constructor don't have a return type and why can't they be static, const and virtual?

Anybody having some valuable thoughts on this - please explain.

[h9uest]

This is actually an interesting question.

I believe you're not looking for an answer like "C++ standard says it doesn't, so it doesn't." because you wouldn't have asked the question in the first place.

Assume we have a class MyClass.
In fact, when you do this:
MyClass my_obj = MyClass();
It works. No compiler error is generated. No runtime error.

That brings us to the question: so constructors have return type?


In my opinion, yes, so no.
When a constructor returns a known type at all times, then there is no need for the programmer to specify the return type anymore. Effectively, we don't have a return type for constructors.


If we are a bit philosophical, then we find the world is like this. Politicians claim they will strive to make a world where everyone is happy. Then, everyone is not happy because everyone is happy.

[zb0S216C]

A user on Stack Overflow^[1] has already answered this.

References:
^[1]http://stackoverflow.com/questions/5757213/why-cant-we-return-anything-from-the-constructor

_Wazzak

[Athar]

Sounds like a homework question.
If you understood what a constructor is and what it does, the answers would be obvious.

[ceruleus]

another interesting question: can a constructor ever fail?

edit: and why/why not?

[Nisheeth]

I guess, a constructor can fail!
I would imagine this would happen in a case like this:

class A
{
     int a;
public:
     A();
}

A::A()
{
     int x;
     a = x;
}

[Athar]

A constructor can be considered to fail when/if it throws an exception.

[LB]

Constructors do not return anything. The expression SomeContainer.push_back(MyClass()); is not calling the constructor directly - MyClass() is a nameless object that is constructed with the default constructor, note my phrasing "is" an object and not "returns" an object.

Constructors can not be static because they rely on the this pointer.

Constructors can not be const because they change the state of the object to construct it.

Constructors can not be virtual because you can not construct an object without knowing its type.

[1vRz3TCk]

Constructors can not be static because they rely on the this pointer.

Do they? I did't think the constructor was even a function, just a glorified initialiser.

[Disch]

A static constructor makes no sense.

Static members work without an object.
A constructor constructs an object.


So what exactly would a static constructor do? With no object to construct, what's the point?

EDIT:

And yes, constructors are functions.

[1vRz3TCk]

They have no name and are therefore not found with name lookups. They are called with explicit type conversion using the functional notation.

Edit: I'm fairly sure they are not functions...looking for the reference...
Edit: Hmmm 'Special member function' maybe that was what I remember.
Edit: Re: this pointer...(brain fart, I avoid explicit this use in constructors)

[sayantani]

thanks all for your input - things are a bit clear to me now. I guess I should start reading Bjarne Stroustroupe C++ Programming Language book to get more insights into C++.

[shacktar]

Constructors can not be const because they change the state of the object to construct it.

Actually, the constructor is called as usual when creating a const object instance. Constructors are allowed to touch const objects because they need to set the initial state.

[zwA4jE8b]

regarding the link provided by framework...

what is functional casting?


are these two instances of V the same? (v1 and v2)

class V
{
  int a, b;
}

int main()
{
  V v1;
  V(v2);

  return 0;
}

[1yR4jE8b]

For Disch: (Static Constructors)
http://msdn.microsoft.com/en-us/library/k9x6w0hc%28v=vs.80%29.aspx

[rapidcoder]

Constructors can not be static because they rely on the this pointer.

Wrong. Constructors are not class members, so the "static" concept (in the meaning of static method or static field) doesn't apply to them. They are neither static nor non-static. From the user perspective they behave exactly like a static method (you can't call a constructor on an existing object), and therefore they cannot be also virtual, internally they have access to the newly created this poiter, so they have access privileges like a non-static member.