tags:

views:

1163

answers:

12

I've often used pointers to const objects, like so...

const int *p;

That simply means that you can't change the integer that p is pointing at through p. But I've also seen reference to const pointers, declared like this...

int* const p;

As I understand it, that means that the pointer variable itself is constant -- you can change the integer it points at all day long, but you can't make it point at something else.

What possible use would that have?

+3  A: 

Same as a "const int" ... if the compiler knows it's not going to change, it can be optimization assumptions based on that.

struct MyClass
{
    char* const ptr;
    MyClass(char* str) :ptr(str) {}

    void SomeFunc(MyOtherClass moc)
    {
         for(int i=0; i < 100; ++i)
         { 
                 printf("%c", ptr[i]);
                 moc.SomeOtherFunc(this);
         }
    }
}

Now, the compiler could do quite a bit to optimize that loop --- provided it knows that SomeOtherFunc() does not change the value of ptr. With the const, the compiler knows that, and can make the assumptions. Without it, the compiler has to assume that SomeOtherFunc will change ptr.

James Curran
Won't SomeOtherFunc have to be declared with a const pointer argument for this to compile? And won't that also be how the compiler would know that SomeOtherFunc won't change the pointer? So declaring the local pointer as const doesn't seem to help.
Andrew Johnson
Andrew: I think you're confusing ptr with this
Leon Timmermans
@Andrew: No. SomeOtherFunc is completely allowed to change any other part of MyClass object.
James Curran
+13  A: 

When you're designing C programs for embedded systems, or special purpose programs that need to refer to the same memory (multi-processor applications sharing memory) then you need constant pointers.

For instance, I have a 32 bit MIPs processor that has a little LCD attached to it. I have to write my LCD data to a specific port in memory, which then gets sent to the LCD controller.

I could #define that number, but then I also have to cast it as a pointer, and the C compiler doesn't have as many options when I do that.

Further, I might need it to be volatile, which can also be cast, but it's easier and clearer to use the syntax provided - a const pointer to a volatile memory location.

For PC programs, an example would be: If you design DOS VGA games (there are tutorials online which are fun to go through to learn basic low level graphics) then you need to write to the VGA memory, which might be referenced as an offset from a const pointer.

Adam Davis
Minor nitpick: for memory mapped devices you certainly (not 'might') need to have the item marked as volatile - otherwise you couldn't be sure if or when the compiler would actually emit the read or write operation.
Michael Burr
+5  A: 

another example: if you know where it was initialized, you can avoid future NULL checks. The compiler guarantees you that the pointer never changed (to NULL)…

bene
In C. In C++, in your particular case (i.e. non-NULL pointers), you use references instead.
paercebal
+2  A: 

I have seen some OLE code where you there was an object passed in from outside the code and to work with it, you had to access the specific memory that it passed in. So we used const pointers to make sure that functions always manipulated the values than came in through the OLE interface.

epotter
+3  A: 

In any non-const C++ member function, the this pointer is of type C * const, where C is the class type -- you can change what it points to (i.e. its members), but you can't change it to point to a different instance of a C. For const member functions, this is of type const C * const. There are also (rarely encountered) volatile and const volatile member functions, for which this also has the volatile qualifier.

Adam Rosenfield
+2  A: 

I've always used them when I wanted to avoid unintended modification to the pointer (such as pointer arithmetic, or inside a function). You can also use them for Singleton patterns.

'this' is a hardcoded constant pointer.

Tom Ritter
+15  A: 

It allows you to protect the pointer from being changed. This means you can protect assumptions you make based on the pointer never changing or from unintentional modification, for example:

int* const p = &i;

...

p++;     /* Compiler error, oops you meant */
(*p)++;  /* Increment the number */
Andrew Johnson
I have never seen that before and I agree that it is a very useful trick.
Rob
It's not a trick :). I try to use const where possible with function arguments so that it is clear that the function won't modify the string or structure being passed in.
Andrew Johnson
A: 

always think of a pointer as an int. this means that

object* var;

actually can be thought of as

int var;

so, a const pointer simply means that:

const object* var;

becomes

const int var;

and hence u can't change the address that the pointer points too, and thats all. To prevent data change, u must make it a pointer to a const object.

DavidG
+1  A: 

Several good reasons have been given as answers to this questions (memory-mapped devices and just plain old defensive coding), but I'd be willing to bet that most instances where you see this it's actually an error and that the intent was to have to item be a pointer-to-const.

I certainly have no data to back up this hunch, but I'd still make the bet.

Michael Burr
i use it a lot for optimization.
DavidG
+4  A: 

One use is in low-level (device driver or embedded) code where you need to reference a specific address that's mapped to an input/output device like a hardware pin. Some languages allow you to link variables at specific addresses (e.g. Ada has use at). In C the most idiomatic way to do this is to declare a constant pointer. Note that such usages should also have the volatile qualifier.

Other times it's just defensive coding. If you have a pointer that shouldn't change it's wise to declare it such that it cannot change. This will allow the compiler (and lint tools) to detect erroneous attempts to modify it.

Michael Carman
+1  A: 

Think of type* and const type* as types themselves. Then, you can see why you might want to have a const of those types.

Shadow2531
yeah, and that type is basically an int.
DavidG