Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!news.tele.dk!feed118.news.tele.dk!not-for-mail Newsgroups: comp.lang.c++ Subject: Re: singleton design References: <320ced85-f297-49bd-80a1-4c3f23aee7ba@glegroupsg2000goo.googlegroups.com> From: Lasse Reichstein Nielsen Date: Mon, 01 Aug 2011 18:39:57 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Rational FORTRAN, windows-nt) Cancel-Lock: sha1:BKBpdSeEsZRBRRf4J5t8TVYIPSo= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 28 Organization: TDC Totalloesninger NNTP-Posting-Host: 87.57.52.80 X-Trace: 1312216811 dtext01.news.tele.dk 36584 87.57.52.80:40236 X-Complaints-To: abuse@post.tele.dk Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:8388 asit writes: > I want to design a singleton class. Ick. Please reconsider. There is usually no good reason to enforce that there is only one instance of a class. Modelling-wise it might make sense to only actually create one instance, but using the singleton (anti-)pattern tends to bite you if you want to test either the class itself or classes depending on it. > here the rule is to make the constructor private. That's okey. What > about copy constructor and assignment operator. If I make it > private, certain things like copying and assigning will lead to > compiler error. How can I handle them ?? If you want to only have one copy, you don't want to have assignment or copying creating more than one instance. If the object is immutable, it might not make any difference, but it still prevents it from being a singleton. You should only pass the object around by reference or pointer. /L -- Lasse Reichstein Holst Nielsen DHTML Death Colors: 'Faith without judgement merely degrades the spirit divine.'