Thread

Topic: reinterpret_cast vs. static_cast

Author: jpotter@falcon.lhup.edu (John E. Potter)
Date: 1997/03/01 Raw View

Jason Merrill (jason@cygnus.com) wrote:
: >>>>> John E Potter <jpotter@falcon.lhup.edu> writes:

: > Jason Merrill (jason@cygnus.com) wrote:

: > : Except that implicit conversions are not performed on the operand
: > : of static_cast in order to find a type that can be cast from; the
: > : new-style casts only perform a single conversion.

: > I like that.  But does CD2 say that?

: On the contrary, it does not say that implicit conversions are performed,
: so they are not.

: > I find in 4/5 that in some cases, standard conversions are suppressed
: > in some contexts and that exceptions are given in the descriptions.

: That paragraph is non-normative.

Yep.  No ;-[ on paragraph 5 and I missed the ;-] at the end which matched
the ;-[ at the beginning of paragraph 4.  And the example of unary & does
not in fact list any exceptions.  Since it expects an lvalue, it would be
redundant to exclude lvalue to rvalue conversions.

: > In 5.2.9/4 exceptions are given for static_cast<void>.  It seems that
: > these exceptions would not be required if all standard conversions
: > were suppressed.

: Those exceptions are to 5/8.

Yep.  Didn't read the line above correctly the first time; however, I
found 5/8 myself.  Now I'm off to find another counter example...

: I will readily agree that the WP is unclear on this point.  However,
: the various operators that do perform implicit conversions say the
: operands "shall" be of some type.  I suggest that this implies the
: implicit conversions, and no such language appears in the description
: of static_cast.

 ... Many hours of enjoyable reading later.

Sold!  Thanks for the education.  Since you educated an educator, it
may have a ripple effect.  Reading the CD2 is now like reading a
mystery novel for the second time.  All (well most) of the clues are
obvious.  Still not much of a plot though.

One part of this thread has been the unsafety of static_cast.
Paragraphs 5-9 (6 void* ==> anything*) are all things which if
used properly are quite safe and reasonable.  Like anything in the
language, they can be misused.  With this issue cleared up, I am
content with the relative safety of static_cast.  I will pick up the
other part, which involves safe things which can not be done, elsewhere.

John
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1997/02/26 Raw View

jpotter@falcon.lhup.edu (John E. Potter) writes:

|>  This has been a very confused thread.  I have no problem with any of the
|>  stuff on reinterpret_cast because the rules are clear in the section on
|>  that subject.  Reinterpret_cast is implementation defined, yet there are
|>  some things guarantied.  If the size and alignment of short are two
|>  and long are four then
|>     reinterpret_cast<long*>(reinterpret_cast<short*>(longPtr))
|>  is a no-op.

Is it required to be a no-op, or only that there is no loss of
information, and that the results compare equal to the original pointer.
(I think that an implementation on a segmented architecture, for
example, could legally canonize the pointers in the cast.)

|>     [ No, an implementation may not return null or abort ]

Others have pointed this out to me in email.

My C standard is not here, or I'd verify, but from memory, the C
standard only guarantees meaning if the cast is to void*, or back to the
original type.  (I could be wrong, though.)

I don't like the wording in the current draft, because it seems to me to
be missing the real point.  The *intent* is, I think, that
reinterpret_cast act as expected whenever possible.  To me, as expected
means that the results of the cast point to the same byte, and that
there is no information lost.  I think that the real condition has to do
with the actual size of the pointers, and not with alignment (but it
should allow changes to force alignment as well).  Of course, I cannot
conceive of an implementation where a larger pointer has stricter
alignment requirements than a smaller one, so maybe it is all right
anyway.

IMHO, however, a guarantee of to void* and back, with the rest
implementation defined (and perhaps a note as to the intent, e.g.: that
the results should be unsurprising for someone familiar with the
architecture), would be sufficient.  Market preasure would take care of
the rest.  I'm not adament about this though, and don't have any real
problems with the current wording.

BTW: it is probably worth pointing out that this entire discussion only
concerns data pointers.  The draft speaks of "pointers to objects", and
a strict interpretation of the definition of object in the draft does
not exclude functions.  In all cases where functions are intended to be
included, however, the draft speaks of objects AND functions, so I think
that the intent is clear.

|>  And the following is unspecified
|>     reinterpret_cast<short*>(reinterpret_cast<long*>(shortPtr))
|>
|>  I can't find anything that says that
|>     static_cast<short*>(static_cast<void*>(shortPtr))
|>  is a no-op.

What is the definition of "(short*)(void*)shortPtr"?  If it is defined
as using static_cast, then this has to be a no-op, or we have broken C
compatibility.

|>  The inner one is covered by standard conversions and I guess
|>  the outer one is covered by malloc.

By malloc?  What does malloc have to do with any of this?  The only
particularity of malloc is that the void* it returns must be appropriate
for a cast to any type.  Since the void* in the above is not a return
value of malloc, however, this doesn't apply here.

|>  It then seems to follow that
|>     static_cast<short*>(static_cast<void*>(longPtr))
|>  is a no-op.  That seems to say that the answer to the original question
|>  is that they are the same.
|>
|>  But what about
|>     static_cast<long*>(static_cast<void*>(shortPtr))
|>  I can't find it as defined, undefined, unspecified, or implementation
|>  defined.  Is it unmentioned or can someone give me a pointer?  And what
|>  does unmentioned mean (pointer please)?
|>
|>  And a long unanswered question, "is
|>     static_cast<short*>(longPtr)
|>  well-formed?"  The inner cast to void* is a standard conversion.  If so,
|>  it seems that (short*)longPtr is a static_cast.
|>
|>  Any enlightenment appreciated,

This is what is bothering me, too, and the main reason why I think that
casting from a void* should be a reinterpret_cast (with, exceptionally,
well defined semantics if either the void* is a return value of malloc,
calloc, realloc or operator new, or the cast is a return to the original
type), and not a static_cast.

In practice, except when performance is an issue, I think that I would
recommend never using a static_cast on a pointer or reference.  For
casting to a base class, a dynamic_cast is just as good (and shouldn't
have any effect on performance, since the compiler can trivially
determine that it cannot fail); for casting to a derived class,
dynamic_cast is safer.  And IMHO, any pointer or reference cast except
those navigating an inheritance lattice are inherently dangerous; use a
reinterpret_cast, which is (or should be) a red flag, signally the
danger.  (FWIW: this idea just occurred to me.  So I don't really know
what it is worth.)

Now if there were only some way to distinguish between a narrowing and a
widening conversion...

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: jpotter@falcon.lhup.edu (John E. Potter)
Date: 1997/02/27 Raw View

Jason Merrill (jason@cygnus.com) wrote:
: >>>>> J Kanze <kanze@gabi-soft.fr> writes:

: > This answers the first question.  But should it be.  Practically, it
: > means that static_cast can be used to cast between arbitrary pointer
: > types, since there is an implicit cast from any pointer type to void*,
: > which will allow the compiler to invoke the static cast.

: Except that implicit conversions are not performed on the operand of
: static_cast in order to find a type that can be cast from; the new-style
: casts only perform a single conversion.

I like that.  But does CD2 say that?

I find in 4/5 that in some cases, standard conversions are suppressed
in some contexts and that exceptions are given in the descriptions.

In 5.2.9/4 exceptions are given for static_cast<void>.  It seems that
these exceptions would not be required if all standard conversions
were suppressed.

No idea what the repercussions would be if that change were made.

John
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1997/02/27 Raw View

Stephen.Clamage@eng.sun.com (Steve Clamage) writes:

|>  In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
|>  >Stephen.Clamage@Eng (Steve Clamage) writes:
|>  >
|>  >|>  >(This leads to a further question: is a static_cast FROM void* legal?
|>  >|>  >Should it be?)
|>  >|>
|>  >|>  Yes, since a static cast can reverse most implicit conversions. (I think
|>  >|>  the only exception is reversing a conversion to a virtual base class.)
|>  >|>  In particular, you can static_cast any data pointer to void* and back to
|>  >|>  the original type and get a pointer that compares equal to the original.
|>  >
|>  >This answers the first question.  But should it be.  Practically, it
|>  >means that static_cast can be used to cast between arbitrary pointer
|>  >types, since there is an implicit cast from any pointer type to void*,
|>  >which will allow the compiler to invoke the static cast.  I don't think
|>  >that this is what the committee wanted, and IMHO, it breaks one of the
|>  >largest single reasons for the new cast syntax: a "sideways" cast within
|>  >a class hierarchy is no longer an error.
|>
|>  I'm not sure what you are trying to say.

That I'm confused:-).  Jason Merrill has since posted, stating that no
implicit conversions may occur on the argument of a static cast; I've
been unable to locate text to this effect in the draft.  This would
solve the problem.

|>  You can't use static_cast
|>  to cast directly sideways in a hierarchy. That is, given
|>   class VB { ... };
|>   class A : public virtual VB { ... };
|>   class B : public virtual VB { ... };
|>   class C : public A, public B { ... };
|>   A* pa = new C;
|>   B* pb = static_cast<B*>(pa); // ERROR

I know that this is the intent; it is one of the major motivations for
the new style casts. My impression (to be confirmed) is that in fact,
since a static_cast<B*>( void* ) is legal, and the compiler can
implicitly convert pa to a void*, this line becomes illegal.

If someone can show me the place in the standard which confirms Jason's
assertion, I'll be happy.  If not, it is an adequate solution (I think),
and perhaps should be adopted.

|>  An old-style cast here would not result in an error message (it is
|>  treated as a reinterpet_cast under the new rules, and is quietly accepted
|>  under the old rules), but would not give a useful answer. The static_cast
|>  must yield an error. Isn't that what we want?
|>
|>  You can write the "double cast"
|>   B* pb = static_cast<B*>(static_cast<void*>(pa));
|>  which is perhaps your complaint.

My complaint (or rather my worry -- let's not call it a complaint until
we're sure that I'm right) is that I think that the compiler will do the
inner static cast implicitly, without my writing it.

|>  But programmers must be educated
|>  never to write code like this, just as they must be educated to
|>  avoid old-style casts: you can easily wind up with syntactically
|>  valid code with unknown or even undefined semantics.
|>
|>  Safe casts in C++ may all be implicit. If you write an explicit cast,
|>  it should always be considered a flag that something unportable might be
|>  occuring. Many of the new-style casts are in fact safe if they compile.
|>  A "double cast", it seems to me, must always signal something dangerous
|>  and definitely unportable, even moreso than a reinterpret_cast.

Agreed.  The next step would be to make the opposite true: implicit
casts in C++ are always safe:-).  Of course, this would break some
common (and safe) C idioms: assigning an int to a char is definitly not
safe in the general case, but if the int is a return value from getc,
and I've already tested for EOF, it is safe, and is standard practice.

(This actually leads to a second question: is it guaranteed that I can
assign a non-EOF return value of getc, or istream::get, to a char, then
convert the char to unsigned char, and get the same results?  I don't
think so: the conversion to char can still be "lossy".  This is
definitly the case in C, in any case.)

Anyway, that's another question.  While I think that there are
weaknesses here, they're inherited from C, we're not going to fix them
in this version of the standard, and market presure will ensure that in
fact, my programs will work on all commercial compilers, even if the
standard doesn't guarantee it.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Author: Jason Merrill <jason@cygnus.com>
Date: 1997/02/28 Raw View

>>>>> John E Potter <jpotter@falcon.lhup.edu> writes:

> Jason Merrill (jason@cygnus.com) wrote:

> : Except that implicit conversions are not performed on the operand of
> : static_cast in order to find a type that can be cast from; the new-style
> : casts only perform a single conversion.

> I like that.  But does CD2 say that?

On the contrary, it does not say that implicit conversions are performed,
so they are not.

> I find in 4/5 that in some cases, standard conversions are suppressed
> in some contexts and that exceptions are given in the descriptions.

That paragraph is non-normative.

> In 5.2.9/4 exceptions are given for static_cast<void>.  It seems that
> these exceptions would not be required if all standard conversions
> were suppressed.

Those exceptions are to 5/8.

I will readily agree that the WP is unclear on this point.  However, the
various operators that do perform implicit conversions say the operands
"shall" be of some type.  I suggest that this implies the implicit
conversions, and no such language appears in the description of
static_cast.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/02/23 Raw View

Stephen.Clamage@Eng (Steve Clamage) writes:

|>  >(This leads to a further question: is a static_cast FROM void* legal?
|>  >Should it be?)
|>
|>  Yes, since a static cast can reverse most implicit conversions. (I think
|>  the only exception is reversing a conversion to a virtual base class.)
|>  In particular, you can static_cast any data pointer to void* and back to
|>  the original type and get a pointer that compares equal to the original.

This answers the first question.  But should it be.  Practically, it
means that static_cast can be used to cast between arbitrary pointer
types, since there is an implicit cast from any pointer type to void*,
which will allow the compiler to invoke the static cast.  I don't think
that this is what the committee wanted, and IMHO, it breaks one of the
largest single reasons for the new cast syntax: a "sideways" cast within
a class hierarchy is no longer an error.

On the other hand, if casting from void* requires a reinterpret_cast, we
have (or at least should have) a case where the semantics of
reinterpret_cast are NOT implementation defined.

--
James Kanze        +33 (0)1 39 55 85 62        email: kanze@gabi-soft.fr
GABI Software, Sarl., 22 rue Jacques-Lemercier, 78000 Versailles, France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1997/02/24 Raw View

John E. Potter wrote:
> This has been a very confused thread.

I agree.

> I have no problem with any of the
> stuff on reinterpret_cast because the rules are clear in the section on
> that subject.  Reinterpret_cast is implementation defined, yet there are
> some things guarantied.  If the size and alignment of short are two
> and long are four then
>    reinterpret_cast<long*>(reinterpret_cast<short*>(longPtr))
> is a no-op.
>
>    [ No, an implementation may not return null or abort ]

Why should 'assert (reinterpret_cast<short*>(longPtr))' work ?

With tagged pointer, the actual value could be saved in
the tag and restored after.

> And the following is unspecified
>    reinterpret_cast<short*>(reinterpret_cast<long*>(shortPtr))

Right

> I can't find anything that says that
>    static_cast<short*>(static_cast<void*>(shortPtr))
> is a no-op.  The inner one is covered by standard conversions and I guess
> the outer one is covered by malloc.  It then seems to follow that
>    static_cast<short*>(static_cast<void*>(longPtr))
> is a no-op.  That seems to say that the answer to the original question
> is that they are the same.

IMO void type has been forgotten in the [expr.static.cast]
clause but the intent is quite clear; while well-formed
(no diagnostic needed), it's undefined behaviour to do
that.

> But what about
>    static_cast<long*>(static_cast<void*>(shortPtr))
> I can't find it as defined, undefined, unspecified, or implementation
> defined.  Is it unmentioned or can someone give me a pointer?  And what
> does unmentioned mean (pointer please)?

The same. static_cast should only be used to go back to the
dynamic type of the object (this is != const_cast where you
need not to know the dynamic type [dynamic constness] of
the object).

So while (1) is well-defined, (2) is not in the following:

class Base {};
class Der : public Base {};

Base        b;
const Base  cb;
Der         d;

void*       pv; // void is a direct base class for everything
Base*       pb;
const Base* pcb;
Der*        pd;

pcb = &b;
const_cast<Base*> (pcb); // OK

pcb = &cb;
const_cast<Base*> (pcb); // (1) well-formed, well-defined

pb = &d;
static_cast<Der*> (pb); // OK

pb = &b;
static_cast<Der*> (pb); // (2) well-formed, undefined

pv = &b;
static_cast<Der*> (pv); // (2b) well-formed, undefined

So the programmer must make sure static_cast doesn't go
under it's dynamic type in the class latice but there
aren't any such restrictions on const_cast.

> And a long unanswered question, "is
>    static_cast<short*>(longPtr)
> well-formed?"  The inner cast to void* is a standard conversion.  If so,
> it seems that (short*)longPtr is a static_cast.

Has I replied James, IMO it's not.

I wrote:

>
> I don't think so; the Dec 96 DWP says:
>
>   5.2.9  Static cast                                  [expr.static.cast]
>
> 3 Otherwise, the static_cast shall perform one of the conversions listed
>   below.   No  other  conversion  shall  be performed explicitly using a
>   static_cast.
>
> IMO it means that static_cast can't perform std conversions
> unless explicitly stated.
>
> So any* -> void* is a compile-time correct static_cast
> void* -> other* is a compile-time correct static_cast
>
> but any* -> other* is NOT

I'll add that the compilers I use things the same and if
it's not true then the static/reinterpret casts has the
practical value of a simple comment.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: Jason Merrill <jason@cygnus.com>
Date: 1997/02/24 Raw View

>>>>> J Kanze <kanze@gabi-soft.fr> writes:

> This answers the first question.  But should it be.  Practically, it
> means that static_cast can be used to cast between arbitrary pointer
> types, since there is an implicit cast from any pointer type to void*,
> which will allow the compiler to invoke the static cast.

Except that implicit conversions are not performed on the operand of
static_cast in order to find a type that can be cast from; the new-style
casts only perform a single conversion.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: Stephen.Clamage@eng.sun.com (Steve Clamage)
Date: 1997/02/25 Raw View

In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
>Stephen.Clamage@Eng (Steve Clamage) writes:
>
>|>  >(This leads to a further question: is a static_cast FROM void* legal?
>|>  >Should it be?)
>|>
>|>  Yes, since a static cast can reverse most implicit conversions. (I think
>|>  the only exception is reversing a conversion to a virtual base class.)
>|>  In particular, you can static_cast any data pointer to void* and back to
>|>  the original type and get a pointer that compares equal to the original.
>
>This answers the first question.  But should it be.  Practically, it
>means that static_cast can be used to cast between arbitrary pointer
>types, since there is an implicit cast from any pointer type to void*,
>which will allow the compiler to invoke the static cast.  I don't think
>that this is what the committee wanted, and IMHO, it breaks one of the
>largest single reasons for the new cast syntax: a "sideways" cast within
>a class hierarchy is no longer an error.

I'm not sure what you are trying to say. You can't use static_cast
to cast directly sideways in a hierarchy. That is, given
 class VB { ... };
 class A : public virtual VB { ... };
 class B : public virtual VB { ... };
 class C : public A, public B { ... };
 A* pa = new C;
 B* pb = static_cast<B*>(pa); // ERROR
An old-style cast here would not result in an error message (it is
treated as a reinterpet_cast under the new rules, and is quietly accepted
under the old rules), but would not give a useful answer. The static_cast
must yield an error. Isn't that what we want?

You can write the "double cast"
 B* pb = static_cast<B*>(static_cast<void*>(pa));
which is perhaps your complaint. But programmers must be educated
never to write code like this, just as they must be educated to
avoid old-style casts: you can easily wind up with syntactically
valid code with unknown or even undefined semantics.

Safe casts in C++ may all be implicit. If you write an explicit cast,
it should always be considered a flag that something unportable might be
occuring. Many of the new-style casts are in fact safe if they compile.
A "double cast", it seems to me, must always signal something dangerous
and definitely unportable, even moreso than a reinterpret_cast.

I think the only legitimate use for a "double cast" is when one of
the pair is a const_cast, since the other three casts cannot remove
constness. But removing const is in general dangerous, of course.
You must somehow know that the object referred to is not really const.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Author: rmashlan@r2m.com (Robert Mashlan)
Date: 1997/02/12 Raw View

Stephen.Clamage@eng.sun.com (Steve Clamage) wrote:

>I was speaking always of the general case. Given pointers to unrelated
>types T1 and T2, converting a T2* to a T1* is in general not portable
>in C or in C++. (And that was the original question that started this
>thread.) In C++ the conversion can be performed in general only
>with a reinterpret_cast. The conversion semantics of a reinterpret_cast
>are defined by the implementation, and so will be in general non-portable.
>(Suppose the pointers are different sizes, and you convert a big
>pointer to a little pointer. The standard can't make any promises
>about the result.)
>
>Malloc is not a general case, but a specific case. Type void* is also
>a special case. Type void* is required to have the characteristic that
>any data pointer can be converted to void* without loss of information.
>The requirements on malloc include that it return a pointer to a block
>of memory suitably aligned for any object of the requested size, and
>that the void* returned be convertible to a pointer to any such data
>object.
>
>Your malloc example is correct and portable code, because of the
>special requirements on malloc and void*. The conversion is
>performed via a static_cast.

Hello Steve,

Ok, that makes sense.  Now consider the following code:

   struct T { unsigned refcnt; } ;

   T* CreateT( char *text )
   {
       T* tp static_cast<T*>( malloc( sizeof(T) + strlen(text) + 1 );

       char* cp = static_cast<char*>( static_cast<void*>( tp+1)  );
       strcpy(cp,text);
       return tp;
   }

In what way could this code not be portable?    The potential
problems, as I see it are:

1)  The requested size given to malloc could cause a problem with
producing a pointer of suitable alignment for T.  If this is the case,
the requested size could be rounded up such that size % sizeof(T) ==
0, which would make the memory block of suitable alignment for an
array of T. (Is it conceivable for an implementation to require this?)

2) There is some completely oddball implementation that needs char* to
be more strictly aligned than T*.   I would think this possibility is
not worth worrying about.

If you make the leap of faith that 2 is not going to be a problem,
should I stick with using the double static_cast to convert the T* to
char*, or would reinterpret_cast do the same job, to have the example
be portable?

A related question -- in terms of new style casts, what does the old
style cast  cp = (char *)tp  do?  Is this a double static_cast or a
single reinterpret_cast, if in fact the two are different?

rm

---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]