From -1189694844839696353 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ede379f5dbbc1549 X-Google-Attributes: gidf78e5,public From: niklasb@my-deja.com Subject: Re: Suggestion: "typeof" keyword Date: 1999/08/24 Message-ID: <7psmcf$thj$1@nnrp1.deja.com>#1/1 X-Deja-AN: 516723334 Approved: Fergus Henderson References: <7nt3vl$1oe$1@nnrp1.deja.com> <7oh7o8$t3f$1@nnrp1.deja.com> <7ol6hi$ej9$2@news.BelWue.DE> <7oup0a$8g2$1@nnrp1.deja.com> <37B3C2AD.5AB722AE@lucent.com> <37B5A571.449B@wanadoo.fr> <37B908A8.717CAC2C@lucent.com> <7pcvjs$tk4$1@nnrp1.deja.com> <7phk8n$b26$1@nnrp1.deja.com> <37BD2185.C0047293@physik.tu-muenchen.de> <7pk70i$6as$1@nnrp1.deja.com> X-Original-Date: Mon, 23 Aug 1999 23:44:17 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Complaints-To: news@news.unimelb.edu.au X-Http-Proxy: 1.0 RED-PRXY-08, 1.0 x38.deja.com:80 (Squid/1.1.22) for client 131.107.3.78 X-Trace: izvestia.its.unimelb.edu.au 935526728 31794 128.250.29.17 (24 Aug 1999 20:32:08 GMT) Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Mon Aug 23 23:44:17 1999 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN8MBH+EDnX0m9pzZAQHCIAF/Zq/PiZG2hleIklqKZ/kiJ0zSEXs1i9k2 A2ReWY04QzsdClnqQ1gkVYqCpvpX04Cb =YY8Y X-MyDeja-Info: XMYDJUIDniklasb NNTP-Posting-Date: 24 Aug 1999 20:32:08 GMT Newsgroups: comp.std.c++ In article , postmast.root.admi.gov@iname.com (blargg) wrote: > In article <7pk70i$6as$1@nnrp1.deja.com>, niklasb@my-deja.com wrote: > > [snip] > > Did you put in an extra "typeof" here? > > template > II find(II begin, II end, const typeof(*II())& val ); > > Don't you mean this? You're right, typo on my part. > > This allows for better parameter validation, and > > better diagnostics, because the compiler has more > > information about the parameter types. > > This gives no extra information about the parameter types. It simply > restricts them. Isn't that the same thing? (When you restrict the domain of a variable, you gain information about what the variable can or cannot be.) > > For example, the compiler could infer from the > > declaration that the first two parameters must > > be of a type that defines operator *. Thus, given > > a call like > > > > find(0, 0, 0); // error: parameter 1: type 'int' > > // does not define operator* > > > > the compiler could flag the first parameter as > > an error -- at the call site. > > That's interesting, but considering the things it wouldn't check, I don't > like this inconsistency. For example, find probably needs operator ++ > defined, but that wouldn't be expressed in the interface. True, if improved parameter validation for template functions were the main goal of typeof, I'd have to say it failed; but since it's merely a happy side- benefit, it seems to me some error-checking is better than none. > > Similarly, given the first two parameters the > > compiler would know the exact type of the third, > > so given a call like > > > > vector v; > > double d = 1.0; > > find(v.begin(), v.end(), d); // error: parameter 3: > > // cannot convert 'double' to const int& > > > > the compiler could flag the third parameter as an > > error -- again, at the call site. > > This is a new one to me, even using the current language definition! Last > time I checked, a const ref could be bound to a temporary. Duh, got me again. Ok, substitute some other type for which there is no conversion -- a string or another iterator, say. > > Without typeof, both of these errors would surface > > only later, when instantiating the body of the > > template function, and the compiler could not easily > > know whether to attribute the error to the function > > or its caller. > > But as I said, this is such inconsistent sparse checking, it's a false > sense of usefulness. I concede that typeof is not (and was not meant to be) a complete solution to the problem of specifying the constraints on template parameters. My intent was merely to point out an interesting side- benefit. I still think it would be kinda useful. The false-sense-of-security argument can be taken too far, as in, 'The compiler can never catch all programming errors, so the fact that it catches any only engenders a false sense of security.' :) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]