In article <3A1948F7.2BB9@free.fr>,
  Valentin Bonnard <Valentin.Bonnard@free.fr> wrote:
> James.Kanze@dresdner-bank.com wrote:

> > In article <8v3u95$um1$1@nnrp1.deja.com>,
> >   wmm@fastdial.net wrote:

> > > That requires a reinterpret_cast, 5.2.10p6:

> > >     A pointer to a function can be explicitly converted to a
> > >     pointer to a function of a different type.

> > Which is what I was afraid of?

> That's anoying.

> > The problem is that normally, reinterpret_cast is a signal for
> > something unportable.

> According to popular wisdom, yes. But popular wisdom is often wrong
> (and people are often clueless).

In this case, my "popular wisdom" is based on 5.2.10/3: "The mapping
performed by reinterpret_cast is implementation defined."  Sounds like
something unportable to me.

> I have used reinterpret_cast when doing ugly portable (and
> time/space efficient) tricks.

> > In order of some of the functions in the C library to work
> > correctly, however, it must be guaranteed portable to convert an
> > arbitrary pointer to function to void (*)() and back without loss
> > of value.

> ???

> (Which functions ? I don't know of any.))

Hmmm.  I was thinking of qsort and bsearch, but I see that they do
have specific signatures.

> > It's really a minor point, but perhaps it would be a good idea to
> > allow converion of pointers to functions to and from void (*)() by
> > means of a static_cast.  For all practical purposes, void (*)() is
> > the void function pointer.

> It has already been discussed here.

> I proposed the invention of a universal function type, to avoid
> overloading ``void (*)()''. (Even if I understand that overloading
> types goes well in the C/C++ tradition, with char meaning ``a member
> of the execution character set'', ``the smallest addressable unit of
> memory, used to implement memcopy'' and ``the smallest integer type,
> whose signeness is implementation defined''.)

> This is a C/C++ issue (and probably more a C one). The same solution
> could be adopted in both languages (perhaps w/o the static_cast
> syntax in C).

The same solution SHOULD be adopted in both languages (except, of
course, for the static_cast syntax).

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James.Kanze@dresdner-bank.com wrote:
>=20
> In article <8v3u95$um1$1@nnrp1.deja.com>,
>   wmm@fastdial.net wrote:

> > That requires a reinterpret_cast, 5.2.10p6:
>=20
> >     A pointer to a function can be explicitly converted to a
> >     pointer to a function of a different type.
>=20
> Which is what I was afraid of?=20

That's anoying.

> The problem is that normally, reinterpret_cast is a signal=20
> for something unportable.=20

According to popular wisdom, yes. But popular wisdom is often=20
wrong (and people are often clueless).

I have used reinterpret_cast when doing ugly portable (and=20
time/space efficient) tricks.

> In order of
> some of the functions in the C library to work correctly, however, it
> must be guaranteed portable to convert an arbitrary pointer to
> function to void (*)() and back without loss of value.

???

(Which functions=A0 ? I don't know of any.))

> It's really a minor point, but perhaps it would be a good idea to
> allow converion of pointers to functions to and from void (*)() by
> means of a static_cast.  For all practical purposes, void (*)() is the
> void function pointer.

It has already been discussed here.

I proposed the invention of a universal function type, to avoid=20
overloading ``void (*)()''. (Even if I understand that overloading=20
types goes well in the C/C++ tradition, with char meaning ``a=20
member of the execution character set'', ``the smallest addressable=20
unit of memory, used to implement memcopy'' and ``the smallest integer=20
type, whose signeness is implementation defined''.)

This is a C/C++ issue (and probably more a C one). The same=20
solution could be adopted in both languages (perhaps w/o the=20
static_cast syntax in C).

--=20

Valentin Bonnard

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]