C++ Initialisation List

A

A

Hi,

It is recommened by many practitioners to always use an initialisation list
to initialise data members of a class. However, I am having problems with
such a list when passing parameters/arguments to a constructor of a class -
see code below:

class Foo{

int number;

public:
Foo(int number): this->number(number) {}
};

The problem lies with the this pointer and the fact that the arguments that
is passed has the same name as a data member of the class. Of course if i
renamed the argument and thus avoid the need of the this pointer the problem
will go away. However, is there a solution to this if i cannot avoid
changing the name of the argument?

Any help appreciated

Regards,
A
 
D

Dave

A said:
Hi,

It is recommened by many practitioners to always use an initialisation list
to initialise data members of a class. However, I am having problems with
such a list when passing parameters/arguments to a constructor of a class -
see code below:

class Foo{

int number;

public:
Foo(int number): this->number(number) {}
};

The problem lies with the this pointer and the fact that the arguments that
is passed has the same name as a data member of the class. Of course if i
renamed the argument and thus avoid the need of the this pointer the problem
will go away. However, is there a solution to this if i cannot avoid
changing the name of the argument?

Any help appreciated

Regards,
A

See a recent post by Andrey Tarasevich (subject "Re: End-of-the-week fun")
that indicates the parameter and the data member may have the same name with
no problems. Just drop the "this" from your example...
 
A

Andrey Tarasevich

A said:
...
class Foo{

int number;

public:
Foo(int number): this->number(number) {}
};

The problem lies with the this pointer and the fact that the arguments that
is passed has the same name as a data member of the class. Of course if i
renamed the argument and thus avoid the need of the this pointer the problem
will go away. However, is there a solution to this if i cannot avoid
changing the name of the argument?
...

Just drop 'this->' and you are done:

class Foo{
int number;
public:
Foo(int number): number(number) {}
};

The memeber names are looked up in the scope of the class ('Foo::number'
is found), the names used in the initializer are looked up in the scope
of the constructor (parameter 'number' is found).

However, many will regard this approach to member/parameter naming as an
example of bad coding style. Maybe you should invent a different name
for either the data member or the constructor parameter.
 
W

Wouter Lievens

Andrey Tarasevich said:
Just drop 'this->' and you are done:

class Foo{
int number;
public:
Foo(int number): number(number) {}
};

The memeber names are looked up in the scope of the class ('Foo::number'
is found), the names used in the initializer are looked up in the scope
of the constructor (parameter 'number' is found).

However, many will regard this approach to member/parameter naming as an
example of bad coding style. Maybe you should invent a different name
for either the data member or the constructor parameter.

I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};
 
H

helge

I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};

what's the [rational] reason for "ending all data members with an
undescore" ?
 
T

Thomas Matthews

helge said:
I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};

what's the [rational] reason for "ending all data members with an
undescore" ?

To differentiate member variables from other variables
such as variables local to a function or module. It is
just one of many popular styles.

Another style is to prefix all member variables with "m_".
But the big point to remember is that all names starting
with an underscore are reserved for the compiler.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
R

Rolf Magnus

helge said:
I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};

what's the [rational] reason for "ending all data members with an
undescore" ?

To show that they are data members and to avoid any accidental hiding
between member variables and parameters or local variables.
 
R

Rob Williscroft

Thomas Matthews wrote in
Another style is to prefix all member variables with "m_".
But the big point to remember is that all names starting
with an underscore are reserved for the compiler.

Such identifiers are reserved only in the global namespace,
this also include's anything at namspace scope declared extern "C".

Identifiers containing a double undescore are reserved everywhere
as are identifiers that start with an undescore followed by an
uppercase letter (presumably A-Z).

So prepending a *single* undescore to member-names that don't
begin with one of A-Z is OK.

Some say that identifiers begining with an uppercase E are reserved
too (as macro's for errno), I haven't seen the relevant quotes from
the standard('s), so I remain to be convinced on this one, still I
avoid all uppercase identifiers begining with E.

And the there is all the macro's defined by the C library getc,
errno, assert etc.

This should probably be in the FAQ, but I couldn't goggle it.

Rob.
 
H

helge

Rolf said:
helge wrote:

I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};

what's the [rational] reason for "ending all data members with an
undescore" ?


To show that they are data members and to avoid any accidental hiding
between member variables and parameters or local variables.

well "hungarian notation" [and clones] are not a part of the language,
the "this" pointer is:

....

private: int m;

void foo(int m ) {
this->m =m;
}

....
 
J

jeffc

A said:
Hi,

It is recommened by many practitioners to always use an initialisation list
to initialise data members of a class. However, I am having problems with
such a list when passing parameters/arguments to a constructor of a class -
see code below:

class Foo{

int number;

public:
Foo(int number): this->number(number) {}
};

The problem lies with the this pointer and the fact that the arguments that
is passed has the same name as a data member of the class. Of course if i
renamed the argument and thus avoid the need of the this pointer the problem
will go away. However, is there a solution to this if i cannot avoid
changing the name of the argument?

Actually, that "trick" has always worked for me: you can use the same name
for the constructor parameter and the member variable (without the this
pointer, of course), and it won't get confused. I don't know if it is
allowed by the standard, but it has worked on all the compilers I've tried.
 
J

jeffc

helge said:
I end all data members with an underscore.

class Point
{
public:
Point(int x, int y);
private:
int x_;
int y_;
};

what's the [rational] reason for "ending all data members with an
undescore" ?

Ummm, to avoid the "problem" that is the subject of this thread? (Of
course, it actually *is* a problem with most normal functions.)
 
J

jeffc

helge said:
well "hungarian notation" [and clones] are not a part of the language,
the "this" pointer is:

...

private: int m;

void foo(int m ) {
this->m =m;
}

...

That's not really the point.
a) you shouldn't wait till the body of the constructor to initialize what
you can initialize in the initializer list
b) "this->" is clunky and redundant. One of the points of OO is to
eliminate extra things like this (much less need for function parameters,
etc.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,023
Latest member
websitedesig25

Latest Threads

Top