|| | |||Browse by category|
http://www.kbpublisher.com - http://www.kbpublisher.com
[b]text[/b] - Bold text.
[u]text[/u] - Underline text.
[i]text[/i] - Italic text.
[color=green]text[/color] - Colored text.
[url]kbpublisher.com[/url] - kbpublisher.com
[url=kbpublisher.com]text[/url] - text
[email]email@example.com[/email] - firstname.lastname@example.org
[h1]text[/h1] - Caption text.
- item 1
- item 2
- item 1
- item 2
I can't stream a bool.
I used to be able to insert and extract both bool and RWBoolean objects to or from a stream, but now I can't stream either. I get the error message: "The call to "operator<<" has no best match." What?s up?
Why doesn't Rogue Wave provide an operator>>() to stream a bool or an RWBoolean?
While that?s a tempting suggestion, we can't create an insertion or extraction operator to stream a bool without creating ambiguity. The problem has to do with casting pointers. According to section 4.12 of the C++ standard, "Boolean Conversions," a pointer can be converted to an rvalue of type bool. The creation of an RWCollectable object provides global operator>>() for RWvistream to stream a pointer in to the object. However, if we create both operators, one to stream a pointer and one to stream a bool, the compiler won't know what to do with a pointer being streamed to an RWCollectable.
Consider the following:
bis >> cip; //Ambiguous!
The extraction shown above generates an ambiguity error. Should the compiler cast the RWbistream to an RWvistream, or cast the pointer to a bool? It can't decide because both casts are equally valid.
If that's true, why did it work before? What changed, and why?
It worked before because previously our compiler characterization tests failed to detect the fact that your compiler supports the native bool type. Since not all compilers support bool as a native type, we use the type RWBoolean in our code instead of bool. After running the characterization tests, we then typedef RWBoolean to either bool, if we think your compiler supports it, or int, if we think it doesn?t. Since our characterization test was faulty, we incorrectly defined the macro RW_NO_BOOL and subsequently typedef?ed RWBoolean to int. There's a streaming operator defined for int, so this worked well. The bool characterization test has now been fixed, however, so the native bool type is being detected, RW_NO_BOOL is NOT being defined, and RWBoolean is being typedef?ed to bool, creating the ambiguity problem.
So how can I get around this problem?
The best way to fix this problem is to use the methods get() and put() instead of the insertion and extraction operators. Another possibility is to explicitly cast the RWBoolean to a streamable type, the most efficient of which would be char. Both of these solutions should also work if used on a compiler that doesn?t support bool as a native type. For example, consider the following :
RWBoolean rwb = true;
bos.put( rwb );
bos << static_cast<char>( rwb );
Your first impulse may be to simply define RW_NO_BOOL. This would not be a good idea, however, since there are other problems that may show up if you do this. The best fix is to use the native type bool, as we have shown above.