Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c
Subject: Re: Rationale for allowing const T* = T* wanted.
Message-ID: <4202@lupine.NCD.COM>
Date: 2 Mar 91 23:11:38 GMT
References: <3913@lupine.NCD.COM> <10034@dog.ee.lbl.gov>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 43

In article <10034@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
+In article <3913@lupine.NCD.COM> rfg@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@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.