From -4072999534142881018 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,4441c5f6d7843223 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-08-12 10:53:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: "Adam H. Peterson" Newsgroups: comp.std.c++ Subject: Re: C++0x Wish List (explicit class) Date: Mon, 12 Aug 2002 17:52:27 GMT Organization: Brigham Young University Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <3D48C729.40503@spamnot.codeweavers.com> <8c8b368d.0208060921.43e9e9d5@posting.google.com> <8c8b368d.0208120553.1e2b6a8e@posting.google.com> X-Trace: mail2news.demon.co.uk 1029174753 mail2news:19350 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) Delivered-To: std-c++@ncar.ucar.edu MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-Priority: 3 X-MSMail-priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 Lines: 168 Xref: archiver1.google.com comp.std.c++:13214 > We all seem to be in agreement that boost::noncopyable and the > proposed new use of explicit solve the exact same problem, i.e., they > prevent the compiler from automatically generating unwanted members > for a class, and both allow the developer to later provide those > members if and as they become desirable. So far, so good. > > However, I would argue that the proposed new use of explicit is > cleaner in that it more concisely expresses the developer's intent > without introducing external dependencies. I'll take the counter-argument. Which looks cleaner to you? class Complicated1 : noncopyable {}; or explicit class Complicated2 {}; Perhaps this is a judgement call, but it looks to me a lot more obvious that there will be issues with copying Complicated1 than it does with Complicated2, at least in the header file. The diagnostic generated for violating these semantics will probably be pretty similar in either case. > > Moreover, I would further argue that use of boost::noncopyable has a > bit of a problem, in addition to being possibly misleading in its > name. The problem is that if you derive from boost::noncopyable, and > then later do want to add one of the members not automatically > provided by the compiler, then the member that is added will contain > an error that, while it has no effect in this particular case, could > be flagged by the compiler if warning levels are set high enough, and > will certainly be flagged by a lint-like tool. The problem is that > the copy ctor and assignment operator for boost::noncopyable are > declared as private and not implemented. Thus, even if you later do > decide to provide one of these operations in your derived class, you > cannot ever copy or assign the boost::noncopyable base class. In that > sense your copy ctor or assignment operator is technically incorrect, > and this error could well be flagged by some tools. For a base class > with any data members this would be a real potential error, and it is > only not so for boost::noncopyable due to the fact that the class has > no data members. Well, I must make a deep personal confession that I have never used Lint or anything like it. I've frequently meant to, but have not found the time or a compelling need. That said, I would say that if such a tool would generate such a diagnostic that could not be suppressed, it would be in error. It is entirely conceivable that a user-defined type may define assignment or copy to do any number of things, as long as it has a semantically consistent interface. What would lint say if my class were using handle/body and simply forwarded operator=() to body->makeSameAs()? (I am partly asking because I don't know, having never used them.) I would especially think that not calling _private_ data members and base classes's op= or copy ctor would be reasonable, since I may have to jump through any number of hoops to construct a consistent interface. I know this is the case for my NeuralNet objects that are composed of a directed-graph-like set of subobjects. There is no mapping between NeuralNet::operator= and Node::operator=. Such a mapping doesn't make sense when the internal graph has to be rebuilt to match the parameter's internal structure. > > Thus, the newly proposed use of explicit would accomplish the same end > as use of boost::noncopyable, but without the possibility of > generating warning messages about an incorrect copy ctor or assignment > operator. And, yes, that warning could be safely ignored, in this > particular case, but I generally do not like to see warnings ignored > since doing so may lead to ignoring real problems. I personally don't like warnings on safe behavior, especially if they cannot be suppressed. The result is a developer using a perfectly valid construct and living with a list of warnings every time he compiles. One of these days, he's going to skip a legitimate warning in that long list. I have a similar gripe about signed/unsigned warnings when the conversion is formally specified by the language and a cast just makes the code more brittle. > > On the basis of the new use of explicit being cleaner and clearer, not > introducing any external dependencies, and not making the copy ctor or > assignment operator, if later implemented, technically incorrect in a > way that could well be flagged by certain tools, I would have to say > that, IMHO, the new use of explicit is a better solution. Since > boost::noncopyable exists to solve a real problem, and has been widely > used, I would say that the C++ committee might be moved to take a look > at this issue. I'm not convinced that boost::noncopyable exhibits any serious shortcomings in solving the problem. What I'd rather see is having it become std::noncopyable in C++0x. If this were to happen, it would be all the easier for lint-like tools to fix their false positive warnings by recognizing the standard way to make a class noncopyable and the standard way to overrule it. > > I would further say that I see no reason why boost::noncopyable, the > new use of explicit, and the idiom of private declaration with no > definition cannot coexist, especially since the latter idiom is > somewhat different in its effect because with either of the first two > methods a developer may later merely declare and implement a member if > and as necessary. I agree that these constructs may all coexist. But I still don't see where explicit class solves any problem better than current methodology, especially if noncopyable becomes part of the standard. Assuming this comes about, if some compiler writer wanted to, they could make inheriting from std::noncopyable behave exactly the same way you want explicit class to behave, with the added benefits that, 1) the grammar of c++ doesn't have to be changed, and 2) we are spared from having yet another keyword overloaded. > With the private declaration and no definition > idiom, doing this would generate a compiler error if a later developer > simply added one of the prohibited members, and in that sense it is a > slightly stronger statement of developer intent, and one that the > compiler can assist in enforcing. I'm not sure I follow. If you're talking about someone adding the member in a derived class, I don't see any difference between the approaches. If you're talking about adding the member in the class with the privately declared copy-oriented members, than I would assume three things about this developer. 1) This developer, in modifying the class definition, is a maintainer of some sort to the class. 2) Before starting such an undertaking, he has read the class definition as currently constituted. He will know that the class is noncopyable/explicit as this will be one of the first things he reads in the definition. Or he will see the private declarations and know exactly how to override the original developer's choice. 3) By undertaking to modify this definition, he hopefully has some idea what the ramifications are, or else he's a monkey trying to type Shakespeare on a teletype. But arguing the merits of private declaration doesn't do anything to strengthen the position that explicit class should be added to the language. > Thus, each of these idioms is > slightly different, and may be appropriately used in different > situations, although there is a good deal of overlap in their meaning. I agree that there are pros and cons between boost::noncopyable and private declaration, making it desirable to choose one or the other in different circumstances (which I would think mostly depend on which developer is doing the choosing). But I don't see any real differences between noncopyable and explicit class. I also think it would be detrimental to have two camps of programmers doing essentially the same thing with different syntaxes. I think this would do more harm than good to people trying to learn C++ (which, IIRC, was a principle motivation for introducing this in the first place). > This, I think, is a good thing, and in keeping with the spirit of C++ > allowing developers to solve the same problem in a way that best fits > both their needs and their own programming style. C++ provides great power as a multiparadigm programming language. Multiparadigm programming is one of the biggest reasons I stick with C++ even after all its nasty quirks. When there is more than one way to do something, it is usually because the different ways to do things in different paradigms. boost::noncopyable and explicit class are both solutions within a single paradigm of programming, though. TIMTOWTDI for its own sake is, IMO, not the spirit of C++. It is more the spirit of Perl, and Perl has felt the effects of it. --- [ 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 ]