"this" question

[Alexander Dong Back Kim]

Dear all,

I used to use C++ programming language at all time but moved to C# and
Java. Few days ago, I restarted studying about C++ with a very
beginner's mind. I wrote a simple class and gcc couldn't compile the
class. Any hints that I'm missing?

Header File:

#ifndef __Calc_h__
#define __Calc_h__

class Calc
{
private:
int a;
int b;
public:
Calc();
Calc(int a, int b);

~Calc();

int plus();
int minus();
int multi();
int divide();
};

#endif

Source File:

#include "Calc.h"

Calc::Calc()
{
this.a = 0;
this.b = 0;
}

Calc::Calc(int a, int b)
{
this.a = a;
this.b = b;
}

Calc::~Calc()
{
this.a = 0;
this.b = 0;
}

int Calc:lus()
{
return this.a + this.b;
}

int Calc::minus()
{
return this.a - this.b;
}

int Calc::multi()
{
return this.a * this.b;
}

int Calc::divide()
{
if (this.b != 0)
{
return this.a / this.b;
}
else if (a != 0)
{
return this.b / this.a;
}
else
{
return 0;
}
}


GCC command:

$gcc Calc.cpp -lstdc++

Error Message:

Calc.cpp: In constructor 'Calc::Calc()':
Calc.cpp:6: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:7: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In constructor 'Calc::Calc(int, int)':
Calc.cpp:12: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:13: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In destructor 'Calc::~Calc()':
Calc.cpp:18: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:19: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In member function 'int Calc:lus()':
Calc.cpp:24: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:24: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In member function 'int Calc::minus()':
Calc.cpp:29: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:29: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In member function 'int Calc::multi()':
Calc.cpp:34: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:34: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp: In member function 'int Calc::divide()':
Calc.cpp:39: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:41: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:41: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:45: error: request for member 'b' in 'this', which is of non-
class type 'Calc* const'
Calc.cpp:45: error: request for member 'a' in 'this', which is of non-
class type 'Calc* const'

I think those error messages mean 'a' and 'b' are not members of Calc
class. Why is that?

Thanks,

 

[Mark P]

Dear all,

I used to use C++ programming language at all time but moved to C# and
Java. Few days ago, I restarted studying about C++ with a very
beginner's mind. I wrote a simple class and gcc couldn't compile the
class. Any hints that I'm missing?

Look at the compiler message. "this" is of type Calc* const, notably a
pointer. Where you have "this." you should have "this->". But "should"
is the wrong word here since you don't need to use "this" at all here.
Rather than "this->a = 0" simply write "a = 0".

 

[Alf P. Steinbach]

* Alexander Dong Back Kim:

$gcc Calc.cpp -lstdc++

Try using g++ instead of gcc.

And by the way, instead of

S::S( int x ) { this.myX = x }

just write

S::S( int x ): myX( x ) {}

and in general, drop the "this." in C++.

Cheers, & hth.,

- Alf

 

[red floyd]

Dear all,

I used to use C++ programming language at all time but moved to C# and
Java. Few days ago, I restarted studying about C++ with a very
beginner's mind. I wrote a simple class and gcc couldn't compile the
class. Any hints that I'm missing?

Header File:

#ifndef __Calc_h__
#define __Calc_h__

Other than the fact that "this" is a pointer, and you should use
"this->" instead of "this.", or just drop the "this" completely, your
include guard is also incorrect.

ISO/IEC 14882:2003 17.4.3.1.2/1 specifies that identifiers containing a
double underscore are reserved to the implementation. Also, don't
change it to _Calc_h_, since identifiers with a leading underscore
followed by an uppercase letter are reserved to the implementation in
the global namespace.

 

[wxghust]

Other than the fact that "this" is a pointer, and you should use
"this->" instead of "this.", or just drop the "this" completely, your
include guard is also incorrect.

ISO/IEC 14882:2003 17.4.3.1.2/1 specifies that identifiers containing a
double underscore are reserved to the implementation. Also, don't
change it to _Calc_h_, since identifiers with a leading underscore
followed by an uppercase letter are reserved to the implementation in
the global namespace.


















- -

^_^, "this" is a pointer.

 

[Alexander Dong Back Kim]

^_^, "this" is a pointer.





^_^, "this" is a pointer.

Far out!!!

It seems I become really stupid because of C# and Java programming
languages which never use "->"!!! How can I possibly forget about "->"
operator!!! haha

Thanks guys who commented my question. =)

Thanks heaps,

 

[Juha Nieminen]

and in general, drop the "this." in C++.

Is there something wrong in using "this->" every time when accessing a
member variable or function? One could argue that it increases
self-documentation and clarity.

 

[Alf P. Steinbach]

* Juha Nieminen:

Is there something wrong in using "this->" every time when accessing a
member variable or function? One could argue that it increases
self-documentation and clarity.

It's generally redundant and just visual clutter.

In clean code, "this->" tells you that there is need to apply that.

On the other hand, it might make it easier to templatize a class, where
qualification with "this->" is sometimes one way of resolving what a
name refers to.

Cheers, & hth.,

- Alf

 

[Juha Nieminen]

It's generally redundant and just visual clutter.

In the same way as using variable names longer than one character is
redundant and visual clutter?
Why comment your code either? It's just clutter.

 

[werasm]

In the same way as using variable names longer than one character is
redundant and visual clutter?

No, naming variables well conveys intent and purpose.
e.g:
If I call a <Car> object EmpireState and a building
object <Mercedes>, then it is certainly not going
to help the maintainer. That is why one character
is not used.

OTOH, if you write a class and you know the name
of the member is x (and especially if you follow some
convention, like suffixing the member with _, or prefixing
it with m_), then (<this->) really does become redundant,
and in fact, I've never come across code where people
used (this->) if they did not need to, except maybe
when writing templates, and they are in doubt of whether
the member in question is dependent on T.

Why comment your code either? It's just clutter.

As far as comments go, if you name your functions and
variables well (so that the names convey intent), the
code becomes self-commenting, and commenting is
hardly needed. This has been discussed many times
in the past.

Regards,

Werner

 

[GameboyHippo]

No, naming variables well conveys intent and purpose.
e.g:
If I call a <Car> object EmpireState and a building
object <Mercedes>, then it is certainly not going
to help the maintainer. That is why one character
is not used.

OTOH, if you write a class and you know the name
of the member is x (and especially if you follow some
convention, like suffixing the member with _, or prefixing
it with m_), then (<this->) really does become redundant,
and in fact, I've never come across code where people
used (this->) if they did not need to, except maybe
when writing templates, and they are in doubt of whether
the member in question is dependent on T.


As far as comments go, if you name your functions and
variables well (so that the names convey intent), the
code becomes self-commenting, and commenting is
hardly needed. This has been discussed many times
in the past.

Regards,

Werner

Ideas like that make my job that much harder. I'm constantly porting
old code to new code. Comments are crucial. Maybe not a comment for
every line of code, but perhaps something at the beginning of each
code item that is public (such as functions and classes). Trust me,
I'm not a guru in every business out there so sometimes I need
comments to explain a business rule or two.

 

[werasm]

Ideas like that make my job that much harder. I'm constantly porting
old code to new code. Comments are crucial. Maybe not a comment for
every line of code, but perhaps something at the beginning of each
code item that is public (such as functions and classes). Trust me,
I'm not a guru in every business out there so sometimes I need
comments to explain a business rule or two.

I did not say don't comment. I said your code should be
self-documenting. I don't know in what domain you are
programming, but if your design conveys your intent,
the compiler should do the talking when you are using
the code erroneously (ideally). All said, we don't live
in an ideal world. Nevertheless, use the mechanism
given by the language and your compiler to convey your
intent (and to encapsulate) and then things will be clear
enough for you (and the maintainers).

Yes, if old code does not convey intent, sometimes
comments are sorely missed, but this has nothing to
do with my point. I've also maintained large ugly
projects (with lots of comments), and the comments
did not seem to help.

In fact, sometimes a requirement or two were commented
out, and when uncommenting this, the program would
suddenly crash in some weird place. Other times
code that was not used were kept just in case it
might be used again, etc, etc. It was hard to figure
whether comments were applicable, as comments
applicable to commented out code were left in etc,
etc. I've had my day of maintenance with and without
comments.

W

 

[werasm]

GameboyHippo wrote:

Ideas like that make my job that much harder. I'm constantly porting
old code to new code. Comments are crucial. Maybe not a comment for
every line of code, but perhaps something at the beginning of each
code item that is public (such as functions and classes). Trust me,
I'm not a guru in every business out there so sometimes I need
comments to explain a business rule or two.

BTW, I'm sure your member functions are riddled with:

this->andThat;

c'mon, admit it. Do you really use (this->). is the point the
previous
poster made really valid?

 

[Juha Nieminen]

As far as comments go, if you name your functions and
variables well (so that the names convey intent), the
code becomes self-commenting, and commenting is
hardly needed.

Personally I disagree with that. Comments are a good way
(even for the programmer itself) to visually separate logical
parts of the source code. When you later need to find a
specific part for whatever modification, good comments may
help you find it a lot faster than if there were no comments
at all.

Also it may not be immediately obvious what some part of the
code is doing from the variable names and code alone.

Personally I use this rule of thumb: If I coded something and
some time later I have to go back to that code and at some part
I have to stop for many seconds to try to remember what that part
is doing, I add the a comment explaining it when I do remember.
The rationale is: If to me, who created that code, it's not
immediately obvious what something is doing, it will be much
harder for someone else to understand it. Besides, it helps me
too, because in the future I don't have to once again try to
remember what something is doing.

Also if something uses a non-obvious technique or algorithm
I think it's good to explain it. Nothing is more irritating than
trying to reverse-engineer an ingenuous or complex algorithm from
someone else's source code, simply because he was too lazy to
explain it.

 

[werasm]

Personally I use this rule of thumb: If I coded something and
some time later I have to go back to that code and at some part
I have to stop for many seconds to try to remember what that part
is doing, I add the a comment explaining it when I do remember.
The rationale is: If to me, who created that code, it's not
immediately obvious what something is doing, it will be much
harder for someone else to understand it. Besides, it helps me
too, because in the future I don't have to once again try to
remember what something is doing.

I don't disagree with this, but comments should not be a
replacement or excuse for writing bad code. Using functions
for a single responsibility implies that the way code reads
is a natural comment in itself.

Also, I said "comments are hardly
needed", I did not say never. I personally like dividers to
separate various parts of my class, and to make it
obvious where to add what - related things being
grouped together. I also like to use comments to indicate
what pre and post conditions to functions are because
that is not necessarily obvious from function names,
nevertheless, good names convey intent and reduce
commenting. Using (this->) as opposed to not cannot
be compared to using good identifier names as opposed
to not. Do you use this-> all over the show? I'd
be surprised. If this is the case you are almost alone
IMHO.

Kind regards,

Werner

Also if something uses a non-obvious technique or algorithm
I think it's good to explain it. Nothing is more irritating than
trying to reverse-engineer an ingenuous or complex algorithm from
someone else's source code, simply because he was too lazy to
explain it.

Agreed, but to write the algorithm to be readable takes more time
than to write the algorithm terse and comment it well. It is true
that if you have a good reason to have terse code, then comment
well.

Regards,

Werner

 

[Fred Zwarts]

As far as comments go, if you name your functions and
variables well (so that the names convey intent), the
code becomes self-commenting, and commenting is
hardly needed. This has been discussed many times
in the past.

If you write your clear code no comments are needed about _what_ the code does.
However, comments are always needed to explain _why_ the code does it in that way.
Often there are several solutions for a problem. Why did the programmer select one of them?
An arbitrary choice, or is there a reason to do it in that way? That is something that cannot
be expressed in the code only, but it may become important when the code needs modification.

 

[GameboyHippo]

BTW, I'm sure your member functions are riddled with:

this->andThat;

c'mon, admit it. Do you really use (this->). is the point the
previous
poster made really valid?

Being that I have a background in other high level programming
languages (Perl, PHP, C#, Java, Ruby, etc...), I usually do throw in
'this' to remain consistent. It triggers in my mind that I'm using an
instance variable as opposed to a local variable.

As far as bad code is concern. Usually it is written in C and I have
to port it to C++.

 

[Old Wolf]

Look at the compiler message. "this" is of type Calc* const

It is not const.

 

[Ian Collins]

Personally I disagree with that. Comments are a good way
(even for the programmer itself) to visually separate logical
parts of the source code. When you later need to find a
specific part for whatever modification, good comments may
help you find it a lot faster than if there were no comments
at all.

You could apply the same argument to factoring out those bits of code
into well names functions. Which has the additional benefit of making
the flow of the original function clearer.

Also if something uses a non-obvious technique or algorithm
I think it's good to explain it. Nothing is more irritating than
trying to reverse-engineer an ingenuous or complex algorithm from
someone else's source code, simply because he was too lazy to
explain it.

No one's going to argue with that.