From -1330392815189560958 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:14 -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:53:18 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: <4150695d@andromeda.datanet.hu> 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: 46 NNTP-Posting-Host: 64.81.147.48 X-Trace: sv3-J3agJJxtj3MwIy1KsOlLFpUNrAR2qxEs4/WB8EO3Th7RUvn5ovngMaTqOGq4IxUnJOpnh0Vp8QAEdml!++aEizF2HANxTlgj7UQehc5/G87miE2aUYRJbTwMp0zjvJosrEvPs2uGt63JqTPpjp0SHXetbkwO!3Kotzsf6DRBwneY2UNGWSHznJp5BSi/a 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++:2894 sean@f4.ca (Sean Kelly) wrote in message news:... > walter@digitalmars.nospamm.com ("Walter") wrote in message > news:... > > It's too bad there is no NaN pattern for integer types. Even better > > would be a memory bit per location that could be set to > > "uninitialized" which would cause a trap if that location was > > read. I wonder some times how many latent bugs of this nature are in > > shipping applications . > The standard does leave room for trap values, though I haven't > encountered a compiler that uses them. My only concern with having > C++ default initialize primitives to a NaN-like value is that it would > silently break a lot of code that relies on current default > constructor behavior (ie. set to zero). Quite nice for D, but it may > be too late for C++. The current situation is that accessing an uninitialized object is undefined behavior. Zero initialization only applies to statics. Many years back, I imagined an ideal hardware: it used 1's complement, and never generated a negative 0. Any read of an object with all one bits would trigger a trap. Manipulating the stack pointer caused any newly accessible memory to be initialized with all one bits. In practice, today, there are no trapping representations for integral types. In practice, too, null pointers and 0.0 floating points are generally all bits 0. Initialization with 0's is thus simple and easy for the implementation. And I'd prefer all types initialized with 0 to, say, int's initialized with 0 but floating points with trapping values. I'd prefer everything to trap, but that not being reasonable, I'd prefer consistency -- everything follows the same rules. -- 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 ]