Re: Simple const-related question
On Feb 18, 9:05 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Daniel T. wrote:
On Feb 18, 5:45 pm, nsdevelo...@yahoo.com wrote:
On Feb 18, 6:30 pm, nsdevelo...@yahoo.com wrote:
Is "const Object* pA = new Object(1)" the same as "const Object A(1)"
in terms of creating const objects that should not be modified through
cast-to-non-const pointers. See the following example:
const int* createInt()
{
return new int(1);
}
void myFunc( const int* const_param )
{
cout << "const_param == " << *const_param << endl;
int *non_const_param = const_cast<int*>( const_param );
*non_const_param = 999;
cout << "const_param == " << *const_param << endl;
}
int main(int argc, char* argv[])
{
int a = 1;
const int b = 1;
int* c = new int(1);
const int* d = new int(1);
const int* e = createInt();
myFunc( &a ); // ok
myFunc( &b ); // bad
myFunc( c ); // ok
myFunc( d ); // bad (?)
myFunc( e ); // bad (?)
return 0;
}
I believe the last two examples are OK. "int const* p = new int()" is
fundamentally different from "int const i = 5", because the type of the
object pointed to may be in a read-only area of memory in the second
case, but not in the first. I'm not sure why you would ever need this,
though; if you need a non-const pointer to a dynamically allocated
object, why not just hang onto it in the first place? Unnecessary
const_casts defeat the purpose of declaring a pointer-to-const in the
first place.
I guess my real question is what does "new int(1)" or "new MyObject()"
create - is it always non-const object, or does it depend on the
context as in the following:
MyObject *p1 = new MyObject(); // p1 is non-const
const MyObject *p2 = new MyObject(); // p2 is ???
What about:
MyObject* myFunction()
{
return new MyObject();
}
MyObject* p1 = myFunction(); // p1 is non-const
const MyObject *p2 = myFunction(); // p2 is ???
Get out of the Java habit of putting () after the class name when
calling new. I'm pretty sure that "new Object();"
Allocates a default-constructed Object.
and "new Object;" do
Allocates a potentially uninitialized object, if Object is a POD type.
http://www.research.att.com/~bs/bs_faq2.html#malloc
I don't usually use the parentheses, either, but I guess I probably
should. I also don't usually allocate objects directly with new.
different things.
In answer to your question, the object returned by new is inherently
non-const, but once placed in a const pointer, non-const functions can
no longer be called on that object through that pointer. That doesn't
mean the object is const though, note for example:
Object* o = new Object;
const Object* o2 = o;
o->non_const_func(); // perfectly OK even though the object is being
held in a pointer to const elsewhere.
Agreed.
Thanks for your help. I'm really trying to avoid the caveat described
here:
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.13
Using the author's example, I want to make sure that "const Set *s =
new S(...)" is not the same as "const Set s". Although the author
doesn't fully explain why changing "s" in the latter case through an
explicit non-const pointer cast (e.g. "Set *ps =
const_cast<Set*>(&s)") is a problem, I'm assuming its because the
compiler was free to optimize by substituting the value of "s"
wherever it was used in code. If that's the case, then I guess the
former case works because "s" is a pointer to dynamic memory that is
allocated at runtime. But I'm no expert in compilers, so I just
wanted to be sure there were not other tricks at play (like what if
"Set" had an inline constructor or something).