From 4598284865152405398 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,386ad3d115455fbe X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-12-06 09:14:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: markus.mauhart@nospamm.chello.at ("Markus Mauhart") Newsgroups: comp.std.c++ Subject: Re: properties of scalar objects w/ indeterminate value //Re: iterator defect or feature? Date: Fri, 6 Dec 2002 17:14:08 +0000 (UTC) Organization: Customers chello Austria Lines: 95 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <3de29db4.7069828@news.earthlink.net> <3defdcd5.44116609@news.earthlink.net> X-Trace: mail2news.demon.co.uk 1039194848 15335 10.0.0.1 (6 Dec 2002 17:14:08 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 6 Dec 2002 17:14:08 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18KM3C-0003zC-00 for mail2news@news.news.demon.net; Fri, 06 Dec 2002 17:14:07 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA16292; Sat, 7 Dec 2002 04:13:57 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-NNTP-Posting-Date: Fri, 06 Dec 2002 11:17:58 MET X-Spam-Status: No, hits=-4.5 required=5.0 tests=INVALID_MSGID,NOSPAM_INC,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:15760 "Andrew Koenig" wrote ... > > > AFAICS this kind of well defined "copy/assignment between same types" > > applies to all 'un-initialized' ('indeterminate value') scalar types. > > No -- it applies *only* to unsigned char. For all other scalar types, > the effect of trying to copy an uninitialized value is undefined. "James Kuyper Jr." wrote ... > > None of the above expressions work for pointers. See section 4.1: "If > .... the object is uninitialized, a program which requires this [lvalue > to rvalue] conversion has undefined behavior". Copy assignment between > same types requires lvalue to rvalue conversion for the copied object; > if that object is uninitialized, it has undefined behavior. "John Potter" wrote ... > > The answer is quite simple. 4.1/1 An lvalue to rvalue conversion on > an uninitialized object is undefined behavior. > > Thow shalt not look at an uninitialized object. Thanks for pointing this out, it was a consistent vote ! I'm only surprised about what "uninitialized" means, that is now I have to change my mind about it. Especially from [dcl.init] 8.5 I thought that the declarations I had used generate initialized objects having indeterminate value, and that only strange code can generate references to "uninitialized" objects. [dcl.init] 8.5,par1: A declarator can specify an initial value for the identifier being declared. The identifier designates an object or reference being initialized. Therefore I thought that the following generates objects that have been "being initialized". iterator i; T* p; double d; [dcl.init] 8.5,par9: If no initializer is specified for an object [...] the object and its subobjects, if any, have an indeterminate initial value90); if the object or any of its subobjects are of const-qualified type, the program is ill-formed. (The last phrase actually indicates that such 'pseudo-initialized' objects are no 1st-class citizens) But now it looks like that in my mind I should replace ... "have an indeterminate initial value" with ... "have an indeterminate initial value and are considered 'uninitialized'" "[Note: you can not even copy or equ-compare their value]" And probably the same then is true for C99, e.g. copying a pointer p 'initialized' only via "T* p;" is undefined behaviour, right ? For me this is currently surprising, e.g. it tells me to be very carfully when relying on the compiler-generated implicit def-ctor and cpoy-ctor of a POD type: struct basic_string { private: wchar_t buf[32]; public: def-ctor() {buf[0] = 0;} //oops, have forgotten initializer "buf()" cpy-ctor(y):buf(y.buf) {} //oops, reading many uninitialized wchar_t }; Or .. struct efficient_vector { private: T buf[32] ;size_t len; public: def-ctor():len() {} //oops, have forgotten initializer "buf()" cpy-ctor(y):buf(y.buf) {} //oops, reading many uninitialized T }; Kind regards, Markus Mauhart. --- [ 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 ]