Why do constructors have same name as the class ?

[James Kanze]

yeti wrote:

Well, the destructor doesn't really have the same name as the
constructor and class does it? Isn't the ~ part of the name?

I don't know if it makes a difference, but it's a separate
token. (Of course, one speaks of functions named "operator new"
or "operator +", which also consist of two tokens. The name of
a type conversion operator is even an unbounded sequence of
tokens.)

As some of the other replies have suggested, this naming
convention seems to help simplify the language by avoiding
additional keywords.

I'm not sure that avoiding keywords makes things simpler in this
case. (It does avoid breaking any code which happens to use
those keywords, of course.)

Some people maintain that a constructor *does* return
something -- it returns a new instance. Since an new instance
is the *only* thing a constructor is allowed to return, by
allowing the programmer to specify a return type or "return
<something>;" ("return;" is O.K.), this would allow the
programmer to mess it up. So, these syntactic elements are
not available in the constructor's syntax -- the opportunity
to make one of these errors is taken away. Not sure if this
view is legitimate or pedagogy.

Now, a destructor is going to destroy an instance, so it can
return neither its object nor any part of its object. Just
what else might you like it to return?

An error code? . (The destruction of the local variable has
failed, the variable is still there, and we're not going to let
you leave the block until you do something about it.)

 

[Ole Nielsby]

Now, a destructor is going to destroy an instance, so it can return
neither
its object nor any part of its object. Just what else might you like it to
return?

Fx the size of the now-vacant memory block.

I wrote an interpreter for a language with a reference-counted data
model. To keep memory footprint small, I want to be able to use a
custom allocator that doesn't use extra space for administration. For
this to work, the size of the garbage chunks must be inferred from the
objects at destruction time.

I defined a method unlinkAndGetSize() which is essentially a value-
returning destructor - this works for me, but my code might have come
out somewhat more elegant if I could have returned this value from the
destructor.

 

[peter koch]

Fx the size of the now-vacant memory block.

I wrote an interpreter for a language with a reference-counted data
model. To keep memory footprint small, I want to be able to use a
custom allocator that doesn't use extra space for administration. For
this to work, the size of the garbage chunks must be inferred from the
objects at destruction time.

I defined a method    unlinkAndGetSize()    which is essentially a value-
returning destructor - this works for me, but my code might have come
out somewhat more elegant if I could have returned this value from the
destructor.

But that is an implementation detail. The book "Inside the C++ object
model" by Stan Lippman gives lots of examples about how to implement
the C++ code. If I remember correctly, returning the size of the
object from the destructor was useful in some situations (I do not
remember them any more, thats just one more reason for you to buy the
excellent book!),

/Peter