 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dave Harris
Guest
|
 Posted: Tue Sep 21, 2004 5:24 am Post subject: Eliminating uninitialised variables |
 |
|
In a comp.lang.c++.moderated thread about const correctness, the issue of
uninitialised variables came up. Accessing an uninitialised variable is a
source of undefined behaviour which requires constant programmer vigilance
to avoid. A mistake often leads to real bugs or crashes, which can be
irreproducible and so hard to track down.
Can we do something constructive towards fixing this? Has it been tried;
are there known problems? Here are my initial thoughts.
We can't require the compiler to reject (at compile time) accesses of
uninitialised variables without breaking existing code, so I think we
would instead have to require all variables to be initialised -
zero-initialised as if they were statics. Since accessing an uninitialised
variable is currently undefined behaviour, a conforming program could not
tell the difference. I can think of two possible objections:
(1) A good compiler could use the undefined behaviour to detect accidents
at run-time, by secretly initialising to a trapping value.
(2) Efficiency.
The efficiency issue we can probably handle by providing a way to request
uninitialised variables explicitly. Eg reusing the keyword "void":
int x; // x is 0.
int y = void; // y is uninitialised.
The important cases are arrays:
int array[1000] = void;
especially when they are instance variables:
struct S {
int array[1000];
S() : array(void) {}
};
I'm not wedded to this particular syntax. The point is that leaving a
variable uninitialised is an optimisation that should be requested
manually. (In many cases, of course, the compiler can optimise out
redundant zero-initialisation without help.)
A compiler could trade speed for safety by using trapping values for void,
but I doubt that deals with the issue raised in (1). The concern is with
cases where:
(a) A programmer adds a new variable to a class.
(b) The programmer forgets to update a constructor, so it gets
zero-initialised.
(c) Zero-initialisation is not sufficient to satisfy the class invariant.
Personally I don't consider this serious enough to block the proposal. I
don't even know of an implementation which does use trapping values to
catch cases like this at run time. Comments?
Other points... with Java the zero-initialisation of a derived class
happens before the base class's constructor is run. I think this should be
permitted in C++, but I'm not sure it should be required. On the other
hand, it probably does no harm and I expect most implementations will want
to zap the whole memory block in one operation anyway.
Zeros are cheaper when bought in bulk, especially if they can be produced
in idle time, and especially if the O/S makes them. So it would be nice if
we could make zero-initialisation the responsibility of the memory manager
rather than the class's constructor. However, I don't see how to achieve
this without breaking backwards compatibility. Probably it should be a
quality of implementation issue anyway.
This would be a difference in behaviour between C++ and C. I don't think
it will cause problems, but perhaps someone with more experience will
comment.
What else am I missing? This is surely the kind of thing which future
revisions of the C++ standard should be considering.
-- 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 ]
|
|
| Back to top |
|
 |
John Nagle
Guest
|
| Posted: Tue Sep 21, 2004 1:05 pm Post subject: Re: Eliminating uninitialised variables |
|
|
I'd suggest allowing initial values within class
declarations, as in
class T {
char* p = 0;
};
Yes, you can do the same thing in each constructor's
initialization section. But it's not as obvious by
examination when someone left out an initialization,
because the initialization and declaration are at
different places.
John Nagle
Animats
Dave Harris wrote:
| Quote: | In a comp.lang.c++.moderated thread about const correctness, the issue of
uninitialised variables came up.
|
---
[ 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 ]
|
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Tue Sep 21, 2004 5:37 pm Post subject: Re: Eliminating uninitialised variables |
|
|
On Mon, 20 Sep 2004 23:24:35 CST, [email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris)
wrote:
| Quote: | In a comp.lang.c++.moderated thread about const correctness, the issue of
uninitialised variables came up. Accessing an uninitialised variable is a
source of undefined behaviour which requires constant programmer vigilance
to avoid. A mistake often leads to real bugs or crashes, which can be
irreproducible and so hard to track down.
Can we do something constructive towards fixing this? Has it been tried;
are there known problems? Here are my initial thoughts.
We can't require the compiler to reject (at compile time) accesses of
uninitialised variables without breaking existing code, so I think we
would instead have to require all variables to be initialised -
zero-initialised as if they were statics. Since accessing an uninitialised
variable is currently undefined behaviour, a conforming program could not
tell the difference. I can think of two possible objections:
(1) A good compiler could use the undefined behaviour to detect accidents
at run-time, by secretly initialising to a trapping value.
(2) Efficiency.
The efficiency issue we can probably handle by providing a way to request
uninitialised variables explicitly. Eg reusing the keyword "void":
int x; // x is 0.
int y = void; // y is uninitialised.
The important cases are arrays:
int array[1000] = void;
especially when they are instance variables:
struct S {
int array[1000];
S() : array(void) {}
};
I'm not wedded to this particular syntax. The point is that leaving a
variable uninitialised is an optimisation that should be requested
manually. (In many cases, of course, the compiler can optimise out
redundant zero-initialisation without help.)
A compiler could trade speed for safety by using trapping values for void,
but I doubt that deals with the issue raised in (1). The concern is with
cases where:
(a) A programmer adds a new variable to a class.
(b) The programmer forgets to update a constructor, so it gets
zero-initialised.
(c) Zero-initialisation is not sufficient to satisfy the class invariant.
Personally I don't consider this serious enough to block the proposal. I
don't even know of an implementation which does use trapping values to
catch cases like this at run time. Comments?
Other points... with Java the zero-initialisation of a derived class
happens before the base class's constructor is run. I think this should be
permitted in C++, but I'm not sure it should be required. On the other
hand, it probably does no harm and I expect most implementations will want
to zap the whole memory block in one operation anyway.
Zeros are cheaper when bought in bulk, especially if they can be produced
in idle time, and especially if the O/S makes them. So it would be nice if
we could make zero-initialisation the responsibility of the memory manager
rather than the class's constructor. However, I don't see how to achieve
this without breaking backwards compatibility. Probably it should be a
quality of implementation issue anyway.
|
It would be fairly easy to require either malloc or operator new to
zero-initialize all storage it allocates. The question is, do we want
to do this all the time?
| Quote: | This would be a difference in behaviour between C++ and C. I don't think
it will cause problems, but perhaps someone with more experience will
comment.
What else am I missing? This is surely the kind of thing which future
revisions of the C++ standard should be considering.
|
I don't think it is worth doing. Zero-initialization doesn't really
make sense for object type members, anyway. I think it's just part of
the job of programming to ensure that member variables are properly
initialized, and with properly designed classes, it's not such a big
chore. I's one of those things that make C++ different from, say,
Visual Basic <g>.
--
Bob Hairgrove
[email]NoSpamPlease (AT) Home (DOT) com[/email]
---
[ 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 ]
|
|
| Back to top |
|
|
Balog Pal
Guest
|
| Posted: Wed Sep 22, 2004 5:07 pm Post subject: Re: Eliminating uninitialised variables |
|
|
In an old version of this thread the idea I liked the most was having
int item = __uninitialised;
int item(__uninitialised);
To make some variable no initialised, and perform default-init for any place
there is no initialiser.
That makes ununited stuff explicit and easy to spot and search. Also it is
backward-compatible except for performance. And not so hard to fix later.
Reusing void or anything else is a bad idea. (If you really want to save a
keyword use static instead <EG>).
| Quote: | (c) Zero-initialisation is not sufficient to satisfy the class invariant.
|
The invariant checks shall catch that. The main problem with noinit is it
leads to UB and in practice to nondeterministic behavior. The memory-junk
may slip through tests if it happens to satisfy the invariant for the test
run.
| Quote: | Zeros are cheaper when bought in bulk, especially if they can be produced
in idle time, and especially if the O/S makes them. So it would be nice if |
we could make zero-initialisation the responsibility of the memory manager
rather than the class's constructor.
You forget C++-level zero-init is not a binary zero fill. zero and null
vlaues may come with whatever bit patterns, and they in fact do for doubles.
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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John G Harris
Guest
|
| Posted: Wed Sep 22, 2004 5:14 pm Post subject: Re: Eliminating uninitialised variables |
|
|
In message <memo.20040920104138.384A (AT) brangdon (DOT) m>, Dave Harris
<brangdon (AT) cix (DOT) co.uk> writes
<snip>
| Quote: | What else am I missing? This is surely the kind of thing which future
revisions of the C++ standard should be considering.
|
1 Are there any compilers that make a good job of warning about the use
of uninitialised variables? If there are then surely that's a better
solution.
2 Why is zero a better junk value than any other junk value?
3 Wouldn't it be simpler to say that all stack space and all heap space
is zeroed before (re-)use?
4 What about volatile?
John
--
John Harris
---
[ 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 ]
|
|
| Back to top |
|
|
Walter
Guest
|
| Posted: Wed Sep 22, 2004 5:15 pm Post subject: Re: Eliminating uninitialised variables |
|
|
"John Nagle" <nagle (AT) animats (DOT) com> wrote
| Quote: | I'd suggest allowing initial values within class
declarations, as in
class T {
char* p = 0;
};
Yes, you can do the same thing in each constructor's
initialization section. But it's not as obvious by
examination when someone left out an initialization,
because the initialization and declaration are at
different places.
|
This is the approach D takes. It makes sense to put the default value where
the declaration is, not off somewhere else.
---
[ 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 ]
|
|
| Back to top |
|
|
Sean Kelly
Guest
|
| Posted: Wed Sep 22, 2004 5:16 pm Post subject: Re: Eliminating uninitialised variables |
|
|
[email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote in message news:<memo.20040920104138.384A (AT) brangdon (DOT) m>...
| Quote: | In a comp.lang.c++.moderated thread about const correctness, the issue of
uninitialised variables came up. Accessing an uninitialised variable is a
source of undefined behaviour which requires constant programmer vigilance
to avoid. A mistake often leads to real bugs or crashes, which can be
irreproducible and so hard to track down.
Can we do something constructive towards fixing this? Has it been tried;
are there known problems? Here are my initial thoughts.
|
Much of the discussion centered initialization problems in classes.
Specifically, missing an initialization among what may be a large
collection of contructors. This problem will likely be reduced by
fowarding contructors, but is still worth addressing. It seems the
simplest solution would be to adjust the wording of 12.6 to include
primitive types.
| Quote: | We can't require the compiler to reject (at compile time) accesses of
uninitialised variables without breaking existing code, so I think we
would instead have to require all variables to be initialised -
zero-initialised as if they were statics. Since accessing an uninitialised
variable is currently undefined behaviour, a conforming program could not
tell the difference. I can think of two possible objections:
(1) A good compiler could use the undefined behaviour to detect accidents
at run-time, by secretly initialising to a trapping value.
|
My suggestion above would imply default initialization, but I suppose
this is another option.
Static arrays are probably the strongest argument against default
initialization (since pointers could be considered initialized simply
by assigning nullptr), but perhaps a means to opt-out would be
sufficient? And if so, where does this leave classes (which obviously
must be initialized)? Is the lack of consistency acceptable?
| Quote: | The efficiency issue we can probably handle by providing a way to request
uninitialised variables explicitly. Eg reusing the keyword "void":
int x; // x is 0.
int y = void; // y is uninitialised.
The important cases are arrays:
int array[1000] = void;
|
Default initialization across the board is a larger issue, though I
suppose it's worth considering for the sake of consistency. Still, I
suspect there are fewer initialization oversights in standard
functions.
Sean
---
[ 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 ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Wed Sep 22, 2004 5:47 pm Post subject: Re: Eliminating uninitialised variables |
|
|
[email]invalid (AT) bigfoot (DOT) com[/email] (Bob Hairgrove) wrote (abridged):
| Quote: | It would be fairly easy to require either malloc or operator new to
zero-initialize all storage it allocates.
|
If operator new is written by the user, such a requirement would break
backwards compatibility.
| Quote: | What else am I missing? This is surely the kind of thing which future
revisions of the C++ standard should be considering.
I don't think it is worth doing. Zero-initialization doesn't really
make sense for object type members, anyway.
|
Perhaps I used the wrong phrase. I meant the kind of initialisation static
objects get. For built-in types, that's as if they were initialised from
zero. Of course the final bit-pattern may not be zero, and of course
user-defined types have their default constructors.
-- 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 ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Wed Sep 22, 2004 7:40 pm Post subject: Re: Eliminating uninitialised variables |
|
|
[email]pasa (AT) lib (DOT) hu[/email] ("Balog Pal") wrote (abridged):
| Quote: | In an old version of this thread the idea I liked the most was having
int item = __uninitialised;
int item(__uninitialised);
|
Which is the same apart from the spelling of __uninitialised. I'd prefer
something short that didn't begin with __, but OK.
| Quote: | You forget C++-level zero-init is not a binary zero fill. zero and null
vlaues may come with whatever bit patterns, and they in fact do for
doubles.
|
I'm not forgetting that. It's one of the reasons I think this should be
quality of implementation - because not all implementations would benefit
from an infrastructure to tag memory known to be zero-filled. However, in
practice a great many would benefit if such tagging were possible, behind
the scenes.
I'm pretty sure IEEE allows all bits 0 for 0.0, but whatever. I'd expect
an implementation to fill the entire memory block with 0s first, then
overwrite any non-0 values afterwards - perhaps during construction, at
the same time that vtable pointers are installed.
-- 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 ]
|
|
| Back to top |
|
|
Greg Comeau
Guest
|
| Posted: Wed Sep 22, 2004 8:29 pm Post subject: Re: Eliminating uninitialised variables |
|
|
In article <6x14d.132741$3l3.96020@attbi_s03>,
Walter <walter (AT) digitalmars (DOT) nospamm.com> wrote:
| Quote: |
"John Nagle" <nagle (AT) animats (DOT) com> wrote in message
news:FQO3d.21860$bB7.16246 (AT) newssvr27 (DOT) news.prodigy.com...
I'd suggest allowing initial values within class
declarations, as in
class T {
char* p = 0;
};
Yes, you can do the same thing in each constructor's
initialization section. But it's not as obvious by
examination when someone left out an initialization,
because the initialization and declaration are at
different places.
This is the approach D takes. It makes sense to put the default value where
the declaration is, not off somewhere else.
|
What does D do if it's also specified on a constructor (or multiple
ones with different values), assuming is has such possibilities?
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
---
[ 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 ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Wed Sep 22, 2004 8:29 pm Post subject: Re: Eliminating uninitialised variables |
|
|
[email]news0 (AT) nospam (DOT) demon.co.uk[/email] (John G Harris) wrote (abridged):
| Quote: | 1 Are there any compilers that make a good job of warning about the use
of uninitialised variables? If there are then surely that's a better
solution.
|
It is legitimate to have uninitialised variables, so long as they are not
accessed, so I don't think the compiler should warn about them. I have
seen classes where an initialised variable is used to guard access to
potentially uninitialised ones. An extreme example:
class Stack{
int array[10000];
int top;
public:
Stack() : top(0) {}
void push( int x ) { array[top++] = x; }
int pop() { return array[--top]; }
};
Here the array contents are not initialised, but I don't think the
compiler should warn about it. We can't reasonably expect the compiler to
figure out what the code is doing at run-time. In general that could
involve solving the Halting Problem.
| Quote: | 2 Why is zero a better junk value than any other junk value?
|
I am not suggesting a junk value. I am suggesting code like:
int *get() {
int *result;
if (condition())
result = value();
return result;
}
would become well-defined and reasonable practice. It would return 0 when
condition() is false. I think 0 is the most useful and natural value, not
least because it is legal for so many built-in types (especially
pointers). Also because it is already used for static variables.
| Quote: | 3 Wouldn't it be simpler to say that all stack space and all heap space
is zeroed before (re-)use?
|
How does that differ from what I said? Are you assuming the bit-pattern of
all-zeros is a valid representation for all built-in types? Whose
responsibility is it to zero the memory? How do I avoid the zeroing if I
have a legitimate performance reason?
| Quote: | 4 What about volatile?
|
Good question. I hadn't thought about it, but I don't think it causes any
new problems. These:
// Proposed
volatile int x;
volatile int x( __uninitialised );
under the new regime would have the semantics of:
// Current
volatile int x( 0 );
volatile int x;
under the current regime - whatever semantics those happen to be. I do
think that volatile is a compelling reason for supporting __uninitialised
(or equivalent). Avoiding superfluous memory writes can be a matter of
correctness as well as performance.
-- 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 ]
|
|
| Back to top |
|
|
Walter
Guest
|
| Posted: Wed Sep 22, 2004 10:42 pm Post subject: Re: Eliminating uninitialised variables |
|
|
"Greg Comeau" <comeau (AT) panix (DOT) com> wrote
| Quote: | In article <6x14d.132741$3l3.96020@attbi_s03>,
Walter <walter (AT) digitalmars (DOT) nospamm.com> wrote:
"John Nagle" <nagle (AT) animats (DOT) com> wrote in message
news:FQO3d.21860$bB7.16246 (AT) newssvr27 (DOT) news.prodigy.com...
I'd suggest allowing initial values within class
declarations, as in
class T {
char* p = 0;
};
Yes, you can do the same thing in each constructor's
initialization section. But it's not as obvious by
examination when someone left out an initialization,
because the initialization and declaration are at
different places.
This is the approach D takes. It makes sense to put the default value
where
the declaration is, not off somewhere else.
What does D do if it's also specified on a constructor (or multiple
ones with different values), assuming is has such possibilities?
|
If an initialization of it is done in the constructor, it overrides the
default specified in the member declaration. Also, constructors can call
each other, making it practical to make 'layered' constructors.
One interesting aspect of this is that it behaves as if all the members have
their default values before even entering the constructor, this means that
if the constructor references a member before the constructor initializes
it, it still will get a predictable value (the default for that member)
rather than garbage.
---
[ 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 ]
|
|
| Back to top |
|
|
Greg Comeau
Guest
|
| Posted: Thu Sep 23, 2004 6:18 am Post subject: Re: Eliminating uninitialised variables |
|
|
In article <1GKClHFePJUBFwoH (AT) jgharris (DOT) demon.co.uk>,
John G Harris <news0 (AT) nospam (DOT) demon.co.uk> wrote:
| Quote: | 2 Why is zero a better junk value than any other junk value?
|
IMO, it is sometimes not even a good non-junk value 
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
---
[ 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 ]
|
|
| Back to top |
|
|
Walter
Guest
|
| Posted: Thu Sep 23, 2004 6:18 am Post subject: Re: Eliminating uninitialised variables |
|
|
"Dave Harris" <brangdon (AT) cix (DOT) co.uk> wrote
| Quote: | I'm pretty sure IEEE allows all bits 0 for 0.0, but whatever.
|
It does. All bits 0 is +0.0 for IEEE 754 floating point encodings.
D, however, default initializes floating point values to the NaN bit
pattern, not 0. This has bug finding advantages because it causes the
programmer to have to think about what value it should be initialized to,
rather than inadvertantly using 0.0 which may become a hidden bug.
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 <g>.
-Walter
www.digitalmars.com free C/C++/D compilers
---
[ 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 ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Thu Sep 23, 2004 4:31 pm Post subject: Re: Eliminating uninitialised variables |
|
|
[email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote (abridged):
| Quote: | I'd suggest allowing initial values within class
declarations, as in
class T {
char* p = 0;
};
Yes, you can do the same thing in each constructor's
initialization section. But it's not as obvious by
examination when someone left out an initialization,
because the initialization and declaration are at
different places.
|
That might be nice, but I see it as a separate issue; we still have to
consider what happens if someone forgets initialisation entirely.
(I think it's a fairly complex issue, too, once you consider order of
initialisation, user-defined types, exceptions, string literals etc.)
-- 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 ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
