Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Casting function pointers to and from void*

Reply
Thread Tools

Casting function pointers to and from void*

 
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      01-12-2007
Julián Albo wrote:

> Did you have? Looks like you are asking for advice because you haven't.


Sorry, I make a mistake between your name and the OP.

--
Salu2
 
Reply With Quote
 
 
 
 
Pete Becker
Guest
Posts: n/a
 
      01-12-2007
Julián Albo wrote:
> Julián Albo wrote:
>
>> Did you have? Looks like you are asking for advice because you haven't.

>
> Sorry, I make a mistake between your name and the OP.
>


I hate when I do that.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
 
Reply With Quote
 
 
 
 
Gavin Deane
Guest
Posts: n/a
 
      01-12-2007

Pete Becker wrote:
> Gavin Deane wrote:
> > Clearly, code that doesn't work is no use. If such code is formally
> > correct and, according to the standard should work, you have a QoI
> > issue, unless your compiler documents its intended deviation from the
> > standard.
> >
> > It is important that code works. Often (very often in my personal
> > experience), it is also important that the code continues to work in
> > the face of changes. Unless you have an inside line to the people who
> > make your compiler, the language standard and your compiler's
> > documentation of any omissions, extensions or variations from the
> > language standard are your only means of knowing how the compiler
> > manufacturer intends any C++ code to behave after their compiler has
> > compiled it. If you step outside that, you're on your own, flying
> > blind. As an engineer, stepping outside the manufacturer's
> > specification should be a big decision.

>
> You're welcome to spend as much time as you like seeking purity. I'll
> trust Unix compilers to continue support standard idioms such as storing
> function addresses in void*'s, and I'll have robust, working code long
> before you do.


Something must be giving you the confidence to regard that as a
standard idiom that will benefit from continuing support. It's not the
language standard. Is it the compiler documentation? I hope I was clear
in my point that I regard compiler documentation of non-standard
behaviour an equally valid source of such confidence as the standard
itself.

If it's not the compiler documentation, it must be something else.
Perhaps simply an unwritten understanding amongst Unix compiler writers
that their customers expect and rely on this behaviour. If so, would it
not be better for the compiler to document the behaviour, so that the
unwritten becomes written and those new to Unix programming don't have
to learn the folklore by word of mouth?

Gavin Deane

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-12-2007
* Gavin Deane:
> Pete Becker wrote:
>> You're welcome to spend as much time as you like seeking purity. I'll
>> trust Unix compilers to continue support standard idioms such as storing
>> function addresses in void*'s, and I'll have robust, working code long
>> before you do.

>
> Something must be giving you the confidence to regard that as a
> standard idiom that will benefit from continuing support. It's not the
> language standard. Is it the compiler documentation? I hope I was clear
> in my point that I regard compiler documentation of non-standard
> behaviour an equally valid source of such confidence as the standard
> itself.


Presumably Pete is referring to any reliable system documentation
whatsoever, such as (1) compiler documentation, and/or (2) the Posix
standard.

There is a difference between 100% portable standard C++ code and
in-practice C++ code.

One difference is, of course <g>, that in 100% portable C++ code you
can't do any i/o, since some systems have no i/o devices compatible with
the forms of i/o supported by the standard library... So there's really
not very much that can be done in 100% portable C++. Even "Hello,
world!" is not 100% portable: it requires a system with text display.
So the question is always (although unfortunately most often left
unstated): what is the range of systems that this code is meant to be
portable to? When that range is "Posix-compliant systems", storing
function pointers in void* is perfectly OK, as far as I know.

--
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?
 
Reply With Quote
 
Gavin Deane
Guest
Posts: n/a
 
      01-13-2007

Alf P. Steinbach wrote:
> * Gavin Deane:
> > Pete Becker wrote:
> >> You're welcome to spend as much time as you like seeking purity. I'll
> >> trust Unix compilers to continue support standard idioms such as storing
> >> function addresses in void*'s, and I'll have robust, working code long
> >> before you do.

> >
> > Something must be giving you the confidence to regard that as a
> > standard idiom that will benefit from continuing support. It's not the
> > language standard. Is it the compiler documentation? I hope I was clear
> > in my point that I regard compiler documentation of non-standard
> > behaviour an equally valid source of such confidence as the standard
> > itself.

>
> Presumably Pete is referring to any reliable system documentation
> whatsoever, such as (1) compiler documentation, and/or (2) the Posix
> standard.


I'm not very familiar with the Posix standard, but if it requires
certain behaviour of C++ programs (e.g. function pointers to be
storable in void*), and the compiler documentation states something to
the effect that "this compiler implements all behaviour required by the
Posix standard" then clearly that is just as good. You know the
compiler author intends for function pointers to be storable in void*
and you know that if you write such code only a compiler bug can cause
it not to work.

> There is a difference between 100% portable standard C++ code and
> in-practice C++ code.


While I recognise that portability is often the reason for the kind of
argument I'm making, note that I haven't mentioned portability at all
in this thread.

> One difference is, of course <g>, that in 100% portable C++ code you
> can't do any i/o, since some systems have no i/o devices compatible with
> the forms of i/o supported by the standard library... So there's really
> not very much that can be done in 100% portable C++. Even "Hello,
> world!" is not 100% portable: it requires a system with text display.
> So the question is always (although unfortunately most often left
> unstated): what is the range of systems that this code is meant to be
> portable to? When that range is "Posix-compliant systems", storing
> function pointers in void* is perfectly OK, as far as I know.


I agree with all that, however I'm not actually coming from the point
of view of portability at all. If the question is "what is the range of
systems that this code is meant to be portable to?", even if the answer
is "none at all, the code will only ever run on the current system", I
still believe is simply good engineering practice that all the code you
write relies only on behaviour documented (either directly or by
reference to another source) by the compiler author.

Gavin Deane

 
Reply With Quote
 
Andre Kostur
Guest
Posts: n/a
 
      01-13-2007
"Alf P. Steinbach" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> * Gavin Deane:
>> Pete Becker wrote:
>>> You're welcome to spend as much time as you like seeking purity.
>>> I'll trust Unix compilers to continue support standard idioms such
>>> as storing function addresses in void*'s, and I'll have robust,
>>> working code long before you do.

>>
>> Something must be giving you the confidence to regard that as a
>> standard idiom that will benefit from continuing support. It's not
>> the language standard. Is it the compiler documentation? I hope I was
>> clear in my point that I regard compiler documentation of
>> non-standard behaviour an equally valid source of such confidence as
>> the standard itself.

>
> Presumably Pete is referring to any reliable system documentation
> whatsoever, such as (1) compiler documentation, and/or (2) the Posix
> standard.
>
> There is a difference between 100% portable standard C++ code and
> in-practice C++ code.
>
> One difference is, of course <g>, that in 100% portable C++ code you
> can't do any i/o, since some systems have no i/o devices compatible
> with the forms of i/o supported by the standard library... So there's
> really not very much that can be done in 100% portable C++. Even
> "Hello, world!" is not 100% portable: it requires a system with text
> display. So the question is always (although unfortunately most often
> left unstated): what is the range of systems that this code is meant
> to be portable to? When that range is "Posix-compliant systems",
> storing function pointers in void* is perfectly OK, as far as I know.
>


Well... arguably it (Hello World) is 100% portable C++ (for a hosted
environment). It is only using facilities provided by the Standard
Library. It puts "Hello, world!" into some sort of output sink. Wherever
the host decides to put that output is up to the OS & platform (Output to a
serial line, output to a screen, output to a printer, or perhaps output to
the proverbial bit bucket. In any case, it goes _somewhere_.).
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      01-13-2007
Alf P. Steinbach wrote:
>
> There is a difference between 100% portable standard C++ code and
> in-practice C++ code.
>


And note that 100% standard C++ code is not ipso facto portable.
Compilers aren't perfect. Portability is a real-world concept, not a
theoretical one.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
 
Reply With Quote
 
Greg
Guest
Posts: n/a
 
      01-13-2007
Marcus Kwok wrote:
> Greg <(E-Mail Removed)> wrote:
> > Function-to-object pointer conversions have been added to standard C++
> > as a "conditionally supported" conversion using reinterpret_cast<>:
> >
> > "Converting a pointer to a function into a pointer to an object type or
> > vice versa is conditionally-supported. The meaning of such a conversion
> > is implementation defined, except that if an implementation supports
> > conversions in both directions, converting an rvalue of one type to the
> > other type and back, possibly with different cv-qualification, shall
> > yield the original pointer value." [expr.reinterpret.cast/8]

>
> Interesting, thanks.
>
> > Conditionally-supported behavior is one that an implementation is not
> > required to support. But an implementation does support the feature
> > must then implement the feature as specified.

>
> Is there a consolidated list of other "conditionally-supported"
> features?


Not that I know of, so I tried putting together a list myself. Aside
from the pointer-to-object opointer-to-function conversion, the other
conditionally-supported behaviors that I found, are:

A character escaped with a backslash:
"Escape sequences in which the character following the backslash is not
listed in Table 6 are conditionally-supported, with
implementation-defined semantics"


A non-POD type parameter in variable argument list:
"Passing an argument of non-POD class type (clause 9) with no
corresponding parameter is conditionally-supported, with
implementation-defined semantics."


The "asm" directive:
"The asm declaration is conditionally-supported; its meaning is
implementation-defined."


Templates with non-C, non-C++ language linkage
"A template, a template explicit specialization (14.7.3), and a class
template partial specialization shall not have C linkage. Use of a
linkage specification other than C or C++ with any of these constructs
is conditionally-supported, with implementation-defined semantics"

Not the most exciting list of features, I would admit. Perhaps
"conditionally-supported" should mean that an implementation has to
support the feature only if someone notices that the feature is
missing.

Greg

 
Reply With Quote
 
Marcus Kwok
Guest
Posts: n/a
 
      01-18-2007
Greg <(E-Mail Removed)> wrote:
> Marcus Kwok wrote:
>> Greg <(E-Mail Removed)> wrote:
>> > Conditionally-supported behavior is one that an implementation is not
>> > required to support. But an implementation does support the feature
>> > must then implement the feature as specified.

>>
>> Is there a consolidated list of other "conditionally-supported"
>> features?

>
> Not that I know of, so I tried putting together a list myself. Aside
> from the pointer-to-object opointer-to-function conversion, the other
> conditionally-supported behaviors that I found, are:
>
> A character escaped with a backslash:
>
> A non-POD type parameter in variable argument list:
>
> The "asm" directive:
>
> Templates with non-C, non-C++ language linkage
>
> Not the most exciting list of features, I would admit.


I agree, but thanks anyway

--
Marcus Kwok
Replace 'invalid' with 'net' to reply
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
More questions about casting function pointers .. Alfonso Morra C Programming 3 08-31-2005 09:49 AM
Baffled by this ... (casting of function pointers) Alfonso Morra C Programming 7 08-26-2005 02:35 PM
casting function pointers ? Alfonso Morra C Programming 4 07-30-2005 12:46 AM
Casting Function pointers : Can anyone correct this MS Knowledge base Example pls ? Dirk Vanhaute C++ 10 10-22-2004 08:25 AM



Advertisments