Jump to content
  • Advertisement
Sign in to follow this  
TEUTON

return value of constructor

This topic is 4484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Every book says that constructor does not have a return type not even void but it never explains why(as far as books which I have read). can anyone plz explain why constructor dos not have a return type.

Share this post


Link to post
Share on other sites
Advertisement
The purpose of a constructor is just to set the memory aside for the object of the new type you create. Besides the initialization stuff you may choose to do inside the function it doesn't effect anything outside the class so a return type is actually pointless. Other than that I would have to say it was just how the language was created.

Vis.

Share this post


Link to post
Share on other sites
Because it isn't a real function. Most of the time, you never even call it, it just gets called when the time comes.

As to why it shouldn't have a return value anyhow, what would it return? Most everything is excluded because you don't have access to it. For instance, what happens to the return value when you call new? It just vanishes...and if you don't have access to it, what good is it? The only remaining option is to return the constructed object...but you already have the constructed object, so what good is that? Really, having a return value at all is illogical.

CM

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
Really, having a return value at all is illogical.


Which is why "void" was added to the language. I was going to add a response similar to yours, but then I thought "Why not make it a function returning void?".

I've never had to overload new so I don't know anything about doing it, so I wonder if returning a value could be useful in overloading new. Is there any situation it might be useful? (Even if it's something like "fewer temporary variables" or "less typing")

Probably best answer is "it isn't a real function". I've never seen an initializer list on any other "function".

Share this post


Link to post
Share on other sites
Quote:
Original post by Way Walker
Which is why "void" was added to the language. I was going to add a response similar to yours, but then I thought "Why not make it a function returning void?".

...

Probably best answer is "it isn't a real function". I've never seen an initializer list on any other "function".

If it were a function returning void, that would suggest you could make it a function returning int. But you can't, so you might as well treat it like a special function from the ground up.
Quote:

I've never had to overload new so I don't know anything about doing it, so I wonder if returning a value could be useful in overloading new. Is there any situation it might be useful? (Even if it's something like "fewer temporary variables" or "less typing")

I seriously doubt it. For instance...when you overload operator new, you don't call the constructor. The system takes care of that for you. I think one would be justified in saying that a user never directly calls a constructor, they simply create objects and the constructors get called at the appropriate time. With this in mind, the compiler is the only thing that'll care if the constructor returns a value or not...and if it did, the compiler can just stealth in whatever return value it wants.

CM

Share this post


Link to post
Share on other sites
My question was related to C++ constructors...but I just read about Java constructors( I guess its the same concept both in C++ and Java)...In the book it is written constructor can't have a return type not even void because it has an implcit return type of class. Is that true.

Share this post


Link to post
Share on other sites
Yes that is more or less true. Technically its implicit return type is always (class*).

Share this post


Link to post
Share on other sites
I don't see any use in a return type at all. You shouldn't be doing anything in a constructor that could cause an error.

That being said, if you do decide to do something like open a file for instance, you could always set a flag and overload the bool operator so you can do this


class Foo
{
private:
bool error_flag;

public:
Foo(char* file); // Sets error flag on fail

operator bool() { return error_flag; }
};

void SomeFunction()
{
Foo bar("Wha.txt");

if (bar)
{
cout << "Could not open Wha.txt" << endl;
}
}




Share this post


Link to post
Share on other sites
Quote:
Original post by Adam Hamilton
I don't see any use in a return type at all. You shouldn't be doing anything in a constructor that could cause an error.


Just a precision: you can generate errors in a constructor but since you can't return them to the caller, the best way to signal them is to throw an exception (@TEUTON: don't be afraid of that word ;)).

Quote:
Original post by Adam Hamilton
That being said, if you do decide to do something like open a file for instance, you could always set a flag and overload the bool operator so you can do this


I strongly encourage you to never ever overload the bool casting operator unless your type relates to a boolean (or to any other fundamental type). It can have nasty side effect that won't be easily spot during runtime and that may introduce very subtil bugs in your program when not used correctly (and believe me, with all this nasty automatic conversions everywhere, you wont' be able to use it correctly [smile])

But you are right: storing the error in a bool is is also another possibility, but it requires you to check for the existence of an error.

Anyway, it is still better to move all the code that might fail in anotehr class method - since this new method will be able to return an error code.

Regards,

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
I think one would be justified in saying that a user never directly calls a constructor, they simply create objects and the constructors get called at the appropriate time.


I agree with everything you said except this line. What about:


class Base
{
int* m_pData;
public:
Base(int nAmount)
{
m_pData = new int[nAmount];
}

void Release()
{
delete [] m_pData;
}
};

class Derived : public Base
{
public:
Derived() : Base(10)
{
// Create a default amount of 10
Base(10);
}

Derived(int nAmount)
{
Base(nAmount);
}
};

// And just in case you were talking about calling just the classe's
// constructor. Wouldn't the following be directly calling it?
Derived MyDerived(21);




EDIT: I changed my source code as to not confuse anybody or to confuse them more, whichevere.

[Edited by - Programmer16 on March 15, 2006 10:30:37 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!