Conversion function problems

[Dave]

Hello all,

Can anybody help with the problem below? I'm trying to define a conversion
function that converts objects to function pointers and am getting a compile
error on the line indicated below. The compiler interprets this is a
function returning a function, which, of course is illegal... What is the
correct syntax to accomplish this?

Thanks,
Dave


#include <iostream>

using namespace std;

double foo_func(int n) {return n + 1.5;}

class foo_t
{
public:
operator double (*)(int)() {return foo_func;} // Compile error here!
};

int main()
{
foo_t f;

cout << f(12) << endl; // Expecting "13.5"...

return 0;
}

[Josephine Schafer]

Re: Conversion function problems


"Dave" <better_cs_now@ yahoo.com> wrote in message
news:vs88qhsjct 036a@news.super news.com...[color=blue]
> Hello all,
>
> Can anybody help with the problem below? I'm trying to define a conversion
> function that converts objects to function pointers and am getting a compile
> error on the line indicated below. The compiler interprets this is a
> function returning a function, which, of course is illegal... What is the
> correct syntax to accomplish this?
>
> Thanks,
> Dave
>
>
> #include <iostream>
>
> using namespace std;
>
> double foo_func(int n) {return n + 1.5;}
>
> class foo_t
> {
> public:
> operator double (*)(int)() {return foo_func;} // Compile error here!
> };
>
> int main()
> {
> foo_t f;
>
> cout << f(12) << endl; // Expecting "13.5"...
>
> return 0;
> }[/color]

Try this -
#include <iostream>

using namespace std;

double foo_func(int n) {return n + 1.5;}
typedef double (*fp)(int) ;
class foo_t
{
public:
operator fp(){return foo_func;}
};

int main()
{
foo_t f;

cout << f(12) << endl; // Expecting "13.5"...

return 0;
}

HTH,
J.Schafer

[David White]

Re: Conversion function problems

"Dave" <better_cs_now@ yahoo.com> wrote in message
news:vs88qhsjct 036a@news.super news.com...[color=blue]
> Hello all,
>
> Can anybody help with the problem below? I'm trying to define a[/color]
conversion[color=blue]
> function that converts objects to function pointers and am getting a[/color]
compile[color=blue]
> error on the line indicated below. The compiler interprets this is a
> function returning a function, which, of course is illegal... What is the
> correct syntax to accomplish this?
>
> Thanks,
> Dave
>
>
> #include <iostream>
>
> using namespace std;
>
> double foo_func(int n) {return n + 1.5;}
>
> class foo_t
> {
> public:
> operator double (*)(int)() {return foo_func;} // Compile error here![/color]

operator double (*())(int n) { return foo_func;}

DW

[David White]

Re: Conversion function problems

"David White" <no@email.provi ded> wrote in message
news:cMVwb.2670 $xm.110030@nasa l.pacific.net.a u...[color=blue][color=green]
> > class foo_t
> > {
> > public:
> > operator double (*)(int)() {return foo_func;} // Compile error[/color][/color]
here![color=blue]
>
> operator double (*())(int n) { return foo_func;}[/color]

Sorry, my compiler is playing tricks on me. I'm sure that compiled without
error once, but it won't do it now. I don't know why. However, this works:

double foo_func(int n) {return n + 1.5;}

typedef double (*ff)(int n);

class foo_t
{
public:
operator ff() { return foo_func;}
};

DW

[John Carson]

Re: Conversion function problems

"Dave" <better_cs_now@ yahoo.com> wrote in message
news:vs88qhsjct 036a@news.super news.com[color=blue]
> Hello all,
>
> Can anybody help with the problem below? I'm trying to define a
> conversion function that converts objects to function pointers and am
> getting a compile error on the line indicated below. The compiler
> interprets this is a function returning a function, which, of course
> is illegal... What is the correct syntax to accomplish this?
>
> Thanks,
> Dave
>
>
> #include <iostream>
>
> using namespace std;
>
> double foo_func(int n) {return n + 1.5;}
>
> class foo_t
> {
> public:
> operator double (*)(int)() {return foo_func;} // Compile error
> here! };
>
> int main()
> {
> foo_t f;
>
> cout << f(12) << endl; // Expecting "13.5"...
>
> return 0;
> }[/color]

Do you really want to convert objects to function pointers or do you just
want an object that acts like a function? In the latter case, you can do it
with this:

class foo_t
{
public:
double operator()(int n)
{
return n + 1.5;
}
};


--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Dave]

Re: Conversion function problems


"Josephine Schafer" <no_spam_jossch afer@hotmail.co m> wrote in message
news:bq18v2$1tk u5f$1@ID-192448.news.uni-berlin.de...[color=blue]
>
> "Dave" <better_cs_now@ yahoo.com> wrote in message
> news:vs88qhsjct 036a@news.super news.com...[color=green]
> > Hello all,
> >
> > Can anybody help with the problem below? I'm trying to define a[/color][/color]
conversion[color=blue][color=green]
> > function that converts objects to function pointers and am getting a[/color][/color]
compile[color=blue][color=green]
> > error on the line indicated below. The compiler interprets this is a
> > function returning a function, which, of course is illegal... What is[/color][/color]
the[color=blue][color=green]
> > correct syntax to accomplish this?
> >
> > Thanks,
> > Dave
> >
> >
> > #include <iostream>
> >
> > using namespace std;
> >
> > double foo_func(int n) {return n + 1.5;}
> >
> > class foo_t
> > {
> > public:
> > operator double (*)(int)() {return foo_func;} // Compile error[/color][/color]
here![color=blue][color=green]
> > };
> >
> > int main()
> > {
> > foo_t f;
> >
> > cout << f(12) << endl; // Expecting "13.5"...
> >
> > return 0;
> > }[/color]
>
> Try this -
> #include <iostream>
>
> using namespace std;
>
> double foo_func(int n) {return n + 1.5;}
> typedef double (*fp)(int) ;
> class foo_t
> {
> public:
> operator fp(){return foo_func;}
> };
>
> int main()
> {
> foo_t f;
>
> cout << f(12) << endl; // Expecting "13.5"...
>
> return 0;
> }
>
> HTH,
> J.Schafer
>
>[/color]

Thx!!! Just out of curiosity, is it possible to do this without a typedef???
I've tried a bunch of different ideas, but none work. Is it syntactically
possible to do this without a typedef, or is a typedef required? For that
matter, is a typedef ever *required*???

[Dave]

Re: Conversion function problems


"John Carson" <donaldquixote@ datafast.net.au > wrote in message
news:3fc42d34$1 @usenet.per.par adox.net.au...[color=blue]
> "Dave" <better_cs_now@ yahoo.com> wrote in message
> news:vs88qhsjct 036a@news.super news.com[color=green]
> > Hello all,
> >
> > Can anybody help with the problem below? I'm trying to define a
> > conversion function that converts objects to function pointers and am
> > getting a compile error on the line indicated below. The compiler
> > interprets this is a function returning a function, which, of course
> > is illegal... What is the correct syntax to accomplish this?
> >
> > Thanks,
> > Dave
> >
> >
> > #include <iostream>
> >
> > using namespace std;
> >
> > double foo_func(int n) {return n + 1.5;}
> >
> > class foo_t
> > {
> > public:
> > operator double (*)(int)() {return foo_func;} // Compile error
> > here! };
> >
> > int main()
> > {
> > foo_t f;
> >
> > cout << f(12) << endl; // Expecting "13.5"...
> >
> > return 0;
> > }[/color]
>
> Do you really want to convert objects to function pointers or do you just
> want an object that acts like a function? In the latter case, you can do[/color]
it[color=blue]
> with this:
>
> class foo_t
> {
> public:
> double operator()(int n)
> {
> return n + 1.5;
> }
> };
>
>
> --
> John Carson
> 1. To reply to email address, remove donald
> 2. Don't reply to email address (post here instead)
>[/color]

I am indeed specifically trying to learn how to create a coversion function
to function pointer. My goal is to learn exactly this...

[Dave]

Re: Conversion function problems


"David White" <no@email.provi ded> wrote in message
news:cMVwb.2670 $xm.110030@nasa l.pacific.net.a u...[color=blue]
> "Dave" <better_cs_now@ yahoo.com> wrote in message
> news:vs88qhsjct 036a@news.super news.com...[color=green]
> > Hello all,
> >
> > Can anybody help with the problem below? I'm trying to define a[/color]
> conversion[color=green]
> > function that converts objects to function pointers and am getting a[/color]
> compile[color=green]
> > error on the line indicated below. The compiler interprets this is a
> > function returning a function, which, of course is illegal... What is[/color][/color]
the[color=blue][color=green]
> > correct syntax to accomplish this?
> >
> > Thanks,
> > Dave
> >
> >
> > #include <iostream>
> >
> > using namespace std;
> >
> > double foo_func(int n) {return n + 1.5;}
> >
> > class foo_t
> > {
> > public:
> > operator double (*)(int)() {return foo_func;} // Compile error[/color][/color]
here![color=blue]
>
> operator double (*())(int n) { return foo_func;}
>
> DW
>
>
>[/color]

That was my next best guess too, but no go (unless it's a problem with my
compiler)!!

[John Carson]

Re: Conversion function problems

"Dave" <better_cs_now@ yahoo.com> wrote in message
news:vs8b5moq6c 73f3@news.super news.com[color=blue]
> "Josephine Schafer" <no_spam_jossch afer@hotmail.co m> wrote in message
> news:bq18v2$1tk u5f$1@ID-192448.news.uni-berlin.de...[color=green]
> >
> > Try this -
> > #include <iostream>
> >
> > using namespace std;
> >
> > double foo_func(int n) {return n + 1.5;}
> > typedef double (*fp)(int) ;
> > class foo_t
> > {
> > public:
> > operator fp(){return foo_func;}
> > };
> >
> > int main()
> > {
> > foo_t f;
> >
> > cout << f(12) << endl; // Expecting "13.5"...
> >
> > return 0;
> > }
> >
> > HTH,
> > J.Schafer
> >
> >[/color]
>
> Thx!!! Just out of curiosity, is it possible to do this without a
> typedef??? I've tried a bunch of different ideas, but none work. Is
> it syntactically possible to do this without a typedef, or is a
> typedef required? For that matter, is a typedef ever *required*???[/color]

According to Lippman's C++ Primer (3rd ed), p. 777:


"A conversion function takes the general form
operator type();
where type is replaced by a built-in type, a class type, or a typedef name.
Conversion functions in which type represents either an array or a function
type are not allowed."

This is also discussed less plainly in the C++ standard, section 12.3.2.
Apparently using function pointers without a typedef creates ambiguities in
parsing the expression.


--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Dave]

Re: Conversion function problems


"John Carson" <donaldquixote@ datafast.net.au > wrote in message
news:3fc43349@u senet.per.parad ox.net.au...[color=blue]
> "Dave" <better_cs_now@ yahoo.com> wrote in message
> news:vs8b5moq6c 73f3@news.super news.com[color=green]
> > "Josephine Schafer" <no_spam_jossch afer@hotmail.co m> wrote in message
> > news:bq18v2$1tk u5f$1@ID-192448.news.uni-berlin.de...[color=darkred]
> > >
> > > Try this -
> > > #include <iostream>
> > >
> > > using namespace std;
> > >
> > > double foo_func(int n) {return n + 1.5;}
> > > typedef double (*fp)(int) ;
> > > class foo_t
> > > {
> > > public:
> > > operator fp(){return foo_func;}
> > > };
> > >
> > > int main()
> > > {
> > > foo_t f;
> > >
> > > cout << f(12) << endl; // Expecting "13.5"...
> > >
> > > return 0;
> > > }
> > >
> > > HTH,
> > > J.Schafer
> > >
> > >[/color]
> >
> > Thx!!! Just out of curiosity, is it possible to do this without a
> > typedef??? I've tried a bunch of different ideas, but none work. Is
> > it syntactically possible to do this without a typedef, or is a
> > typedef required? For that matter, is a typedef ever *required*???[/color]
>
> According to Lippman's C++ Primer (3rd ed), p. 777:
>
>
> "A conversion function takes the general form
> operator type();
> where type is replaced by a built-in type, a class type, or a typedef[/color]
name.[color=blue]
> Conversion functions in which type represents either an array or a[/color]
function[color=blue]
> type are not allowed."
>
> This is also discussed less plainly in the C++ standard, section 12.3.2.
> Apparently using function pointers without a typedef creates ambiguities[/color]
in[color=blue]
> parsing the expression.
>
>
> --
> John Carson
> 1. To reply to email address, remove donald
> 2. Don't reply to email address (post here instead)
>[/color]


Ahh, OK, cool! Can anybody cite any other cases where a typedef is
*required* to accomplish something???

[David White]

Re: Conversion function problems

"John Carson" <donaldquixote@ datafast.net.au > wrote in message
news:3fc43349@u senet.per.parad ox.net.au...[color=blue]
> According to Lippman's C++ Primer (3rd ed), p. 777:
>
>
> "A conversion function takes the general form
> operator type();
> where type is replaced by a built-in type, a class type, or a typedef[/color]
name.[color=blue]
> Conversion functions in which type represents either an array or a[/color]
function[color=blue]
> type are not allowed."[/color]

But you can't return an array or function from any other kind of function
either, not just a conversion operator, with or without a typedef.
[color=blue]
> This is also discussed less plainly in the C++ standard, section 12.3.2.
> Apparently using function pointers without a typedef creates ambiguities[/color]
in[color=blue]
> parsing the expression.[/color]

Even if the standard doesn't allow it, I'm not convinced that the Lippman
extract has anything to do with requiring a typedef to return a function
pointer. Does he give the general form of a function as this?
type name(/*parameters*/)

which excludes the tiny fraction of functions that don't conform, such as:
double (*f())(int);

(It is just a primer, after all).

DW

[John Carson]

Re: Conversion function problems

"David White" <no@email.provi ded> wrote in message
news:vYWwb.2698 $xm.110111@nasa l.pacific.net.a u[color=blue]
> "John Carson" <donaldquixote@ datafast.net.au > wrote in message
> news:3fc43349@u senet.per.parad ox.net.au...[color=green]
> > According to Lippman's C++ Primer (3rd ed), p. 777:
> >
> >
> > "A conversion function takes the general form
> > operator type();
> > where type is replaced by a built-in type, a class type, or a
> > typedef name. Conversion functions in which type represents either
> > an array or a function type are not allowed."[/color]
>
> But you can't return an array or function from any other kind of
> function either, not just a conversion operator, with or without a
> typedef.[/color]

The 1998 standard say this in section 8.3.5, p4:

"Functions shall not have a return type of type array or function, although
they may have a return type of type pointer or reference to such things."

The following is an example that works (without even a typedef):

#include <iostream>
using namespace std;

double f0(double n)
{
return n;
}
double f1(double n)
{
return n+1;
}
double f2(double n)
{
return n+2;
}

// this is a function taking an integer argument
// and returning a pointer to a function that
// takes a double as argument and returns a double

double (*function(int x))(double)
{
if(x==1)
return f1;
else if(x==2)
return f2;
else
return f0;
}

int main()
{
cout << function(1)(9.3 )<< endl; // expect 10.3
cout << function(2)(9.3 )<< endl; // expect 11.3
return 0;
}


--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[David White]

Re: Conversion function problems

"John Carson" <donaldquixote@ datafast.net.au > wrote in message
news:3fc44eb0@u senet.per.parad ox.net.au...[color=blue]
> "David White" <no@email.provi ded> wrote in message
> news:vYWwb.2698 $xm.110111@nasa l.pacific.net.a u[color=green]
> > But you can't return an array or function from any other kind of
> > function either, not just a conversion operator, with or without a
> > typedef.[/color]
>
> The 1998 standard say this in section 8.3.5, p4:
>
> "Functions shall not have a return type of type array or function, although
> they may have a return type of type pointer or reference to such things."
>
> The following is an example that works (without even a typedef):
>
> #include <iostream>
> using namespace std;
>
> double f0(double n)
> {
> return n;
> }
> double f1(double n)
> {
> return n+1;
> }
> double f2(double n)
> {
> return n+2;
> }
>
> // this is a function taking an integer argument
> // and returning a pointer to a function that
> // takes a double as argument and returns a double
>
> double (*function(int x))(double)[/color]

And in my previous post, this was a function returning a pointer to a function taking an int
parameter and returning a double:
double (*f())(int);
[color=blue]
> {
> if(x==1)
> return f1;
> else if(x==2)
> return f2;
> else
> return f0;
> }
>
> int main()
> {
> cout << function(1)(9.3 )<< endl; // expect 10.3
> cout << function(2)(9.3 )<< endl; // expect 11.3
> return 0;
> }[/color]

I'm not sure what your point is. The statement you seem to have replied to remains the case,
i.e., that you can't return a function or an array from anything.

DW

[John Carson]

Re: Conversion function problems

"David White" <no@email.provi ded> wrote in message
news:85_wb.2705 $xm.110713@nasa l.pacific.net.a u[color=blue]
>
> I'm not sure what your point is. The statement you seem to have
> replied to remains the case, i.e., that you can't return a function
> or an array from anything.
>[/color]

Well...I wasn't sure what your point was. I thought (though I wasn't sure)
that you were disputing that there was a special need for typedefs where
conversion operators are concerned. I was taking it as given that we were
interested in the return of pointers to functions rather than the return of
functions.

I now think that you are simply disputing my interpretation of the Lippman
quote:

"A conversion function takes the general form
operator type();
where type is replaced by a built-in type, a class type, or a typedef name.
Conversion functions in which type represents either an array or a function
type are not allowed."

You will note that Lippman makes no reference at all to pointers, yet a
conversion operator can certainly return, say, a pointer to a class type.
Accordingly, I interpreted all his statements about types as including
pointers to those types. Thus I interpret him as saying that a conversion
operator cannot return an explicit function pointer but can return a typedef
name for a function pointer.

I admit that this interpretation is arguable, but it does seem to conform to
what I observe of compiler behaviour.

--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[David White]

Re: Conversion function problems

"John Carson" <donaldquixote@ datafast.net.au > wrote in message
news:3fc47cb2$1 @usenet.per.par adox.net.au...[color=blue]
> "David White" <no@email.provi ded> wrote in message
> news:85_wb.2705 $xm.110713@nasa l.pacific.net.a u[color=green]
> >
> > I'm not sure what your point is. The statement you seem to have
> > replied to remains the case, i.e., that you can't return a function
> > or an array from anything.
> >[/color]
>
> Well...I wasn't sure what your point was. I thought (though I wasn't sure)
> that you were disputing that there was a special need for typedefs where
> conversion operators are concerned. I was taking it as given that we were
> interested in the return of pointers to functions rather than the return[/color]
of[color=blue]
> functions.
>
> I now think that you are simply disputing my interpretation of the Lippman
> quote:[/color]

That's right.
[color=blue]
> "A conversion function takes the general form
> operator type();
> where type is replaced by a built-in type, a class type, or a typedef[/color]
name.[color=blue]
> Conversion functions in which type represents either an array or a[/color]
function[color=blue]
> type are not allowed."
>
> You will note that Lippman makes no reference at all to pointers, yet a
> conversion operator can certainly return, say, a pointer to a class type.
> Accordingly, I interpreted all his statements about types as including
> pointers to those types. Thus I interpret him as saying that a conversion
> operator cannot return an explicit function pointer but can return a[/color]
typedef[color=blue]
> name for a function pointer.[/color]

Yes, I'm not as sure about my interpretation now. Even a primer should get
it right, but I was unfairly implying that it might be a little sloppy.

DW