From 5287495086156837486 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,e81c11f6dfdb3cd2 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-06-11 10:07:02 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Daniel Frey Newsgroups: comp.std.c++ Subject: Re: default object init (w: suggestion for C++Ox) Date: Mon, 11 Jun 2001 17:06:20 GMT Organization: aixigo AG Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3B248346.2843304@aixigo.de> References: <9fol0l$52$1@woodrow.ucdavis.edu> <3B207BDB.9A5AAA2F@aixigo.de> <3b2290d9@andromeda.datanet.hu> X-Trace: mail2news.demon.co.uk 992279198 mail2news:758 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au 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) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Sender: 320011725109-0001@t-dialin.net X-Accept-Language: en X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.cs.mu.OZ.AU id SAA26089 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id DAA04894 Lines: 82 Xref: archiver1.google.com comp.std.c++:5933 Balog Pal wrote: >=20 > "Daniel Frey" wrote in message news:3B207BDB.9A= 5AAA2F@aixigo.de... >=20 > >While we are at it: I sometimes forget to initialize a member variable > >if I have large classes and several ctors. Would it make sense to allo= w > >declaring a member variable as 'explicit', meaning you have to provide > >it for all ctors? For example: >=20 > I'm sure it would make even more sense to make your 'explicit' the def= ault for the builtin types. I tried not to break compatibility. But I agree that it's a good idea to make it the default. > There was a proposal in the past dealing with this problem in an intere= sting new way: >=20 > int foo; // would mean int foo =3D int(); setting a defined value, 0 > int foo =3D noinit; // asking the behavior that is default now. I wonder if this is consistent. I'd prefer "int i;" and "int i =3D int();= " to be the same, giving me an uninitialized variable. If I want to initialize it, I'd write "int i =3D 0;" or "int i =3D int( 0 );". This is the usual difference between T::T() and=20 explicit T::T( const U& init_Value ); > Using that all variables in an existing program would gain legal values= , eliminating undefined bahavior due to accessing unitialised objects. At= the cost of little grow of binaries and a few cycles. That determined p= rogrammers could gain back by adding that noinit where appropriate, if th= ey find it necessary. (In a really correct program noinit is pretty rare = in any case.) But they are initialized without the programmer specifying the value - again this could lead to surprisingly effects. The above suggestion does what it promises: No value specified -> no initialization, Value specified -> initialization. For a new C++, this all could make sense in a larger picture: I'd prefer to get rid of PODs as far as possible. When working with integers, you should use a class providing them for you. But I think we had that discussion already in anther thread recently, so I don't want to rewind it here... > note another interesting side effect: you could grep all the places you= use uninitialsed stuff. Correct, but I don't consider it important. > Certainly your explicit would have use having that, if some members nee= d nondefault initialisation. Just let's not step on the keyword overloadi= ng path again, selecting a fresh new word. Though I don't like new keywords, it would be OK if they fit into a consistent picture. I think my first proposal is the conservative approach - not breaking backward compatibility, while yours is an intermediate solution, better in some points, breaking compatibility and only the part of a necessary renovation. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de --- [ 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.research.att.com/~austern/csc/faq.html ]