On Jul 30, 6:21 pm, "BobR" <removeBadB...@worldnet.att.net> wrote:
> James Kanze wrote in message...
> > On Jul 28, 9:11 am, "BobR" wrote:
> > > JohnQ wrote in message...
> > > > "BobR" <removeBadB...@worldnet.att.net> wrote in messaget...
> > > > > struct Rect : RECT{
> > > > > Rect( long x1 = 0, long y1 = 0, long x2 = 10, long y2 = 10 ){
> > > > > left = x1; bottom = y1; right = x2; top = y2;}
> > > > How will the compiler be able to distinguish between using the default
> > > > constructor and the one above where you gave default values to all the
> > > > arguments? (This is a minor note that is off-topic for the thread).
> > > The one above is the only constructor (once you declare/define one, the
> > > compiler does not).

> > Not quite. There's also a compiler generated copy constructor.

> Thanks James. I posted late night, and started to re-post an
> addition, but, was talking about constructors only.
> Copy-constructors are, to me, an separate column.

I know what you mean. From a language point of view, it may
always be a constructor, but from a logical point of view, I,
too, tend to think of creating a new object as somehow different
from creating a copy. I even have a few special cases where I
keep count of the copies, and the "real" destruction---something
like freeing the resource in RAII---only takes place when the
last copy is destructed. (Boost::shared_ptr is a special case
of this particular idiom.)

> Like the old Chinese restaurant menu, one from column A,
> one from column B, etc. (Ctor, CCtor, op=, Dtor).

More likely, either everything from column B, or nothing:-).

> (what, two from column A?
> that will be another $2.75! only one in col D, the Dessert-tor (when you
> finish that, the meal is over.)).

> Without an constructor, a copy-constructor seems pretty
> useless (how would you get an instance to copy? <G>).

Quite. If you have a user defined copy-constructor (which
inhibits the automatic generation of a default constructor),
you'd better have at least one other user defined constructor as
well.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34