473,326 Members | 2,099 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

void * instead of bool

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
Jul 22 '05 #1
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
Jul 22 '05 #2
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
Jul 22 '05 #3
> > 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
Jul 22 '05 #4
"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 <<
Jul 22 '05 #5
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.
Jul 22 '05 #6
* 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?
Jul 22 '05 #7
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.
Jul 22 '05 #8
"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.
Jul 22 '05 #9
* 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?
Jul 22 '05 #10
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/
Jul 22 '05 #11
* 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?
Jul 22 '05 #12
> 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.
Jul 22 '05 #13
* 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?
Jul 22 '05 #14
"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?
Jul 22 '05 #15
* 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?
Jul 22 '05 #16
"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.
Jul 22 '05 #17
* 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?
Jul 22 '05 #18
> 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
-- --
Jul 22 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

52
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?
27
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; }
2
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;...
6
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*...
1
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...
2
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,...
2
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:...
5
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...
16
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...
0
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...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
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...
1
isladogs
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...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
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....
0
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
0
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...
0
isladogs
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...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.