From 618629301710539102 X-Google-Thread: f78e5,e8e0ab29e8861265 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!newsfeed00.sul.t-online.de!t-online.de!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: Tue, 26 Jul 2005 15:46:10 GMT Lines: 89 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1121963458.661748.118300@f14g2000cwb.googlegroups.com> <1122299887.515239.317170@g49g2000cwa.googlegroups.com> <1122336456.595882.282330@g49g2000cwa.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 1122392796 6606 158.152.254.254 (26 Jul 2005 15:46:36 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 26 Jul 2005 15:46:36 +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 j6QFkAgH002576; Wed, 27 Jul 2005 01:46:10 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Tue, 26 Jul 2005 00:13:10 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 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++ Xref: g2news1.google.com comp.std.c++:1496 Bob Bell wrote: > "Steven T. Hatton" wrote: >> kanze@gabi-soft.fr wrote: >> >> > "Steven T. Hatton" wrote: >> >> People can argue that there are mechanisms for locating such >> >> definitions without a great deal of effort. It may only take >> >> a minute. Do that 60 times, and it takes an hour. The >> >> arrangement of different code bases makes this more difficult >> >> than it would be if there were a formal mechanism for >> >> organizing resources(as in Java). >> > >> > I don't know. I've found it just as difficult to locate >> > definitions in Java as in C++. More difficult, in fact, because >> > the definitions are always embedded in a mess of implementation >> > details. >> >> With the exception of interfaces and abstract classes, Java doesn't have >> any distinction between "declaration" and "definition" (that I can thing >> of.) >> Of course these features are used extensively. Nonetheless, because the >> Java source code is more coherently organized by specification (or at >> least recommendation and convention), and also because Java specifies a >> great many infrastructure mechanism to facilitate locating resources, the >> Java resource base can be searched much more effectively and >> deterministically than can a C++ code base. > > As far as I can tell, this simply isn't true; at least, searching for > definitions in a C++ code base does not have to be inefficient or > non-deterministic. Modern IDEs accomplish this quite handily; the > Metrowerks IDE can quickly take me to the definitions of macros, > functions, classes, typedefs, etc. > > In other words, the ability to search a code base is a tools issue, not > a language issue. > > Bob Well, my original reply seems to have gone too far off topic for the moderators to accept, so here's the best response I can give. It was included in my original reply. I'm hoping this is topical enough. Please see this article titled "An empirical analysis of C preprocessor use": http://pag.csail.mit.edu/~mernst/pubs/c-preprocessor-tse2002-abstract.html "Abstract: This is the first empirical study of the use of the C macro preprocessor, Cpp. To determine how the preprocessor is used in practice, this paper analyzes 26 packages comprising 1.4 million lines of publicly available C code. We determine the incidence of C preprocessor usage ? whether in macro definitions, macro uses, or dependences upon macros ? that is complex, potentially problematic, or inexpressible in terms of other C or C++ language features. We taxonomize these various aspects of preprocessor use and particularly note data that are material to the development of tools for C or C++, including translating from C to C++ to reduce preprocessor usage. Our results show that while most Cpp usage follows fairly simple patterns, an effective program analysis tool must address the preprocessor. "The intimate connection between the C programming language and Cpp, and Cpp's unstructured transformations of token streams, often hinder programmer understanding of C programs and tools built to engineer C programs, such as compilers, debuggers, call graph extractors, and translators. Most tools make no attempt to analyze macro usage, but simply preprocess their input, which results in a number of negative consequences; an analysis that takes Cpp into account is preferable, but building such tools requires an understanding of actual usage. Differences between the semantics of Cpp and those of C can lead to subtle bugs stemming from the use of the preprocessor, but there are no previous reports of the prevalence of such errors. Use of C++ can reduce some preprocessor usage, but such usage has not been previously measured. Our data and analyses shed light on these issues and others related to practical understanding or manipulation of real C programs. The results are of interest to language designers, tool writers, programmers, and software engineers. " -- 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 ]