From -1590632790065205444 X-Google-Thread: f78e5,e8e0ab29e8861265 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: hattons@globalsymmetry.com ("Steven T. Hatton") Newsgroups: comp.std.c++ Subject: Re: If C++ had interfaces, what would they be? Date: Thu, 28 Jul 2005 16:55:24 GMT Lines: 82 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <_cadnel6Iu4Qx3XfRVn-tA@speakeasy.net> References: <1121963458.661748.118300@f14g2000cwb.googlegroups.com> <1122299887.515239.317170@g49g2000cwa.googlegroups.com> <1122336456.595882.282330@g49g2000cwa.googlegroups.com> <42E60A63.9050409@cs.york.ac.uk> <1122409313.507177.240760@g14g2000cwa.googlegroups.com> <1122497839.229429.320980@z14g2000cwz.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.demon.co.uk 1122569791 14660 158.152.254.254 (28 Jul 2005 16:56:31 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 28 Jul 2005 16:56:31 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: KNode/0.9.1 X-DMCA-Complaints-To: abuse@speakeasy.net X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j6SGtOCd016810; Fri, 29 Jul 2005 02:55:24 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Wed, 27 Jul 2005 23:09:49 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 X-Spamscanner: mailbox4.ucsd.edu (v1.6 Apr 6 2005 07:48:50, 0.0/5.0 3.0.0) X-Postfilter: 1.3.32 X-Authentication-Warning: serv2.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 68956 j6S49qZ7079474 mailbox4.ucsd.edu) Xref: g2news1.google.com comp.std.c++:1541 Bob Bell wrote: > Steven T. Hatton wrote: > What has that got to do with C++? Much. For one thing, the information structure may not be hierarchically organized if we art talking about C++ code. If there is an extensive use of macros, the adjective "organized" is likely to be inaccurate. With #defines and #includes, changing one value which could be determined by anything from a patch version for a seemingly unrelated program, to a compiler option, the entire structure of a translation unit can be significantly altered. One cannot simply look at the current context and understand what the code in front of him or her means. Even knowing what a macro /can/ be expanded to doesn't tell you /what/ it will be expanded to. Resolving such questions takes (wastes) time. It is not uncommon that trying to read code written in Cpp, and called C++, requires learning an entirely new unstructured programming language. > So you were searching a code base using a tool that was poorly suited > for the job. How does that support the idea that C++ needs to be > changed? It's not a question of whether I can find the source of the non-returning branch. I can find it. The problem is that it exists in the first place. Read the final paragraph in D&E. > I don't see the connection between difficulties associated with using a > web browser to browse code and the idea that use of the preprocessor > can lead to problems; would the situation be any different if you were > using a web browser to find an overload of a function? A template > specialization? A class definition? A free function? AAMOF, yes, such things are _far_ easier to find and evaluate with, for example, doxygen output. I've taken to running Doxygen on all libraries I happen to be using. The documentation at the following link is far from perfect, but it does show the usefulness of the tool http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/ For the most part, I actually prefer my own Doxygen generated output run against code representing the declarations in Standard Library to any of the online documentation of the Standad Library I've seen elswhere. It has virtually no commenting. The infomation it provides is extracted directly from the source code. > Don't get me wrong; I'm all for seeing the preprocessor improve. But I > don't think it's very realistic to hope that it will go away, or be > replaced by something "better". For one thing, it's just too useful; > for some of the things it does, there just isn't any better solution. > (If you haven't already, stop by www.boost.org and have a look at the > preprocessor metaprogramming library.) I wasn't blown away by what I saw. My instincts tell me there are better ways of accomplishing the same things. > As for 1), I don't have an answer for it, and in fact I agree with you; > the preprocessor needs to be used carefully. As for 2), C++ has gone to > great lengths to provide alternatives to the preprocessor. I have to confess, I had never considered macro exclusion as a possible benefit to introducing modules to C++ until I saw Daveed's proposal. That relates back to what I'm talking about regarding interfaces. I didn't start this thread in order to promote any particular concept, or design of something called an "interface". I just thought it would be a good thing to discuss. I just realized (remembered) there is another angle on how the abstract notion of an interface relates the the problem of macros. -- STH http://www.kdevelop.org http://www.suse.com http://www.mozilla.org --- [ 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 ]