On Sun, 19 Nov 2000 21:57:59 GMT, Tom wrote:
> And it turns out that Scott wrote the preface/intro to Herb's book,
> which I should buy really. The small C++ world...

Yes, you really should buy it :-) As a point of clarification, I wrote the
book's Foreword, but Herb wrote the Preface and everything else in the
book.  (The book doesn't have an Introduction, but it does have an
Afterword.)

I know that the difference between a Foreword, a Preface, and an
Introduction isn't important to most readers, but authors have to agonize
over what goes where, so I suspect that Herb won't object if I set the
record straight :-)

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

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

I believe the correct thing to do is to use a static_cast

static_cast<char (*)(char, locale)>(std::toupper)

This will pick out the correct version of an overloaded function without
causing a dangerous reinterpret_cast. There is no need for a
"distinguish_cast" in C++, although you may argue that it is a better name
for this task.

Daryle Walker <dwalker07@snet.net.invalid> wrote in message
news:1ek25it.q22d5l1dkw35jN%dwalker07@snet.net.invalid...
> I've seen code occasionally that uses a cast to pick out one of several
> function overloads.  Something like:
>
> (char (*)(char, locale))std::toupper
>
> to force the compiler to use the C++ version of toupper, instead of the
> C version.  Not only is this use of a cast obsure, it can lead to an
> erroronus reinterpret_cast if there isn't a compatible object with the
> given name.  Maybe we can explicitly give this use a "distinguish_cast"?
>
> --
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> dwalker07 AT snet DOT net
>
> ---
> [ 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.     ]
>


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

Tom <the_wid@my-deja.com> wrote:

> Previously, Daryle Walker wrote in comp.std.c++:
> > I've seen code occasionally that uses a cast to pick out one of several
> > function overloads.  Something like:

> > (char (*)(char, locale))std::toupper

> > to force the compiler to use the C++ version of toupper, instead of the
> > C version.  Not only is this use of a cast obsure, it can lead to an
> > erroronus reinterpret_cast if there isn't a compatible object with the
> > given name.  Maybe we can explicitly give this use a "distinguish_cast"?

> Won't static_cast work fine for the above? No need to use the C style
> cast, and no need for a new cast.
[SNIP example]

I think the main problem isn't what kind of cast to use, but that is it
_not_ really a cast at all!  The casting is a kludge to pick one version
out of several overloads.  Nothing really needs to be converted.  My
suggestion just makes the kludge more obvious, and minimizes accidental
reinterpret_casts.  We should really have a brand new non-cast construct
to solve this.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

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

Previously, Daryle Walker wrote in comp.std.c++:
>
> I think the main problem isn't what kind of cast to use, but that is it
> _not_ really a cast at all!  The casting is a kludge to pick one version
> out of several overloads.  Nothing really needs to be converted.  My
> suggestion just makes the kludge more obvious, and minimizes accidental
> reinterpret_casts.  We should really have a brand new non-cast construct
> to solve this.

This is really a programmer education issue - Don't use C style casts! I think it's one of the first points in Scott Meyer's Exceptional C++, but, alas, not everyone's read that.

static_cast avoids accidental reinterpret_casts. I don't understand why it's necessary to add a new keyword. If you really want to show in your code where you are distinguishing overloads rather than casting, then the following might help:

#define distinguish_overload static_cast

but if you see static_cast<function type>(&function) then what else could it mean but an overload choice?

Tom

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

Didn't someone suggest a week or to back that the correct way to
do this is

    &std::toupper(char, locale)

?

That is, you can leave out the cast, because you can specify the
precise overload that you want by filling in arguments.

And if I'm talking complete drivel, wouldn't this be a better
resolution to the problem than a new kind of cast?

"Daryle Walker" <dwalker07@snet.net.invalid> wrote...
 > I've seen code occasionally that uses a cast to pick out one of several
> function overloads.  Something like:
>
 > (char (*)(char, locale))std::toupper
>
 > to force the compiler to use the C++ version of toupper, instead of the
> C version.  Not only is this use of a cast obsure, it can lead to an
> erroronus reinterpret_cast if there isn't a compatible object with the
> given name.  Maybe we can explicitly give this use a "distinguish_cast"?


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

In article <Voyager.001116185354.5431332D@administrator.co.uk>,
  the_wid@my-deja.com wrote:

> but if you see static_cast<function type>(&function) then what else
> could it mean but an overload choice?

Good question.  According to 5.2.9, static_cast isn't legal for a
pointer to function type anyway, or at least I can't find it.  On the
other hand, 13.4 gives 5.2.9 as a reference, so it was obviously
intended there that it be legal.

Another question is how you cast a function pointer to void (*)() (the
unofficial void pointer for functions) using the new style casts.

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

In article <8v3lej$mk3$1@nnrp1.deja.com>,
  James.Kanze@dresdner-bank.com wrote:
> In article <Voyager.001116185354.5431332D@administrator.co.uk>,
>   the_wid@my-deja.com wrote:
>
> > but if you see static_cast<function type>(&function) then what else
> > could it mean but an overload choice?
>
> Good question.  According to 5.2.9, static_cast isn't legal for a
> pointer to function type anyway, or at least I can't find it.  On the
> other hand, 13.4 gives 5.2.9 as a reference, so it was obviously
> intended there that it be legal.

That falls under 5.2.9p2:

    An expression e can be explicitly converted to a type T
    using a static_cast of the form static_cast<T>(e) if the
    declaration    T t(e);    is well-formed,

If the function type in the static_cast is the same as the
function type of the expression (after overload resolution),
the declaration is fine and so is the static_cast.

> Another question is how you cast a function pointer to void (*)() (the
> unofficial void pointer for functions) using the new style casts.

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.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


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:
>
> In article <Voyager.001116185354.5431332D@administrator.co.uk>,
>   the_wid@my-deja.com wrote:
>
> > but if you see static_cast<function type>(&function) then what else
> > could it mean but an overload choice?
>
> Good question.  According to 5.2.9, static_cast isn't legal for a
> pointer to function type anyway, or at least I can't find it.  On the
> other hand, 13.4 gives 5.2.9 as a reference, so it was obviously
> intended there that it be legal.

Huh?  5.2.9 talks about "T" pretty generically without limitting it to
any particular type (to include pointers to functions, and pointers
to members).  Paragraph 2 says you can use static_cast to make an
explicit conversion of an expression e to type T if the declaration
T t(e) would be valid.

It then says OTHERWISE one of the conversions below (which enumerates
all the ones you were probably looking at).  Most of these conversions
invert one of the conversions that paragraph 2 would permit.

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

In article <Voyager.001116185354.5431332D@administrator.co.uk>, Tom
<the_wid@my-deja.com> writes
>This is really a programmer education issue - Don't use C style casts! I think
>it's one of the first points in Scott Meyer's Exceptional C++, but, alas, not
>everyone's read that.

I am sure you did not intend to hurt Herb Sutter's feelings and he is a
very forgiving person, and I doubt that Scott will be too offended at
being described as the author of that book:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

"Ken Hagan"  wrote:

> Didn't someone suggest a week or to back that the correct way to
> do this is
>
>     &std::toupper(char, locale)
>
> ?

That would have made for a cleaner syntax.

I think that the committee felt that the need to disambiguate
between overloaded functions was rare and that one (ugly) way
to disambiguate was enough.

Perhaps, if people experience a real need, the syntax you
describe can make into the next C++ revision. Until, we must
use casts.

--

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

James.Kanze@dresdner-bank.com wrote:
> In article <Voyager.001116185354.5431332D@administrator.co.uk>,
>   the_wid@my-deja.com wrote:
>
>> but if you see static_cast<function type>(&function) then what else
>> could it mean but an overload choice?
>
> Good question.  According to 5.2.9, static_cast isn't legal for a
> pointer to function type anyway, or at least I can't find it.

What are you looking for   ? The string ``pointer to function''   ?

5.2.9 doesn't mention function pointers, and doesn't need to.

A static_cast can perform implicit conversions, and this is
what we want. static_cast canot be used to convert from one
function type to another -- also what the_wid@my-deja.com
said.

> On the
> other hand, 13.4 gives 5.2.9 as a reference, so it was obviously
> intended there that it be legal.

Indeed.

> Another question is how you cast a function pointer to void (*)() (the
> unofficial void pointer for functions) using the new style casts.

reinterpret_cast (see 5.2.10/6).

--

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

I've seen code occasionally that uses a cast to pick out one of several
function overloads.  Something like:

(char (*)(char, locale))std::toupper

to force the compiler to use the C++ version of toupper, instead of the
C version.  Not only is this use of a cast obsure, it can lead to an
erroronus reinterpret_cast if there isn't a compatible object with the
given name.  Maybe we can explicitly give this use a "distinguish_cast"?

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

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

Previously, Daryle Walker wrote in comp.std.c++:
> I've seen code occasionally that uses a cast to pick out one of several
> function overloads.  Something like:
>
> (char (*)(char, locale))std::toupper
>
> to force the compiler to use the C++ version of toupper, instead of the
> C version.  Not only is this use of a cast obsure, it can lead to an
> erroronus reinterpret_cast if there isn't a compatible object with the
> given name.  Maybe we can explicitly give this use a "distinguish_cast"?

Won't static_cast work fine for the above? No need to use the C style cast, and no need for a new cast.

#include <cstdio>
#include <cctype>
//#include <locale> shouldn't pull in locale,
// hence stdio above rather than iostream

class locale
{
public:
 locale()
 {
  using namespace std;
  printf("locale()\n");
 }
};

int main(int argc, char* argv[]) {
 using namespace std;

 //printf("%c\n", static_cast<char (*)(char, locale const&)>
 //       (&toupper)
 //        ('a', locale()));
 printf("%c\n", ((char (*)(char, locale const&))(&toupper))
         ('a', locale()));
}

The above compiles, but is of course undefined behaviour (it actually prints
locale()
A
on gcc, but that's within the remit of undefined behaviour!)

Now, swap the two printfs, and it doesn't compile, complaining about converting function types.

Tom

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

On Fri, 17 Nov 2000 20:24:13 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

>In article <Voyager.001116185354.5431332D@administrator.co.uk>, Tom
><the_wid@my-deja.com> writes
>>This is really a programmer education issue - Don't use C style casts! I think
>>it's one of the first points in Scott Meyer's Exceptional C++, but, alas, not
>>everyone's read that.
>
>I am sure you did not intend to hurt Herb Sutter's feelings and he is a
>very forgiving person, and I doubt that Scott will be too offended at
>being described as the author of that book:)

Whoops! I looked in a book shop on Saturday, and it turns out the book
I meant was Scott Meyer's "More Effective C++". He just says to prefer
C++ style casts, but I can think of no normal situation to use a
C-style cast at all!

And it turns out that Scott wrote the preface/intro to Herb's book,
which I should buy really. The small C++ world...

Tom

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

In article <8v3u95$um1$1@nnrp1.deja.com>,
  wmm@fastdial.net wrote:
> In article <8v3lej$mk3$1@nnrp1.deja.com>,
>   James.Kanze@dresdner-bank.com wrote:
> > In article <Voyager.001116185354.5431332D@administrator.co.uk>,
> >   the_wid@my-deja.com wrote:

> > > but if you see static_cast<function type>(&function) then what
> > > else could it mean but an overload choice?

> > Good question.  According to 5.2.9, static_cast isn't legal for a
> > pointer to function type anyway, or at least I can't find it.  On
> > the other hand, 13.4 gives 5.2.9 as a reference, so it was
> > obviously intended there that it be legal.

> That falls under 5.2.9p2:

>     An expression e can be explicitly converted to a type T
>     using a static_cast of the form static_cast<T>(e) if the
>     declaration    T t(e);    is well-formed,

> If the function type in the static_cast is the same as the function
> type of the expression (after overload resolution), the declaration
> is fine and so is the static_cast.

So obvious that I missed it:-).  I skipped over the sentence because
there are no legal implicit conversions between pointers to functions,
but of course, in this case, there is no conversion involved.

> > Another question is how you cast a function pointer to void (*)()
> > (the unofficial void pointer for functions) using the new style
> > casts.

> 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?  The problem is that normally,
reinterpret_cast is a signal for something unportable.  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.

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.


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

In article <8v3ssl$mvv$1@nef.ens.fr>,
  Valentin.Bonnard@free.fr (Valentin Bonnard) wrote:
> James.Kanze@dresdner-bank.com wrote:
> > In article <Voyager.001116185354.5431332D@administrator.co.uk>,
> >   the_wid@my-deja.com wrote:

> >> but if you see static_cast<function type>(&function) then what else
> >> could it mean but an overload choice?

> > Good question.  According to 5.2.9, static_cast isn't legal for a
> > pointer to function type anyway, or at least I can't find it.

> What are you looking for   ? The string ``pointer to function''   ?

> 5.2.9 doesn't mention function pointers, and doesn't need to.

> A static_cast can perform implicit conversions, and this is what we
> want. static_cast canot be used to convert from one function type to
> another -- also what the_wid@my-deja.com said.

What we want, of course, is no conversion.  I skipped the part about
implicit conversions because there are no implicit conversions between
pointers to functions, and they don't fall under any of the explicitly
enumerated cases either.  On the other hand, T->T (the identity
conversion) is implicit for all types, including pointers to
functions.  Which is the point I overlooked.


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:
[...]
> 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 are those?

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

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