Brian McNamara! <vaps4bm@prism.gatech.edu> schrieb in im Newsbeitrag:
8kjrk7$33o$1@news-int.gatech.edu...
> It recently occurred to me that there are functions that you can call,
> but that you cannot take a pointer to, even if you know their signature.
> This is a consequence of namespaces, Koenig lookup, and (maybe) overload
> resolution.  Here is a short example:
>
>    namespace N {
>       class Foo {};
>       void print( Foo ) {}
>    }
>
>    void print( int ) {}
>
>    template <class T>     // T should be a "printable"
>    struct Bar {           // that is, print(a_t_obj) should be legal
>       void f() { T x; print( x ); }
>       void g() {
>          T x;
>          void (*f)( T ) = &print;
>          f(x);
>       }
>    };
>
>    int main() {
>       Bar<int> ok;
>       ok.f();
>       ok.g();
>       Bar<N::Foo> bad;
>       bad.f();          // ok, Koenig lookup to the rescue
>       bad.g();          // eep!
>    }
>
> The point I wish to illustrated is that, within the template class Bar,
> I can _call_ print, but I cannot take its address.  This is because
> taking the address seems to require knowing what namespace the function
> is defined in (which is unreasonable in the template context).  However,
> Koenig lookup makes the actual call allowable.
>
> My question: is this asymmetry "by design", or is it an accidental
> omission in the standard?  If it is not intended, I expect there is
> probably some way to have Koenig lookup "kick in" during
> pointer-to-function overload resolution which rectifies it.
>

'Koenig Lookup' seems only to be defined to the usage of an unqualified name
in an function call, but really can't see why KL shouldn't also be used in
[over.over] since its basically the same thing: Determination of the
function's address, which is to be called in the one and stored in the other
place.

Well, only basically, since the function call lookup has also to consider
conversions in its matches, but this makes the overload resolution in
address taking even more simple.

I'd rather be able to specifiy the signature of an function name, so that I
could write:

&print(Foo)

or

using N::print(Foo);

---
Marco Manfredini




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

It recently occurred to me that there are functions that you can call,
but that you cannot take a pointer to, even if you know their signature.
This is a consequence of namespaces, Koenig lookup, and (maybe) overload
resolution.  Here is a short example:

   namespace N {
      class Foo {};
      void print( Foo ) {}
   }

   void print( int ) {}

   template <class T>     // T should be a "printable"
   struct Bar {           // that is, print(a_t_obj) should be legal
      void f() { T x; print( x ); }
      void g() {
         T x;
         void (*f)( T ) = &print;
         f(x);
      }
   };

   int main() {
      Bar<int> ok;
      ok.f();
      ok.g();
      Bar<N::Foo> bad;
      bad.f();          // ok, Koenig lookup to the rescue
      bad.g();          // eep!
   }

The point I wish to illustrated is that, within the template class Bar,
I can _call_ print, but I cannot take its address.  This is because
taking the address seems to require knowing what namespace the function
is defined in (which is unreasonable in the template context).  However,
Koenig lookup makes the actual call allowable.

My question: is this asymmetry "by design", or is it an accidental
omission in the standard?  If it is not intended, I expect there is
probably some way to have Koenig lookup "kick in" during
pointer-to-function overload resolution which rectifies it.

--
Brian McNamara

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