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?

 
 
Jim Langston
Guest
Posts: n/a
 
      12-18-2005
"Protoman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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.


Well, if you're alread evaluating a variable to determine which function to
call... why not just call the function there instead?

Instead of:
v_v_fptr ptr=select(val);
ptr();

Just have:
select(val);

and have your select function do:

void select(bool arg)
{
if(arg==true)
cout << "Success" << endl;
else
cout << "Error" << endl;
}

Or, if you want to keep your success and error functions call them instead.

void select(bool arg)
{
if(arg==true)
Success();
else
Failure();
}

I don't see that you are gaining anything by returning a function to call,
then just calling the function. You are just adding an (error prone) level
of complexity for no good reason.

Just because you *can* do something doesn't mean you *should*.


 
Reply With Quote
 
 
 
 
Protoman
Guest
Posts: n/a
 
      12-18-2005

Jim Langston wrote:
> "Protoman" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
> > 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.

>
> Well, if you're alread evaluating a variable to determine which function to
> call... why not just call the function there instead?
>
> Instead of:
> v_v_fptr ptr=select(val);
> ptr();
>
> Just have:
> select(val);
>
> and have your select function do:
>
> void select(bool arg)
> {
> if(arg==true)
> cout << "Success" << endl;
> else
> cout << "Error" << endl;
> }
>
> Or, if you want to keep your success and error functions call them instead.
>
> void select(bool arg)
> {
> if(arg==true)
> Success();
> else
> Failure();
> }
>
> I don't see that you are gaining anything by returning a function to call,
> then just calling the function. You are just adding an (error prone) level
> of complexity for no good reason.
>
> Just because you *can* do something doesn't mean you *should*.


I was just doing it to learn about returning fn ptrs from fns; in a
real prog I would definitely not do this unless I had a *very good*
reason.

 
Reply With Quote
 
 
 
 
Ben Pope
Guest
Posts: n/a
 
      12-19-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.


Quite different to a goto.

When a failure occurs, it is often the case that you do not know how to
handle the error, and so you inform your caller. If you do it via error
codes, then the caller has to check the return value, and decide what to
do, possibly informing its caller via a return code.

This results in lots of checks of calls into function for errors that
rarely occur, and manually propagating the error up the call stack.

With exceptions, you can short-cut the call up the stack. This means
you deal with the error when you know how to do so.

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


Often, yes. If for example the filename was provided on the command
line, to the program, and you do a bunch of stuff, then try to open the
file and it doesn't exist, rather than manually propagate the error up
the call stack with return codes you can just throw, and then catch it
near the top, and inform the user they can't spell.

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


Yes, I would have preferred to have to explicitly specify anything that
a function could throw, and for the compiler to provide static analysis:

#include <iostream>

void fun1() {
throw "foo";
}
void fun2() throw() {
throw "bar";
}
void fun3() throw() {
fun1();
}

int main() {
try {
fun1();
} catch (char* e) {
std::cout << "This is expected to fail: " << e << std::endl;
}
try {
fun3();
} catch (char* e) {
std::cout << "This is NOT expected to fail: " << e << std::endl;
}

}

It's a shame that more analysis is not done to ensure that fun3 does not
throw. VC8 warns that fun2 throws, but does not warn that fun3 calls a
function that throws.

> Multithreaded code is almost always impossible to manage using exceptions.


Surely you have to manage throwing, anyway?

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


Exceptions are for exceptional situations, things which are really bad,
things you don't really know how to deal with. If you write code to
deal with it, it means you expect it to happen, in which case it may not
be best to consider it an exceptional situation.

The normal process of handling errors via return codes is often the most
practical way of dealing with an error, especially if the caller of the
function experiencing the error can deal directly with it.

If it really is exceptional, it's likely that you can't deal with it
directly at the call site, you may have to get 10 calls up the stack to
deal with it, so it's often more manageable to throw.

> Anyhow, I'm sure that there are plenty o people who would debate this,
> and I'm looking forward to a constructive one.


It could be interesting!

Ben Pope.
 
Reply With Quote
 
deane_gavin@hotmail.com
Guest
Posts: n/a
 
      12-19-2005

Ben Pope wrote:
> Exceptions are for exceptional situations, things which are really bad,
> things you don't really know how to deal with. If you write code to
> deal with it, it means you expect it to happen, in which case it may not
> be best to consider it an exceptional situation.
>
> The normal process of handling errors via return codes is often the most
> practical way of dealing with an error, especially if the caller of the
> function experiencing the error can deal directly with it.
>
> If it really is exceptional, it's likely that you can't deal with it
> directly at the call site, you may have to get 10 calls up the stack to
> deal with it, so it's often more manageable to throw.


You could also find fully expected error situations arising several
levels down the call stack from where they need to be handled simply
because you have sensibly factored your code in many small functions
rather than few larger ones.

In such cases, even though the 'error' might be expected I find
exceptions a much cleaner control structure than having to propogate an
error code up the call stack manually. Debating the definitions of
'error situation' and 'exceptional situation' seems academic to me when
what I am really choosing between is clean code vs cluttered code.

Gavin Deane

 
Reply With Quote
 
Geo
Guest
Posts: n/a
 
      12-19-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.


while, for if..else.. return, break, continue... are ALL glorified
gotos, you advising against those also ?
>
> 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.


Possibley, as they stand they are useless, but I'm not conviced they
have any worth anyway.

>
> Multithreaded code is almost always impossible to manage using exceptions.
>


What's that got to do with anything, C++ is NOT a multithreaded
language, threading is not part of C++, exceptions are, you would be
more correct to say, use exceptions, don't use threads

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


But you don't, that's the point, you only need to catch at the place
you wish to deal with the excaption, return codes on the other hand, do
need to be dealt with everywhere

>
> Anyhow, I'm sure that there are plenty o people who would debate this,
> and I'm looking forward to a constructive one.


Enjoy...

 
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