copy constructor problem

[al.cpwn]

class test {
public:
test()
:a(0)
{

}
int get() { return a; }
test(const test& t)
:a(t.get())
{
}
void modify()
{
a++;
}
private:
int a;
};
Intuitively it seems that the parameter to copy constructor should be
const test&
However, if I try to use get() method, my compiler gives the error:

i:\Documents and Settings\Al Cpwn\My Documents\Visual Studio
Projects\c++\1.cpp(11) : error C2662: 'test::get' : cannot convert
'this' pointer from 'const test' to 'test &'

Can someone please help me understand why?

[dragoncoder]

[e-mail] wrote:

class test {
public:
test()
:a(0)
{

}
int get() { return a; }

Modify the above line so that get() is a const member function
int get() const { return a; }

[Richard Herring]

In message <11**********************@j33g2000cwa.googlegroups .com>,
al*****@gmail.com writes

class test {
public:
test()
:a(0)
{

}
int get() { return a; }
test(const test& t)
:a(t.get())
{
}
void modify()
{
a++;
}
private:
int a;
};
Intuitively it seems that the parameter to copy constructor should be
const test&
However, if I try to use get() method, my compiler gives the error:

i:\Documents and Settings\Al Cpwn\My Documents\Visual Studio
Projects\c++\1.cpp(11) : error C2662: 'test::get' : cannot convert
'this' pointer from 'const test' to 'test &'

Can someone please help me understand why?

You're trying to call the non-const function get() on the const
reference argument t.

Change it to int get() const { return a; }
--
Richard Herring

[Kai-Uwe Bux]

al*****@gmail.com wrote:

class test {
public:
test()
:a(0)
{

}
int get() { return a; } Try:

int get () const { return a; }
test(const test& t)
:a(t.get())
{
}
void modify()
{
a++;
}
private:
int a;
};
Intuitively it seems that the parameter to copy constructor should be
const test&
However, if I try to use get() method, my compiler gives the error:

Best

Kai-Uwe Bux

[al.cpwn]

I have a question: how does the compiler know which function to call,
is the const keyword sufficient? For primitive types such as int or
double, do we also have const keyword specified for certain operations?

[Phlip]

al.cpwn wrote:

I have a question: how does the compiler know which function to call,
is the const keyword sufficient? For primitive types such as int or
double, do we also have const keyword specified for certain operations?

Could you post a code sample of the effect you are asking about?

The guideline is "top-level const is bad karma", but we don't know if you
are asking about top-level const.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Richard Herring]

In message <11**********************@z34g2000cwc.googlegroups .com>,
al*****@gmail.com writes

[please quote some context so we know what you're talking about]

I have a question: how does the compiler know which function to call,
is the const keyword sufficient?
If a class has both const and non-const versions of a member function,
it decides which to call on the basis of whether the object (or the
salient reference or pointer to it) is const or not.
For primitive types such as int or
double, do we also have const keyword specified for certain operations?

Primitive types don't have such member functions. Can you give an
example of what you mean?

--
Richard Herring

[al.cpwn]

Richard Herring wrote:

In message <11**********************@z34g2000cwc.googlegroups .com>,
al*****@gmail.com writes

[please quote some context so we know what you're talking about]

I have a question: how does the compiler know which function to call,
is the const keyword sufficient?
If a class has both const and non-const versions of a member function,
it decides which to call on the basis of whether the object (or the
salient reference or pointer to it) is const or not.

For primitive types such as int or
double, do we also have const keyword specified for certain operations?

Primitive types don't have such member functions. Can you give an
example of what you mean?

for example:
int a=0;
a++; //++(int) is non const

const int b=0;
b++; //error

do we get an error because there is no const function named ++(int)? or
do we get an error because the compiler simply knows that ++(int) will
change b somehow.
--
Richard Herring

[Gernot Frisch]

do we get an error because there is no const function named ++(int)?
or
do we get an error because the compiler simply knows that ++(int)
will
change b somehow.

Don't you mate aliens because you know it won't bring forth kids, or
do you not mate them because they don't exist?
What's the difference?

-Gernot

[al.cpwn]

Gernot Frisch wrote:

do we get an error because there is no const function named ++(int)?
or
do we get an error because the compiler simply knows that ++(int)
will
change b somehow.

Don't you mate aliens because you know it won't bring forth kids, or
do you not mate them because they don't exist?
What's the difference?

thank you for taking the time to share your rhetoric. If you had a
better response that would have been great as well.

[Richard Herring]

In message <11*********************@t31g2000cwb.googlegroups. com>,
al*****@gmail.com writes

Richard Herring wrote:

In message <11**********************@z34g2000cwc.googlegroups .com>,
al*****@gmail.com writes

[please quote some context so we know what you're talking about]

>I have a question: how does the compiler know which function to call,
>is the const keyword sufficient?
If a class has both const and non-const versions of a member function,
it decides which to call on the basis of whether the object (or the
salient reference or pointer to it) is const or not.

>For primitive types such as int or
>double, do we also have const keyword specified for certain operations?
>

Primitive types don't have such member functions. Can you give an
example of what you mean?

for example:
int a=0;
a++; //++(int) is non const

const int b=0;
b++; //error

do we get an error because there is no const function named ++(int)?

Yes. According to section 13.6 the built-in operator ++ is equivalent to
calling the (non-member) operators operator++(int &) {prefix} or
operator++(int &, int) {postfix} and there are no equivalent operators
taking const int & arguments. So technically the error is indeed because
there is no const operator++ that can be applied to int.
or
do we get an error because the compiler simply knows that ++(int) will
change b somehow.

It amounts to the same thing. Since you can't redefine the built-in
operators for arithmetic types, there's no way to tell the difference.

--
Richard Herring

[Richard Herring]

In message <P1**************@baesystems.com>, Richard Herring
<ju**@[127.0.0.1]> writes

In message <11*********************@t31g2000cwb.googlegroups. com>,
al*****@gmail.com writes

Richard Herring wrote:

In message <11**********************@z34g2000cwc.googlegroups .com>,
al*****@gmail.com writes

[please quote some context so we know what you're talking about]

>I have a question: how does the compiler know which function to call,
>is the const keyword sufficient?

If a class has both const and non-const versions of a member function,
it decides which to call on the basis of whether the object (or the
salient reference or pointer to it) is const or not.

>For primitive types such as int or
>double, do we also have const keyword specified for certain operations?
>
Primitive types don't have such member functions. Can you give an
example of what you mean?
for example:
int a=0;
a++; //++(int) is non const

const int b=0;
b++; //error

do we get an error because there is no const function named ++(int)?

Yes. According to section 13.6 the built-in operator ++ is equivalent
to calling the (non-member) operators operator++(int &) {prefix} or
operator++(int &, int) {postfix} and there are no equivalent operators
taking const int & arguments. So technically the error is indeed
because there is no const operator++ that can be applied to int.

Oops... because there is no operator++ that can be applied to const int
&.
It's a non-member, so the constness of the operator itself is moot.

or
do we get an error because the compiler simply knows that ++(int) will
change b somehow.

It amounts to the same thing. Since you can't redefine the built-in
operators for arithmetic types, there's no way to tell the difference.

--
Richard Herring