Rationale for allowing const T* = T* wanted.
Ron Guilmette
rfg at NCD.COM
Sun Mar 3 09:11:38 AEST 1991
In article <10034 at dog.ee.lbl.gov> torek at elf.ee.lbl.gov (Chris Torek) writes:
+In article <3913 at lupine.NCD.COM> rfg at lupine.ncd.com (Ron Guilmette) writes:
+>I have been stirring up trouble in x3j16 [regarding const]
+
+Good :-)
+
+In my opinion, the entire const/non-const setup in ANSI C is wrong.
+(I am not entirely happy with it in C++ either, but note that the notion
+of `const' is fairly different in the two languages.)
+
+There is something fundamentally `bad' about the fact that, for instance,
+a strchr() function must cast a const-pointer to a non-const pointer:
+
+ char *strchr(const char *str, int c0) {
+ char c = c0, sc;
+ for (; *str != c; str++)
+ if (*str == '\0')
+ return (NULL);
+ return ((char *)str);
+ }
+
+In effect, strchr() can be used to `dequalify' a pointer:
The C++ community already knows all about this leftover problem from C.
Fortunately, this can be (and probably will be) simply solved in the
C++ standard (in the library part that is).
In C++, we don't have to suffer this problem because we can *overload*
and provide two different versions of strchr(), like:
const char *strchr (const char *, int);
char *strchr ( char *, int);
The one which actually gets called will depend upon the types of the
actual parameters in the call.
Happy now?
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg at ncd.com uucp: ...uunet!lupine!rfg
// New motto: If it ain't broke, try using a bigger hammer.
More information about the Comp.std.c
mailing list