From -5324095534787635516 X-Google-Thread: f78e5,e8e0ab29e8861265 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 25 Jul 2005 14:10:11 -0500 Return-Path: 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) Delivered-To: std-c++@ucar.edu From: kanze@gabi-soft.fr Newsgroups: comp.std.c++ Subject: Re: If C++ had interfaces, what would they be? Organization: http://groups.google.com Message-ID: <1122299887.515239.317170@g49g2000cwa.googlegroups.com> References: <1121963458.661748.118300@f14g2000cwb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g49g2000cwa.googlegroups.com; posting-host=62.160.54.162; posting-account=qsfl8gwAAABZGaLp2a7FeTfDkJamzWYW X-Virus-Scanned: amavisd-new at ucar.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.ucar.edu id j6PDwpNC016432 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Mon, 25 Jul 2005 14:06:51 CST Lines: 117 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-LoyH5+Nh2MMbSnn7JaKu5MpxLycriQLq85czF3/7bHB4t0civwXfy5f0X3guHYvREVY1xEgVq5Iw1cZ!D4ayvR3gGv/C7rOywAXl+7HLjFbA42rtbAink1InHUe23lLhinOBS26M31bU3zKRNbbdKJL8oON4!/AKImr+1j+ycCqVRbMgh4rCcjN28RI5vNC3PCcoveW4= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:1479 "Steven T. Hatton" wrote: > kanze@gabi-soft.fr wrote: > > Steven T. Hatton wrote: > > [...] > >> I'm wondering if there would be any advantage in attempting > >> to formalize the notion of an interface as it relates to > >> the #include directive. I'm thinking that something along > >> the lines of the OMG's IDL might serve as a starting point > >> in designing such a feature. > > I think that part of the problem you perceive is purely > > pragmatic. Ideally, we'd all like to put the "interface", > > and only the interface, in the header, and everything else > > in the implementation files. From the very beginning, > > however, C++ has struck a pragmatic compromize -- there are > > very practical reasons why class definitions must contain > > the specification of the private members, even though they > > aren't part of the "interface". > 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. > 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. 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... [...] > >> I acknowledge that it might also serve as an example of why > >> such a feature should *not* be introduced into C++. One > >> thing that is not clear to me is /what/, exactly, the term > >> "interface" should mean in C++. Is there any potential > >> practical advantage to introducing a formal language > >> construct called an "interface"? What would that construct > >> consist of? > > Personnally, I would oppose any proposal which used the key > > word interface, simply because the Java (mis-)implementation > > of it has caused too much confusion around it. > 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. And nothing private or protected. In sum, a perfectly arbitrary set of conditions. Java apparently needed as second something, since its classes lacked essential features like multiple inheritance. C++ has no need for it. 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. > > 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. > 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. -- James Kanze GABI Software Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 --- [ 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 ]