I have a simple vector implementation in C, which holds an array of void*. It's up to the user to take care of the actual type.
I want to 'promise' that the vector will not alter its contents, so I store data as:
Struct _Vector{
UInt32 used;
UInt32 size;
const void** arr;
};
I don't know if it's considered "overdoing it" with my constness correctness, but I try to maintain const correctness with my accessors/modifiers:
void vector_add(Vector *v, const void* const elem);
void vector_set(Vector *v, const UInt32 idx, const void* const elem);
When I return an element from the vector, it is a pointer to the user's data so I let the user modify the data being pointed to, by casting away the constness in the internal array.
void* vector_get(const Vector *v, const UInt32 idx){
if ( idx >= v->used )
exitAtError("Vector","Array out of bounds");
return (void*)v->arr[idx];
}
Instead of returning a const void*, I return a void* instead. The idea is that internally, I want to ensure that I am not changing the data being pointed to, but I don't care what happens to the data outside the vector.
Is this considered a correct use of const? I would think it's okay to declare data as const in one place, while having it be mutable elsewhere. I'm unsure after reading many dogmatic articles claiming never to cast away constness, and if it is casted away, then the use of const was not appropriate to begin with.
I want to 'promise' that the vector will not alter its contents
This is C. Data structures do not have behavior. You can define a vector data structure such that the data ultimately pointed-to cannot be modified via the vector, and that's what you have done. Of course, this has its implications.
I don't know if it's considered "overdoing it" with my constness correctness, but I try to maintain const correctness with my accessors/modifiers:
If you're going to bother with const at all, then by all means do adhere rigorously to const-correctness. Otherwise, there's not much point.
When I return an element from the vector, it is a pointer to the user's data so I let the user modify the data being pointed to, by casting away the constness in the internal array.
Nope. You've blown it. const-correctness needs to be all or nothing to be worth anything.
By casting away const, you violate the contract that your Vector type makes with its users by allowing the pointed-to values to be modified via an instance. Indirectly so, to be sure, but that doesn't matter. Moreover, this can contribute to wider violations of const correctness -- suppose, for example, that the data entered into your vector were const in the first place. Then storing them in your data structure would be ok, but you provide functions that could allow them to be modified (or at least would allow an attempt at that).
You could consider using an opaque data structure instead of const-qualifying the members to prevent elements from being accessed directly through the vectors. Ultimately, though, const-correctness will require separate data structures and functions for vectors that contain const data and those that contain non-const data.
I would consider this a bad idea, as it allows writing to const objects without a warning. For example:
const int x = 5;
vector_add(&v, &x);
int *p = vector_get(&v, 0);
*p = 6; // oops
Instead, return const void *. Then you can let the caller make the decision about when to cast away const.
You'll probably end up having two versions of the vector, one holding void * and one holding const void *.
While other answers are correct in limited const-correctness perspective, you should note that in C once pointer entered this vector, there is no way to know if data is [im]mutable. In this case, vector should not care about that and always take and return non-const pointers. If someone wants to pass const-pointer there, he will cast and take care to un-cast when doing get(). It is responsibility of user to restore initial storage semantics, as he does know it.
Your actual claim here is that you will never ever dereference the pointer, but not that it is const. Just write that in docs.