>Hey... i am not here for any arguments....
Neither am I, but if you really want to be a jerk about it I'll be happy to oblige.
>I was just asking for a simple answer
Duh! But the answer isn't simple, nor is it relevant to your current studies, that's the whole point.
>u don't have to reply if u don't want to.....
Fine. The constructor does two things: it allocates memory to an object, and initializes the data members of the object to a predictable state. The latter is best defined by the program, but the former is only possible if the C++ run-time handles it. The reason that constructors do not return a value is because to do so would destroy any chance of using temporary objects without a variable to store them, and since the primary desire for a return value is to indicate success or failure, exceptions are the better solution.
Now, you could trick yourself into thinking that a constructor returns the object that it creates, if you really wanted to, because some of the syntax suggests it:
std::string s = std::string ( "This is a test" );
But that's just syntactic sugar. A more accurate description would be that a constructor evaluates to a temporary object, then that object is assigned to an identifier in the symbol table if an "assignment" is made during the declaration. If a constructor really returned the object that it created, this would be illegal, or a special case:
std::string s ( "This is a test" );
Sure, the language could have specified that a constructor returns, say, a bool, which can be used to determine success or failure, but then how would you link the newly created object with an identifier? C++ would be forced to either do something decidedly un-C++-like:
std::string ( s, "This is a test" );
std::cout<< s <<'\n';
Or force the Java approach where object variables are actually pointers and a special variant of the new operator returns the new object after checking the return value of the constructor and throwing an exception on failure:
std::string *s = new std::string ( "This is a test" );
In reality, the C++ approach is more flexible, and if you need to determine success or failure, simply throw an exception from within the constructor and call it good:
test::test()
{
// Try to initialize
if ( failure )
throw fatal_error;
}
In light of this, there's no reason for a constructor to return a value and forcing a constructor to return a value would break code that assumes it evaluates to a temporary object, or require massive changes to the language just to keep everything working nicely, which of course would break millions of lines of existing C++ code.
Let's go back to your initial question, which was incorrectly answered for you and caused you to ask a less coherent question. Why doesn't a constructor return a value? Because it was a design decision when C with Classes was first created. For this and other implementation reasons, a constructor has no address that's meaningful to you.
