From -2033366572156457285 X-Google-Thread: f78e5,e2cfdf64f67c7793 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 28 Sep 2004 09:00:08 -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) Date: Tue, 28 Sep 2004 13:52:57 GMT Delivered-To: std-c++@ucar.edu From: kanze@gabi-soft.fr Newsgroups: comp.std.c++ Subject: Re: Eliminating uninitialised variables Organization: http://groups.google.com Message-ID: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: groups-abuse@google.com Approved: Fergus Henderson , moderator of comp.std.c++ X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on manifold.algebra.com X-Spam-Status: No, hits=0.3 required=3.0 tests=NO_REAL_NAME autolearn=no version=2.64 * 0.3 NO_REAL_NAME From: does not include a real name Lines: 51 NNTP-Posting-Host: 64.81.147.48 X-Trace: sv3-8oGLwQ2FV7zOOmW6Q8+d5a7kTH0gTu+BlINhbLTEeareEhYF28K8c+xjOV9+6uN/5gekYYp6jjd+1oY!5nkFilkSuBs1kNruwaNkLWlnvOAf8sl6KDGdQdUs4Nnaklt1lEYGdGOz87YiBWhx2c5M+f9wmtYb!90ZlFAXiUwZP8RefkH3ImNpKvRrO8t8w 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.13 Xref: g2news1.google.com comp.std.c++:2892 brangdon@cix.co.uk (Dave Harris) wrote in message news:... > > I don't think it is worth doing. Zero-initialization doesn't really > > make sense for object type members, anyway. I think it isn't so much a question of getting a useful initialization. It's more a question of getting something repeatable -- if 0 isn't any good, then your code will fail systematically, and not just at odd moments when you aren't looking. I think in some ways this would be like specifying the order of evaluation in an expression. I don't think that good code would take advantage of it, even if it were guaranteed; it's too subtle, and a reader is too likely to miss the point. On the other hand, it makes whatever was written a good deal more reproduceable; if there is an error, there is always the same error. > Perhaps I used the wrong phrase. I meant the kind of initialisation > static objects get. For built-in types, that's as if they were > initialised from zero. Of course the final bit-pattern may not be > zero, and of course user-defined types have their default > constructors. The only problem I see is how to define this initialization with regards to references. We all know that in practice, depending on context and the compiler, a reference either occupies no memory, or it is a pointer; neither pose a problem for the proposition. But the standard doesn't know this, and I can't figure out how to word your requirement for references. Or course, since a reference MUST be initialized anyway, it is probably sufficient to say that they aren't included in the guarantee. For the rest, I'm all for it. (I'd prefer requiring a trap of some sort when an uninitialized variable is accessed, but I don't think that is very realistic; it wouldn't be very easy or very cheap to implement on the majority of hardware.) -- James Kanze GABI Software http://www.gabi-soft.fr 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 ]