In article <TKORVOLA.94Apr14114336@dopey.hut.fi> tkorvola@dopey.hut.fi
(Timo Korvola) writes:

|> Consider this:

|> -----
|> class foo
|> {
|>   //...
|> };

|> class bar:
|> public foo
|> {
|>   //...
|> public:
|>   bar( const foo &);
|> };
|> -----

|> The question is whether bar::bar( const foo &) should be considered a
|> copy constructor.  Quoting ARM (Reprinted with corrections, May,
|> 1991), p.  264:

|> "A copy constructor for a class X is a constructor that can be called
|> to copy an object of class X: that is, one that can be called with a
|> single argument of type X.  For example, X::X(const X&) and
|> X::X(X&,int=0) are copy constructors.  A copy constructor is generated
|> only if no copy constructor is declared."

The current draft of the working papers says that " A copy constructor
for a class X is a constructor whose first parameter is of type X& or
const X& and whose other parameters, if any, all have defaults, so
that it can be called with a single argument of type X."  This is a
change (correction) with regards to the ARM.

|> Well, bar::bar( const foo &) can be called with a single argument of
|> type X, by implicit reference conversion.  However, the compilers I
|> have tested (gcc, IBM's xlC and HP's CC) don't treat it as a copy
|> constructor but instead generate a default one.

|> Has the ANSI committee decided that only trivial conversions are to be
|> used when looking for a copy constructor?  This seems silly: in the
|> example above would require the creation of an additional constructor
|> bar::bar( const bar &) the implementation of which would be identical
|> to that of bar::bar( const foo &).  This is particularly annoying,
|> since you can't just even call one constructor from the other.

If bar contains additional data, that is not in foo, then you will
have to provide the copy constructor; a constructor just taking bar
will not copy the additional data.  In many cases, the compiler
generated default will do the job.  If not:

 foo::foo( foo const& other )
     :bar( other )
 {
 }

Is a good start.  You'll have to fill in the rest yourself.  (Hint:
the body is almost always empty.)
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

Consider this:

-----
class foo
{
  //...
};

class bar:
public foo
{
  //...
public:
  bar( const foo &);
};
-----

The question is whether bar::bar( const foo &) should be considered a
copy constructor.  Quoting ARM (Reprinted with corrections, May,
1991), p.  264:

"A copy constructor for a class X is a constructor that can be called
to copy an object of class X: that is, one that can be called with a
single argument of type X.  For example, X::X(const X&) and
X::X(X&,int=0) are copy constructors.  A copy constructor is generated
only if no copy constructor is declared."

Well, bar::bar( const foo &) can be called with a single argument of
type X, by implicit reference conversion.  However, the compilers I
have tested (gcc, IBM's xlC and HP's CC) don't treat it as a copy
constructor but instead generate a default one.

Has the ANSI committee decided that only trivial conversions are to be
used when looking for a copy constructor?  This seems silly: in the
example above would require the creation of an additional constructor
bar::bar( const bar &) the implementation of which would be identical
to that of bar::bar( const foo &).  This is particularly annoying,
since you can't just even call one constructor from the other.

--
 Timo Korvola  Timo.Korvola@hut.fi

Timo Korvola (tkorvola@dopey.hut.fi) writes:

|o|class foo
|o|{
|o|  //...
|o|};
|o|class bar:
|o|public foo
|o|{
|o|  //...
|o|public:
|o|  bar( const foo &);
|o|};
|o|-----

|o|The question is whether bar::bar( const foo &) should be considered a
|o|copy constructor.

|o|Well, bar::bar( const foo &) can be called with a single argument of
|o|type X, by implicit reference conversion.  However, the compilers I
|o|have tested (gcc, IBM's xlC and HP's CC) don't treat it as a copy
|o|constructor but instead generate a default one.

Actually, in this example, we can say that bar is a "foo" but foo "is NOT"
a "bar"... ... therefore this is NOT a copy constructor... Rather a
conversion of one type to another... I cannot construct a valid "bar" from
it's super-class since "bar" may have additional "data members"... How are
they treated... .

If the implementation of bar::bar(const foo &) handles the situation of
the different data members, then indeed it is converting a foo to a bar
...
--

-------------------------------------------
| Bob Zimmerman   bobzim@mcs.com          |
|        Voice:   (708) 402-4664          |
|          Fax:   (708) 402-0617          |
|                                         |
| Anything I say represents only my view! |
| It has nothing to do with the folks I   |
| work for... How's that for a disclaimer |
-------------------------------------------

In article <TKORVOLA.94Apr14114336@dopey.hut.fi>, tkorvola@dopey.hut.fi (Timo Korvola) says:
>
>
>Consider this:
>-----
>class foo
>{
>  //...
>};
>
>class bar:
>public foo
>{
>  //...
>public:
>  bar( const foo &);
>};
>-----
>The question is whether bar::bar( const foo &) should be considered a
>copy constructor.  Quoting ARM (Reprinted with corrections, May,
>1991), p.  264:
>
>"A copy constructor for a class X is a constructor that can be called
>to copy an object of class X: that is, one that can be called with a
>single argument of type X.  For example, X::X(const X&) and
>X::X(X&,int=0) are copy constructors.  A copy constructor is generated
>only if no copy constructor is declared."
>
>Well, bar::bar( const foo &) can be called with a single argument of
>type X, by implicit reference conversion.  However, the compilers I
>have tested (gcc, IBM's xlC and HP's CC) don't treat it as a copy
>constructor but instead generate a default one.
>
>Has the ANSI committee decided that only trivial conversions are to be
>used when looking for a copy constructor?  This seems silly: in the
>example above would require the creation of an additional constructor
>bar::bar( const bar &) the implementation of which would be identical
>to that of bar::bar( const foo &).  This is particularly annoying,
>since you can't just even call one constructor from the other.
>
>--
>        Timo Korvola            Timo.Korvola@hut.fi

I think your example cannot be considered a copy constructor because
there is not enough data to be copied, only a part of 'bar' ( 'foo') is
available, so the copy will be partly uninitialised. What do you want
to put in the members of 'bar' anyway? Initial values ?

   Greetings , Eric