Calling one constructor from another in VC++

[Peter E. Granger]

I'm fairly new to C++ and VC++, but for the most part it seems to do most of
the same things that can be done in Java, with just some syntactic and
structural adjustments. However, one thing I haven't been able to figure out
is how to call one constructor from another within a class. It's easy enough
to call the base class's constructor from the derived class, but that's not
what I'm trying to do.

For example, in Java (or J#) it's easy to do this:

public class Circle
{
private int PointX;
private int PointY;
private int Radius;

public Circle()
{
this.PointX = 0;
this.PointY = 0;
this.Radius = 0;
}

public Circle(int x, int y)
{
this();
this.PointX = x;
this.PointY = y;
}

public Circle(int x, int y, int r)
{
this(x, y);
this.Radius = r;
}
}

However, trying to do the same thing in VC++ doesn't work:

// Sphere.h (partial file)
class Sphere
{
public:
Sphere(void);
Sphere(int x, int y);
Sphere(int x, int y, int r);
~Sphere(void);

private:
int PointX;
int PointY;
int Radius;
};

// Circle.cpp (partial file)
#include ".\circle.h "

Circle::Circle( void)
{
this->PointX = 0;
this->PointY = 0;
this->Radius = 0;
}

Circle::Circle( int x, int y)
{
Circle();
this->PointX = x;
this->PointY = y;
}

Circle::Circle( int x, int y, int r)
{
Circle(x, y);
this->Radius = r;
}

In the C++ version, I also tried using this() instead of Circle(), which
caused a compiler error. I also tried doing it without the this-> specifier,
which made no difference. The end result if you call the second constructor
is that the X and Y values have been set, and the Radius is uninitialized.
If you use the third constructor, you get exactly the opposite results. (And
I don't mean they have values of zero; looking at them with the debugger, I
see values of -842150451 for the uninitialized members.)

So is there any way in C++ to let one constructor build on another like
this?

Thanks for any help.

[Ken Alverson]

"Hendrik Schober" <Sp******@gmx.d e> wrote in message
news:e8******** *****@tk2msftng p13.phx.gbl...

Ken Alverson <US********@Alv erson.net> wrote:

"Hendrik Schober" <Sp******@gmx.d e> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

Note that C++ has default parameters which,
AFAIK, where introduced especially to solve
this problem:

Default parameters were introduced because, at the time, there was no such
thing as method overloading. They just happen to also solve some of the
simpler cases of redundant constructors.

"The original motivation for default parameters
was exactly because a ctor cannot call another
ctor for the same type." (Francis Glassborow)
http://www.google.de/groups?selm=pM5...on.demon.co.uk
I don't have D&E handy here, but I believe that
function overloading was among the very first
features of C++. Wasn't there even an 'overload'
keyword (considered?) ones but later dismissed
because it wasn't needed?

OTOH, I know the first one only from Francis'
posting and the second only from my memory, so
i might be wrong.

I could be wrong, and I'm more than willing to admit if I am, but I remember
pretty clearly reading somewhere that the reason we still had default
parameters was backward compatibility with pre-overload code. If overloads
had existed from the get-go, it was argued that default parameters would never
have been created. I'll see if I can find where I read that and see if it has
any credibility.

Ken

[Arnold the Aardvark]

This is something that kinda sorta might work, but it's horribly
inefficient:

Circle::Circle( int x, int y, int r)
{
//> Circle(x, y);

Circle temp(x, y);
std::swap(*this , temp); // temp now contains our unitialised values
// and will quietly disappear at the end of
// this scope.
this->Radius = r;
}

I don't recommend this at all. It is cheaper and more readable to hand off
to an init() function. And more efficient than your example as you only set
values once [if we ignore the fact that the members have already been
default initialised to garbage in every case]:

Circle::Circle( )
{ init(0, 0, 0); }

Circle::Circle( int x, int y)
{ init(x, y, 0); }

Circle::Circle( int x, int y, int r)
{ init(x, y, r); }

What you are attempting is a Java idiom not a C++ one. Don't be mislead by
superficial similarities in syntax; they are totally different animals. You
should definitely prefer member initialiser lists:

Circle::Circle( )
: PointX(0), PointY(0), Radius(0)
{ }

Circle::Circle( int x, int y)
: PointX(x), PointY(y), Radius(0)
{ }

Circle::Circle( int x, int y, int r)
: PointX(x), PointY(y), Radius(r)
{ }

FWIW I learnt Java and C++ the other way around. I find I miss little
things, too: templates, RAII, type safe containers... Ho hum.
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Arnold the Aardvark]

Ken Alverson wrote:

I could be wrong, and I'm more than willing to admit if I am, but I
remember pretty clearly reading somewhere that the reason we still had
default
parameters was backward compatibility with pre-overload code.

"Given general function overloading, default arguments are logically
redundant and at best a minor notational convenience. However, C with
Classes had default argument lists for years before general overloading
became avilable in C++." - Stroustrup, D&E, S:2.12.2.
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Ken Alverson]

"Arnold the Aardvark" <[e-mail]> wrote in message
news:bv******** ***********@new s.demon.co.uk.. .

Ken Alverson wrote:

I could be wrong, and I'm more than willing to admit if I am, but I
remember pretty clearly reading somewhere that the reason we still had
default
parameters was backward compatibility with pre-overload code.

"Given general function overloading, default arguments are logically
redundant and at best a minor notational convenience. However, C with
Classes had default argument lists for years before general overloading
became avilable in C++." - Stroustrup, D&E, S:2.12.2.

That's the quote I remember, thanks!

Ken

[Hendrik Schober]

Ken Alverson <US********@Alv erson.net> wrote:

[...]

"Given general function overloading, default arguments are logically
redundant and at best a minor notational convenience. However, C with
Classes had default argument lists for years before general overloading
became avilable in C++." - Stroustrup, D&E, S:2.12.2.
That's the quote I remember, thanks!

So I got it wrong.
Now, wait... No! Francis got it wrong! :)
Ken

Schobi

P.S.: Actually... No. This quote still doesn't
say they were not introduced to help with
the problem of redundant constructor code.

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Arnold the Aardvark]

Hendrik Schober wrote:

Ken Alverson <US********@Alv erson.net> wrote:

[...]

> "Given general function overloading, default arguments are logically
> redundant and at best a minor notational convenience. However, C with
> Classes had default argument lists for years before general overloading
> became avilable in C++." - Stroustrup, D&E, S:2.12.2.

That's the quote I remember, thanks!

So I got it wrong.
Now, wait... No! Francis got it wrong! :)

Ken

Schobi

P.S.: Actually... No. This quote still doesn't
say they were not introduced to help with
the problem of redundant constructor code.

I didn't have time to skim the whole book, you understand,
but there was something about:

"The default argument list was a very late addition to
the class definition. It was added to curb the proliferation
of identical 'standard argument lists' for class objects
passed as function arguments, ... they can be used to
make class object declarations less verbose and more
similar to struct declarations." - same section.

He's lost me a bit there. :-( 'standard argument lists'?
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Carl Daniel [VC++ MVP]]

Ken Alverson wrote:

"Mihajlo Cvetanovic" <ma*@RnEeMtOsVe Et.co.yu> wrote in message
news:40******** ******@RnEeMtOs VeEt.co.yu...

There is something called "placement new" which in this context
behaves exactly like calling one c-tor from another, but programmers
are discouraged from using it.

Placement new is only designed to be used on uninitialized memory.
By the time you get to the first line of a constructor, you have a
semi-valid object in that memory that would be wiped out.

You'll sometimes see people doing bizarre (but legal) things like:

this->~Foo();
new (this) Foo();

To "re-initialize" an object. You can use this same technique to "call" one
constructor from within another. But don't.

-cd

[Ken Alverson]

"Carl Daniel [VC++ MVP]" <cp************ *************** **@mvps.org.nos pam>
wrote in message news:uW******** *****@TK2MSFTNG P11.phx.gbl...

Ken Alverson wrote:

Placement new is only designed to be used on uninitialized memory.
By the time you get to the first line of a constructor, you have a
semi-valid object in that memory that would be wiped out.

You'll sometimes see people doing bizarre (but legal) things like:

this->~Foo();
new (this) Foo();

Is that actually legal though? I thought about it, but I wasn't sure if it
was legal to call the destructor before the constructor completed. Either way
it fails if the type of this is really a derived class and not Foo.

Regardless of whether or not it is legal, it's a bad idea, as you noted.

Ken

[Hendrik Schober]

Arnold the Aardvark <[e-mail]> wrote:

[...]
He's lost me a bit there. :-( 'standard argument lists'?
Me too. :)
Arnold the Aardvark

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Ken Alverson wrote:

"Carl Daniel [VC++ MVP]"
<cp************ *************** **@mvps.org.nos pam> wrote in message
news:uW******** *****@TK2MSFTNG P11.phx.gbl...

Ken Alverson wrote:

Placement new is only designed to be used on uninitialized memory.
By the time you get to the first line of a constructor, you have a
semi-valid object in that memory that would be wiped out.
You'll sometimes see people doing bizarre (but legal) things like:

this->~Foo();
new (this) Foo();

Is that actually legal though? I thought about it, but I wasn't sure
if it was legal to call the destructor before the constructor
completed.

Yes, it's legal - the object is considered constructed at the start of the
constructor body. Afterall, an exception thrown from within the constructor
body will invoke the destructor.
Either way it fails if the type of this is really a
derived class and not Foo.
Indeed.

Regardless of whether or not it is legal, it's a bad idea, as you
noted.
Yes - it's evil. I've seen it in clever "production " code written by a
fresh young code-jockey who liked to be too clever...

Ken

-cd