From -2934689173697759855 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ede379f5dbbc1549 X-Google-Attributes: gidf78e5,public From: postmast.root.admi.gov@iname.com (blargg) Subject: Re: Suggestion: "typeof" keyword Date: 1999/08/23 Message-ID: #1/1 X-Deja-AN: 516302519 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> <37BBE6CC.FE2475E5@physik.tu-muenchen.de> X-Original-Date: Mon, 23 Aug 1999 07:27:28 -0500 X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 935440209 28630 128.250.29.17 (23 Aug 1999 20:30:09 GMT) Organization: e-mail address IS valid - but fools the spammers X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN8GvLOEDnX0m9pzZAQG/XgF+NS+xepjTSQVL/sUE+CiKwQwnosF0B7bM 0f/2iKlcTtepDRGzs8ol5UFlcD4PeORl =+lYa NNTP-Posting-Date: 23 Aug 1999 20:30:09 GMT Newsgroups: comp.std.c++ In article , sbnaran@uiuc.edu wrote: > On 19 Aug 1999 20:16:34 GMT, blargg wrote: > > >This could be true, but why throw away information? The user can always > >remove it if they want. > > On the other hand, they could always add the information if they want. That's a new one - recovering destroyed information. You should immediately start working on a compression algorithm that does this. You'll make millions. Imagine, compress anything to 0 bytes! Ahem. > Or are there cases where they won't be able to do this? Think of > examples where we use typeof in a template function. That's exactly the point. I'm thinking about "filters" that go between the arguments or return value of a caller and a function invocation. They want to pass everything *exactly*, including reference types. But I suppose this isn't really a problem with typeof in particular. The same exists today with templates. > The next question is what is more intuitive to use: that typeof throws > away top level const and value/reference distinction, or retains it? The real question is, is this convenience coming at the expense of some power of typeof()? > > typeof (ir)::type ir2 = ir; > > Great idea. I tried this program > > #include > template struct typeof_t { typedef T type; }; > template typeof_t typeof(T) { abort(); } > struct A { int a[3]; }; > int main() > { > A a; > cout << sizeof(typeof(a)::type) << '\n'; // LINE 8 > } > > The EDG compilers tell me > "type.cc", line 8: error: expected a ")" > cout << sizeof(typeof(a)::type) << '\n'; // LINE 8 > ^ > As 'typeof' is a keyword in egcs, I had to replace "typeof" with > "Typeof". Egcs gave me a parse error before "::" on LINE 8. > > So it appears that the scope resolution operator cannot be applied > to return types of functions. Uhhh, duhhh! :-) That was a proposed syntax by myself and Christopher Eltschka. It is not currently valid. Must have been disappointing to have it not compile :-( > Which means that "typeof(thing)::type" > can't work. I don't know whether the standard actually mandates > this, but my guess is that it does. The question is why does the > standard mandate this. Because the scope resolution operator doesn't operate on objects on the LHS. > I think that allowing "::" to be applied to the return types of > functions but not introducing the 'typeof' keyword would be a > better idea than introducing the 'typeof' keyword but leaving > the "::" rules alone. Then we could implement struct typeof in > terms of the existing core language. Right. And it takes away the (agonizing :-) choice of what the type would be. The rules of type deduction are determined by the template we use (if we use one). > This saves us the ordeal > of figuring out the semantics of 'typeof'. > > In the previous post you said > > #define typeof(x) typeof(x)::type [shouldn't it be #define typeof(x) typename typeof(x)::type ?] Yep. My brain isn't always fully conformant regarding typename :-) --- [ 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 ]