From 180940948932717931 X-Google-Thread: f78e5,e2cfdf64f67c7793 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit 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: Sun, 26 Sep 2004 11:10:46 -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: Sun, 26 Sep 2004 16:06:03 GMT Delivered-To: std-c++@ucar.edu From: brangdon@cix.co.uk (Dave Harris) Newsgroups: comp.std.c++ Subject: Re: Eliminating uninitialised variables Message-ID: References: <8c8b368d.0409240549.7c0ee626@posting.google.com> Reply-To: brangdon@cix.co.uk X-Orig-X-Trace: news.uni-berlin.de M4r9ZC6tP1Fz/2Xyb8g4Wweys7T5BcY8tp0wihZ8hdlfoKhIo= 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.0 required=3.0 tests=none autolearn=no version=2.64 Lines: 106 NNTP-Posting-Host: 64.81.147.48 X-Trace: sv3-4P4mMktXpg9WjRyaQDxRZ4iJubxAUIuGgmaB/9SfIi+CzQEAD/xPi9qqvFOLZCJcsHJ6p2CxNXUYUUZ!hn6iC40Z4XyfrjtE7gz7uPO8Wha+e54KElxIkjDIqRTuRoz3yULH+Upap/Yd3rK4cpWwJDOTV5De!jilpnf3kl3CCbdH05A== 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++:2881 rmaddox@isicns.com (Randy Maddox) wrote (abridged): > Do we even need to do anything about this? As other posters have > pointed out there are situations in which uninitialized variables are > normal, expected and not a problem. That is why I suggested syntax for leaving variables uninitialised explicitly, when that is what the programmer intends. > Also, don't most compilers do a good job of warning about > uninitialized variables, if the warning level is set high enough > at least? I don't believe so. Some manage it in easy cases, eg for local variables, but it's hard to do well (eg) for class instance variables without also warning for the legitimate cases you mention above. There is currently no portable syntax for the programmer to indicate their intent. > Once the compiler warns it's up to the developer to decide if it is > a problem or not and take corrective action if and as necessary. If it's not a problem, there is no (portable) corrective action available to prevent the warning for that particular case. And in my view, production code should compile clean, with no compiler warnings whatsoever. Your approach would require me to initialise variables always, even though uninitialised variables are sometimes required for correctness and efficiency. Clearly, the crucial idea is to have the __uninitialised syntax or similar. Given that, it seems to me we have 3 choices: (1) Using a variable which is implicitly or explicitly uninitialised remains undefined behaviour in both cases. Compilers are encouraged to warn about the implicit case, but are not required to. (2) Using a variable which is explicitly uninitialised is undefined behaviour. A program which may use a variable which is implicitly uninitialised is ill-formed; a compile-time diagnostic is required. (3) Using a variable which is explicitly uninitialised is undefined behaviour. Variables which are implicitly uninitialised are default/zero-initialised. (By "using" I think I mean an l-value to r-value conversion; I certainly don't mean an assignment to the variable. I'm not aiming for precise legalese at this stage.) (1) is the smallest, least problematic change. It does not affect the correctness or efficiency of existing code. It still allows compilers to detect uninitialised variables at run-time We can start with (1) and move to (2) or (3) later. The disadvantage is that it leaves it up to the compiler vendor. (2) has two problems. First, it breaks existing code. The break is not silent and is easy to fix by adding __uninitialised. The broken code is probably buggy anyway, but might be OK, eg, if it is never executed. Second, it requires us to nail down the exact forms of code that must produce a diagnostic. This will add quite a lot of verbiage to the standard - I guess a page or so. For example, does: enum { Red, Blue, Green } colour = Red; int x; switch (colour) { case Red: case Blue: case Green: x = 0; default: use(x); } require a diagnostic? What if the initialisation of colour isn't visible? What if "Green" is deleted, so the enum's range is 0-1 instead of 0-3? (3) also has two problems. First, it affects the efficiency of existing code. Some code will silently get default initialisation when it doesn't need it. The loss of efficiency will be silent and unobvious (it will often depend on the quality of the optimiser). In most cases it will be too small to show up in a profiler. You can fix it by adding __uninitialised. Second, there may be a long transition period in which some compilers conform to the new standard and others do not. If a programmer relies on the new default initialisation, their code will silently break if they switch to an older compiler that doesn't yet provide it. In practice this probably means programmers will be reluctant to take advantage of the new default initialisation - but they will still benefit from the removal of undefined behaviour. In my view (2) is a non-starter. It's not worth breaking existing code or writing all the verbiage the standard would need. My initial proposal was (3) and I still think this is good, but I am bothered by the potential loss of efficiency. I would be content with (1). -- 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 ]