Rationale for allowing const T* = T* wanted.

[Ron Guilmette]

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.