Page 1 of 1
outermost qualifiers are dropped anyway
Posted: 2011-04-20T03:40:08-07:00
by 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)
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T06:37:09-07:00
by 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.
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T06:52:10-07:00
by 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) { }
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T07:13:31-07:00
by magick
'const int' and 'int const' exhibit the exact same behavior. If we're wrong, post a pointer to documentation that says otherwise. Thanks.
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T11:48:07-07:00
by 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.
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T11:55:33-07:00
by 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.
Re: outermost qualifiers are dropped anyway
Posted: 2011-04-20T23:18:04-07:00
by yecril71pl
magick wrote: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
the
signature of f will be
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.