From -1543521981166676165 X-Google-Thread: f78e5,2a0144bbf1d6a893 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: jfa1@cec.wustl.edu ("James Aguilar") Newsgroups: comp.std.c++ Subject: Re: Proposal: Allow member typedefs to be used in return types without qualification Date: Fri, 22 Apr 2005 21:53:37 GMT Organization: Washington University in St. Louis Lines: 63 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <8lv9e.22540$ox3.11441@trnddc03> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1114206830 26506 158.152.254.254 (22 Apr 2005 21:53:50 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 22 Apr 2005 21:53:50 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU X-MSMail-Priority: Normal X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j3MLrbSp029199; Sat, 23 Apr 2005 07:53:37 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Fri, 22 Apr 2005 20:09:47 +0000 (UTC) X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:4573 ""Max T. Woodbury"" wrote in message news:8lv9e.22540$ox3.11441@trnddc03... > > This causes technical parsing problems. The return type of the function has > to be known to be a type to parse it properly. In order to identify it as a > type in this context you need to know which class the member function belongs > to, but that information is not available until the 'Example::' is seen. So > what you want to do is not possible given that parsing is a sequential > process. This is not the case. Any LALR(1) parser should be able to put the return type lower on the Abstract Syntax Tree than the function node. For instance, the syntax for the rule in CUP would be something like this: FunctionHeader ::= Typename:t Identifier:i OPAREN FParamList:fpl CPAREN {: RESULT = FunctionNode(i); RESULT.addChild(t); RESULT.addChild(fpl); :} I do not know what it would look like in YACC or whatever the C++ compiler compiler is, but, to my knowledge, all of the set of compiler compilers use LALR(1) style parsers. And other such out of order syntax is easily permitted. The return type could definitely be resolved to class scope without changing the accepted language very much, and certainly the current set of accepted programs could still be accepted with this modification. Now, I can see another reason, and that's that the parameters -look- like they are scoped to the class, whereas the return type does not, but this argument is far from convincing for me. > There are two ways around the sequencing problem. The simplest would be to > put the return type after the function name. This would be a major change to > declaration syntax and would break every "C" and "C++" program ever written. > That makes this first possibly totally unacceptable. The second would be > to make the context qualifier 'sticky'. That is > > Example::result_type operator ()(input_type in1, input_type in2) > { > return in1 < in2; > } This could possibly work but doesn't really make much sense in the overall context of "this method is part of a class. Now everything else here is also part of that class." "This return type is part of a class, now everything else is," is much less attractive. > would be an acceptable definition of 'Example::operator ()'. How wise this > change to the language would be is another question of course and I have NO > opinion on that. Thanks for your input. - JFA1 --- [ 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://www.jamesd.demon.co.uk/csc/faq.html ]