-1

I am re-declaring a const int variable a few times in a switch-case statement of a function as shown following:

void functionB(type param1, type param2, ..., const int paramConstInt = 100);

void setup() {
    ...
}

void loop() {
    ...
    functionA();
}

void functionA() {
    ...
    switch(var) {
        case 0: {
            const int paramConstInt = 200;
            ...
            functionB(param1, param2,..., paramConstInt);
            break;
        }
        case 1: {
            const int paramConstInt = 300;
            ...
            functionB(param1, param2,..., paramConstInt);
            break;
        }
        case 2: {
            functionB(param1, param2,...);
            ...
            break;
        }
        ...
        default: 
            // if nothing else matches, do the default
            // default is optional
            break;
        }

}

void functionB(type param1, type param2,..., const int paramConstInt) {
    ...
}

Does standard C++ allow for it? I am asking so because, if I try to change one of the paramConstInt inside a switch case to 1000 or so I have a strange behaviour similar to that given by a memory leakage. I think anybody willing to replicate this oddity can do it and report. If const int is replaced by just int, the problem seems to disappear.

  • Are you using paramConstInt somewhere else ? If now why not simply call functionB(param1, param2,..., XYZ); where XYZ is the value. For example functionB(param1, param2,..., 300); ? – Andre Courchesne Jan 2 '17 at 13:49
  • yes, using paramConstInt in the switch-case block as well before passing it as an argument; so the pseudocode above should more precisely be: const int paramConstInt = 200; ...; functionB(param1, param2,..., paramConstInt); – vooorka Jan 2 '17 at 14:13
  • Then your const is not a constant, it's variable. I suggest defining it as such. – Andre Courchesne Jan 2 '17 at 14:24
  • 1
    What you describe, along with the posted code, has no issue in C++ whatsoever. If you have a strange behavior when setting paramConstInt to 1000, then this is probably due to what functionB does with that argument value. – jfpoilpret Jan 2 '17 at 14:55
  • You have to show us the code of functionB to check what could explain that odd behavior. – jfpoilpret Jan 2 '17 at 16:18
-1

Sorry for alerting the community for one of my faults. I'll try to explain what happened in my code and why "const int" made a difference against just "int". In my code, functionA() is not being called by loop() as sketched above but it is actually repeatedly called by a third function, say functionAcaller(), which keeps control while in a millis-interval. Moreover, functionB being called by functionA in turn, has several parameters among which an array vital to the correct functioning of the program, name it MAIN_ARRAY. I didn't notice up to the time I started debugging the "const int" issue that MAIN_ARRAY is local and declared (not initialized) within each switch case (same array size for all switch cases) though every time I enter again one of the switch-cases I actually need to change the values the array contained in the previous run. In spite of the fact that I (re)declared MAIN_ARRAY every time I entered functionA() switch-cases, things were fine since the previous values were not probably cleared by the micro. Well, there was in reality a problem given by "const int paramConstInt". When I set it too big, the program lagged. I guess it had to do with its default value being only 100. Another problem was possibly the order of (re)declaration: whether the first variable being (re)declared was MAIN_ARRAY or const int paramConstInt. Anyway, even when MAIN_ARRAY was (re)declared as first thing once back to functionA() switch-cases, a too big const int paramConstInt caused problems while int alone of the same value was just fine. Sorry again for not having delved into this issue more deeply in advance but since everything was all right except for "const int" I really thought that was the problem.

  • Once inside the scope of a switch-case, the first memory allocations carried out are for statics and constants. If there are any, any allocation from a previous run must be shuffled. However, I still don't understand why a small-value const int was just fine. – vooorka Jan 2 '17 at 20:43
  • Essentially the poster was (unknowingly) relying on the old contents of then retracted stack still being there when the stack subsequently grew back into that region. That's an extremely unsafe assumption easily broken by minor code changes or differences in compiler behavior. It's possible the small value was being optimized out and directly inserted where needed, while the large value may have required stack manipulation. One would have to read the disassembled output of the compiler to know; of course the only real answer is not to violate the contract of the programming model! – Chris Stratton Jan 2 '17 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.