Re: [AD] constness in ugetx() |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
gfoot@xxxxxxxxxx wrote:
> Can't you make it ugetx(char const **c)? I don't know much about
> `const', but I think that makes the chars are not const, the outer
> pointer is, and the inner pointer is not.
I tested 16 all permutations of putting const keyword in four different
places (ugetx(const char const * const * const c)) and it seems like the
two first positions are equivalent (both meaning that the actual
characters are read-only). Unfortunately, it also seems that none of the
permutations can handle both being passed non-const `char **' and `const
char **'.
I'll try to explain how it seems to work:
IMO it's very hard to think about these things so I'll use the
following diagram, displaying three chunks of memory of which the first
two are pointers:
[char **x, the pointer] -> [char *y] -> [char s]
`x' is the only piece of memory that will be copied to local memory when
passing `x' as an argument to `ugetx()'. `y' will be increased by
`ugetx()' so that it points to the next unicode character of `s'. `s' is
the memory location where the actual characters are stored. Putting
`const' in the first or second position will tell the compiler that `s',
ie the actual characters, are be read-only. Putting `const' in the third
position will tell the compiler that `y' is read-only -- but `y' will
indeed be changed, so that ought not to be an option. Putting `const' in
the fourth position will tell the compiler that `ugetx()' won't change
the local parameter, ie it won't change its copy of `x'. Yuck, this is
hairy: I hope it made sense to someone :-)
Now, the problem in our case is that if you pass a non-const `char **'
to ugetx(), the resulting pointer in the calling function will also be a
non-const `char **', but if you pass it a `const char **' the resulting
pointer in the calling function will still be a `const char **'. I.e. if
the characters of the string were read-only, they will continue to be so
and otherwise they will continue to be writable. However, the compiler
can't be told that it works this way using the `const' keyword.
So, unless I have gotten something wrong (very likely :-) I can still
only see the solutions that I mentioned in my previous email:
- Provide two functions, `ugetx(char **x)' and `ugetx_c(const char
**x)' (or whatever they should be called).
- Use the current solutions, forcing people who pass non-const a `char
**' to do an unlogical typecast.
- Throw away the `const' keyword in `ugetx(), forcing people who pass a
`const char **' to do an unlogical typecast.
And in each case we could provide overloaded functions for C++ users.
Any opinions?
Sven