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? > >