Syntax of constructors of inherited classes calling the original constructor

[lars.uffmann]

I have to work on a rather big project that a bunch of people wrote and
that has no useful documentation at all, my C++ has rusted in a bit,
now I stumbled over a constructor that looks something like the below
and have no idea what to do with it :)

inheritedClass: :inheritedClass ([...bunch of arguments...])
: originalConstru ctor ([...bunch of arguments...])
, m_cells(cells), m_srfcs(srfcs)
{
[... some code ...]
}

Now my problem is that I have no clue what the comma-separated
arguments(?) m_cells and m_srfcs do in this method definition. Is
anyone able to enlighten me what this syntax is good for?

Besides not knowing what those arguments do, I must know wether this
usage of the two class instances (m_cells and m_srfcs are instances of
2 classes) would call their constructor, because in that case I would
need to modify the argument passed to them.

I would simply test this, but the project is just too big and there are
too many changes that I have to do at once before I can do a test
compilation and check it's runtime behaviour.

Any help is appreciated :)

Regards,

Lars Uffmann

[Irina Marudina]

> Copy constructor is a default constructor that exists for each object

that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

The default copy constructor is generated for you by the compiler. It
calls all the copy constructors of the members of the class. If a
member variable is from a primitive type - bitwise copy is done in the
manner you describe.

Regards,
Irina Marudina

[bvatsa]

Hey,

This is a type of initializing the members of class, in which class
contains some other objects as their members. This type of member
initiliazation called as "Member initializqation list"..

U better search "Member initializqation list in c++". in
Google and u may get some idea abt this

..
Gabriel wrote:

la**********@rw th-aachen.de wrote:

Copy constructor is a default constructor that exists for each object

....each class

that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

Regards,

Lars Uffmann

Yup, that's right. You should be careful with this one. if your class
contains any pointers or contains classes containing pointers or
(recurse this), you are about to crash, since the data is not copied
recursively. In theese cases you should either write the copy
constructor or explicitly deactive it.
You can use this idiom to make the copy constructor inaccesible:
class Blob{
private: Blob& Blob(const Blob&);
// other stuff
};

--
Who is General Failure and why is he reading my hard disk?

[deane_gavin]

la**********@rw th-aachen.de wrote:

Copy constructor is a default constructor that exists for each object
that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

Regards,

Lars Uffmann

You need to be careful with your terminology. Saying the "copy
constructor is a default constructor..." is confusing "default
constructor" means something else.

Having said that, yes the compiler generates a copy constructer
automatically for any class unless you choose to declare one yourself.
But the compiler generated copy constructor does not necessarily simply
do a memory copy. Your example was

inheritedClass: :inheritedClass ([...bunch of arguments...])
: originalConstru ctor ([...bunch of arguments...])
, m_cells(cells), m_srfcs(srfcs)
{
[... some code ...]
}

and we are talking about the construction of m_cells.

If m_cells and cells are of the same type, m_cells(cells) in the
initialiser list copy-constructs m_cells. What that means depends on
the type of m_cells and cells. If m_cells is a pointer as I think you
are saying, then the value of cells is indeed simply copied to m_cells.
Both pointers now have the same value so point to the same object.

But if cells and m_cells were objects of a class type you had defined,
then m_cells(cells) would not simply copy memory, it would construct
m_cells from cells using the copy-constructor for that class.

Gavin Deane

[deane_gavin]

deane_ga...@hot mail.com wrote:

la**********@rw th-aachen.de wrote:

Copy constructor is a default constructor that exists for each object
that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

Regards,

Lars Uffmann

You need to be careful with your terminology. Saying the "copy
constructor is a default constructor..." is confusing "default
constructor" means something else.

What's the point of trying to clear up confusion if I'm only going to
write confusing sentences myself. I missed the full stop after "is
confusing". Should have been

You need to be careful with your terminology. Saying the "copy
constructor is a default constructor..." is confusing. "default
constructor" means something else.

Apologies if it wasn't clear first time round.

Gavin Deane

[Gabriel]

bv****@gmail.co m wrote:

Hey,

This is a type of initializing the members of class, in which class
contains some other objects as their members. This type of member
initiliazation called as "Member initializqation list"..

Hmmm. Í don't understand what you are saying. Would you mind to explain
again?

Please don't top-post.

Gabriel
U better search "Member initializqation list in c++". in
Google and u may get some idea abt this

.
Gabriel wrote:

la**********@rw th-aachen.de wrote:

Copy constructor is a default constructor that exists for each object

....each class

that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

Regards,

Lars Uffmann

Yup, that's right. You should be careful with this one. if your class
contains any pointers or contains classes containing pointers or
(recurse this), you are about to crash, since the data is not copied
recursively. In theese cases you should either write the copy
constructor or explicitly deactive it.
You can use this idiom to make the copy constructor inaccesible:
class Blob{
private: Blob& Blob(const Blob&);
// other stuff
};

--
Who is General Failure and why is he reading my hard disk?

--
Who is General Failure and why is he reading my hard disk?

[lars.uffmann]

> Yup, that's right. You should be careful with this one. if your class

contains any pointers or contains classes containing pointers or
(recurse this), you are about to crash, since the data is not copied
recursively.

Gah - Didn't think about this. I >think< it doesn't necessarily pose a
problem
in this case as the newly constructed instance is supposed to use the
very same object m_cells identified by the (referential) argument
cells.

I just had a closer look at inheritedClass, and apparently m_cells is
declared as a reference:
inheritedClass : originalClass {
// some stuff
cellClass & m_cells;
// some more stuff
}

I just had a look into a documentation of declarations by reference at
http://www.everything2.com/index.pl?node=reference
and it appears to me that the copy constructor m_cells(cells) would -
in this case - initialize m_cells with the memory address of cells so
that inheritedClass can use m_cells just as the calling class used the
object cells. Is that correct?

Regards,

Lars Uffmann

[Ben Pope]

la**********@rw th-aachen.de wrote:

Copy constructor is a default constructor that exists for each object
that you create? Basically doing a memory copy of (cells) and
positioning the object pointer m_cells on that memory?

It's not a "memory copy", it calls the copy constructor for all data
members of the class.

For POD, that's bitwise, but not necessarily so for non-POD.

For this reason, smart pointers and other "smart" objects that properly
manage their internals do not require any special treatment.

If you hold a raw pointer to anything, you will probably need to deal
with it in your copy constructor and assignment operator.

Ben Pope

[lars.uffmann]

> If m_cells is a pointer as I think you are saying, then the value of

cells is indeed simply copied to m_cells. Both pointers now have
the same value so point to the same object.

I think that would cover my most recent posts' question - the
initialization list simply makes sure that "inheritedClass " can access
"cells" via it's property "m_cells".
Seems the code is actually doing what it is supposed to be doing.

Reading undocumented, bad structured code by other people is a
nightmare.
Did I just state the obvious? *g*

Thanks everyone - this is probably not the last you'll hear from me,
but this problem is solved now at last :)

Regards,

Lars Uffmann

[deane_gavin]

la**********@rw th-aachen.de wrote:

Yup, that's right. You should be careful with this one. if your class
contains any pointers or contains classes containing pointers or
(recurse this), you are about to crash, since the data is not copied
recursively.

Gah - Didn't think about this. I >think< it doesn't necessarily pose a
problem
in this case as the newly constructed instance is supposed to use the
very same object m_cells identified by the (referential) argument
cells.

I just had a closer look at inheritedClass, and apparently m_cells is
declared as a reference:
inheritedClass : originalClass {
// some stuff
cellClass & m_cells;
// some more stuff
}

I just had a look into a documentation of declarations by reference at
http://www.everything2.com/index.pl?node=reference
and it appears to me that the copy constructor m_cells(cells) would -
in this case - initialize m_cells with the memory address of cells so
that inheritedClass can use m_cells just as the calling class used the
object cells. Is that correct?

Yes. If m_cells and cells are both of type reference-to-cellClass, then
after

m_cells(cells)

in the initialiser list of the inheritedClass constructor, both m_cells
and cells are references to the same object.

But note that while references may well be implemented as pointers by
the compiler, you should not think of them as pointers. They are
different.

http://www.parashift.com/c++-faq-lit...s.html#faq-8.1

Gavin Deane

[Howard]

"Gabriel" <ab***@127.0.0. 1> wrote

You can use this idiom to make the copy constructor inaccesible:
class Blob{
private: Blob& Blob(const Blob&);
// other stuff
};

Constructors don't have a return value. For "Blob", the copy constructor
would be:

Blob( const Blob& );

Perhaps you're confusing that with the assignment operator?

-Howard