Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #4820 > unrolled thread

Which casting conversion to use for void*?

Back to article view | Back to comp.lang.c++

Contents

  Which casting conversion to use for void*? Nephi Immortal <immortalnephi@gmail.com> - 2011-05-08 15:44 -0700
    Re: Which casting conversion to use for void*? Ian Collins <ian-news@hotmail.com> - 2011-05-09 10:48 +1200
    Re: Which casting conversion to use for void*? Qi <no@no.no> - 2011-05-09 14:31 +0800
      Re: Which casting conversion to use for void*? Martijn van Buul <pino@dohd.org> - 2011-05-09 08:04 +0000
      Re: Which casting conversion to use for void*? Noah Roberts <dont@email.me> - 2011-05-09 09:21 -0700
        Re: Which casting conversion to use for void*? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 11:34 -0700
          Re: Which casting conversion to use for void*? Noah Roberts <dont@email.me> - 2011-05-09 12:48 -0700
            Re: Which casting conversion to use for void*? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 14:12 -0700
            Re: Which casting conversion to use for void*? Stuart Redmann <DerTopper@web.de> - 2011-05-09 23:44 -0700
              Re: Which casting conversion to use for void*? "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-10 18:24 +0200
                Re: Which casting conversion to use for void*? Stuart Redmann <DerTopper@web.de> - 2011-05-10 22:56 -0700
          Re: Which casting conversion to use for void*? Öö Tiib <ootiib@hot.ee> - 2011-05-09 13:44 -0700
            Re: Which casting conversion to use for void*? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 14:04 -0700
              Re: Which casting conversion to use for void*? Öö Tiib <ootiib@hot.ee> - 2011-05-09 14:33 -0700
                Re: Which casting conversion to use for void*? Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-05-09 23:46 +0200
                  Re: Which casting conversion to use for void*? Öö Tiib <ootiib@hot.ee> - 2011-05-09 15:16 -0700
        Re: Which casting conversion to use for void*? Ian Collins <ian-news@hotmail.com> - 2011-05-10 08:02 +1200
          Re: Which casting conversion to use for void*? Öö Tiib <ootiib@hot.ee> - 2011-05-09 13:59 -0700
            Re: Which casting conversion to use for void*? Ian Collins <ian-news@hotmail.com> - 2011-05-10 09:27 +1200
              Re: Which casting conversion to use for void*? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-10 07:42 +0000
                Re: Which casting conversion to use for void*? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:20 +1200
                  Re: Which casting conversion to use for void*? Dombo <dombo@disposable.invalid> - 2011-05-10 21:08 +0200
                    Re: Which casting conversion to use for void*? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-11 16:23 +0000
                      Re: Which casting conversion to use for void*? Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-05-11 18:57 +0200
                        Re: Which casting conversion to use for void*? Öö Tiib <ootiib@hot.ee> - 2011-05-11 16:30 -0700
                        Re: Which casting conversion to use for void*? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-12 13:54 +0000
        Re: Which casting conversion to use for void*? Qi <no@no.no> - 2011-05-10 10:45 +0800
    Re: Which casting conversion to use for void*? "Balog Pal" <pasa@lib.hu> - 2011-05-09 10:44 +0200
      Re: Which casting conversion to use for void*? ThosRTanner <ttanner2@bloomberg.net> - 2011-05-11 04:57 -0700

Page 1 of 2  [1] 2  Next page →

#4820 — Which casting conversion to use for void*?

	Which should I use correct casting conversion after I create void
variables?

For example:

void *memory = malloc( 0x1000 );

char *pString = static_cast< char* >( memory );

or

char *pString = reinterpret_cast< char* >( memory );


	After I deallocate the memory, I will convert from char* back to
void* prior free( void* ) function.

[toc] | [next] | [standalone]

#4822

On 05/ 9/11 10:44 AM, Nephi Immortal wrote:
> 	Which should I use correct casting conversion after I create void
> variables?

You never create void variables!

> For example:
>
> void *memory = malloc( 0x1000 );
>
> char *pString = static_cast<  char*>( memory );
>
> or
>
> char *pString = reinterpret_cast<  char*>( memory );

static_cast.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4825

On 2011-5-9 6:44, Nephi Immortal wrote:
> 	Which should I use correct casting conversion after I create void
> variables?
>
> For example:
>
> void *memory = malloc( 0x1000 );
>
> char *pString = static_cast<  char*>( memory );
>
> or
>
> char *pString = reinterpret_cast<  char*>( memory );
>
>
> 	After I deallocate the memory, I will convert from char* back to
> void* prior free( void* ) function.

*static_cast* until compiler complains. Then use reinterpret_cast.
static_cast is type safe cast, reinterpret_cast not.


-- 
WQ

[toc] | [prev] | [next] | [standalone]

#4827

* Qi:
> static_cast is type safe cast

It's not. static_cast works for *related* types, but doesn't guarantee
the cast will be safe. 

It's safer than reinterpret_cast, but not safe.

-- 
Martijn van Buul - pino@dohd.org 

[toc] | [prev] | [next] | [standalone]

#4833

On 5/8/2011 11:31 PM, Qi wrote:
> On 2011-5-9 6:44, Nephi Immortal wrote:
>> Which should I use correct casting conversion after I create void
>> variables?
>>
>> For example:
>>
>> void *memory = malloc( 0x1000 );
>>
>> char *pString = static_cast< char*>( memory );
>>
>> or
>>
>> char *pString = reinterpret_cast< char*>( memory );
>>
>>
>> After I deallocate the memory, I will convert from char* back to
>> void* prior free( void* ) function.
>
> *static_cast* until compiler complains. Then use reinterpret_cast.
> static_cast is type safe cast, reinterpret_cast not.

I can't say I recommend this procedure.  It can easily lead people to 
cast when they don't have to.  For example, I found code like this in a 
project I worked on:

// whatnot.h

struct A
struct B

struct whatnot
{
   A* a;
   void fun(B* b) { a = (B*)b; }
};

// B.h

#include "A.h"

struct B : A {....};

Of course, it's quite silly to do an upcast like this.  It's even worse 
to do a C-style cast.  What's even worse than that about it is that this 
particular cast will be a reinterpret_cast.

The reason of course that it was done is almost certainly that the 
compiler complained about unrelated types and recommended a reinterpret 
or C-style cast (the MS compiler does this).  A more appropriate 
solution of course is to include the appropriate headers and/or move the 
body of f() into a cpp file.

So, it's not really a well recommended practice in my opinion to plug in 
reinterpret_cast when the compiler starts to bitch.  This cast should 
really be reserved for very special cases and, in fact, with almost all 
modern C++ it's completely unnecessary.

-- 
http://crazycpp.wordpress.com

[toc] | [prev] | [next] | [standalone]

#4836

On May 9, 9:21 am, Noah Roberts <d...@email.me> wrote:
> On 5/8/2011 11:31 PM, Qi wrote:
>
>
>
> > On 2011-5-9 6:44, Nephi Immortal wrote:
> >> Which should I use correct casting conversion after I create void
> >> variables?
>
> >> For example:
>
> >> void *memory = malloc( 0x1000 );
>
> >> char *pString = static_cast< char*>( memory );
>
> >> or
>
> >> char *pString = reinterpret_cast< char*>( memory );
>
> >> After I deallocate the memory, I will convert from char* back to
> >> void* prior free( void* ) function.
>
> > *static_cast* until compiler complains. Then use reinterpret_cast.
> > static_cast is type safe cast, reinterpret_cast not.
>
> I can't say I recommend this procedure.  It can easily lead people to
> cast when they don't have to.  For example, I found code like this in a
> project I worked on:
>
> // whatnot.h
>
> struct A
> struct B
>
> struct whatnot
> {
>    A* a;
>    void fun(B* b) { a = (B*)b; }
>
> };
>
> // B.h
>
> #include "A.h"
>
> struct B : A {....};
>
> Of course, it's quite silly to do an upcast like this.  It's even worse
> to do a C-style cast.  What's even worse than that about it is that this
> particular cast will be a reinterpret_cast.
>
> The reason of course that it was done is almost certainly that the
> compiler complained about unrelated types and recommended a reinterpret
> or C-style cast (the MS compiler does this).  A more appropriate
> solution of course is to include the appropriate headers and/or move the
> body of f() into a cpp file.
>
> So, it's not really a well recommended practice in my opinion to plug in
> reinterpret_cast when the compiler starts to bitch.  This cast should
> really be reserved for very special cases and, in fact, with almost all
> modern C++ it's completely unnecessary.

I thank you for that example, which is quite similar to the one that I
like to use.

However, let me possibly take a slightly different stance though. In C+
+ code, you should never use the C-style cast for casting with class
types. In all cases, the C-style cast is equivalent to either a
static_cast or a reinterpret_cast, and as you have pointed out, it can
be quite "ambiguous", or hard to tell for a human reader, which it is
when working with class types. It's error prone. That's why I suggest
writing what you mean and write either the static_cast or the
reinterpret_cast.

Having said that, reinterpret_cast is almost never needed, so I don't
"like" when I see it. However, sometimes you do need it, and I much
prefer to see a reinterpret_cast over a C-style which is in effect
doing a reinterpret_cast on class types.

[toc] | [prev] | [next] | [standalone]

#4837

On 5/9/2011 11:34 AM, Joshua Maurice wrote:
> On May 9, 9:21 am, Noah Roberts<d...@email.me>  wrote:
>> On 5/8/2011 11:31 PM, Qi wrote:
>>
>>
>>
>>> On 2011-5-9 6:44, Nephi Immortal wrote:
>>>> Which should I use correct casting conversion after I create void
>>>> variables?
>>
>>>> For example:
>>
>>>> void *memory = malloc( 0x1000 );
>>
>>>> char *pString = static_cast<  char*>( memory );
>>
>>>> or
>>
>>>> char *pString = reinterpret_cast<  char*>( memory );
>>
>>>> After I deallocate the memory, I will convert from char* back to
>>>> void* prior free( void* ) function.
>>
>>> *static_cast* until compiler complains. Then use reinterpret_cast.
>>> static_cast is type safe cast, reinterpret_cast not.
>>
>> I can't say I recommend this procedure.  It can easily lead people to
>> cast when they don't have to.  For example, I found code like this in a
>> project I worked on:
>>
>> // whatnot.h
>>
>> struct A
>> struct B
>>
>> struct whatnot
>> {
>>     A* a;
>>     void fun(B* b) { a = (B*)b; }
>>
>> };
>>
>> // B.h
>>
>> #include "A.h"
>>
>> struct B : A {....};
>>
>> Of course, it's quite silly to do an upcast like this.  It's even worse
>> to do a C-style cast.  What's even worse than that about it is that this
>> particular cast will be a reinterpret_cast.
>>
>> The reason of course that it was done is almost certainly that the
>> compiler complained about unrelated types and recommended a reinterpret
>> or C-style cast (the MS compiler does this).  A more appropriate
>> solution of course is to include the appropriate headers and/or move the
>> body of f() into a cpp file.
>>
>> So, it's not really a well recommended practice in my opinion to plug in
>> reinterpret_cast when the compiler starts to bitch.  This cast should
>> really be reserved for very special cases and, in fact, with almost all
>> modern C++ it's completely unnecessary.
>
> I thank you for that example, which is quite similar to the one that I
> like to use.
>
> However, let me possibly take a slightly different stance though. In C+
> + code, you should never use the C-style cast for casting with class
> types. In all cases, the C-style cast is equivalent to either a
> static_cast or a reinterpret_cast

This is not actually true.  There are certain, very rare conditions in 
which a C-style cast does not match any of the available new-style casts 
and is absolutely necessary for the specific cast needed.  Correctly 
casting to a protected/private base class for example; although it's 
extremely rare that you'd want to do this, when you do a C-style cast is 
necessary.

, and as you have pointed out, it can
> be quite "ambiguous", or hard to tell for a human reader, which it is
> when working with class types. It's error prone. That's why I suggest
> writing what you mean and write either the static_cast or the
> reinterpret_cast.

Although my example uses a C-Style cast, it would fall afoul of error 
when applying Qi's rule, "use static_cast until the compiler complains, 
then use reinterpret_cast."  The author of the code in question probably 
thought they where doing a static cast, and it's only because a static 
cast would not work there that a reinterpret cast is the actual result.

-- 
http://crazycpp.wordpress.com

[toc] | [prev] | [next] | [standalone]

#4842

On May 9, 12:48 pm, Noah Roberts <d...@email.me> wrote:
> On 5/9/2011 11:34 AM, Joshua Maurice wrote:
> > However, let me possibly take a slightly different stance though. In C+
> > + code, you should never use the C-style cast for casting with class
> > types. In all cases, the C-style cast is equivalent to either a
> > static_cast or a reinterpret_cast
>
> This is not actually true.  There are certain, very rare conditions in
> which a C-style cast does not match any of the available new-style casts
> and is absolutely necessary for the specific cast needed.  Correctly
> casting to a protected/private base class for example; although it's
> extremely rare that you'd want to do this, when you do a C-style cast is
> necessary.

Well, thank you for teaching me something new. I tested it out on an
available compiler, and it's there in C++03, 5.4 Explicit type
conversion (cast notation) / 7.

That's horrible. I would want a nice glaring comment for any such kind
of cast, if ever required.

[toc] | [prev] | [next] | [standalone]

#4850

On 9 Mai, Noah Roberts wrote:

[snip]

> There are certain, very rare conditions in
> which a C-style cast does not match any of the available new-style casts
> and is absolutely necessary for the specific cast needed.  Correctly
> casting to a protected/private base class for example; although it's
> extremely rare that you'd want to do this, when you do a C-style cast is
> necessary.

[snip]

Could you please elaborate, preferably with an example? The following
works just fine without any C-style cast:

#include <iostream>

class PrivateBase
{
public:
  void f ()
  {
    std::cout << "PrivateBase";
  }
};

class PublicDerived : private PrivateBase
{
public:
  PrivateBase* GetBase ()
  {
    return this;
  }
};

int main ()
{
  PublicDerived pd;
  pd.GetBase ()->f ();
  return 0;
}

Thanks in advance,
Stuart

[toc] | [prev] | [next] | [standalone]

#4868

* Stuart Redmann, on 10.05.2011 08:44:
> On 9 Mai, Noah Roberts wrote:
>
> [snip]
>
>> There are certain, very rare conditions in
>> which a C-style cast does not match any of the available new-style casts
>> and is absolutely necessary for the specific cast needed.  Correctly
>> casting to a protected/private base class for example; although it's
>> extremely rare that you'd want to do this, when you do a C-style cast is
>> necessary.
>
> [snip]
>
> Could you please elaborate, preferably with an example? The following
> works just fine without any C-style cast:
>
> #include<iostream>
>
> class PrivateBase
> {
> public:
>    void f ()
>    {
>      std::cout<<  "PrivateBase";
>    }
> };
>
> class PublicDerived : private PrivateBase
> {
> public:
>    PrivateBase* GetBase ()
>    {
>      return this;
>    }
> };
>
> int main ()
> {
>    PublicDerived pd;
>    pd.GetBase ()->f ();
>    return 0;
> }
>
> Thanks in advance,
> Stuart

The problem arises when you have to use a cast, i.e. you don't control the code 
of the derived class and it doesn't offer the required access. For example, you 
might want to do this during debugging. Or for unit-testing.

Then a C style cast can correctly cast to inaccessible base as if a static_cast 
were used and had access to the base.

This includes pointer value adjustment, if needed.

I do not know what other "certain, very rare conditions" Noah refers to.

As far as the C++ standard is concerned casting to inaccessible base is the only 
thing a C style cast can actively do that named casts cannot. On the passive 
side, a C style cast can change behavior when the relevant types change (e.g. 
from const_cast to reinterpret_cast), but presumbably that's not it. However, I 
guess some compiler might implement other casting functionality as a language 
extension.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#4879

 On 9 Mai, Noah Roberts wrote:
> >>
> >> There are certain, very rare conditions in
> >> which a C-style cast does not match any of the available new-style casts
> >> and is absolutely necessary for the specific cast needed.  Correctly
> >> casting to a protected/private base class for example; although it's
> >> extremely rare that you'd want to do this, when you do a C-style cast is
> >> necessary.


Stuart Redmann on 10.05.2011 wrote:
> > Could you please elaborate, preferably with an example? The following
> > works just fine without any C-style cast:
> >
> > #include<iostream>
> >
> > class PrivateBase
> > {
> > public:
> >    void f ()
> >    {
> >      std::cout<<  "PrivateBase";
> >    }
> > };
> >
> > class PublicDerived : private PrivateBase
> > {
> > public:
> >    PrivateBase* GetBase ()
> >    {
> >      return this;
> >    }
> > };
> >
> > int main ()
> > {
> >    PublicDerived pd;
> >    pd.GetBase ()->f ();
> >    return 0;
> > }

On 10 Mai, Alf P. Steinbach wrote:
> The problem arises when you have to use a cast, i.e. you don't control the code
> of the derived class and it doesn't offer the required access. For example, you
> might want to do this during debugging. Or for unit-testing.
>
> Then a C style cast can correctly cast to inaccessible base as if a static_cast
> were used and had access to the base.
>
> This includes pointer value adjustment, if needed.
>
> I do not know what other "certain, very rare conditions" Noah refers to.
>
> As far as the C++ standard is concerned casting to inaccessible base is the only
> thing a C style cast can actively do that named casts cannot. On the passive
> side, a C style cast can change behavior when the relevant types change (e.g.
> from const_cast to reinterpret_cast), but presumbably that's not it. However, I
> guess some compiler might implement other casting functionality as a language
> extension.

I'd consider such a cast as serious defective (well, OK for debugging
purposes).
IOW, C style casts allows to shoot oneself in the foot to a much
greater extent ;-)

Thanks for the clarification,
Stuart

[toc] | [prev] | [next] | [standalone]

#4839

On May 9, 9:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
>
> In all cases, the C-style cast is equivalent to either a
> static_cast or a reinterpret_cast, and as you have pointed out, it can
> be quite "ambiguous", or hard to tell for a human reader, which it is
> when working with class types.

Nitpick ... in all cases C-style cast is either a static_cast,
dynamic_cast, const_cast, reinterpret_cast or combination of such.

That of course strengthens the rest of your points even more.

[toc] | [prev] | [next] | [standalone]

#4841

On May 9, 1:44 pm, Öö Tiib <oot...@hot.ee> wrote:
> On May 9, 9:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
>
>
> > In all cases, the C-style cast is equivalent to either a
> > static_cast or a reinterpret_cast, and as you have pointed out, it can
> > be quite "ambiguous", or hard to tell for a human reader, which it is
> > when working with class types.
>
> Nitpick ... in all cases C-style cast is either a static_cast,
> dynamic_cast, const_cast, reinterpret_cast or combination of such.

const_cast yes, but unless I'm losing my mind, C-style casts can never
be dynamic_casts. Can it? Example please? I was pretty sure no, but
now you're making me question that. Whipping through a couple of
examples, I'm pretty sure no still.

[toc] | [prev] | [next] | [standalone]

#4844

On May 10, 12:04 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On May 9, 1:44 pm, Öö Tiib <oot...@hot.ee> wrote:
>
> > On May 9, 9:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > > In all cases, the C-style cast is equivalent to either a
> > > static_cast or a reinterpret_cast, and as you have pointed out, it can
> > > be quite "ambiguous", or hard to tell for a human reader, which it is
> > > when working with class types.
>
> > Nitpick ... in all cases C-style cast is either a static_cast,
> > dynamic_cast, const_cast, reinterpret_cast or combination of such.
>
> const_cast yes, but unless I'm losing my mind, C-style casts can never
> be dynamic_casts. Can it? Example please? I was pretty sure no, but
> now you're making me question that. Whipping through a couple of
> examples, I'm pretty sure no still.

Not sure ... isn't it dynamic_cast like that:

 struct OneInterface
 {
     virtual void one() = 0;
 };

 struct OtherInterface
 {
     virtual void other() = 0;
 };

 class X
     : public OneInterface
     , public OtherInterface
 {
 public:
     virtual void one() {}
     virtual void other() {}
 };

 int main()
 {
     OneInterface* p = new X;
     p->one();
     // static_cast and reinterpret_cast both wrong:
     OtherInterface* p2 = (OtherInterface*)p;
     p2->other();
 }

[toc] | [prev] | [next] | [standalone]

#4845

Öö Tiib wrote:

> On May 10, 12:04 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>> On May 9, 1:44 pm, Öö Tiib <oot...@hot.ee> wrote:
>>
>> > On May 9, 9:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>
>> > > In all cases, the C-style cast is equivalent to either a
>> > > static_cast or a reinterpret_cast, and as you have pointed out, it
>> > > can be quite "ambiguous", or hard to tell for a human reader, which
>> > > it is when working with class types.
>>
>> > Nitpick ... in all cases C-style cast is either a static_cast,
>> > dynamic_cast, const_cast, reinterpret_cast or combination of such.
>>
>> const_cast yes, but unless I'm losing my mind, C-style casts can never
>> be dynamic_casts. Can it? Example please? I was pretty sure no, but
>> now you're making me question that. Whipping through a couple of
>> examples, I'm pretty sure no still.
> 
> Not sure ... isn't it dynamic_cast like that:
> 
>  struct OneInterface
>  {
>      virtual void one() = 0;
>  };
> 
>  struct OtherInterface
>  {
>      virtual void other() = 0;
>  };
> 
>  class X
>      : public OneInterface
>      , public OtherInterface
>  {
>  public:
>      virtual void one() {}
>      virtual void other() {}
>  };
> 
>  int main()
>  {
>      OneInterface* p = new X;
>      p->one();
>      // static_cast and reinterpret_cast both wrong:
>      OtherInterface* p2 = (OtherInterface*)p;
>      p2->other();
>  }

Assuming that the code compiles (did not check too hard), I think the line

  OtherInterface* p2 = (OtherInterface*)p;

is seen by the compiler as a reinterpret_cast as per [5.9/7] and the line

  p2->other();

is undefined behavior. In [5.4/5] and [5.4/7], you find a list of what the 
cast notation can mean; and a dynamic_cast is not listed.


Best,

Kai-Uwe Bux

[toc] | [prev] | [next] | [standalone]

#4846

On May 10, 12:46 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Tiib wrote:
> > On May 10, 12:04 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> >> On May 9, 1:44 pm, Tiib <oot...@hot.ee> wrote:
>
> >> > On May 9, 9:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> >> > > In all cases, the C-style cast is equivalent to either a
> >> > > static_cast or a reinterpret_cast, and as you have pointed out, it
> >> > > can be quite "ambiguous", or hard to tell for a human reader, which
> >> > > it is when working with class types.
>
> >> > Nitpick ... in all cases C-style cast is either a static_cast,
> >> > dynamic_cast, const_cast, reinterpret_cast or combination of such.
>
> >> const_cast yes, but unless I'm losing my mind, C-style casts can never
> >> be dynamic_casts. Can it? Example please? I was pretty sure no, but
> >> now you're making me question that. Whipping through a couple of
> >> examples, I'm pretty sure no still.
>
> > Not sure ... isn't it dynamic_cast like that:
>
> >  struct OneInterface
> >  {
> >      virtual void one() = 0;
> >  };
>
> >  struct OtherInterface
> >  {
> >      virtual void other() = 0;
> >  };
>
> >  class X
> >      : public OneInterface
> >      , public OtherInterface
> >  {
> >  public:
> >      virtual void one() {}
> >      virtual void other() {}
> >  };
>
> >  int main()
> >  {
> >      OneInterface* p = new X;
> >      p->one();
> >      // static_cast and reinterpret_cast both wrong:
> >      OtherInterface* p2 = (OtherInterface*)p;
> >      p2->other();
> >  }
>
> Assuming that the code compiles (did not check too hard), I think the line

Tried with comeau online ... compiles.

>   OtherInterface* p2 = (OtherInterface*)p;
>
> is seen by the compiler as a reinterpret_cast as per [5.9/7] and the line
>
>   p2->other();
>
> is undefined behavior. In [5.4/5] and [5.4/7], you find a list of what the
> cast notation can mean; and a dynamic_cast is not listed.

Yes, seems so. Thanks. Lack of dynamic_cast in list is then yet
another reason why not to use C style casts.

[toc] | [prev] | [next] | [standalone]

#4838

On 05/10/11 04:21 AM, Noah Roberts wrote:
>
> So, it's not really a well recommended practice in my opinion to plug in
> reinterpret_cast when the compiler starts to bitch.  This cast should
> really be reserved for very special cases and, in fact, with almost all
> modern C++ it's completely unnecessary.

While I agree in theory, a lot of my nice shiny modern C++ had to deal 
with C interfaces.  Try using BSD socket and name service functions 
without a smattering of reinterpret_casts.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4840

On May 9, 11:02 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 05/10/11 04:21 AM, Noah Roberts wrote:
>
>
>
> > So, it's not really a well recommended practice in my opinion to plug in
> > reinterpret_cast when the compiler starts to bitch.  This cast should
> > really be reserved for very special cases and, in fact, with almost all
> > modern C++ it's completely unnecessary.
>
> While I agree in theory, a lot of my nice shiny modern C++ had to deal
> with C interfaces.  Try using BSD socket and name service functions
> without a smattering of reinterpret_casts.

Yes but lot of these C things have C++ wrappers. Instead of raw C
networking most aim something like ACE, boost::asio, QDataStream
etc ... it is more typesafe and portable.

[toc] | [prev] | [next] | [standalone]

#4843

On 05/10/11 08:59 AM, Öö Tiib wrote:
> On May 9, 11:02 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 05/10/11 04:21 AM, Noah Roberts wrote:
>>
>>
>>
>>> So, it's not really a well recommended practice in my opinion to plug in
>>> reinterpret_cast when the compiler starts to bitch.  This cast should
>>> really be reserved for very special cases and, in fact, with almost all
>>> modern C++ it's completely unnecessary.
>>
>> While I agree in theory, a lot of my nice shiny modern C++ had to deal
>> with C interfaces.  Try using BSD socket and name service functions
>> without a smattering of reinterpret_casts.
>
> Yes but lot of these C things have C++ wrappers. Instead of raw C
> networking most aim something like ACE, boost::asio, QDataStream
> etc ... it is more typesafe and portable.

Ug, why did you have to mention ACE?  I got over the nightmares years 
ago, now they will come back!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4856

On Mon, 2011-05-09, Ian Collins wrote:
> On 05/10/11 08:59 AM, Öö Tiib wrote:
>> On May 9, 11:02 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>>> On 05/10/11 04:21 AM, Noah Roberts wrote:
>>>
>>>
>>>
>>>> So, it's not really a well recommended practice in my opinion to plug in
>>>> reinterpret_cast when the compiler starts to bitch.  This cast should
>>>> really be reserved for very special cases and, in fact, with almost all
>>>> modern C++ it's completely unnecessary.
>>>
>>> While I agree in theory, a lot of my nice shiny modern C++ had to deal
>>> with C interfaces.  Try using BSD socket and name service functions
>>> without a smattering of reinterpret_casts.
>>
>> Yes but lot of these C things have C++ wrappers. Instead of raw C
>> networking most aim something like ACE, boost::asio, QDataStream
>> etc ... it is more typesafe and portable.

Or you write your own custom wrappers.

> Ug, why did you have to mention ACE?  I got over the nightmares years 
> ago, now they will come back!

Care to expand on that?  I have never used ACE, but got the impression
that it's pretty invasive and old-fashioned. Yet you see people
praise it now and then.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web