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...])
: originalConstructor ([...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

[deane_gavin]

[e-mail] wrote:

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...])
: originalConstructor ([...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?
http://www.parashift.com/c++-faq-lit....html#faq-10.6
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.

Yes, that syntax calls the constructors for m_cells and m_srfcs

Gavin Deane

[Gabriel]

la**********@rwth-aachen.de wrote:

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,
I doubt that this is a good idea. You seem not to be qualified for this.
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...])
: originalConstructor ([...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?
m_cells and m_srfcs are members variables of inheritedClass. The above
initializes theese varibles with the values 'cells' and 'srfcs'.

This is a very basic idiom. You should refer to your Stroustrup (chapter
10.4.6) or other textbook of your choice to read about it.
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.
No need to change the project. Just create a very small sandbox project
with just one file to explore the syntax and behaviour of this idiom.

Gabriel
Any help is appreciated :)

Regards,

Lars Uffmann

[Gabriel]

la**********@rwth-aachen.de wrote:

Btw, I'm just curious: At which institute do you work?

Gabriel

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...])
: originalConstructor ([...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

[Sunil Varma]

la**********@rwth-aachen.de wrote:

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...])
: originalConstructor ([...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

the comma separated arguments m_cells and m_srcs are initialization
constructs for those variables of that class.

those constructs call the corresponding constructors depending on the
type of arguments.

[lars.uffmann]

> m_cells and m_srfcs are members variables of inheritedClass.

The above initializes theese varibles with the values 'cells' and 'srfcs'.
Thank you - I've had a chance to talk with my "boss" at the institute
in between and that is the information I was looking for, he said the
same :)

For a moment I was wondering why the initialization isn't done in the
inherited Constructor, but that is because then the properly
initialized member variables would NOT be available for the original
constructor to be handled. Either way, this option of initializing
member variables was completely new to me :)
No need to change the project. Just create a very small sandbox
project with just one file to explore the syntax and behaviour of
this idiom. TBH, I only started working with Linux again when I was assigned to
this project, and while I am quite comfortable with producing quality
C++ code, I am not so familiar with the gnu compiler and makefiles yet
:)
I'll have to experiment a bit before I get a test project running I
guess, just been to lazy to do that yet.
Btw, I'm just curious: At which institute do you work?

Institute of Aerodynamics - we're working on a numerical flow solver,
my job is to merge two versions that have been modified by different
people without the use of a CVS, and later to port the flow solver for
usage on a cluster system (simultaneous computing).
Regards,

Lars Uffmann

[lars.uffmann]

btw thank you for the parashift link, Gavin, that sort of covered all
questions I had left about the initialization list :)
Except that I am still not sure wether this calls the constructors of
m_cells and m_srfcs. Because the call m_cells(cells) just initializes
the class, and (cells) is not an argument for m_cells constructor, but
rather an object of the same type as m_cells.

Either way, my main question is answered - I do not need to modify the
code in this case at all :)

Regards,

Lars Uffmann

[Sunil Varma]

la**********@rwth-aachen.de wrote:

btw thank you for the parashift link, Gavin, that sort of covered all
questions I had left about the initialization list :)
Except that I am still not sure wether this calls the constructors of
m_cells and m_srfcs. Because the call m_cells(cells) just initializes
the class, and (cells) is not an argument for m_cells constructor, but
rather an object of the same type as m_cells.

Either way, my main question is answered - I do not need to modify the
code in this case at all :)

Regards,

Lars Uffmann

in such case it calls the copy constructor of the of the m_cells
objects' class.

[lars.uffmann]

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

[Gabriel]

la**********@rwth-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?

[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**********@rwth-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**********@rwth-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...])
: originalConstructor ([...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]

[e-mail] wrote:

la**********@rwth-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.com 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**********@rwth-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**********@rwth-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**********@rwth-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

[Gabriel]

Howard wrote:

"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

Yes, I was. Looked too long as I wrote it, but I just couldn't see it.
Thanx.

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