By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,915 Members | 1,280 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,915 IT Pros & Developers. It's quick & easy.

What's the best method for displaying the value of a function pointer?

P: n/a

Given function pointer, say void (*func)(void*), what's the best way to
display it on an iostream?

as far as I can tell, there is no default overload for operator<<, and a
function pointer doesn't have a conversion to a void*.

The only options I can see are either a C-style cast to void* (unsafe
and ugly), or some kind of template:

template<class T, class U> ostream& operator<<(ostream&, const U&)

which does some kind of copy of the pointer value into an array of
unsigned char (memcpy, or some such), and then outputs the data
byte-by-byte. This, of course, has endian issues (and formatting issues
for oddball architectures such as 16-bit intel).

Any suggestions?

Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
red floyd wrote:


The only options I can see are either a C-style cast to void* (unsafe
and ugly),


There's nothing unsafe about it, although it's possible (but unlikely)
that it won't give you useful information. On POSIX-conformant platforms
it's well defined.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #2

P: n/a
Pete Becker wrote:
red floyd wrote:


The only options I can see are either a C-style cast to void* (unsafe
and ugly),


There's nothing unsafe about it, although it's possible (but unlikely)
that it won't give you useful information. On POSIX-conformant platforms
it's well defined.


I thought the Standard said something about function pointers being cast
to void*? Hence the comment about "unsafe".

[FALLACY type=compiler-specific]
I know g++ 3.2.3 gives me a warning when I use either static_cast or
reinterpret-cast.
[/FALLACY]
Jul 23 '05 #3

P: n/a
red floyd wrote:
Pete Becker wrote:
red floyd wrote:


The only options I can see are either a C-style cast to void* (unsafe
and ugly),

There's nothing unsafe about it, although it's possible (but unlikely)
that it won't give you useful information. On POSIX-conformant
platforms it's well defined.


I thought the Standard said something about function pointers being cast
to void*? Hence the comment about "unsafe".


Standard C++ doesn't allow converting a function pointer into a void*.
That doesn't mean it's "unsafe." It only means that if your compiler
allows it (which every one I use does) you might want to check the
compiler's documentation to see what it does. But any compiler that
doesn't do the obvious thing is seriously freaky.

I know g++ 3.2.3 gives me a warning when I use either static_cast or
reinterpret-cast.


Yes, that's what the standard requires. Having issued a diagnostic, the
compiler is free to do whatever the implementor chooses. If you were
writing a compiler and wanted to implement explicit conversions from
function pointers to void pointers, what would you do? (assuming the
usual architecture, where function pointers and data pointers are the
same size). There's nothing unsafe about that, is there? <g>

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #4

P: n/a
Pete Becker wrote:
red floyd wrote:
Pete Becker wrote:
red floyd wrote:

The only options I can see are either a C-style cast to void*
(unsafe and ugly),
There's nothing unsafe about it, although it's possible (but
unlikely) that it won't give you useful information. On
POSIX-conformant platforms it's well defined.


I thought the Standard said something about function pointers being
cast to void*? Hence the comment about "unsafe".

Standard C++ doesn't allow converting a function pointer into a void*.
That doesn't mean it's "unsafe." It only means that if your compiler
allows it (which every one I use does) you might want to check the
compiler's documentation to see what it does. But any compiler that
doesn't do the obvious thing is seriously freaky.

I know g++ 3.2.3 gives me a warning when I use either static_cast or
reinterpret-cast.


Yes, that's what the standard requires. Having issued a diagnostic, the
compiler is free to do whatever the implementor chooses. If you were
writing a compiler and wanted to implement explicit conversions from
function pointers to void pointers, what would you do? (assuming the
usual architecture, where function pointers and data pointers are the
same size). There's nothing unsafe about that, is there? <g>


Agreed, the only place I can think of where sizeof(void*) != sizeof(void
(*)()) is in oddball stuff like '286 medium or compact model code. But
I was trying to be standard compliant. Given that the standard (in
theory) forbids such conversions, shouldn't they have provided a
portable way to output a generic function pointer?

Jul 23 '05 #5

P: n/a
Pete Becker wrote:
[redacted]


BTW, Pete, I'm well aware of your reputation, and who you work for, and
realize your knowledge of the Standard far exceeds mine. Please don't
take offense at my arguments :-)
Jul 23 '05 #6

P: n/a
red floyd wrote:

Agreed, the only place I can think of where sizeof(void*) != sizeof(void
(*)()) is in oddball stuff like '286 medium or compact model code. But
I was trying to be standard compliant.
I know. Mostly I was objecting to the word "unsafe." <g> Too many
programmers have learned, erroneously, that undefined behavior causes acne.
Given that the standard (in
theory)
and in fact.
forbids such conversions,
Just to drive it in: the standard requires a diagnostic. Nothing more.
Once the compiler issues a diagnostic it can do whatever the implementor
wants.
shouldn't they have provided a
portable way to output a generic function pointer?


Maybe, although it's not nearly as useful as being able to show the
address of a data object.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #7

P: n/a
red floyd wrote:
Pete Becker wrote:
[redacted]

BTW, Pete, I'm well aware of your reputation, and who you work for, and
realize your knowledge of the Standard far exceeds mine. Please don't
take offense at my arguments :-)


I didn't take offense. Sorry if I sounded like I did. <g>

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.