That's not quite true.
class MyClass
{
public:
void Foo();
void Bar() const;
int n;
}
MyClass a;
const MyClass& b(a);
b.Foo(); // OK, Foo is const
b.Bar(); // Compile error, Bar is not const
b.a = 10; // Compile error, can't modify b because it's const
the "const" in "const MyClass& b(a);" doesn't mean that the memory address
of b doesn't change, it means b can only do const things (like call a
function that's declared as const).
So it is evil that the assignment operator of CRefArray takes a const
reference to a CRefArray as an argument but doesn't actually copy the
CRefArray but rather "attaches" to it.
On Mon, Apr 30, 2012 at 4:49 PM, Alok Gandhi <alok.gan...@modusfx.com>wrote:
> >isn’t “const” keyword a hint that we won’t change input array?
>
> when using 'const' keyword we are merely telling the compiler that the
> memory address of the object (or the pointer) should not change. As you can
> see we are passing the CRefArray& which is to say that we are passing by
> reference, or the pointer to the object. Otherwise when we pass a variable
> directly to a function a local copy of that variable is made in the stack
> frame memory of that function. You can find more on this on the net for
> sure.
>
>
> On 4/30/2012 7:41 PM, piotrek marczak wrote:
>
> isn’t “const” keyword a hint that we won’t change input array?
>
>
