Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > A good use of fn ptrs?

Reply
Thread Tools

A good use of fn ptrs?

 
 
Protoman
Guest
Posts: n/a
 
      12-17-2005
Is this a good use of fn ptrs?

#include <iostream>
#include <cstdlib>
using namespace std;

typedef void (*v_v_fptr)();

void Error(){cout << "Error" << endl;}

void Success(){cout << "Success" << endl;}

v_v_fptr select(bool arg){if(arg==true)return Success; else return
Error;}

int main()
{
bool val;
cout << "1|0?: " << endl;
cin >> val;
v_v_fptr ptr=select(val);
ptr();
system("PAUSE");
return 0;
}

Or should I use fn objs instead? Thanks!!!

 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      12-17-2005
Protoman wrote:
> Is this a good use of fn ptrs?
>

....
>
> Or should I use fn objs instead? Thanks!!!
>


fn objs are more extensible and you loose nothing.
 
Reply With Quote
 
 
 
 
Protoman
Guest
Posts: n/a
 
      12-17-2005
How would I make it use fn objs? Like this:

class select
{
public:
v_v_fptr operator()(bool val){if(val==true)return Success;else return
Error;}
};
//...
v_v_fptr ptr=select()(val);
ptr();

Could you help? Thanks!!!

 
Reply With Quote
 
Viktor Prehnal
Guest
Posts: n/a
 
      12-17-2005
I am programming for more that 10 years in C++ but I have not seen such
a way of error checking. But syntatically it is correct. If I were you I
would use exceptions.


Protoman wrote:
> Is this a good use of fn ptrs?
>
> #include <iostream>
> #include <cstdlib>
> using namespace std;
>
> typedef void (*v_v_fptr)();
>
> void Error(){cout << "Error" << endl;}
>
> void Success(){cout << "Success" << endl;}
>
> v_v_fptr select(bool arg){if(arg==true)return Success; else return
> Error;}
>
> int main()
> {
> bool val;
> cout << "1|0?: " << endl;
> cin >> val;
> v_v_fptr ptr=select(val);
> ptr();
> system("PAUSE");
> return 0;
> }
>
> Or should I use fn objs instead? Thanks!!!
>

 
Reply With Quote
 
Protoman
Guest
Posts: n/a
 
      12-17-2005
Why use exceptions? This is just an examp; in a real prog, I'd use it
to determine what fn to call based on the val of a var.

 
Reply With Quote
 
Viktor Prehnal
Guest
Posts: n/a
 
      12-17-2005
Protoman wrote:
> Why use exceptions? This is just an examp; in a real prog, I'd use it
> to determine what fn to call based on the val of a var.
>

exceptions divide execution code from error checking code, that's the
reason why they were created....
 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      12-17-2005
Viktor Prehnal wrote:
> Protoman wrote:
>
>> Why use exceptions? This is just an examp; in a real prog, I'd use it
>> to determine what fn to call based on the val of a var.
>>

> exceptions divide execution code from error checking code, that's the
> reason why they were created....


Is attempting to open a file that is not there an exception or an error?
 
Reply With Quote
 
Ben Pope
Guest
Posts: n/a
 
      12-18-2005
Gianni Mariani wrote:
> Viktor Prehnal wrote:
>> Protoman wrote:
>>
>>> Why use exceptions? This is just an examp; in a real prog, I'd use it
>>> to determine what fn to call based on the val of a var.
>>>

>> exceptions divide execution code from error checking code, that's the
>> reason why they were created....

>
> Is attempting to open a file that is not there an exception or an error?


If the file was expected to exist, or if the file was necessary for the
program to operate, then almost certainly an exception.

If the filename was entered by the user, then probably an error,
although that error could easily be propagated up the stack by an
exception...

As is often the case, it depends!

Ben Pope
--
I'm not just a number. To many, I'm known as a string...
 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      12-18-2005
Ben Pope wrote:
> Gianni Mariani wrote:

....
>> Is attempting to open a file that is not there an exception or an error?

>
>
> If the file was expected to exist, or if the file was necessary for the
> program to operate, then almost certainly an exception.
>
> If the filename was entered by the user, then probably an error,
> although that error could easily be propagated up the stack by an
> exception...
>
> As is often the case, it depends!


So now, exceptions are glorified cross function gotos. Probably not a
good thing.

I was on the fence for quite a while on exceptions and I'm now leaning
on a very minimal usage of exceptions. Opening a file is in almost
every case I have come across, not a case for using exceptions, even if
you expect the file to exist.

It's also very unfortunate that exception specifiers are dynamically
handled rather than allowing the compiler to do a static analysis.

Multithreaded code is almost always impossible to manage using exceptions.

I'm not trying to say exceptions are bad, I'm saying they're very
limited in utility. Also, I find it a fallacy that code is easier to
write. Handling exceptions correctly can get quite involved making the
code much more difficult to write if you have to write try/catch blocks
everywhere.

Anyhow, I'm sure that there are plenty o people who would debate this,
and I'm looking forward to a constructive one.
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      12-18-2005
Gianni Mariani wrote:

> Ben Pope wrote:
>> Gianni Mariani wrote:

> ...
>>> Is attempting to open a file that is not there an exception or an error?

>>
>>
>> If the file was expected to exist, or if the file was necessary for the
>> program to operate, then almost certainly an exception.
>>
>> If the filename was entered by the user, then probably an error,
>> although that error could easily be propagated up the stack by an
>> exception...
>>
>> As is often the case, it depends!

>
> So now, exceptions are glorified cross function gotos. Probably not a
> good thing.


Well, that is what throw and catch do: transfer control to the handler
unwinding the stack as much as necessary to get to the handlers context. I
can see two main differences to goto: (a) goto is a little less restricted
in where it can take you, but (b) the target of the jump is always known,
whereas a throw can take you to a place that you do not know in advance.


> I was on the fence for quite a while on exceptions and I'm now leaning
> on a very minimal usage of exceptions. Opening a file is in almost
> every case I have come across, not a case for using exceptions, even if
> you expect the file to exist.


I tend to advocate throwing whenever the construction of an object fails.
The reason is that I usually do not see a good way of dealing with
half-constructed objects. So, failure to claim a resource is, in my book,
always a good candidate for a throw().


> It's also very unfortunate that exception specifiers are dynamically
> handled rather than allowing the compiler to do a static analysis.
>
> Multithreaded code is almost always impossible to manage using exceptions.


Could you elaborate on this one. I have no experience in multithreaded
programming, so I do not really understand what you are refering to.


> I'm not trying to say exceptions are bad, I'm saying they're very
> limited in utility. Also, I find it a fallacy that code is easier to
> write. Handling exceptions correctly can get quite involved making the
> code much more difficult to write if you have to write try/catch blocks
> everywhere.


The unfortunate thing is that you have to beware of exceptions whether you
use them or not: code beyond your control may throw just as well. In the
context of another thread it recently dawned upon me that very innocent
looking code can actually leak resources when exceptions enter the picture:

template < typename T >
class X {

T* data;

public:

X ( T const & t )
: data ( new T )
{
*data = t; // this leaks the pointer if the assignment throws.
}

}; // X

Better:

template < typename T >
class X {

T* data;

public:

X ( T const & t )
: data ( new T( t ) )
{}

}; // X

The upshot is: you really have to go through your code thinking "this line
might throw, what happens" at every single line you encounter. I find that
very hard, indeed.


Best regards

Kai-Uwe Bux
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is a good free anti-virus is good to use? Robert Computer Support 7 02-23-2007 01:14 PM
Good slide scanning service vs. good slide scanner for Do-It-Yourself? LAshooter Digital Photography 0 06-25-2005 07:14 AM
Signs are good, but WAN no good =?Utf-8?B?bmV0bnV0?= Wireless Networking 2 08-21-2004 12:41 PM
JLO situation+ why fastglass is good+DSLR is good Hugo Drax Digital Photography 0 01-17-2004 11:41 PM
Not even a newbee. Good at school course. please advise good start sikka noel C++ 8 08-05-2003 06:43 AM



Advertisments