double return on a function

Question

4.00/5 (1 vote)

See more:

Simple code just for an example, of what im trying to ask

C++

void parseLine(string line)
{
  stringstream ss(line);
  string word;
  while(getline(ss,word,' '))
  {
    if(word == "Done")
    {
     return; //return; //HERE: Is there a way from here to return back to main?
    }
  }
}

void parseFile(string filename)
{
  fstream infile(filename);
  string line;

  while(getline(infile,line))
    parseLine(line);
    
}

int main()
{
 parseFile("filename.txt");
 cout << "Done! " << endl;
 return 0;
}

In the function parseLine if it hits a word named Done,
is there a fancy way besides booleans of returning back to main without modifying parseFile?

Posted 17-Aug-12 12:12pm

Balington

Updated 17-Aug-12 12:18pm

v2

Add a Solution

Comments

Kenneth Haugland 17-Aug-12 18:23pm

I dont understand your question, so you want to exit both void's?

Balington 17-Aug-12 18:29pm

Yah, return from parseLine will bring me back to parseFile, I want parseFile to also return back to main immediatly after

[no name] 17-Aug-12 18:39pm

No

Sergey Alexandrovich Kryukov 17-Aug-12 20:33pm

Finally understood and answered. Please see -- not so trivial question, just not well formulated.
I even up-voted it by 4.
--SA

3 solutions

Solution 4

I propose this:

C#

int parseLine(string line)
{
  stringstream ss(line);
  string word;
  while(getline(ss,word,' '))
  {
    if(word == "Done")
    {
     return 0;
    }
  }
  return 1;
}

and this:

C#

while(getline(infile,line) && parseLine(line)); // <<-- semicolon

Also, x86/amd64 assembler. :)

Posted 18-Aug-12 12:44pm

Mihai Vrinceanu

Solution 3

just have parseLine return true if it found "Done", false otherwise?

then change your loop

C#

while(getline(infile,line))
{
    if(parseLine(line))
    {
         break;
    }
}

syntax-wise, un-braced clauses are accidents waiting to happen, but i'm ambivalent about the "break; or return;" debate :)

Posted 17-Aug-12 18:28pm

barneyman

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-08-17T13:17:00

Solution 2

Of course you can do it! You can throw an exception (or some specific type) instead of return and catch it in main. Practically, this is the only straightforward technique to achieve that. Even though it is legitimately used and actually used in a number of cases, this seems to be a big overkill for this simple task and need serious care in case of a complicated algorithm; I would recommend you to review the code design instead.

—SA

Posted 17-Aug-12 13:17pm

Sergey Alexandrovich Kryukov

Updated 17-Aug-12 13:23pm

v2

Comments

[no name] 17-Aug-12 20:35pm

Agreed.... waaaaaaaaaaaaaay overkill for this trivial example.

Sergey Alexandrovich Kryukov 17-Aug-12 20:42pm

Thank you, Wes.

This could be a matter of discussion, not so important.

This is the answer: it can be done. After all, the questions with "without using this and that" are not correct for practical questions, but they can make perfect sense theoretically.
--SA

pasztorpisti 18-Aug-12 4:12am

+5, Exceptions are just mutiple returns with a result. The result can be error and success as well, or even neutral like the Abort in delphi that is silent even if uncaught.

Sergey Alexandrovich Kryukov 18-Aug-12 11:59am

Thank you. Good note about Delphi Abort, which is had exactly this intended use.
Now, let me tell you that your "multiple returns" is not accurate enough. Exceptions are much more powerful then that. Calls and returns are all based on stack. Exceptions break through stack structure: they just remember full context and jump from one context to another in one step. (It resembles old C "long jump" function at the most primitive level, but exceptions of the thread actually introduce another separate stack made of "try" points where all contexts are remembered.)

By the way, I was the author of the very early and fully-fledged structural exception handling implementation in the form of library (this is quite possible, that's how Windows API allows plain C to use it). At that time, exceptions was not introduced in Borland Pascal, not in C++, not in any Windows or Linux/Unix API. They were only introduced in CLU (B.Listkov et al) and, from the very beginning, in Ada. So I know a bit how it looks, from the CPU level. I used Pascal with inline Assember.

There is something like a flame war about using exceptions for non-errors, like the use in parsing we discuss. Many people ferociously maintain that going beyond the purpose of dealing with errors and failures is the abuse. In my strong opinion, this is the pure baseless "ideologism". Why not? If you read old books/articles when the use of exceptions was pioneered, you will see the special considerations, explaining that exception is not an error in general case, this is exceptional situation, with processing isolated from "regular" situations, flow of computing. "The reactor overheated", but no "error" is going on. So, why not "jump back" in parsing?

--SA

pasztorpisti 18-Aug-12 14:10pm

I think that a correct implementation for exception handling must have the same effect as "multiple returns", it has to provide this kind of safety otherwise its useless. What you have written about stack unwinding should be just an implementation detail - however for example in Visual C++ when you turn off exception handling you are still able to throw exceptions, you just turned off the generated code that would clean up the stack correctly (oops...).
I have never seen any exception handling libraries. I myself only written a "manual per thread structured exception handler" using windows' support for that (fs:[0]), but that havent dealt with stack cleanup (however this isn't an issue in C or lower level languages. Implementing the exception handler in another way might require your knowledge of the stack frame generated by the compiler, and you might have to modify it if I guess right...
Jumping back in parsing is a good example for a 'good' non-error exception, however its a fact that the use of exceptions to return success is usually limited and not practical because in case of success you usually don't want to skip code (with the currently popular paradigms). On the other hand - even jumping back during parsing can be treated as some kind of 'small error'. - To be honest I have never spent time thinking about this deeply. :-)

Sergey Alexandrovich Kryukov 18-Aug-12 22:07pm

Basically correct, but not accurate. You cannot reduce exception effect to some return-like behavior, not because the nature of it is different, but because it's different outside the implementation. For example, return may returns values, but thrown exception always ignores it: none of the stack-unwound method does not return anything... Do I need to continue?.. This is a different thing, and the attempt to "rationalize" it is not quite accurate. It's better to say that the notion of return becomes inapplicable. It's like moving through the labyrinth by entering all passages and returning from the dead ends -- exception handling is like having the walls temporarily removed and going straight to the previously marked stop... by the way, it turns out to be a useful metaphor, will try to use it later... :-)
--SA

pasztorpisti 18-Aug-12 22:30pm

You are right about the return values. I have to incorporate that into my tale somehow. :-) I like teaching exceptions with the "automatic error check and return + call tree" tale because it seems to be easier for exception learner newbies to understand - it builds on already known simple operations of the language. However your metaphor can also be useful but you should couple it with some practical examples.

Sergey Alexandrovich Kryukov 18-Aug-12 23:26pm

I found it right during this discussion, so consider yourself as a co-author... :-)
--SA

pasztorpisti 19-Aug-12 5:39am

Thank you! Its an honor! :-)