outermost qualifiers are dropped anyway

[yecril71pl]

The outermost const qualifiers in function declarations like MagickSetSize mean nothing, either to the compiler or to the developer, and should be dropped:

Code: Select all

  MagickBooleanType MagickSetSize(MagickWand *wand,
    /* const */ size_t columns, /* const */ size_t rows)

[magick]

The const tell the developer that the value is read-only. Since the value is read-only it permits the compiler to possibly better optimize the code. If we try to assign the value we get

• wand/magick-property.c: In function 'MagickSetSize':
  wand/magick-property.c:2864:1: error: assignment of read-only parameter 'columns'

which is meaningful to the developer. If you disagree we will need a better explanation before we could consider removing the const.

[yecril71pl]

The way to go is (and has always been):

Code: Select all

/* declaration */
void foo (int);
/* implementation,works even in C++ */
void foo (int const x) { }

[magick]

'const int' and 'int const' exhibit the exact same behavior. If we're wrong, post a pointer to documentation that says otherwise. Thanks.

[yecril71pl]

The point is not whether you put the outermost const qualifier before or after the type. Just do not put it in the API declaration, and even less into the documentation.

[magick]

Well again, const is meaningful to a developer. It tells the developer the value does not change in the scope of the method and we also want the docs to match exactly the signature of the method.

[yecril71pl]

Well again, const is meaningful to a developer. It tells the developer the value does not change in the scope of the method and we also want the docs to match exactly the signature of the method.

Since the only developer that is concerned about such things is the implementor of this particular function, I assume that you have the implementor in mind. However, even if you declare

Code: Select all

void f(int const);

the signature of f will be

Code: Select all

void f(int);

The only location where const should be preserved is the definition, not the signature. So I guess you meant to exactly match the definition instead.

Now, having the documentation tailored specifically for the implementor of the documented method is a bit funny. Of course, it does not harm much, except for rising the surprise factor for client developers Anyway, I do not intend to annoy you about this any more.