C++ casts

[Jacob]

It is a common recommendation to use
"static_cast<SomeType> someInstance" instead of the
traditional infamous "(SomeType) someInstance".

Should I use the same practice for simple types,
i.e. instead of:

double fraction = (double) n / total;

should I write this?

double fraction = static_cast<double>(n) /
static_cast<double>(total);

I find the traditional version a lot more readable
in this case.

Thanks!

[Alf P. Steinbach]

* Jacob:

It is a common recommendation to use
"static_cast<SomeType> someInstance" instead of the
traditional infamous "(SomeType) someInstance".

Should I use the same practice for simple types,
i.e. instead of:

double fraction = (double) n / total;

should I write this?

double fraction = static_cast<double>(n) /
static_cast<double>(total);

I find the traditional version a lot more readable
in this case.

There are at least three reasons why it's a Good Idea (TM) to use the C++
named casts also for simple built-in types:

* It helps you and maintainers of your code remember to not use C-style
casts in general, which can help to prevent accidental usage.

* C-style casts can do const_cast and reinterpret_cast, which you probably
don't want (especially not for pointer values).

* The type definitions may be changed when the code is maintained.

--
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?

[benben]

"Jacob" <ja***@yahoo.com> wrote in message
news:3M********************@telenor.com...

It is a common recommendation to use
"static_cast<SomeType> someInstance" instead of the
traditional infamous "(SomeType) someInstance".

Should I use the same practice for simple types,
i.e. instead of:

double fraction = (double) n / total;

should I write this?

double fraction = static_cast<double>(n) /
static_cast<double>(total);

I find the traditional version a lot more readable
in this case.
This is TRUE! The traditional version DOES feel a lot natural than the C++
new cast operators.

But this is EXACTLY why C++ cast operators look this way: they are so ugly
looking to discourage you and alert you from using them. And you can always
pick up all casts using a find in a text editor.

Thanks!

[pookiebearbottom]

Is the equivilent of
double fraction = (double) n / total;
really
double fraction = static_cast<double>(n) / total;

double fraction = (double) n / (double) total;

isn't that readable either

[Greg]

Jacob wrote:

It is a common recommendation to use
"static_cast<SomeType> someInstance" instead of the
traditional infamous "(SomeType) someInstance".

Should I use the same practice for simple types,
i.e. instead of:

double fraction = (double) n / total;

should I write this?

double fraction = static_cast<double>(n) /
static_cast<double>(total);

I find the traditional version a lot more readable
in this case.

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

assuming that n and total are both a scalar value type convertible to a
double.

Greg

[Jacob]

benben wrote:

But this is EXACTLY why C++ cast operators look this way: they are so ugly
looking to discourage you and alert you from using them. And you can always
pick up all casts using a find in a text editor.

So did they really invent this ugly syntax so I
shouldn't use casting, or is this just an urban
myth?

I'd guess there are people from academia telling you
not to cast ever, but no industry scale C++ system
can do without it. And how can I find the fraction of
int 10 to int 35 without casting?

And why do I need a syntax so that _Notepad_ can tell
me where my casts are? First, I wouldn't categorize
code by casts (I don't need a way to find them all),
and a _proper_ editor would tell me (if asked) anyway.

Isn't it so that static_cast (and its cousins) is an
aid for the compiler to to proper type checking and
that neither the compiler nor the runtime environment
can help me when trying to find the fraction of two
integers?

Thanks!

[Jacob]

Greg wrote:

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

assuming that n and total are both a scalar value type convertible to a
double.

I like this. I did search for backing on this syntax
originally but neither S. Meyers nor A. Sutter mentions
it. And my colleges didn't knew about it.

Could you please back it with some links?

Thanks!

[Alf P. Steinbach]

* Jacob:

Greg wrote:

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

This is not "the C++ way": using C casts is the way of C programmers.

assuming that n and total are both a scalar value type convertible to a
double.
I like this.

It's C-style casts, expressed in C++ functional notation.

'T(v)' is equivalent to '(T)v'.

I did search for backing on this syntax
originally but neither S. Meyers nor A. Sutter mentions
it. And my colleges didn't knew about it.

Could you please back it with some links?

§5.2.3/1.

--
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?

[peter.koch.larsen]

Jacob skrev:

benben wrote:

But this is EXACTLY why C++ cast operators look this way: they are so ugly
looking to discourage you and alert you from using them. And you can always
pick up all casts using a find in a text editor.
So did they really invent this ugly syntax so I
shouldn't use casting, or is this just an urban
myth?

I heard that reinterpret_cast was made purposefully ackward to
discourage its use.

I'd guess there are people from academia telling you
not to cast ever, but no industry scale C++ system
can do without it. And how can I find the fraction of
int 10 to int 35 without casting?
I doubt any from academia would tell you never to cast, but casting the
C++ way really is much better. Casting in C++ is much rarer than in C,
however.

And why do I need a syntax so that _Notepad_ can tell
me where my casts are? First, I wouldn't categorize
code by casts (I don't need a way to find them all),
and a _proper_ editor would tell me (if asked) anyway.
Well, finding casts is not easy when you use C-syntax. But the primary
raison d'etre for the new casts is that you tell precisely what kind of
cast you're performing.
Isn't it so that static_cast (and its cousins) is an
aid for the compiler to to proper type checking and
that neither the compiler nor the runtime environment
can help me when trying to find the fraction of two
integers?
There is no aid whatsoever to the compiler. There's a huge aid to the
reader of your code - yourself a half year later or one of your
collegues. A traditional C-style cast does not tell you anything, and
you do cast away const amongst other things. Don't use them.

Thanks!

/Peter

[Default User]

Greg wrote:

Jacob wrote:

It is a common recommendation to use
"static_cast<SomeType> someInstance" instead of the
traditional infamous "(SomeType) someInstance".

Should I use the same practice for simple types,
i.e. instead of:

double fraction = (double) n / total;

should I write this?

double fraction = static_cast<double>(n) /
static_cast<double>(total);

I find the traditional version a lot more readable
in this case.

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

assuming that n and total are both a scalar value type convertible to
a double.

I think that's even worse. It's very difficult to search for those, and
it's less obvious at a glance that casting is going on.


Brian

[Greg]

Alf P. Steinbach wrote:

* Jacob:

Greg wrote:

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

This is not "the C++ way": using C casts is the way of C programmers.

assuming that n and total are both a scalar value type convertible toa
double.

I like this.

It's C-style casts, expressed in C++ functional notation.

'T(v)' is equivalent to '(T)v'.

I did search for backing on this syntax
originally but neither S. Meyers nor A. Sutter mentions
it. And my colleges didn't knew about it.

Could you please back it with some links?

§5.2.3/1.

The expression double(n) is uniquely C++ both syntactically and
conceptually since it "constructs" the double value by converting n:

A simple-type-specifier (dcl.type) followed by a parenthesized
expression-list constructs a value of the specified type given
the expression list. (5.2.3.1)

And in fact replacing "double" with the name of a class that has a
single parameter constuctor would not change the meaning of the
expression at all - only the type of the value constructed would
differ. The advantage here is that the syntax for constructing built-in
types is made compatible with constructing user-defined types - and
consistency leads to more comprehensible code.

The funtional notation is far more restrictive than the C style casts.
It cannot be used to convert pointers - which are far and away the most
dangerous conversions to undertake. Certainly for doubles, ints, chars
and the rest of the built in types, using the static_cast notation
would be slightly ridiculous. There is no polymorphism with the
built-in types so whatever the statically declared type of a variable
happens to be, will be its type for all intents and purposes. In light
of that fact, one might as well use the notation that creates the least
clutter in the source code, and that looks the most like existing code
that performs the identical operation for class types.

Greg

[Alf P. Steinbach]

* Greg:

The expression double(n) is uniquely C++ both syntactically and
conceptually since it "constructs" the double value by converting n:
Do you by any chance have pointy hair?

It cannot be used to convert pointers - which are far and away the most
dangerous conversions to undertake.

int main()
{
typedef unsigned char* UcPtr;

UcPtr p;
double c;

p = UcPtr( &c );
}

--
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?

[benben]

>> But this is EXACTLY why C++ cast operators look this way: they are so

ugly looking to discourage you and alert you from using them. And you can
always pick up all casts using a find in a text editor.
So did they really invent this ugly syntax so I
shouldn't use casting, or is this just an urban
myth?

That's what Bjarne Stroustrup said in his faq, have a read.

I'd guess there are people from academia telling you
not to cast ever, but no industry scale C++ system
can do without it. And how can I find the fraction of
int 10 to int 35 without casting?
Not to cast ever is unrealistic, indeed. However, knowing the potential
danger of cast yet leaving casts all over the source is asking for trouble,
especially during debugging. A better way would be writing a function which
does the cast for its callers. This way the code becomes more explicit and,
most importantly, you are localizing some dangereous operations and that'd
make debugging and maintaining much easier. Now, you would have ended up
with a bunch of such functions that really are doing the same thing with
different types; to generalize, and to make code concise, you can use
template. Now you end up with some function templates that look like the
following:

template <typename TypeTo, typename TypeFrom>
TypeTo my_safe_cast(const TypeFrom& from)
{
// localized dangereous casting code...
}

apple a = my_safe_cast<orange>(o);

Which, basically, is what static_cast, dynamic_cast, and reinterpret_cast
are.

And why do I need a syntax so that _Notepad_ can tell
me where my casts are? First, I wouldn't categorize
code by casts (I don't need a way to find them all),
and a _proper_ editor would tell me (if asked) anyway.
I haven't seen an editor that can effectively tell me where all the C-style
casts are. This is not for catagorizing code but for maintainance. Again, if
my program is plagued by overflow/underflow and bit and byte level runtime
errors I'd be glad to be able to find out all casting, bit operation,
limits, etc in a couple of seconds.
Isn't it so that static_cast (and its cousins) is an
aid for the compiler to to proper type checking and
that neither the compiler nor the runtime environment
can help me when trying to find the fraction of two
integers?
Type casting by itself doesn't have much meaning. You might want to cast a
double to an int this way and I might want it the other way. Some casting
operations are quite trivial while others can be quite complex and
expensive. So there are always different ways to cast from one type to
another and that's why C++:

1. provides different cast operators that does a specific job
2. provides its cast operators as if they are function templates so that
you can write your own cast operators.

Having that said, type cast is not the best way for type conversion.
Whenever possible, it is easier, simpler, and more managable to start with
copy constructor, assignment overloading, and explicit functions.

Thanks!

No worries!

Ben

[Greg]

Alf P. Steinbach wrote:

* Greg:

The expression double(n) is uniquely C++ both syntactically and
conceptually since it "constructs" the double value by converting n:

Do you by any chance have pointy hair?

It cannot be used to convert pointers - which are far and away the most
dangerous conversions to undertake.

int main()
{
typedef unsigned char* UcPtr;

UcPtr p;
double c;

p = UcPtr( &c );
}

Granted, it's possible to circumvent the restrictive syntax of this
method of conversion, but if someone is determined to convert a char
pointer to a double, I doubt that they would go about it this way.

The function notation for explicit conversions was added to C++ for a
reason. It does not exist for backward compatibility with C. There must
therefore be situations where its use would be a better choice than any
other conversion operator. And if converting an int to a double is not
one of those cases, then for what kind of conversion was it meant to be
used?

Greg

[Old Wolf]

Jacob wrote:

Greg wrote:

You should avoid casts altogether and write it the C++ way:

double fraction = double(n) / double(total);

Only one of the operands of '/' (or any other arithmetic
operator) needs to be converted:

double fraction = double(n) / total;

Another option would be:
double fraction = n;
fraction /= total;
I like this. I did search for backing on this syntax
originally but neither S. Meyers nor A. Sutter mentions
it. And my colleges didn't knew about it.

Could you please back it with some links?

It's called "constructing a temporary object".
Here is an analogous example, with string
instead of double:

string name = string("john") + " doe";

I fail to see how this is un-C++ as another poster
claimed; would he prefer to write:
string name = static_cast<string>("john") + " doe";
?

One reason that constructor syntax can be applied to
intrinsic types as well as class types is this:

template<typename A, typename B>
A sum(B x, B y)
{
return A(x) + y;
}

// in a function somewhere
cout << sum<double>(1, -5) << '\n';
cout << sum<string>("john", " doe") << '\n';

[Alf P. Steinbach]

* Greg:

Alf P. Steinbach wrote:

* Greg:

The expression double(n) is uniquely C++ both syntactically and
conceptually since it "constructs" the double value by converting n:
Do you by any chance have pointy hair?

It cannot be used to convert pointers - which are far and away the most
dangerous conversions to undertake.

int main()
{
typedef unsigned char* UcPtr;

UcPtr p;
double c;

p = UcPtr( &c );
}

Granted, it's possible to circumvent the restrictive syntax of this
method of conversion,

The syntax is not restrictive, quite the opposite, and no circumvention is
needed.

but if someone is determined to convert a char
pointer to a double, I doubt that they would go about it this way.
Do you at all understand that your statement "it cannot be used to convert
pointers" is incorrect?

The function notation for explicit conversions was added to C++ for a
reason. It does not exist for backward compatibility with C. There must
therefore be situations where its use would be a better choice than any
other conversion operator. And if converting an int to a double is not
one of those cases, then for what kind of conversion was it meant to be
used?

Do you by any chance have pointy hair?

--
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]

* Old Wolf:

It's called "constructing a temporary object".
No, in general it's not, because it's equivalent to a C-style cast: the
standard uses the word equivalent.

Here is an analogous example, with string
instead of double:

string name = string("john") + " doe";

I fail to see how this is un-C++ as another poster
claimed; would he prefer to write:
string name = static_cast<string>("john") + " doe";
?

The example is not analogous except partially in syntax.

<url: http://www.nizkor.org/features/fallacies/straw-man.html>.

When you attack someone's position, be accurate, be truthful, name names,
and so on.

--
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?

[Jacob]

Old Wolf wrote:

double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

[Old Wolf]

Jacob wrote:

Old Wolf wrote:

double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

Huh?

Are you saying this is bad because someone might
remove the second statement at a later date?

[Old Wolf]

Alf P. Steinbach wrote:

* Old Wolf:

[re. the construction: double(n) ]

It's called "constructing a temporary object".

No, in general it's not, because it's equivalent to a C-style cast: the
standard uses the word equivalent.

Well, constructing a [X] with [Y] as parameter, is equvalent
to casting [Y] to [X], is it not? Certainly no conforming
program can tell the difference. You conveniently snipped
the template example, which I think is a good illustration
of temporary objects.

Here's another example:

double get() { return double(); }

The return statement creates a temporary double and then
returns it. No arguments here.

But you would say that the following does not create a
temporary double? :

double get() { return double(1); }

[Alf P. Steinbach]

* Old Wolf:

Here's another example:

double get() { return double(); }

The return statement creates a temporary double and then
returns it. No arguments here.
First point you're wrong, for the general case of _any_ type: there is no
requirement of a temporary in the standard. Quite the opposite. ;-) Second
point you're wrong, this code involves a 'double' rvalue, and there's no
such thing as a temporary non-class type rvalue. Third point you're wrong,
the notation with no arguments is not the cast notation described by
§5.2.3/1 and championed by Greg, which we were discussing, but the rvalue
creation notation described by §5.2.3/2, which is a very different beastie.

But you would say that the following does not create a
temporary double? :

double get() { return double(1); }

Yes, I would.

--
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?

[Jacob]

Old Wolf wrote:

Jacob wrote:

Old Wolf wrote:

double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

Huh?

Are you saying this is bad because someone might
remove the second statement at a later date?

Basically it is bad because it is wrong.

A "fraction" is a well defined concept and should
never be allowed to be outside the range [0.0, 1.0].

[Kai-Uwe Bux]

Jacob wrote:

Old Wolf wrote:

Jacob wrote:

Old Wolf wrote:
double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

Huh?

Are you saying this is bad because someone might
remove the second statement at a later date?

Basically it is bad because it is wrong.

A "fraction" is a well defined concept and should
never be allowed to be outside the range [0.0, 1.0].

Hm, if that is a pending bug, then I suppose that wrinting

double fraction = 0.5;

is already pretty bad. Using the type double to represent a fraction that
*should never be allowed to be outside [0.0, 1.0]* is flawed then. You
should create a FractionClass (or template so that you can use float,
double, or higher precision) that will enforce the interval condition as an
invariant.
Best

Kai-Uwe Bux

[Greg]

Alf P. Steinbach wrote:

* Old Wolf:

It's called "constructing a temporary object".

No, in general it's not, because it's equivalent to a C-style cast: the
standard uses the word equivalent.

But they are equivalent when converting simple types only, and not,
say, when converting class types. And simple type conversions carry
little risk - they are unlikely ever to crash. Pointer to type
conversions, on the other hand, can and do lead to crashes every now
and then.

Since pointer to type conversions carry the most risk, whichever
conversion notation makes them harder to express is the safer, better
notation. And since functional notation makes pointer to type
conversions much less convenient to express than the C cast notation -
functional notation is the better choice when performing an explicit
type conversion.

Greg

[Alf P. Steinbach]

* Greg:

Alf P. Steinbach wrote:

* Old Wolf:

It's called "constructing a temporary object".
No, in general it's not, because it's equivalent to a C-style cast: the
standard uses the word equivalent.

But they are equivalent when converting simple types only, and not,
say, when converting class types.

Sorrry, that's incorrect -- but it's also irrelevant.

Since pointer to type conversions carry the most risk, whichever
conversion notation makes them harder to express is the safer, better
notation. And since functional notation makes pointer to type
conversions much less convenient to express than the C cast notation -
functional notation is the better choice when performing an explicit
type conversion.

I'd tend to agree with that if there were no other alternatives, choosing
between Baddum and Worsum.

However, we do have C++ named casts.

--
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?

[Stein Gulbrandsen]

Jacob <ja***@yahoo.com> writes:

Old Wolf wrote:

double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

Another way to write it without cast could be:

double fraction = 1.0 * n / total;

Not very nice, though.

[Alf P. Steinbach]

* Stein Gulbrandsen:

Jacob <ja***@yahoo.com> writes:

Old Wolf wrote:

double fraction = n;
fraction /= total;

This is certainly a way to compute the fraction n/total
without using casts, but it is conceptually wrong;
At the instance between the two statements "fraction"
will be incorrect and represents a pending bug.

Another way to write it without cast could be:

double fraction = 1.0 * n / total;

Not very nice, though.

I think that's nearly nicest... It is correct and readable. An alternative
is to declare named 'double' versions of the arguments.

--
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?

[Old Wolf]

Alf P. Steinbach wrote:

* Old Wolf:

Here's another example:

double get() { return double(); }

The return statement creates a temporary double and then
returns it. No arguments here.

First point you're wrong, for the general case of _any_ type: there is no
requirement of a temporary in the standard. Quite the opposite. ;-) Second
point you're wrong, this code involves a 'double' rvalue, and there's no
such thing as a temporary non-class type rvalue. Third point you're wrong,
the notation with no arguments is not the cast notation described by
§5.2.3/1 and championed by Greg, which we were discussing, but the rvalue
creation notation described by §5.2.3/2, which is a very different beastie.

So it is the rvalue creation notation, but it does not create an
rvalue? I'm with you now...

But you would say that the following does not create a
temporary double? :

double get() { return double(1); }

Yes, I would.

#include <iostream>

int main()
{
double const &d = double(1);
double const &e = double(3);

std::cout << d << ' ' << e << std::endl;
}

(I presume this program does not have undefined behaviour).
The references d and e are undoubtedly bound to objects.
These objects aren't lvalues so they must be rvalues.

They aren't named so they must be temporary.

They had their lifetime extended by being bound to a const
reference, so this makes them a good candidate for being
temporary rvalues, wouldn't you say?

[Old Wolf]

Jacob wrote:

A "fraction" is a well defined concept and should
never be allowed to be outside the range [0.0, 1.0].

Not. (Non-negative) proper fractions are in the range [0, 1).
Negative proper fractions are in (-1, 0). Positive and negative
improper fractions are in [1, inf) and (-inf, -1] respectively.

All of these are fractions, of one sort or another.

NB. Naming proper, improper, and mixed fractions is
usually only done at an elementary level (apparently to
help learning), in practical mathematics the issue never comes up.

[Alf P. Steinbach]

* Old Wolf:

Alf P. Steinbach wrote:

* Old Wolf:

Here's another example:

double get() { return double(); }

The return statement creates a temporary double and then
returns it. No arguments here.
First point you're wrong, for the general case of _any_ type: there is no
requirement of a temporary in the standard. Quite the opposite. ;-) Sec=

ond

point you're wrong, this code involves a 'double' rvalue, and there's no
such thing as a temporary non-class type rvalue. Third point you're wron=

g,

the notation with no arguments is not the cast notation described by
=A75.2.3/1 and championed by Greg, which we were discussing, but the rval=

ue

creation notation described by =A75.2.3/2, which is a very different beas=

tie.

Please use a decent newsreader (not Gaggle) or fix the quoting manually.

So it is the rvalue creation notation, but it does not create an
rvalue? I'm with you now...
Not sure what you refer to by 'it', but you're contradicting yourself.

But you would say that the following does not create a
temporary double? :

double get() { return double(1); }

Yes, I would.

#include <iostream>

int main()
{
double const &d =3D double(1);
double const &e =3D double(3);

std::cout << d << ' ' << e << std::endl;
}

(I presume this program does not have undefined behaviour).

It's OK, except _really_ formally <ostream> should also be included... ;-)

The references d and e are undoubtedly bound to objects.
Yes.

These objects aren't lvalues
Nope. They're lvalues, initialized from the rvalues. The standard goes on
and on about it.

so they must be rvalues.
Nope.

They aren't named so they must be temporary.
Yes.

They had their lifetime extended by being bound to a const
reference,
Yes.

so this makes them a good candidate for being
temporary rvalues, wouldn't you say?

Nope.

--
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?

[Old Wolf]

Alf P. Steinbach wrote:

* Old Wolf:

Alf P. Steinbach wrote:

* Old Wolf:
First point you're wrong, for the general case of _any_ type: there is no
requirement of a temporary in the standard. Quite the opposite. ;-) Sec=

ond

point you're wrong, this code involves a 'double' rvalue, and there's no
such thing as a temporary non-class type rvalue. Third point you're wron=

g,

Please use a decent newsreader (not Gaggle) or fix the quoting manually.

Well, it looks just fine when reading via Gaggle, it is only when your
reply with the quoting appears that it looks funny, which would tend
to suggest that the problem is with your reader or a server somewhere
that reformats the messages as it goes.

Usually I reformat quotes to be less than 72 cols but sometimes I can't
be bothered. I will try harder in future :)

[Alf P. Steinbach]

* Alf P. Steinbach:

* Old Wolf:

Here's another example:

double get() { return double(); }

The return statement creates a temporary double and then
returns it. No arguments here.

First point you're wrong, for the general case of _any_ type: there is no
requirement of a temporary in the standard. Quite the opposite. ;-) Second
point you're wrong, this code involves a 'double' rvalue, and there's no
such thing as a temporary non-class type rvalue. Third point you're wrong,
the notation with no arguments is not the cast notation described by
§5.2.3/1 and championed by Greg, which we were discussing, but the rvalue
creation notation described by §5.2.3/2, which is a very different beastie.

I now think I was wrong & you were right on point two: it seems there are
temporary non-class rvalues, and in particular the result of a functional
notation or C style cast is probably a temporary object, this tidbit tucked
away in §3.10/6, phrased with qualifications so that it's difficult to grok.

In the example above this temporary, if any, can be elided.

But you would say that the following does not create a
temporary double? :

double get() { return double(1); }

Yes, I would.

Well, I wouldn't say that for sure any more. ;-)

However, regarding conclusions, the question was whether the functional
notation cast, which is equivalent to C-style cast, is a good idea/habit.

And, going up back up the thread, the proposed counter-example to the
position that it's not a good idea or habit, leading to the above, was

string name = string("john") + " doe";

And this is formally a cast, per the equivalence between functional notation
and C style cast notation, but, assuming 'string' is 'std::string', it's an
invocation of the 'std::string' constructor, not something that could turn
out to be or later become a const_cast or a reinterpret_cast, as T(x) can be
or become when T is a non-class type.

The fundamental difference is between class type and non-class type.
PS: Going down the thread instead of up, I discover to my horror that I
wrote about reference bound temporary objects "they're lvalues", in the
context of rvalue versus lvalue: the distinction rvalue/lvalue is only
meaningful for _expressions_, so it's only when the reference is _used_.

--
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?