Hi,
Why is there void* conversion to check for std::istream failure bit? Why not
a conversion to bool?
When I try to return an istream from a function that actually returns bool,
I get the following warning (in VC .NET):
warning C4800: 'void *' : forcing value to bool 'true' or 'false'
(performance warning)
I can get rid of it by returning (stream != 0) or (!!stream), but it looks
ugly to me. Besides that, I suspect that it might perhaps be generating
unoptimal code. Compiler does not know that void* value holds only 0 or 1 in
the case of streams, and adds extra code to prevent the value going out of
bool range. At least that's what the warning is trying to say.
Is there any reason to avoid automatic conversion to bool and prever
conversion to void* instead?
Marcin 18 2861
"Marcin Kalicinski" <ka****@poczta.onet.pl> wrote in message
news:cb**********@korweta.task.gda.pl... Hi,
Why is there void* conversion to check for std::istream failure bit? Why
not a conversion to bool?
If you have a conversion to bool then the following nonsense would compile
float f = cin;
Conversion to void* is less likely to be called accidentally. When I try to return an istream from a function that actually returns
bool, I get the following warning (in VC .NET):
warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning)
I can get rid of it by returning (stream != 0) or (!!stream), but it looks ugly to me. Besides that, I suspect that it might perhaps be generating unoptimal code. Compiler does not know that void* value holds only 0 or 1
in the case of streams, and adds extra code to prevent the value going out of bool range. At least that's what the warning is trying to say.
You could do this
return some_stream.good(); Is there any reason to avoid automatic conversion to bool and prever conversion to void* instead?
See above.
Marcin
john
Marcin Kalicinski wrote: Hi,
Why is there void* conversion to check for std::istream failure bit? Why not a conversion to bool?
Because you definitily don't want this to compile:
ifstream if;
int j;
j = 2 + if; When I try to return an istream from a function that actually returns bool, I get the following warning (in VC .NET):
warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning)
I can get rid of it by returning (stream != 0) or (!!stream), but it looks ugly to me.
YOu can turn off that warning completely in VC++ with the help of a pragma
Besides that, I suspect that it might perhaps be generating unoptimal code.
Don't worry about that. You will never notice the difference.
Your PC can do around 1 * 10^9 operations per second and you
worry about 1 or 2 instructions more or less.
Compiler does not know that void* value holds only 0 or 1 in the case of streams, and adds extra code to prevent the value going out of bool range. At least that's what the warning is trying to say.
It is.
But in practice this isn't a problem at all. Is there any reason to avoid automatic conversion to bool and prever conversion to void* instead?
See above.
--
Karl Heinz Buchegger kb******@gascad.at
> > Besides that, I suspect that it might perhaps be generating unoptimal code.
Don't worry about that. You will never notice the difference. Your PC can do around 1 * 10^9 operations per second and you worry about 1 or 2 instructions more or less.
I always thought that C++ main advantage over other languages is that almost
optimal code can be generated from it.
Not the case here, but 2 extra instructions make difference sometimes, no
matter how fast will CPUs become, as there will always be problems where
they are still too slow.
Fortunately, John has already pointed out that stream.good() will do
optimally without warning and those extra 2 instructions, so C++ is saved
:-)
Marcin
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at... Why is there void* conversion to check for std::istream failure bit? Why
not a conversion to bool?
Because you definitily don't want this to compile:
ifstream if; int j;
j = 2 + if;
Even more entertaining:
int j = 42;
std::cout >> j; // Oops, I really should have written <<
Karl Heinz Buchegger wrote: Because you definitily don't want this to compile:
ifstream if; int j;
j = 2 + if;
"if" is a keyword...
--
Regards,
Buster.
* Karl Heinz Buchegger: Marcin Kalicinski wrote: Hi,
Why is there void* conversion to check for std::istream failure bit? Why not a conversion to bool?
Because you definitily don't want this to compile:
ifstream if; int j;
j = 2 + if;
Assuming you meant to use a non-keyword instead of "if", _why_ on or off
Earth would I definitily (?) not want that to compile?
The same goes for Andrew's example.
On the contrary, a good design does not needlessly limit the user to
do only things the designer is able to foresee the usefulness of.
I think there are two more realistic explanations.
One is that perhaps the original design dates from a time before 'bool'
was introduced in the language. Another is that perhaps there is some
subtle issue with e.g. function overload resolution, e.g. passing an
ifstream object to a constructor where one overload takes a bool. In
the latter case (which does not exclude the first) the conversion to
void* is already one conversion, and void* is a very unspecific type, so
a direct conversion to a more sensible type would, ideally, be chosen.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
John Harrison wrote: "Marcin Kalicinski" <ka****@poczta.onet.pl> wrote in message news:cb**********@korweta.task.gda.pl... Hi,
Why is there void* conversion to check for std::istream failure bit? Why not a conversion to bool?
If you have a conversion to bool then the following nonsense would compile
float f = cin;
Why should one worry about that? There is a lot of nonsense that does
compile, but isn't a problem, because nobody writes that nonsense
anyway.
"Alf P. Steinbach" <al***@start.no> wrote in message
news:40*****************@news.individual.net... Assuming you meant to use a non-keyword instead of "if", _why_ on or off Earth would I definitily (?) not want that to compile?
The same goes for Andrew's example.
which was:
int j;
cout >> j; // Oops, I meant to write <<
I think there are two more realistic explanations.
One is that perhaps the original design dates from a time before 'bool' was introduced in the language. Another is that perhaps there is some subtle issue with e.g. function overload resolution, e.g. passing an ifstream object to a constructor where one overload takes a bool.
Actually, my example is the original motivating reason for having the stream
classes convert to void * rather than to bool. Well, not quite, because the
example long predates the existence of bool--but exactly the same problem
came up when we considered having the iostream classes converting to int.
* Andrew Koenig: "Alf P. Steinbach" <al***@start.no> wrote in message news:40*****************@news.individual.net...
Assuming you meant to use a non-keyword instead of "if", _why_ on or off Earth would I definitily (?) not want that to compile?
The same goes for Andrew's example.
which was:
int j; cout >> j; // Oops, I meant to write <<
I think there are two more realistic explanations.
One is that perhaps the original design dates from a time before 'bool' was introduced in the language. Another is that perhaps there is some subtle issue with e.g. function overload resolution, e.g. passing an ifstream object to a constructor where one overload takes a bool.
Actually, my example is the original motivating reason for having the stream classes convert to void * rather than to bool. Well, not quite, because the example long predates the existence of bool--but exactly the same problem came up when we considered having the iostream classes converting to int.
It seems then that you (all) did something that perhaps was right, for
the wrong reasons... ;-)
Can you recall why implicit conversion was judged to be desirable when
there clearly were issues with that that were regarded as "problems"?
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote in news:40*****************@news.individual.net in
comp.lang.c++: Because you definitily don't want this to compile:
ifstream if; int j;
j = 2 + if; Assuming you meant to use a non-keyword instead of "if", _why_ on or off Earth would I definitily (?) not want that to compile?
Perhaps because:
j = 2 + bool( if );
is fine ('if' aside). The same goes for Andrew's example.
here it is:
<quote>
int j = 42;
std::cout >> j; // Oops, I really should have written <<
</quote>
bool -> int is 1 or 0, 1 >> non-zero is 0 (or undefined (42 an on a
32 bit system for eg)).
int i = std::cout && !j;
If you must :). On the contrary, a good design does not needlessly limit the user to do only things the designer is able to foresee the usefulness of.
But an "input stream" is not a number.
Also there is no limit, fail() is perfectly accessible.
I think there are two more realistic explanations.
One is that perhaps the original design dates from a time before 'bool' was introduced in the language.
Not convincing, int does equally well.
Another is that perhaps there is some subtle issue with e.g. function overload resolution, e.g. passing an ifstream object to a constructor where one overload takes a bool. In the latter case (which does not exclude the first) the conversion to void* is already one conversion, and void* is a very unspecific type, so a direct conversion to a more sensible type would, ideally, be chosen.
The original design (AFAICT) called for:
if ( std::cin >> a ) /* whatever */;
and also:
std::cin >> a >> b;
to be valid (and meaningfull).
The first suggests operator >> should return bool, the second
then suggests std::istream should have a conversion to bool.
But operator bool means that a stream is also a number
which (IM<earth bound>O) is *not* desirable.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
* Rob Williscroft: Alf P. Steinbach wrote in news:40*****************@news.individual.net in comp.lang.c++:
Because you definitily don't want this to compile:
ifstream if; int j;
j = 2 + if; Assuming you meant to use a non-keyword instead of "if", _why_ on or off Earth would I definitily (?) not want that to compile?
Perhaps because:
j = 2 + bool( if );
is fine ('if' aside).
C++ is full of alternative ways of achieving anything, some more
explicit than others. We do not wish the implicit ones to not compile
merely because there is some explicit way of achieving the same. On the
contrary, programmers would be less than enthusiastic about henceforth
having to write a = a + 1, with compile errors on a += 1 and ++a (say).
Hence the argument does not hold.
Having an explicit way is not a reason to ban the implicit ways. The same goes for Andrew's example.
here it is:
<quote> int j = 42; std::cout >> j; // Oops, I really should have written << </quote>
bool -> int is 1 or 0, 1 >> non-zero is 0 (or undefined (42 an on a 32 bit system for eg)).
In other words, you can see no advantage.
Neither can I, but it's harmless.
int i = std::cout && !j; If you must :).
Already discussed above. On the contrary, a good design does not needlessly limit the user to do only things the designer is able to foresee the usefulness of.
But an "input stream" is not a number.
But an "input stream" is not a bool.
But an "input stream" is not a void*.
If you mean this should not have been an implicit operation, I agree.
Also there is no limit, fail() is perfectly accessible.
I think there are two more realistic explanations.
One is that perhaps the original design dates from a time before 'bool' was introduced in the language. Not convincing, int does equally well.
One reason 'bool' was introduced was that int does not do equally well;
in particular int is not distinct from int. Another is that perhaps there is some subtle issue with e.g. function overload resolution, e.g. passing an ifstream object to a constructor where one overload takes a bool. In the latter case (which does not exclude the first) the conversion to void* is already one conversion, and void* is a very unspecific type, so a direct conversion to a more sensible type would, ideally, be chosen.
The original design (AFAICT) called for:
if ( std::cin >> a ) /* whatever */;
and also:
std::cin >> a >> b;
to be valid (and meaningfull).
The first is a requirement to support side-effect based code, which is
ungood square (TM). The second, operator chaining, isn't so bad on its
own, but it precludes better designs so it's also a bit ungood (TM). I
rather liked the original printf-like formatting that Bjarne suggested,
and which I believe is now carried further, to type safety, in Boost.
The first suggests operator >> should return bool, the second then suggests std::istream should have a conversion to bool.
Yes, and all that to support two ungood requirements, and void* as a
replacement to a-void accidental invocation of the shift operator, which
would be detected in the first rough trying-out of the program anyway.
But operator bool means that a stream is also a number which (IM<earth bound>O) is *not* desirable.
And following that logic: an "input stream" is not a void*.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
> Can you recall why implicit conversion was judged to be desirable when there clearly were issues with that that were regarded as "problems"?
Because we didn't want to break C compatibility.
* Andrew Koenig: Can you recall why implicit conversion was judged to be desirable when there clearly were issues with that that were regarded as "problems"?
Because we didn't want to break C compatibility.
Does that mean that implicit conversion was required to support the
coding convention established in C (namely a side-effect based loop
condition), or that implicit conversion war required to upheld direct C
_language_ compatibility (I don't see what could be broken by not having
an implicit conversion)?
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.no> wrote in message
news:40*****************@news.individual.net... Can you recall why implicit conversion was judged to be desirable when there clearly were issues with that that were regarded as "problems"?
Because we didn't want to break C compatibility.
Does that mean that implicit conversion was required to support the coding convention established in C (namely a side-effect based loop condition), or that implicit conversion war required to upheld direct C _language_ compatibility (I don't see what could be broken by not having an implicit conversion)?
It means that the rules for converting built-in types were intentially the
same for C++ as they were for C.
Maybe I'm not understanding what you mean when you say "implicit conversion
was judged to be desirable." What conversion are you speaking about,
specifically?
* Andrew Koenig: "Alf P. Steinbach" <al***@start.no> wrote in message news:40*****************@news.individual.net...
> Can you recall why implicit conversion was judged to be desirable when > there clearly were issues with that that were regarded as "problems"? Because we didn't want to break C compatibility.
Does that mean that implicit conversion was required to support the coding convention established in C (namely a side-effect based loop condition), or that implicit conversion war required to upheld direct C _language_ compatibility (I don't see what could be broken by not having an implicit conversion)?
It means that the rules for converting built-in types were intentially the same for C++ as they were for C.
Maybe I'm not understanding what you mean when you say "implicit conversion was judged to be desirable." What conversion are you speaking about, specifically?
Having the implicit conversion to void*, operator void*(), as opposed to
not having it which would require explicit use of e.g. fail() (better)
and would avoid the "problem" with accidental shift-operator invocation.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.no> wrote in message
news:40*****************@news.individual.net... * Andrew Koenig:
not having it which would require explicit use of e.g. fail() (better) and would avoid the "problem" with accidental shift-operator invocation.
There was a general desire to be able to write code like
while (cin >> x)
do_something_with(x);
instead of
while (cin >> x, !x.eof())
do_something_with(x);
That kind of notational compactness is important in a heavily used library.
* Andrew Koenig: "Alf P. Steinbach" <al***@start.no> wrote in message news:40*****************@news.individual.net... * Andrew Koenig:
not having it which would require explicit use of e.g. fail() (better) and would avoid the "problem" with accidental shift-operator invocation.
There was a general desire to be able to write code like
while (cin >> x) do_something_with(x);
instead of
while (cin >> x, !x.eof()) do_something_with(x);
That kind of notational compactness is important in a heavily used library.
Uhm, yes, that's what I thought.
Topic drift: what about
namespace std
{
inline bool failed( std::istream const& s ){ return s.fail(); }
}
...
while( !failed( cin >> x ) )
{
doSomethingWith( x );
}
I think that's a much better way to provide convenience operations than
a type conversion operator -- also gives readable & explicit code...
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
> Hi, Why is there void* conversion to check for std::istream failure bit? Why not a conversion to bool?
Simple answer: because the Standard says so.
When I try to return an istream from a function that actually returns bool, I get the following warning (in VC .NET):
warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning)
I can get rid of it by returning (stream != 0) or (!!stream), but it looks ugly to me. Besides that, I suspect that it might perhaps be generating unoptimal code. Compiler does not know that void* value holds only 0 or 1 in the case of streams, and adds extra code to prevent the value going out of bool range. At least that's what the warning is trying to say.
Is there any reason to avoid automatic conversion to bool and prever conversion to void* instead?
As I said before, the reason is because the Standard says so.
Marcin
If you are curious about knowing *why* the Standard says what it says,
ask in comp.std.c++.
-- --
To iterate is human, to recurse divine.
-L. Peter Deutsch
-- -- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Vladimir Grul |
last post by:
Hello,
I have a class member function declared as
class some_class {
....
virtual int call(void);
};
Can I use this-> inside the function body?
|
by: Maximus |
last post by:
Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:
void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}
|
by: Jakob Bieling |
last post by:
Hi,
I remember reading a document that advised to prefer 'operator void*'
over 'operator bool' or other way round, when I want to provide the ability
to use code like this:
test_class t;...
|
by: keepyourstupidspam |
last post by:
Hi,
I want to pass a function pointer that is a class member.
This is the fn I want to pass the function pointer into:
int Scheduler::Add(const unsigned long timeout, void* pFunction, void*...
|
by: Neo |
last post by:
hi,
This is my first post in C++ group, so please be nice to me. Thanks.
Also, I will post my first C++ program following. There is a compile
error, I cannot figure it out even I can fix it. And...
|
by: sovarschizsuzsa |
last post by:
Hy!
I have written a MC++ wrapper DLL file for use in a C# project. This
wrapper DLL is built on a C DLL.
I have the following functions in the C DLL:
int First(char* a1, char* a2, void* *a3,...
|
by: tkirankumar |
last post by:
Hi all,
uname -a
SunOS cbmrsd1a1 5.10 Generic_118833-17 sun4us sparc FJSV,GPUZC-M
g++ -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/specs
Configured with:...
|
by: Jim Langston |
last post by:
I am using some code that I got that uses a form a message dispatching where
the data is passed via a void*. I don't like void*'s so am experimenting
with a different way to do them in C++. I...
|
by: PeterAPIIT |
last post by:
Hello all C++ expert programmer,
i have wrote partial general allocator for my container.
After reading standard C++ library and code guru article, i have
several questions.
1. Why...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |