[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

deprecating T(V) as c-style cast for POD T in favor of initialization semantics - Off topic kinda

Gianni Mariani

10/28/2008 2:33:00 AM

So I was put straight that double(v) is the same as (double)(v)
recently and I'm somewhat surprised. I'm not the only one.

I think T(V) should have exactly the same semantics as
static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
developers that would object.

What I'd like to propose is that the c-style cast interpretation of
T(V) for POD T be the same as initialization of a temporary object T
with a value V. i.e. T id(V).

The rationale is that T(V) being a C-ctyle cast is far more dangerous
than using a c-style cast because use of T(V) in templates is often
used to initialize a temporary T and the fact that it becomes a c-
style cast in some cases and is an initialization in others would be
mostly unintended.

I do believe that most current uses of the T(V) syntax for POD T would
be in cases were the developer intended a static cast or
initialization so there would be very few cases where this would be
problematic. Deprecating the c-ctyle cast meaning should have minimal
undesired impact.

I'd like to hear how others feel about this.
3 Answers

blargg.h4g

10/28/2008 2:44:00 AM

0

In article
<84b5cfff-4eb7-4fb1-97d4-343e24a07d0c@e2g2000hsh.googlegroups.com>, Gianni
Mariani <owebeeone@gmail.com> wrote:

> So I was put straight that double(v) is the same as (double)(v)
> recently and I'm somewhat surprised. I'm not the only one.
>
> I think T(V) should have exactly the same semantics as
> static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
> developers that would object.
>
> What I'd like to propose is that the c-style cast interpretation of
> T(V) for POD T be the same as initialization of a temporary object T
> with a value V. i.e. T id(V).
>
> The rationale is that T(V) being a C-ctyle cast is far more dangerous
> than using a c-style cast because use of T(V) in templates is often
> used to initialize a temporary T and the fact that it becomes a c-
> style cast in some cases and is an initialization in others would be
> mostly unintended.
>
> I do believe that most current uses of the T(V) syntax for POD T would
> be in cases were the developer intended a static cast or
> initialization so there would be very few cases where this would be
> problematic. Deprecating the c-ctyle cast meaning should have minimal
> undesired impact.
>
> I'd like to hear how others feel about this.

Agreed fully!

A better example is int(expr), where expr being a pointer type causes this
to be a reinterpret_cast. For example, the following code might have been
written when d is a double,

// d is a double
int i = int(d);

but later for some reason d becomes a pointer to double. At that point, it
silently becomes reinterpret_cast<int> (d).

However, even if the language can't be changed, compilers could add a
warning when a functional-style cast would result in a const_cast or
reinterpret_cast. Then it becomes a quality-of-implementation issue.
Someone told me that Stroustrup had lamented that this slipped through,
and should have meant static_cast or similar all along.

Ian Collins

10/28/2008 2:46:00 AM

0

Gianni Mariani wrote:
> So I was put straight that double(v) is the same as (double)(v)
> recently and I'm somewhat surprised. I'm not the only one.
>
> I think T(V) should have exactly the same semantics as
> static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
> developers that would object.
>
> What I'd like to propose is that the c-style cast interpretation of
> T(V) for POD T be the same as initialization of a temporary object T
> with a value V. i.e. T id(V).
>
> The rationale is that T(V) being a C-ctyle cast is far more dangerous
> than using a c-style cast because use of T(V) in templates is often
> used to initialize a temporary T and the fact that it becomes a c-
> style cast in some cases and is an initialization in others would be
> mostly unintended.
>
Well it certainly isn't a C style cast for pointers. You can't write

void* p;

int* n(p);

--
Ian Collins

blargg.h4g

10/28/2008 3:42:00 AM

0

In article <6mncmcFgdr8lU25@mid.individual.net>, Ian Collins
<ian-news@hotmail.com> wrote:

> Gianni Mariani wrote:
> > So I was put straight that double(v) is the same as (double)(v)
> > recently and I'm somewhat surprised. I'm not the only one.
> >
> > I think T(V) should have exactly the same semantics as
> > static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
> > developers that would object.
> >
> > What I'd like to propose is that the c-style cast interpretation of
> > T(V) for POD T be the same as initialization of a temporary object T
> > with a value V. i.e. T id(V).
> >
> > The rationale is that T(V) being a C-ctyle cast is far more dangerous
> > than using a c-style cast because use of T(V) in templates is often
> > used to initialize a temporary T and the fact that it becomes a c-
> > style cast in some cases and is an initialization in others would be
> > mostly unintended.
>
> Well it certainly isn't a C style cast for pointers. You can't write
>
> void* p;
>
> int* n(p);

But you can write (and have compile)

typedef int* ip;
void* p;
int* n = ip(p); // static_cast<int*> (p)

as well as

typedef int* ip;
int i;
int* n2 = ip(i); // reinterpret_cast<int*> (i)

which makes it just as unsafe as a C-style cast. The proposal is to make
these equivalent to

int* n( p ); // error
int* n2( i ); // error

or perhaps

int* n = static_cast<int*> (p); // OK
int* n2 = static_cast<int*> (i); // error

(I prefer the former, since a static_cast should be verbose and visible)