const read only local copies

Question

Hello

gcc 4.4.4 c89

I am just wondering is it worth passing a const into a function.

i.e.

void do_something(const char *dest, const int size)

The size is a read-only so I don't want to change it. However, some developers never have this as const has it is a local copy that is being used. The pointer is const as you can change the value in the calling routine.

I always have a const on read-only local copies, as it confirms to anyone reading my code that it is a read-only variable. And also, when coding I don't make the mistake of changing it without realizing.

Many thanks for any suggestions,

Answer 1

The so called "const correctness" is very important especially if you are creating some module (dll for example) where other people will use it. It makes it much easier to understand the purpose of the function and helps prevent some odd bugs (among other things). So yes, i would definetly suggest using the const modifier where applicable.

EDIT: now looking closely at the function header, it seems that "dest" is something which the function has to change. Then declaring it as const seems odd.

Answer 2

People's opinion differ on this. I know some perfectly capable developers who write that const for any parameter that should not be changed locally in the function. Logically that is just consequent application of the const-correctness principle.

Whatever you do, however, you should omit the const in the function declaration in the header. The const should be part only in the function definition. C (and C++, too) has rules that make this compatible (i.e a const for a value parameter is ignored (when it affects the parameter only at its toplevel) for pure function declarations that don't have a body). The rationale is that such a const will not change anything with regard to the caller, and is thus an implementation detail of the called function.

This does not hold for your first parameter. Any capable developer i know will put that const there, because it's making an important guarantee to the caller of your function (that it won't change the data pointed to of what is passed in). The name of your parameter, however, seems a bit odd, because it indicates that the function does need to write into what is pointed to.

Notice that to be consequent, you would have to make the first parameter itself const too, like you did with the second parameter. Thus this would become (renaming it to "source" too, to avoid confusion).

void do_something(const char * const source, const int size)

Answer 3

In my opinion there is no point in declaring const on anything else than a pointed area. Scalar parameters (and even pointers) are local copies with the exact same constraints as other local variables. They are in fact local variables and it's sometime appropriate to use them and modify them which may avoid unecessary copies of their values.

char * strcat(char *d, const char *s)
{
  char *p = d;

  while(*p) p++;
  while(*s) *p++ = *s++;
  *p = 0;
  return d;
}


char * strcat(char *d, const char *s)
{
char *p = d;
const char *s2 = s;

  while(*p) p++;
  while(*s2) *p++ = *s2++;
  *p = 0;
  return d;
}

Is the second variant really better? I don't think so.

When using the old K&R syntax it's more obvious that they are local variables of the function.

char * strcat(d, s)
char *d;
const char *s;
{
...

Answer 4

Personally, I like putting const on as many variables as possible – I rarely change the value of a variable once assigned. (One notable exception are of course loop counters/iterators.)

At the very least, this significantly improves debuggability because it ensures that values cannot be changed. This makes tracking the state of the execution much easier. It also improves readability because it signals the intent of working with immutable values.

Consequently, I do the same for function parameters. After all, they behave like normal variables inside the function.

On the other hand, this confuses the hell out of many other programmers so in most collaborative projects I refrain from doing this; it would break consistency and be counter-productive.