Obviously my mind is set on a different path than yours, which is exactly why I asked how you would do it.
You've seen it before, I don't know why I need to humor you.
Stroustrup: C++ Style and Technique FAQ -- How do I write this very simple program?
He writes a whole program in this answer. It's pretty much like that. I simply determine if the input is good or bad and use a simple conditional tool, such as if, to either proceed or else. Exceptions will obfuscate.
I would probably refactor the code so that it isn't a long stack of function calls if I can. You know, if you can only process a chunk of input at a time, recursion isn't the feature you should necessarily be using. If I am actually using recursion, even then it's literally one, maybe two conditionals... it's hard for me to write anything that would be gospel.
I hope you seriously don't make input routines that end up as bad as you say.
Bad can be a difficult thing to define. What matters is that code is readable, flexible and easy to maintain. Any way of designing to code to achieve this is a good thing. But this can be done in a number of ways, including mine and your style.
If the design achieves this goal, then I would not call it bad.
I could equally well call your style bad since it leaves a lot of clutter around with lots of if statements and error handling. It would be beneficial to centralize this to one place.
Leave just enough code to properly diagnose the error and leave it up to the parent to handle errors that cannot be locally handled.
I'm just saying that, well, you pulled this out in earnest:
It strikes me as a bit antagonistic and just unreal. What is so hard and unreasonable about what I'm suggesting, that you seriously consider some program that uses a long stack of nested functions. Aren't you concerned more about the system's limits: like, if I parse enough input, can I take this "readable, flexible and easy to maintain" program, use up all it's stack space, and crash it? Is that really why you wrote the input like that? Cause I really could only think of recursion when you mentioned the call stack. And considering recursion, it doesn't make sense what you said, because the base case doesn't add that much confusion.And what if the error occurs in the middle of a long stack of nested functions? Are you going to put if statements in every function to check if an error occurred and return if it does?
Is that what you're concerned about? I don't really do that. It was an example.
I might see maybe 3-4 nested functions, but that's it.
Basically:
Command handler
--> Part of the command handler (split because the function is too long)
--> Utility function wrapper
--> Utility function
But I would use exceptions instead of if statements to handle errors. Using if statements to check for return is usually for library functions (such as those returning iterators).
I'm much more concerned about units of work. If the function is long, I can probably break it up into a series of tasks and make smaller functions. I don't think this makes things unruly, but I don't use exceptions to control the flow of the program. You're not really interrupting anything if you're just going to give the user another chance anyway, and exceptions will separate the conditional from the branching code, by design.
I don't care what library functions do. I can't fashion my career on a library design.
And yes, in the future, I will take examples seriously so make sure they don't sound ridiculous.
I wouldn't return "NULL". Returning an empty string would be easier for everybody.
If you can, prefer passing large and complex objects by const reference (that is, unless you indeed want a copy to be made)Code:string auxiliary_p(string s)
Code:string auxiliary_p(const string& s)I don't think filling the string with "placeholder" is necessary.Code:string ret("placeholder"); istringstream in(s); in>>ret;
This seems to be a longwinded way of doingCode:bool answer(string s) { short n(s.size()); while(n>1) n%=2; return static_cast<bool>(n); }
That doesn't make the answer particularly random, though. The same question always receives the same answer. Picking a random answer might involve something likeCode:bool answer(const string& s) { return s.size() % 2 == 1; }
Code:bool answer() { return std::rand() % 2 == 1; //include <cstdlib> }The meaning of a parameter with a name like that might be a bit unclear.Code:bool yn
Last edited by anon; 07-22-2011 at 08:39 AM.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Thank you for the informative answer.^That was my intention. The same question getting differently answered seems a little weird.That doesn't make the answer particularly random, though. The same question always receives the same answer.
The filling with "placeholder" was a remnant from the time I was putting together the main() without the actual implementations
.Also, the advice for calling by const reference is one I'd start following from now.
"return s.size() % 2 == 1;" ...I love shortcuts.
Last edited by manasij7479; 07-22-2011 at 08:57 AM.
Yeah, if you have a recursive parser, exceptions can be the best way to deal with a syntax error. Or any other error that forces an abort. But you usually don't write programs that are intended to error out most of the time.
But I wouldn't use exceptions for bad user input in a text field. And that's what the OP's example would be.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Just wrote a gui wrapper to the program ..using QT. Download .This is my first gui program that actually does something.
Last edited by manasij7479; 07-25-2011 at 03:00 AM.