Re: [AD] Update on `const' |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Laurence Withers wrote:
> - `const' is C89. This means that probably every compiler we use
> accepts it, so we can do away with the ugly AL_CONST and just
> use plain const. If this does prove to be a problem anywhere, we can
> use preprocessor trickery to solve it.
Even if this is true, is it worth converting back to 'const'? The fact
that we switched in the first place means that preprocessor trickery
with 'const' is not too easy, and using AL_CONST makes it almost
trivial. What's the gain?
> - Several functions have incorrect semantics, taking a const pointer
> but returning a mutable one. An example of this is `get_filename'. I
> suppose the idea behind it is that the function doesn't alter the
> string, so it is passed as `const', but the user might want to alter
> it afterwards, so it is returned as mutable. This is not really
> valid; in actual fact, in situations like this, we should have two
> functions:
>
> char* get_filename(char* path);
> const char* get_filename_const(const char* path);
Ugh? what's wrong with
char *get_foo(char const * path); ?
It means (AFAIK) exactly what you say: the parameter is not altered,
and the return value may be altered. In the case of get_filename
you're right though: a pointer to a part of the original string is
returned, meaning implicitly that the return value is const as
well. In C++ the function probably wouldn't compile as it is now,
since it assigns a const string to a non-const pointer.
> We have to treat `char*' and `const char*' as separate types.
I think in this case we should just make the return value of
get_filename be const. Are there any examples where it is really
useful to split this up in 2 functions? It seems awkward to me.
Hein Zelle
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
Hein Zelle hein@xxxxxxxxxx
http://www.icce.rug.nl/~hein
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<