In article <3b2290d9@andromeda.datanet.hu>, "Balog Pal" <pasa@lib.hu>
wrote:

> int foo; // would mean  int foo = int();  setting a defined value, 0 int
> foo = noinit; // asking the behavior that is default now.
>
> Using that all variables in an existing program would gain legal values,
> eliminating undefined bahavior due to accessing unitialised objects.

Except that the behavior could be just as bad, because T() may not be a
`defined' value for the problem it is being used in.

It may make debugging easier, by being more predictable. But then again,
you compiler can do that for you without needing a standards change.

---
[ 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                ]

Balog Pal wrote:
>=20
> "Daniel Frey" <daniel.frey@aixigo.de> 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                ]

"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:3B207BDB.9A5AAA2F@aixigo.de...

>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 allow
>declaring a member variable as 'explicit', meaning you have to provide
>it for all ctors? For example:

I'm sure  it would make even more sense to make your 'explicit' the default for the builtin types.

I'm just growing tired of hunting all those bugs related to uninitialised vasiables. I find no amonunt of asking, begging, demanding, praying, moaning, etc can make other people make enough disciplined to acomplish such a simple looking task.

Tha language gave us a hand by providing inescapable ctors, but it's just not enough.

There was a proposal in the past dealing with this problem in an interesting new way:

int foo; // would mean  int foo = int();  setting a defined value, 0
int foo = noinit; // asking the behavior that is default now.

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  programmers could gain back by adding that noinit where appropriate, if they find it necessary. (In a really correct program noinit is pretty rare in any case.)

note another interesting side effect: you could grep all the places you use uninitialsed stuff.

Certainly your explicit would have use having that, if some members need nondefault initialisation. Just let's not step on the keyword overloading path again, selecting a fresh new word.

Paul

---
[ 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                ]