Re: Order of evaluation of function arguments
ThosRTanner wrote:
James Kanze wrote:
Maciej Sobczak wrote:
while (stream >> x)
Very bad (what does the conversion to bool mean). Much better
would be:
stream >> x ;
while ( ! stream.failed() ) ...
Actually, that might be a bit of a disaster, because you're likely to
forget to put the end one in. And any continues would go badly wrong.
It'd be safer to recode as
for (stream >> x; stream >> x; !stream.failed())
1. I think you switched the second and third parameter (?) to the for()
loop.
2. It still has the disadvantage that the input operation is repeated twice.
// I'd write it like this:
while(true)
{
stream >> x >> y >> ...;
if(stream.fail())
break;
use(x,y,...);
}
Unfortunately C++ has no loop construct that does the breaking in the
middle. Other than that, to answer the question "what does the conversion
to bool mean", it simply means that the operation (in that
case "stream>>x") succeeded. I find this principle rather clear, and it
also visibly connects the operation and the checking for the result. Yes,
not [ab]using the operator overloading would have made this clearer.
In general, implicit conversion to bool is almost always wrong.
A stream or a pointer isn't true or false, and any conventions
for the conversion are very arbitrary.
You'd be surprised how difficult it can be to persuade people of that.
I hate people doing if (pointer) rather than if (pointer != null). But
I'm told
1) It's easier to write
2) It's more efficient (!!?)
Well, it's less to write and (more importantly) less to read, once you
wrapped your brain around the fact that a pointer in a boolean context
means that it points to an object (let's disregard dangling, invalid
pointers).
I find this extremely useful when a boolean state can be meaningfully
associated with an object. Pointers are just one example, smart pointers
are another (because they mimic the behaviour of pointers). Handles to
resources are a third, when they can either have a resource associated or
not. Boost's 'optional' (aka fallible) and 'any' (an unbounded variant
type) classes fall into the same scheme.
Concerning streams, the message is less clear. The problem is that a stream
always includes the accumulated failure states from all operations since
the last clear(), but there could be many different kinds of failures.
Therefore, you always need to check right after the operation that might
have failed. Exceptions could have been used to advantage there, but even
there I'm not exactly clear how that should have been done.
I would say that implicit conversions between fundamental types is what
is broken in C++ (this is what we get from C), but the concept itself
is not necessary stupid and can be used with advantage for user-defined
types.
In some cases, yes. The fact that you need to explicitly
inhibit it (e.g. with explicit) isn't really right---it should
be the reverse, but in the end, inplicit conversions involving
user defined classes are designed by the author, and so
hopefully, only exist in the rare cases where they do make
sense.
Almost: you can specify a conversion to another type, but you can't make
that conversion explicit[1], which is the big danger with these
conversions.
Coming from a place where reinterpret_cast as considered to be THE
essential weapon in the C++ programmers armoury (even to the point of
reinterpret_casting a point to a structure into a pointer to an int so
that you can end off the necessary bits that compromise a bit field in
the structure and compare it with a shifted magic number, rather than
an enumeration value), I find that statement a little optimistic :-(
Some people can carry "You can write fortran in any language" to
unbelievable extremes.
I'm sorry for you. To me that sounds like vandalism. OTOH, vandalism
shouldn't be the guideline for a language like C++, which aims at being a
sharp tool for educated users.
[1] Hmmm, I just had an idea:
// some class that should support a conversion to a string
struct whatever {
whatever( std::string const& name): m_identifier(name) {}
// emulate this:
// explicit operator (std::string)() const;
operator cast<std::string>() const
{ return cast<std::string>(m_identifier); }
private:
std::string const m_identifier;
};
// helper to make conversion explicit
template< typename TargetType>
struct cast
{
explicit cast(TargetType value): m_value(value) {}
operator (TargetType)() const
{ return m_value; }
private:
TargetType m_value;
};
// example usage:
whatever x("foo");
std::string id = cast<std::string>(x);
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]