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 2 of 2 — ← Prev page 1 [2]

#4858

On 05/10/11 07:42 PM, Jorgen Grahn wrote:
> 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.

I do write a lot of wrappers, hence the frequent use of reinterpret_cast!

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

No, too painful....  Invasive and old-fashioned sums it up pretty well!

-- 
Ian Collins

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

#4872

Op 10-May-11 10:20, Ian Collins schreef:
> On 05/10/11 07:42 PM, Jorgen Grahn wrote:
>> 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.
>
> I do write a lot of wrappers, hence the frequent use of reinterpret_cast!
>
>>> 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.
>
> No, too painful.... Invasive and old-fashioned sums it up pretty well!

And yet some parts are surprisingly immature (buggy/sloppy implemented) 
for such an old library. But if you like nineties style C++ and yet 
another C++ library with its own string and container classes you 
probably like ACE. Personally I would consider other options first 
before considering ACE; my memories of ACE aren't that pleasant as well.

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

#4891

On Tue, 2011-05-10, Dombo wrote:
> Op 10-May-11 10:20, Ian Collins schreef:
>> On 05/10/11 07:42 PM, Jorgen Grahn wrote:
>>> On Mon, 2011-05-09, Ian Collins wrote:
...
>>>> 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.
>>
>> No, too painful.... Invasive and old-fashioned sums it up pretty well!
>
> And yet some parts are surprisingly immature (buggy/sloppy implemented) 
> for such an old library. But if you like nineties style C++ and yet 
> another C++ library with its own string and container classes you 
> probably like ACE. Personally I would consider other options first 
> before considering ACE; my memories of ACE aren't that pleasant as well.

Thanks. "Nineties-style C++" was actually the third prejudice I had
against it.

/Jorgen

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

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

#4893

Jorgen Grahn wrote:

> On Tue, 2011-05-10, Dombo wrote:
>> Op 10-May-11 10:20, Ian Collins schreef:
>>> On 05/10/11 07:42 PM, Jorgen Grahn wrote:
>>>> On Mon, 2011-05-09, Ian Collins wrote:
> ...
>>>>> 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.
>>>
>>> No, too painful.... Invasive and old-fashioned sums it up pretty well!
>>
>> And yet some parts are surprisingly immature (buggy/sloppy implemented)
>> for such an old library. But if you like nineties style C++ and yet
>> another C++ library with its own string and container classes you
>> probably like ACE. Personally I would consider other options first
>> before considering ACE; my memories of ACE aren't that pleasant as well.
> 
> Thanks. "Nineties-style C++" was actually the third prejudice I had
> against it.

Just curious: what are the main characteristics of "nineties-style C++"?


Best,

Kai-Uwe Bux

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

#4899

On May 11, 7:57 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Jorgen Grahn wrote:
> > On Tue, 2011-05-10, Dombo wrote:
> >> Op 10-May-11 10:20, Ian Collins schreef:
> >>> On 05/10/11 07:42 PM, Jorgen Grahn wrote:
> >>>> On Mon, 2011-05-09, Ian Collins wrote:
> > ...
> >>>>> 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.
>
> >>> No, too painful.... Invasive and old-fashioned sums it up pretty well!
>
> >> And yet some parts are surprisingly immature (buggy/sloppy implemented)
> >> for such an old library. But if you like nineties style C++ and yet
> >> another C++ library with its own string and container classes you
> >> probably like ACE. Personally I would consider other options first
> >> before considering ACE; my memories of ACE aren't that pleasant as well.
>
> > Thanks. "Nineties-style C++" was actually the third prejudice I had
> > against it.
>
> Just curious: what are the main characteristics of "nineties-style C++"?


Style like of all C++ frameworks that work. Low usage of namespaces
and so there are prefixes ("old fashioned"), low usage of templates
("invasive"), remarkable usage of preprocessor ("legacy") or code-
generating tools (again all the bad names).

Large and wide framework because reliable and portable standard
library is assumed to be missing. So most bricks (these things are
made of) are present in framework. Significant part of these bricks
are reinvented for supporting concurrency and interprocess
communication. Concurrency is OTW into C++ language two decades after
it was needed so no wonder. Likewise boost defines its own containers
and smart pointers for networking.

I suggested ACE as one of several available and working alternatives
to raw chewing of C socket API or the like that Ian Collins described
like main reason why his C++ code is pile of unmaintainable
'(sockaddr*)&s_addr' crap. I nowhere said that ACE is single available
shiny and modern way out of it.

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

#4921

On Wed, 2011-05-11, Kai-Uwe Bux wrote:
> Jorgen Grahn wrote:
>
>> On Tue, 2011-05-10, Dombo wrote:
>>> Op 10-May-11 10:20, Ian Collins schreef:
>>>> On 05/10/11 07:42 PM, Jorgen Grahn wrote:
>>>>> On Mon, 2011-05-09, Ian Collins wrote:
>> ...
>>>>>> 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.
>>>>
>>>> No, too painful.... Invasive and old-fashioned sums it up pretty well!
>>>
>>> And yet some parts are surprisingly immature (buggy/sloppy implemented)
>>> for such an old library. But if you like nineties style C++ and yet
>>> another C++ library with its own string and container classes you
>>> probably like ACE. Personally I would consider other options first
>>> before considering ACE; my memories of ACE aren't that pleasant as well.
>> 
>> Thanks. "Nineties-style C++" was actually the third prejudice I had
>> against it.
>
> Just curious: what are the main characteristics of "nineties-style C++"?

It's not as if I have a formal definition, but to me it's roughly:

- heavy use of inheritance, little use of templates
- heavy use of raw pointers and heap allocation
- much attention to the big, heavy objects, not enough
  attention to the small, shortlived "concrete classes"
- not compatible with the STL

Once again, I don't know anything about ACE myself.

/Jorgen

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

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

#4847

On 2011-5-10 0:21, Noah Roberts wrote:
> 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:

IMHO, upon the cast issue, I prefer,

1, Keep cast minimal. Don't abuse using it.
If there are a lot of cast, the design may be wrong.

2, When cast is not avoidable, prefer safer cast to unsafe one.
so prefer static_cast to reinterpret_cast.

3, reinterpret_cast should be rarely used, only used in low level code,
or as other mentioned, mix C code.

4, When RTTI is needed, using dynamic_cast.

Just my 2 cents.


-- 
WQ

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

#4829

"Nephi Immortal" <immortalnephi@gmail.com>
> Which should I use correct casting conversion after I create void
> variables?
> void *memory = malloc( 0x1000 );
> char *pString = static_cast< char* >( memory );
> char *pString = reinterpret_cast< char* >( memory );

The general sugestion is to use static_cast wherever it compiles, and 
reinterpret otherwise.
static_cast works to upcast void* to anything -- what probably made sense 
for some contexts but IMO is more hurtful. As you can lose type info easily:

A* a;
B* b;
B* foo(void * p) { return static_cast<B*>(p);}
b = foo(a);

The last row is equivalent to b = reinterpret_cast<B*>(a); without the cast 
actually present in the code.

For these reasons I suggest to use static_cast to deal with input that is 
"genuinely" void/typeless, like that malloc.  And use reinterpret_cast when 
your input was originally typed, and you're not sure.  For surefire, 
nonmissable cases static_cast is okay again -- like you have an enum and a 
void*, and the enum tells you the original type at store.

Certainly in a good program you should be sure everywhere -- as you go 
eventually can get rid of all reinterpret_cast cases -- until then it is 
easy to locate them.

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

#4887

On May 9, 9:44 am, "Balog Pal" <p...@lib.hu> wrote:
>
> A* a;
> B* b;
> B* foo(void * p) { return static_cast<B*>(p);}
> b = foo(a);

Shouldn't that last line be b = foo(static_cast<void *>(a)); ?

> The last row is equivalent to b = reinterpret_cast<B*>(a); without the cast
> actually present in the code.

Somewhere or other I've seen advice to use
static_cast<B*>(static_cast<void*>(a));

in preference to using reinterpret_cast, on the basis it's safer.

>
> For these reasons I suggest to use static_cast to deal with input that is
> "genuinely" void/typeless, like that malloc.  And use reinterpret_cast when
> your input was originally typed, and you're not sure.  For surefire,
> nonmissable cases static_cast is okay again -- like you have an enum and a
> void*, and the enum tells you the original type at store.
>
> Certainly in a good program you should be sure everywhere -- as you go
> eventually can get rid of all reinterpret_cast cases -- until then it is
> easy to locate them.

void * and casts can be horribly overused. I've seen a class that
could only deal with a certain layout of data, but it still had a void
* constructor and a lot of casting to the only supported type
internally.

Replacing the void * with the correct type uncovered more than one
place where the wrong data was passed in.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web