A good use of fn ptrs?

[Protoman]

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==tr ue)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!!!

[Gianni Mariani]

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.

[Protoman]

How would I make it use fn objs? Like this:

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

Could you help? Thanks!!!

[Viktor Prehnal]

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==tr ue)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!!!

[Protoman]

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.

[Viktor Prehnal]

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

[Gianni Mariani]

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?

[Ben Pope]

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

[Gianni Mariani]

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.

[Kai-Uwe Bux]

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