Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: initialization
90 views
Skip to first unread message
Message has been deleted
Martin Shobe
Mar 26, 2015, 7:51:13 PM3/26/15
to
On 3/26/2015 6:28 PM, Stefan Ram wrote:
> I was reading a C++ book.
>
> It said:
>
> a variable should only be left uninitialized in extremely rare circumstances.
>
> ...
>
> char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
In this case, if the extractor fails, answer will be 0 instead of an
indeterminate value.
Martin Shobe
> I was reading a C++ book.
>
> It said:
>
> a variable should only be left uninitialized in extremely rare circumstances.
>
> ...
>
> char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
In this case, if the extractor fails, answer will be 0 instead of an
indeterminate value.
Martin Shobe
Message has been deleted
Öö Tiib
Mar 26, 2015, 8:44:15 PM3/26/15
to
On Friday, 27 March 2015 02:00:48 UTC+2, Stefan Ram wrote:
> Ok, but if one employs the following pattern:
>
> char answer = 0; if( cin >> answer )... else ...
>
> will there still be an advantage of the initialization?
Usually it is better to initialize variables with some trickier
values than 0. It is more likely to cause outcome that catches
attention on case of defects.
People may forget in the forest of ifs and elses that failed
'operator>>' does leave the uninitialized 'answer' still
uninitialized (regardless of pattern) and use it for something.
Also compiler is usually not clever enough to warn about it in
such scenario.
>
> char answer = 0; if( cin >> answer )... else ...
>
> will there still be an advantage of the initialization?
Usually it is better to initialize variables with some trickier
values than 0. It is more likely to cause outcome that catches
attention on case of defects.
People may forget in the forest of ifs and elses that failed
'operator>>' does leave the uninitialized 'answer' still
uninitialized (regardless of pattern) and use it for something.
Also compiler is usually not clever enough to warn about it in
such scenario.
Martin Shobe
Mar 26, 2015, 10:24:54 PM3/26/15
to
> Ok, but if one employs the following pattern:
> char answer = 0; if( cin >> answer )... else ...
> will there still be an advantage of the initialization?
As long as you only use answer in the if part of the statement, there's
> char answer = 0; if( cin >> answer )... else ...
> will there still be an advantage of the initialization?
no immediate advantage. (There might be one later, you'll have to decide
for yourself how important that is compared to the cost of having code
that is pointless now.) If you use answer elsewhere, it's the same as in
your first example.
Martin Shobe
Melzzzzz
Mar 26, 2015, 10:32:33 PM3/26/15
to
On 26 Mar 2015 23:28:36 GMT
Though, I can't see reason why not to initialize it in the
first place...
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> I was reading a C++ book.
>
> It said:
>
> a variable should only be left uninitialized in extremely rare
> circumstances.
>
> ...
>
> I was reading a C++ book.
>
> It said:
>
> a variable should only be left uninitialized in extremely rare
> circumstances.
>
> ...
>
> char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
>
>
None. You check if cin failed...
>
> What could be the reason for the » = 0« in such a case?
>
>
Though, I can't see reason why not to initialize it in the
first place...
David Harmon
Mar 28, 2015, 1:10:16 PM3/28/15
to
On 26 Mar 2015 23:28:36 GMT in comp.lang.c++, r...@zedat.fu-berlin.de
(Stefan Ram) wrote,
circumstances. Maybe never.
(Stefan Ram) wrote,
> I was reading a C++ book.
>
> It said:
>
>a variable should only be left uninitialized in extremely rare circumstances.
>
> ...
>
>char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
Because a variable should only be left uninitialized in extremely rare
>
> It said:
>
>a variable should only be left uninitialized in extremely rare circumstances.
>
> ...
>
>char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
circumstances. Maybe never.
Marcel Mueller
Mar 28, 2015, 1:25:38 PM3/28/15
to
On 28.03.15 18.10, David Harmon wrote:
> Because a variable should only be left uninitialized in extremely rare
> circumstances. Maybe never.
There are use cases where it is no problem to declare uninitialized PODs.
> Because a variable should only be left uninitialized in extremely rare
> circumstances. Maybe never.
E.g. if a value is initialized by switch/case/default. Assigning an
initial value is useless in this case.
Or if it is an output (reference) parameter and the exception thrown
when it fails is not caught within the scope of the variable.
Marcel
Bo Persson
Mar 28, 2015, 1:46:19 PM3/28/15
to
On 2015-03-27 00:28, Stefan Ram wrote:
> I was reading a C++ book.
>
> It said:
>
> I was reading a C++ book.
>
> It said:
>
> a variable should only be left uninitialized in extremely rare circumstances.
>
>
> ...
>
> char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
>
>
What would be the reason for NOT initalizing the variable? Saving half a
>
> char answer = 0; cin >> answer;
>
> What could be the reason for the » = 0« in such a case?
>
>
nanosecond?
Bo Persson
Osmium
Mar 28, 2015, 2:08:59 PM3/28/15
to
"David Harmon" <sou...@netcom.com> wrote in message
news:8e-dnWfMSo7wfYvI...@earthlink.com...
David Brown
Mar 28, 2015, 2:37:35 PM3/28/15
to
nothing to put in it. That way you can make use of the compiler's
static error checking to warn you if you accidentally use it later
without having set it.
Öö Tiib
Mar 28, 2015, 10:51:26 PM3/28/15
to
function by non-const reference or pointer.
If you really want to get advantage from not initializing variables
then you need something that instruments stuff for runtime checking.
For example clang's memory sanitizer. Such tools seem to only warn
if the program actually reads from unintialized variable when running.
That may be some rare corner case.
Lot of types have some "unavailable" state when you don't have anything
to put into those. Floating point has NaN, pointers have nullptr and
so on. I prefer to initialize with such. Rest I initialize with some
likely bad value (minimum for signed value, maximum for unsigned value,
"#FEIL#" for string etc. Works fine.
Message has been deleted
JiiPee
Mar 29, 2015, 7:22:02 AM3/29/15
to
On 28/03/2015 17:25, Marcel Mueller wrote:
> On 28.03.15 18.10, David Harmon wrote:
>> Because a variable should only be left uninitialized in extremely rare
>> circumstances. Maybe never.
>
> There are use cases where it is no problem to declare uninitialized PODs.
> E.g. if a value is initialized by switch/case/default. Assigning an
> initial value is useless in this case.
althouth even then I guess its not 100% useless, as initializing might
> On 28.03.15 18.10, David Harmon wrote:
>> Because a variable should only be left uninitialized in extremely rare
>> circumstances. Maybe never.
>
> There are use cases where it is no problem to declare uninitialized PODs.
> E.g. if a value is initialized by switch/case/default. Assigning an
> initial value is useless in this case.
help in a situation where human forgets for example insert default case.
So for debugging purposes and protecting human errors. But how usefull
this is am not sure...
JiiPee
Mar 29, 2015, 7:29:40 AM3/29/15
to
:). I think am gonna use that.
Did you invent it yourself? I normally put something like -1.0, but NaN
is better? Sometimes I also think putting MAX_FLOAT, but that is
actually a valid value...so maybe not so good.
Vir Campestris
Mar 29, 2015, 4:11:20 PM3/29/15
to
On 29/03/2015 12:29, JiiPee wrote:
> "Floating point has NaN". oh thats a good idea, never thought of that
> :). I think am gonna use that.
> Did you invent it yourself? I normally put something like -1.0, but NaN
> is better? Sometimes I also think putting MAX_FLOAT, but that is
> actually a valid value...so maybe not so good.
The nice thing about NaN as opposed to -1 is that -1 + 1 is 0; a
> "Floating point has NaN". oh thats a good idea, never thought of that
> :). I think am gonna use that.
> Did you invent it yourself? I normally put something like -1.0, but NaN
> is better? Sometimes I also think putting MAX_FLOAT, but that is
> actually a valid value...so maybe not so good.
perfectly valid number. But NaN + 1 is still NaN.
Andy
David Brown
Apr 6, 2015, 5:53:30 PM4/6/15
to
On 29/03/15 04:51, Öö Tiib wrote:
> On Saturday, 28 March 2015 20:37:35 UTC+2, David Brown wrote:
>> On 28/03/15 18:46, Bo Persson wrote:
>>> On 2015-03-27 00:28, Stefan Ram wrote:
>>>> I was reading a C++ book.
>>>>
>>>> It said:
>>>>
>>>> a variable should only be left uninitialized in extremely rare
>>>> circumstances.
>>>>
>>>> ...
>>>>
>>>> char answer = 0; cin >> answer;
>>>>
>>>> What could be the reason for the » = 0« in such a case?
>>>>
>>>>
>>>
>>> What would be the reason for NOT initalizing the variable? Saving half a
>>> nanosecond?
>>>
>>
>> As a general point, you should not initialise a variable if you have
>> nothing to put in it. That way you can make use of the compiler's
>> static error checking to warn you if you accidentally use it later
>> without having set it.
>
> Compilers do not typically warn if you pass uninitialied variable to
> function by non-const reference or pointer.
Just because compilers can't check /everything/, does not mean you
> On Saturday, 28 March 2015 20:37:35 UTC+2, David Brown wrote:
>> On 28/03/15 18:46, Bo Persson wrote:
>>> On 2015-03-27 00:28, Stefan Ram wrote:
>>>> I was reading a C++ book.
>>>>
>>>> It said:
>>>>
>>>> a variable should only be left uninitialized in extremely rare
>>>> circumstances.
>>>>
>>>> ...
>>>>
>>>> char answer = 0; cin >> answer;
>>>>
>>>> What could be the reason for the » = 0« in such a case?
>>>>
>>>>
>>>
>>> What would be the reason for NOT initalizing the variable? Saving half a
>>> nanosecond?
>>>
>>
>> As a general point, you should not initialise a variable if you have
>> nothing to put in it. That way you can make use of the compiler's
>> static error checking to warn you if you accidentally use it later
>> without having set it.
>
> Compilers do not typically warn if you pass uninitialied variable to
> function by non-const reference or pointer.
should ignore the checks they /can/ do!
But I agree that sometimes using an "unavailable" or known-bad value is
a good choice for initialisation when you don't have a real valid value.
Öö Tiib
Apr 7, 2015, 9:22:37 AM4/7/15
to
On Tuesday, 7 April 2015 00:53:30 UTC+3, David Brown wrote:
> On 29/03/15 04:51, Öö Tiib wrote:
> > On Saturday, 28 March 2015 20:37:35 UTC+2, David Brown wrote:
> >> On 28/03/15 18:46, Bo Persson wrote:
> >>> On 2015-03-27 00:28, Stefan Ram wrote:
> >>>> I was reading a C++ book.
> >>>>
> >>>> It said:
> >>>>
> >>>> a variable should only be left uninitialized in extremely rare
> >>>> circumstances.
> >>>>
> >>>> ...
> >>>>
> >>>> char answer = 0; cin >> answer;
> >>>>
> >>>> What could be the reason for the » = 0« in such a case?
> >>>>
> >>>>
> >>>
> >>> What would be the reason for NOT initalizing the variable? Saving half a
> >>> nanosecond?
> >>>
> >>
> >> As a general point, you should not initialise a variable if you have
> >> nothing to put in it. That way you can make use of the compiler's
> >> static error checking to warn you if you accidentally use it later
> >> without having set it.
> >
> > Compilers do not typically warn if you pass uninitialied variable to
> > function by non-const reference or pointer.
>
> Just because compilers can't check /everything/, does not mean you
> should ignore the checks they /can/ do!
I don't suggest to ignore any opportunities. As next thing I
> On 29/03/15 04:51, Öö Tiib wrote:
> > On Saturday, 28 March 2015 20:37:35 UTC+2, David Brown wrote:
> >> On 28/03/15 18:46, Bo Persson wrote:
> >>> On 2015-03-27 00:28, Stefan Ram wrote:
> >>>> I was reading a C++ book.
> >>>>
> >>>> It said:
> >>>>
> >>>> a variable should only be left uninitialized in extremely rare
> >>>> circumstances.
> >>>>
> >>>> ...
> >>>>
> >>>> char answer = 0; cin >> answer;
> >>>>
> >>>> What could be the reason for the » = 0« in such a case?
> >>>>
> >>>>
> >>>
> >>> What would be the reason for NOT initalizing the variable? Saving half a
> >>> nanosecond?
> >>>
> >>
> >> As a general point, you should not initialise a variable if you have
> >> nothing to put in it. That way you can make use of the compiler's
> >> static error checking to warn you if you accidentally use it later
> >> without having set it.
> >
> > Compilers do not typically warn if you pass uninitialied variable to
> > function by non-const reference or pointer.
>
> Just because compilers can't check /everything/, does not mean you
> should ignore the checks they /can/ do!
mentioned the tools (like valgrind and clang memory sanitizer)
that can do the runtime checks (when compiler can't detect
compile-time problem).
I was trying to say that leaving variables uninitialized is not
good *general* suggestion because the compile-time warnings are
situation-specific and tools that track such meta-information
run-time are platform-specific. Not *all* use those so not
*all* can gain from following of that advice. IOW it depends.
Other similar things are variables containing dangling pointers,
"moved from" variables and variables with contents from "dirty"
sources. We either use special tools that analyze usage of such
variables or use idioms that make it more likely that defects
manifest themselves without special tools instrumented.
> But I agree that sometimes using an "unavailable" or known-bad value is
> a good choice for initialisation when you don't have a real valid value.
outweigh those on general case. Most of us like to fail ASAP
and use most terse syntax but C++ does not support us with that
choice.
Similarly assigning null to variable that contains dangling
pointer and does not leave scope anytime soon is widely accepted
idiom (and lot of coding standards require it) despite compilers
warn about potential (and tools detect actual) dangling pointer dereferencing / passing / returning / deleting. It is because the
code can use the null value in meaning of absence of value *and*
when it ignores it then null value manifests defects lot more
likely.
Message has been deleted
Öö Tiib
Apr 7, 2015, 5:02:57 PM4/7/15
to
On Tuesday, 7 April 2015 20:03:09 UTC+3, Stefan Ram wrote:
> . I'd also like to see (not from C# but from my mind):
>
> for( int const i = 0; i < 10; ++i )...
>
> in the sense that »const« above means: write accesses to i
> are allowed only in the for-parentheses (as in ++i above)
> (and similarly for other loops).
what is wrong with:
for( int i = 0; i < 10; ++i ) { /* code */ }
Plus static code analysis tool that can be configured to warn
about magic number '10' used and when 'i' is modified
instead of '/* code */' ?
These are very common warnings from static code analysis tools.
> . I'd also like to see (not from C# but from my mind):
>
> for( int const i = 0; i < 10; ++i )...
>
> in the sense that »const« above means: write accesses to i
> are allowed only in the for-parentheses (as in ++i above)
> (and similarly for other loops).
what is wrong with:
for( int i = 0; i < 10; ++i ) { /* code */ }
Plus static code analysis tool that can be configured to warn
about magic number '10' used and when 'i' is modified
instead of '/* code */' ?
These are very common warnings from static code analysis tools.
0 new messages