Return statement is NOT exiting the function!!!

EDIT: Title of thread should read "Return statement affected by other return statements"

Hi all, I have a piece of code that resembles the following:

Code:

---

int locomotives_required (double tons_per_wagon, double train_tons, double gradient)
{
    double tons_per_axle_variable = tons_per_axle(tons_per_wagon);
    ifstream ifs;
    ifs.open ("C:\\C++ Projects\\Coal Logistics\\LoadTables.txt", std::ofstream::out | std::ofstream::app);
    string lineread;
    getline (ifs, lineread);
    char* wordptr = tokenizer(lineread);
    int number = atoi(wordptr);
    int j;
    int locomotive_counter = 0;
    if (tons_per_axle_variable < number)
        return ERROR_LOW_WAGON_WEIGHT;
    for (int i = 1; *wordptr != 'EOF'; i++) //select the correct table
    {
        wordptr = tokenizer("NULL");
        if (tons_per_axle_variable < atof(wordptr))
            for (j = 1; j <= 18; j++)
            {
                getline (ifs, lineread);
                if (gradient == atof(tokenizer(lineread)))
                    for (int k = 0; k <= 6; k++)
                    {
                        locomotive_counter++;
                        if (train_tons <= atof(tokenizer("NULL")))
                            return 3;
                    }
            }
            if (j == 19)
                return ERROR_HIGH_GRADIENT;
        else
        {
            getline(ifs,lineread);
            while (lineread != "")
                getline(ifs,lineread);
            getline(ifs,lineread);
            wordptr = tokenizer(lineread);
        }
    }
    if (*wordptr == 'EOF')
        return ERROR_HIGH_WAGON_WEIGHT;
}

---

Neglecting all the distractions, please look at line number 26. I have written this piece of code such that this called function always returns at line 26, which should return the number 3. I ran a debugger and checked step by step to make sure the function returns at line 26 and it does.

Note that in theory, the return keywords at lines 30 and 41 should have no bearing on the outcome of returning the value "3" at line 26.

Yet when I run this program and print the outcome I always get a 6-8 digit random number every time like: 767172 and 393620 etc...

To solve this problem I COMMENT OUT lines 30 and 41 and rather make an empty statement like " ;" and finally the function returns the value 3 as it should.

Can anybody explain this???

Just in case this is the/a reason for the problem, are you aware that this:

Code:

---

        if (tons_per_axle_variable < atof(wordptr))
            for (j = 1; j <= 18; j++)
            {
                getline (ifs, lineread);
                if (gradient == atof(tokenizer(lineread)))
                    for (int k = 0; k <= 6; k++)
                    {
                        locomotive_counter++;
                        if (train_tons <= atof(tokenizer("NULL")))
                            return 3;
                    }
            }
            if (j == 19)
                return ERROR_HIGH_GRADIENT;
        else
        {
            getline(ifs,lineread);
            while (lineread != "")
                getline(ifs,lineread);
            getline(ifs,lineread);
            wordptr = tokenizer(lineread);
        }

---

should be correctly indented as:

Code:

---

        if (tons_per_axle_variable < atof(wordptr))
            for (j = 1; j <= 18; j++)
            {
                getline (ifs, lineread);
                if (gradient == atof(tokenizer(lineread)))
                    for (int k = 0; k <= 6; k++)
                    {
                        locomotive_counter++;
                        if (train_tons <= atof(tokenizer("NULL")))
                            return 3;
                    }
            }
        if (j == 19)
            return ERROR_HIGH_GRADIENT;
        else
        {
            getline(ifs,lineread);
            while (lineread != "")
                getline(ifs,lineread);
            getline(ifs,lineread);
            wordptr = tokenizer(lineread);
        }

---

?

Are you actually storing the output somewhere? Or perhaps some other piece of code is overwriting memory it doesn't own.

Quote:

---

Originally Posted by laserlight

Just in case this is the/a reason for the problem, are you aware that this:

Code:

---

        if (tons_per_axle_variable < atof(wordptr))
            for (j = 1; j <= 18; j++)
            {
                getline (ifs, lineread);
                if (gradient == atof(tokenizer(lineread)))
                    for (int k = 0; k <= 6; k++)
                    {
                        locomotive_counter++;
                        if (train_tons <= atof(tokenizer("NULL")))
                            return 3;
                    }
            }
            if (j == 19)
                return ERROR_HIGH_GRADIENT;
        else
        {
            getline(ifs,lineread);
            while (lineread != "")
                getline(ifs,lineread);
            getline(ifs,lineread);
            wordptr = tokenizer(lineread);
        }

---

should be correctly indented as:

Code:

---

        if (tons_per_axle_variable < atof(wordptr))
            for (j = 1; j <= 18; j++)
            {
                getline (ifs, lineread);
                if (gradient == atof(tokenizer(lineread)))
                    for (int k = 0; k <= 6; k++)
                    {
                        locomotive_counter++;
                        if (train_tons <= atof(tokenizer("NULL")))
                            return 3;
                    }
            }
        if (j == 19)
            return ERROR_HIGH_GRADIENT;
        else
        {
            getline(ifs,lineread);
            while (lineread != "")
                getline(ifs,lineread);
            getline(ifs,lineread);
            wordptr = tokenizer(lineread);
        }

---

?

---

You are correct in spotting this but it doesnt affect the code.

Quote:

---

Originally Posted by tabstop

Are you actually storing the output somewhere? Or perhaps some other piece of code is overwriting memory it doesn't own.

---

Nope. The output is a mere integer and returns directly as an integer.

UPDATE: I only commented out line 41 and it returns the number 3. Line 41 is the culprit but I don't know why? How would one return line (41) mysteriously affect the other (26)?

Line 41 is what happens if your for-loop on line 14 gets to the end. Therefore, your for-loop on line 14 gets to the end.

Quote:

---

Originally Posted by tabstop

Line 41 is what happens if your for-loop on line 14 gets to the end. Therefore, your for-loop on line 14 gets to the end.

---

But it cant get to the end because between line 14 and line 41 is line 26. The conditions leading up to line 26 are all satisfied and the return 3 statement is executed. I even checked with debugging to make sure that the function ends with line 26 and it does. It never reached line 41.

This is crazy.

Quote:

---

Originally Posted by Vespasian

But it cant get to the end because between line 14 and line 41 is line 26. The conditions leading up to line 26 are all satisfied and the return 3 statement is executed. I even checked with debugging to make sure that the function ends with line 26 and it does. It never reached line 41.

This is crazy.

---

If that was the case, then changing line 41 would not have made a difference. You can't really have this both ways. I'll reiterate that there can be lots of things wrong in the calling function as well (such as the ever-popular-on-the-forums calling-a-function-but-not-storing-the-return-value), so you need to check there also.

Quote:

---

Originally Posted by Vespasian

You are correct in spotting this but it doesnt affect the code.

---

Yes, but it can affect how you reason about your code, i.e., you could have thought that your code should have done something when actually it does something else.

In fact, it looks like your code is wrong: what if tons_per_axle_variable >= atof(wordptr) on the first iteration of the outer loop? Then you are comparing j with 19, but j was not initialised.

Quote:

---

Originally Posted by Vespasian

I only commented out line 41 and it returns the number 3.

---

You cannot only comment it out because that would result in a compile error. So, what did you replace it with? If you replaced it with an empty return statement or an empty statement, then you have undefined behaviour should control actually reach that point.

Why do you think the code below is valid?

Code:

---

*wordptr != 'EOF'

---

Is 'EOF' valid in C++; because in C its a error or warning!

Tim S.

Indeed. Are you compiling with warnings turned on at a high level? Do you pay attention to your compiler warnings?

Quote:

---

Originally Posted by stahta01

Why do you think the code below is valid?

Code:

---

*wordptr != 'EOF'

---

Is 'EOF' valid in C++; because in C its a error or warning!

Tim S.

---

It's not valid.
Either it should be a constant (e.g. wordptr != EOF) or it should be a string (e.g. wordptr != "EOF").
Of course, those examples are not necessarily valid since I don't know what tokenizer returns or how it works. Plus, wordptr is a C-string, which makes you have to use C-style string functions.

Okay then, I'm going to look at

Code:

---

*wordptr != 'EOF'

---

more carefully and see what I come up with...

The point I am making is that I find it surprising that although C/C++ is a strictly imperative/procedural language, something like a return statement at the end of the code affects another return statement in the middle of the code even though return statements shouldnt be connected at all. And I cannot see how they are connected to "under the bonnet" of the C/C++ language

Quote:

---

Originally Posted by Vespasian

The point I am making is that I find it surprising that although C/C++ is a strictly imperative/procedural language...

---

C++ is not strictly an imperative/procedural language. It is a multi-paradigm language (imperative, object oriented, generic among them).

Quote:

---

...something like a return statement at the end of the code affects another return statement in the middle of the code even though return statements shouldnt be connected at all.

---

They don't affect each other.

You should at least have a warning stating something to the effect of "control reaches end of non-void function" for that last bit at the end of the function. Assuming the last "if" test was made correct, there could be the potential that the test failed and the associated return statement would not be executed. You'd then reach the end of the function without an explicit return.

Quote:

---

Originally Posted by hk_mp5kpdw

You should at least have a warning stating something to the effect of "control reaches end of non-void function" for that last bit at the end of the function. Assuming the last "if" test was made correct, there could be the potential that the test failed and the associated return statement would not be executed. You'd then reach the end of the function without an explicit return.

---

But this cant be the case because I ran the debugger step by step, and the last step the debugger ran was line 26 indeed proving it exited the function at line 26. It never so much as sniffed line 41

Quote:

---

Originally Posted by Elysia

It's not valid.
Either it should be a constant (e.g. wordptr != EOF) or it should be a string (e.g. wordptr != "EOF").
Of course, those examples are not necessarily valid since I don't know what tokenizer returns or how it works. Plus, wordptr is a C-string, which makes you have to use C-style string functions.

---

I changed it to EOF and it if anything its worse off now... Because even commenting out line 41 doesnt work anymore and returns a random number everytime.

Quote:

---

Originally Posted by laserlight

Indeed. Are you compiling with warnings turned on at a high level? Do you pay attention to your compiler warnings?

---

I enabled warnings "demanded by strict ISO C and ISO C++ [-pedantic]" and enabled all warning prompts under compiler flags.

Yet after I compile I get zero build warnings.


Im gonna try look at the if statements more closely even though it makes absolutely no sense that one return statement affects the other return statement even though the latter is NEVER called (as proven by the debugger)