From 6689778864526017635 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8deb6f8d7372d4a3 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2004-04-08 14:05:05 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!newsrout1.ntli.net!news.ntli.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: francis@robinton.demon.co.uk (Francis Glassborow) Newsgroups: comp.std.c++ Subject: Re: "explicit class" (proposal N1582) Date: Thu, 8 Apr 2004 21:05:02 +0000 (UTC) Organization: Southfield Microcomputer SS Lines: 46 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <423c153c.0404070224.bd836ab@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Trace: mail2news.demon.co.uk 1081458302 10030 10.0.0.1 (8 Apr 2004 21:05:02 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 8 Apr 2004 21:05:02 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1BBghp-0002bb-00 for mail2news@news.news.demon.net; Thu, 08 Apr 2004 21:05:02 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i38L4ui2026156; Fri, 9 Apr 2004 07:04:56 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i38L4tnX026146; Fri, 9 Apr 2004 07:04:55 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-User-Agent: Turnpike/6.02-U () X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on mulga.cs.mu.OZ.AU X-Spam-Status: No, hits=0.3 required=5.2 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60-mulga_r1 Xref: archiver1.google.com comp.std.c++:1572 In article <423c153c.0404070224.bd836ab@posting.google.com>, MJ writes >Proposal N1582 suggests to disable the automatic generation of the >following functions: > >- default constructor >- copy constructor >- copy assignment operator >- destructor > >I didn't find anything about the address operator. Is the address >operator function also supposed to be disabled in an "explicit class"? This is under consideration as are a number of other possible additions some of which are somewhat revolutionary (such as looking at mechanisms for making private members invisible and so not participate in overload resolution). In the case of operator & I am not sure whether it is better characterised as auto generated (as is operator =) or can be overloaded in class scope (as is operator new). I think either view is supportable. > >Furthermore, in an "explicit class" I would expect that the implicit >conversion for constructors is turned off (as if the constructors were >declared as "explicit"). Are constructors in an "explicit class" >implicitly declared as explicit? There is a problem here in that we do not have a mechanism for switching conversion behaviour back on. However as the author of the paper I am considering how that option might be incorporated. Perhaps adding '!explicit' and its equivalent 'not explicit' might serve without costing another keyword. > -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects --- [ 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 ]