From -158617264092910375 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bb2cedb5166b3859 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-11-12 17:45:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!t-online.de!diablo.theplanet.net!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Michiel Salters Newsgroups: comp.std.c++ Subject: Re: Typeof considered harmful (long) Date: Tue, 13 Nov 2001 01:44:00 GMT Organization: http://www.newsranger.com Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <58LH7.21413$xS6.32670@www.newsranger.com> References: X-Trace: mail2news.demon.co.uk 1005615848 mail2news:7834 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request NNTP-Posting-Date: Mon, 12 Nov 2001 02:47:13 EST X-Abuse: abuse@jtwis.com X-Added: Message sent through jtwis.com at 2001-11-12 02:47:28 Lines: 107 Xref: archiver1.google.com comp.std.c++:8142 In article , Brian Parker says... > >Hi all, > >The following is a proposal I have been considering that gives the benefits >of typeof with only minor extensions to the current C++ type deduction >rules... >Introduction: > >The type deduction mechanism of C++98 has several limitations that >unnecessarily limit aspects of generic programming. As a solution for these >limitations, it has often been proposed that a typeof() operator be added as >a language extension. In this paper, it is shown that typeof(), whilst >solving most such problems, is syntactically clumsy and has its own >limitations. As an alternative, the semantics of type deduction in C++ can >be extended without adding a new keyword to produce a more powerful, more >elegant, and easier to use solution. If this extension was implemented, the >language would have much more complete support for generic programming. [ SNIP typeof explanation ] >Proposed solution by extending C++ type deduction: >The fundamental problem is that L and R in the above template function are >essentially non-deduced contexts. A solution, then is to specify that after >function argument deduction, if function template parameters remain >non-deduced and are not used as part of the function signature (excluding >the return type), then the type is deduced to be that of the initializing >expression (or more accurately, it is deduced by the same algorithm that a >function parameter is deduced to match an initialising function argument). > >So, for example, L above will be deduced to be the type of the initializing >expression "p1 * p2", and R will be deduced as the type of the return >expression "local * p2". >A difficulty with the return type deduction is that there can be multiple >return paths from a function. If this is the case then the type R is deduced >as the widest type of all return paths (this is the same rule used for the >return type of the conditional operator (?:) ). If there is no single >convertible type then, of course, the deduction fails. > >At first glance, it may appear that a problem with this solution is that the >function source code needs to be available to the compiler to deduce the >function prototype when the template is instantiated. But this is, of >course, a requirement for a template function anyway, and, as discussed >above, using typeof for the return type essentially requires the user to put >a large part (potentially all) of a function's implementation in the >function prototype in type form anyway. You are wrong. A template can be exported, in which case the source code need not be available where the template is declared. >Note: it may also be argued that a minor disadvantage of this solution is in >the usage of typeof in a non-template function such as the following > >void func() >{ > . > typeof(compose(f1, f2)) ff = compose(f1, f2); > . >} > >(Such a usage, although strictly unnecessary as all types are in principal >known, may still be convenient if the type if large and unwieldy as a return >type from a compose operator often is) In addition, it is a major disadvantage that this solution does not work in class templates. Many of the uses of typeof are not associated with an initializing expression in such context, but are used to define class members. >In summary, the advantages of this extension to the C++ type deduction >mechanism include- >(1) Fully backward compatible- it simply allows code to compile that would >previously fail to compile. >(2) No new keyword needed. >(3) Adds minimal verbiage compared to the use of typeof, and has a >straightforward interpretation that cannot be accidentally used incorrectly. Let's see if (3) holds template void f( Arg a ) { Local i=a, j=a+1; //... } Oops. Is typeof(a)==typeof(a+1) ? If not ? I think this proposal needs some work to handle class templates, exported templates and a cleaner formulation of "THE type of initializing expression" Regards, Michiel Salters -- Michiel Salters Consultant Technical Software Engineering CMG Trade, Transport & Industry Michiel.Salters@cmg.nl --- [ 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.research.att.com/~austern/csc/faq.html ]