In article <3869D4C1.D965AE7B@cup.hp.com>,
  Alain Miniussi <alainm@cup.hp.com> wrote:
> "nimel@my-deja.com" wrote:

[...]

> > My question is if the following workaround will lead to defined
> > behavior:
> >
> > typedef void (AnyFptr*)();
> > AnyFptr fptr2 = reinterpret_cast<AnyFptr>(f); // Is this ok?

[...]

> > reinterpret_cast<int(*)(int)>(fptr2)(42);  // And this?

[...]

> > Finally, if the above is valid, is there a better way to
> > write it? Perhaps something like:
> >
> > struct AnyFunctionPtr
> > {
> >   typedef void (Ptr*)();
> >   Ptr m_func;
> >
> >   template <???>
> >   AnyFunctionPtr(??? x); // Accepts only function pointers
> >
> >   operator cast_back() const; // Possible? Syntax? template?
> > };
>
> I don't see what you're trying to do. Do you need to store
> different function pointer type in a uniform way ? what
> restrictions exist wrt the functions prototypes ? what
> kind of tradeoff betwen (speed|space)eficiency and security
> are you ready to do ? how do you find back the real function
> signature ? etc... if your design append to be correct,
> you probably need some form of Command design pattern but
> I can't say more without additional information.

I'm not sure about what I wan't to do, except getting rid of the
ugly reinterpret_cast, especially when casting to the void*
equivalent type. Just like I can convert any ordinary pointer
to void*, I want to be able to convert any function pointer to
the AnyFunctionPtr type without the explicit cast.

This is not something I wan't to do for a real system, I was
just asking the question to improve my understanding of the
C++ language.

/Niklas Mellin


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

nimel@my-deja.com wrote:
>
> If I remember correctly, the standard forbids casting from a function
> pointer to void*. Then the following code is not compliant:
>
> int f(int x) { return 0; }
>
> void* fptr = f;  // Error, cannot cast function pointer to void*
> // Btw, should the compiler complain about the line above?
>
> reinterpret_cast<int(*)(int)>(ftpr)(42); // Will static_cast do?

Sure - section 5.2.10 says that through reinterpret_cast<>, "A pointer
to a function can be explicitly converted to a pointer to a function of
a different type."

The same is not true of static_cast<>.

> My question is if the following workaround will lead to defined
> behavior:
>
> typedef void (AnyFptr*)();
> AnyFptr fptr2 = reinterpret_cast<AnyFptr>(f); // Is this ok?

Sure.

> reinterpret_cast<int(*)(int)>(fptr2)(42);  // And this?

Yes.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"nimel@my-deja.com" wrote:

>
> If I remember correctly, the standard forbids casting from a function
> pointer to void*.

Right (see 4 for implicit convertion and 5 for explicit)

> Then the following code is not compliant:
>
> int f(int x) { return 0; }
>
> void* fptr = f;  // Error, cannot cast function pointer to void*
> // Btw, should the compiler complain about the line above?

Yes.

> reinterpret_cast<int(*)(int)>(ftpr)(42); // Will static_cast do?

static_cast wont do, and I don't think reinterpret_cast will (5.2.10,
5.2.10/4 seems to allow it with an intermediate integral type, since
"pointer" is supposed to stands for "pointer to object or function").

> My question is if the following workaround will lead to defined
> behavior:
>
> typedef void (AnyFptr*)();
> AnyFptr fptr2 = reinterpret_cast<AnyFptr>(f); // Is this ok?

Yes (5.2.10/6)

> reinterpret_cast<int(*)(int)>(fptr2)(42);  // And this?

yes (still 5.2.10/6)

> Finally, if the above is valid, is there a better way to
> write it? Perhaps something like:
>
> struct AnyFunctionPtr
> {
>   typedef void (Ptr*)();
>   Ptr m_func;
>
>   template <???>
>   AnyFunctionPtr(??? x); // Accepts only function pointers
>
>   operator cast_back() const; // Possible? Syntax? template?
> };

I don't see what you're trying to do. Do you need to store
different function pointer type in a uniform way ? what
restrictions exist wrt the functions prototypes ? what
kind of tradeoff betwen (speed|space)eficiency and security
are you ready to do ? how do you find back the real function
signature ? etc... if your design append to be correct,
you probably need some form of Command design pattern but
I can't say more without additional information.

Alain


 Sent via Deja.com http://www.deja.com/
 Before you buy.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

If I remember correctly, the standard forbids casting from a function
pointer to void*. Then the following code is not compliant:

int f(int x) { return 0; }

void* fptr = f;  // Error, cannot cast function pointer to void*
// Btw, should the compiler complain about the line above?

reinterpret_cast<int(*)(int)>(ftpr)(42); // Will static_cast do?

My question is if the following workaround will lead to defined
behavior:

typedef void (AnyFptr*)();
AnyFptr fptr2 = reinterpret_cast<AnyFptr>(f); // Is this ok?

reinterpret_cast<int(*)(int)>(fptr2)(42);  // And this?

Finally, if the above is valid, is there a better way to
write it? Perhaps something like:

struct AnyFunctionPtr
{
  typedef void (Ptr*)();
  Ptr m_func;

  template <???>
  AnyFunctionPtr(??? x); // Accepts only function pointers

  operator cast_back() const; // Possible? Syntax? template?
};

/Niklas Mellin


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]