From -7905538559661802287 X-Google-Thread: f78e5,e2cfdf64f67c7793 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!peer01.cox.net!cox.net!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: brangdon@cix.co.uk (Dave Harris) Newsgroups: comp.std.c++ Subject: Re: Eliminating uninitialised variables Date: Wed, 22 Sep 2004 20:29:55 GMT Lines: 80 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1GKClHFePJUBFwoH@jgharris.demon.co.uk> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1095884999 19648 158.152.254.254 (22 Sep 2004 20:29:59 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 22 Sep 2004 20:29:59 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Spam-Checker-Version: SpamAssassin 2.64-mulga_r1 (2004-01-11) on mulga.cs.mu.OZ.AU X-Orig-X-Trace: news.uni-berlin.de P27d9TsDVQtVt3poWV7CdQwu1gcwyRCg6Kw+rmSumamxFPzfo= X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64-mulga_r1 X-Reply-To: brangdon@cix.co.uk X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i8MKTtBV016546; Thu, 23 Sep 2004 06:29:55 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:2843 news0@nospam.demon.co.uk (John G Harris) wrote (abridged): > 1 Are there any compilers that make a good job of warning about the use > of uninitialised variables? If there are then surely that's a better > solution. It is legitimate to have uninitialised variables, so long as they are not accessed, so I don't think the compiler should warn about them. I have seen classes where an initialised variable is used to guard access to potentially uninitialised ones. An extreme example: class Stack{ int array[10000]; int top; public: Stack() : top(0) {} void push( int x ) { array[top++] = x; } int pop() { return array[--top]; } }; Here the array contents are not initialised, but I don't think the compiler should warn about it. We can't reasonably expect the compiler to figure out what the code is doing at run-time. In general that could involve solving the Halting Problem. > 2 Why is zero a better junk value than any other junk value? I am not suggesting a junk value. I am suggesting code like: int *get() { int *result; if (condition()) result = value(); return result; } would become well-defined and reasonable practice. It would return 0 when condition() is false. I think 0 is the most useful and natural value, not least because it is legal for so many built-in types (especially pointers). Also because it is already used for static variables. > 3 Wouldn't it be simpler to say that all stack space and all heap space > is zeroed before (re-)use? How does that differ from what I said? Are you assuming the bit-pattern of all-zeros is a valid representation for all built-in types? Whose responsibility is it to zero the memory? How do I avoid the zeroing if I have a legitimate performance reason? > 4 What about volatile? Good question. I hadn't thought about it, but I don't think it causes any new problems. These: // Proposed volatile int x; volatile int x( __uninitialised ); under the new regime would have the semantics of: // Current volatile int x( 0 ); volatile int x; under the current regime - whatever semantics those happen to be. I do think that volatile is a compelling reason for supporting __uninitialised (or equivalent). Avoiding superfluous memory writes can be a matter of correctness as well as performance. -- Dave Harris, Nottingham, UK --- [ 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 ]