From -1940756031735922017 X-Google-Thread: f78e5,e8e0ab29e8861265 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!feed.news.tiscali.de!newsfeed.icl.net!newsfeed.fjserv.net!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: Mon, 25 Jul 2005 22:49:20 GMT Lines: 190 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> 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 1122331782 21518 158.152.254.254 (25 Jul 2005 22:49:42 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 25 Jul 2005 22:49:42 +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 j6PMnKNR012569; Tue, 26 Jul 2005 08:49:20 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Mon, 25 Jul 2005 17:41:22 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 X-Postfilter: 1.3.31 X-Authentication-Warning: serv3.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++:1487 kanze@gabi-soft.fr wrote: > "Steven T. Hatton" wrote: >> kanze@gabi-soft.fr wrote: >> Understood. I believe this is so the compiler can allocate >> memory for the member fields. I'm not sure that "problem" >> needs to be solved for all classes. My objection to the >> #include directive is that it is external to the language, and >> its behavior is not based on program structure. One of the >> most frustrating aspects of C++ is trying to figureout where >> some macro, or other symbol in the current scope originated. >> This is due mostly to the nesting of #includes. > > I don't think you're alone in not liking includes. When one file holds #defined constans and is indirectly #included in another file #defining function-like macros which depend on the #defined constants, and that file is in turn indirectly #included in a user source file which uses the function like macros, you end up with non-returning branches at compile time that make a goto look tame. I'm describing a real C++ program with a significant user base in the above description. The Doxygen file dependencies really /do/ look like spaghetti. >> 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. Some of this goes beyond what should be considered for C++ (although I believe it is being provided with C++/CLI). It seems, however, that C++ makes the process of locating resources unnecessarily difficult. I believe the biggest contributor to the problem of resolving definitions is due to the practically non-deterministic nature of the Cpp. > Or are you referring to the fact that some Java implementations > require that the directory structure be consistent with the > package structure. But even then, unless you know what > CLASSPATH is set to... It is seldom a problem to find what the classpath is set to. I really don't know what other C++ implementations use, but with GCC, there are several factors which go into determining what gets included, and in what order, at compile time. And that just addresses the source code, not the library resources. $LD_LIBRARY_PATH, $LIBRARY_PATH, /etc/ld.so.conf, etc... As for whether Java implementations store their resources in a directory structure reflecting the package structure, and public class names; Java, as I understand _The Java Language Specification_, requires that such a structure be recoverable if, for example, resources are stored in a database. The use of jar files to hold Java resources is practically identical to using a directory structure, and many tools actually support browsing a jar file as if it were an ordinary directory. >> What are your objections to Java's interfaces? They are very >> much the same as pure abstract base classes. > > They are almost exactly the same as a C++ class with no > functions other than pure virtual, and no data other than static > const. I believe you cannot actually get a Java array to enforce constness on its elements. > And nothing private or protected. In sum, a perfectly > arbitrary set of conditions. This is what Bjarne calls a "pure interface", and he strongly advises using them. > Java apparently needed as second something, since its classes > lacked essential features like multiple inheritance. C++ has no > need for it. Bill Venners: "I programmed almost exclusively in C++ for about five years, 1991 to 1996. In those days, I thought the sole purpose of multiple inheritance was to let me inherit data and functions, both virtual and implemented, from multiple superclasses. I never imagined using what's now called an interface in Java, an abstract class that has no data and only pure virtual functions. I just never thought about using multiple inheritance that way, and neither did the C++ programmers with whom I worked. These days you seem to be recommending abstract classes a lot. Was the usefulness of multiply inheriting pure interfaces something that was discovered with experience, or did we just somehow miss the message about" abstract classes? Bjarne Stroustrup: "I had a lot of problems explaining that to people and never quite understood why it was hard to understand. From the first days of C++, there were classes with data and classes without data. The emphasis in the old days was building up from a root with stuff in it, but there were always abstract base classes. In the mid to late eighties, they were commonly called ABCs (Abstract Base Classes): classes that consisted only of virtual functions. In 1987, I supported pure interfaces directly in C++ by saying a class is abstract if it has a pure virtual function, which is a function that must be overridden. Since then I have consistently pointed out that one of the major ways of writing classes in C++ is without any" state, that is, just an interface. "From a C++ view there's no difference between an abstract class and an interface. Sometimes we use the phrase "pure abstract class," meaning a class that exclusively has pure virtual functions (and no data). It is the most common kind of abstract class. When I tried to explain this I found I couldn't effectively get the idea across until I introduced direct language support in the form of pure virtual functions. Since people could put data in the base classes, they sort of felt obliged to do so...." http://www.artima.com/intv/modern.html > And of course, the real problem is the enormous amount of > confusion that using the word "interface" as a keyword has > created, given that Java interfaces represent only a very small > subset of what we normally mean by interface. Actually, the confusion might be comming from the other direction. People do use the expression "interface" when talking about all the public members of a Java class. But the use of the term in that context is usually qualified as a "class interface". In C++ the term interface has many different connotations. It would probably be wise to adopt a practice of using specific language when talking about interfaces in C++. E.g., "pure interface", and "protected interface" are meaningful terms to me. >> > Other than that, I do think that C++ would benefit by a >> > cleaner concept of modules, what is exported, what not, etc. >> > But it isn't quite obvious what. > >> I'm thinking the topics discussed in this article have >> relevance to the concepts of interface, and how they might be >> supported in C++ > >> http://en.wikipedia.org/wiki/Software_library > > Yet another Wiki entry which seems to miss most of the > essential, and wander down more or less unrelated side paths. > But I don't see the relevance to the C++ language anywhere. What I'm thinking is that a module, similar to what has been proposed in this document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf could be thought of as an interface similar to what is used in CORBA, XPCom, DCOP, etc. I don't want to dictate that they must be used in that way, but I would highly recommend their being so used. Which makes me wonder if they should expose any member fields directly. It may even be worth considering making them pure virtual. >> One example where the concept of interfaces has been >> successfully used in C++ development is with IBM's XPCOM. >> Part of using XPCOM involves an OMG IDL-like stub generation >> process which I don't believe is, in itself, viable for >> inclusion in the C++ Standard. > > Corba uses a concept of interfaces. In so far as Corba goes > beyond C++, allowing calls across the network to functions > written in another language, it's use of the word may be > justified. That is exactly what I am trying to formalize, with the exception that I am not trying to specify something that is /intentionally/ language-neutral. I have, however, suggested that something like this would facilitate inter-language communication (or linkage?). -- 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 ]