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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/