AVR Freaks

https://stackoverflow.com/questi...

So it's from Lambda Calculus. I don't know the exact chronology of the thing but I suspect C++11 has "borrowed" the idea from Python where Lambda's were they are used extensively.

EDIT: seems I am quite wrong - Lambda's are pervasive across a whole raft of languages: https://en.wikipedia.org/wiki/An...

But I fear this thread is going off topic so all be warned that I will split this into a separate "functions within functions" in the compiler/programming forum shortly.

+1

As I suggested above if you find yourself doing something like:

void a_func(void) {
    switch(something) {
        case 0: {
            PORTB |= (1 << 3);
            x = 3;
            count++;
            break;
        }
        case 1: {
            PORTB |= (1 << 5);
            x = 5;
            count++;
            break;
        }
        case 2: {
            PORTB |= (1 << 1);
            x = 1;
            count++;
            break;
        }
        default: break;
    }
}

where you are repeating almost identical code but you don't want the overhead of a CALL/RET to a separate function then surely you'd just:

static inline void stuff(int n) {
    x = n;
    count++;
}

void a_func(void) {
    switch(something) {
        case 0: {
            PORTB |= (1 << 3);
            stuff(3);
            break;
        }
        case 1: {
            PORTB |= (1 << 5);
            stuff(5);
            break;
        }
        case 2: {
            PORTB |= (1 << 1);
            stuff(1);
            break;
        }
        default: break;
    }
}

That will just inline the "stuff" repeatedly but saves you retyping great swathes of repeated code. Also (more importantly) it gives you just one copy where all the bug fixes can be applied.

I've had a number of times where I've had repeated code that would have been better served by a function within a function.  Usually it is repeated instructions that I'd prefer to optimize that need access to the local variables of the parent function.  Sometimes they end up in a function and I pass variables to them, sometimes some of those variables end up being globals, sometimes I just leave it repeated code.  I like the macro idea to at least not have multiple copies of code to correct/change, I'll try that next time.

I wasn't thinking about using the parameter/variable replacement features of a macro, just replacement.  I was actually thinking of something more like:

  instruction1;

  instruction2;

  instruction3;


  morecode;


  instruction1;

  instruction2;

  instruction3;

with

#define codereplacement \

  instruction1;\

  instruction2;\

  instruction3


  codereplacement;


  morecode;


  codereplacement;

I got you clawson.  They discourage defines like #define MAX_ITEMS 1000 then as well?

const uint16_t max_items = 1000;

Any reasonable compiler will simply optimise the use of this. So that when you later write:

if (entered_num < max_items) {

there won't be a "max_items" actually created in memory and that then has a runtime read access in this statement. Instead the compiler will optimize this as if you had simply written:

if (entered_num < 1000) {

(just as it would have done if #define were used). But the difference is that this particular 1000 has a known type (uint16_t) so if entered_num were a uint32_t (say) then expect a warning from the compiler (certainly from a code analyser like lint, splint, cppcheck, Klockwork, QAC, etc etc) to point out that you are comparing a 32 bit wide to a 16 bit wide and this may not be what you intended. Such knowledge could not be made available to the compiler if just 1000 or MAX_ITEMS (as a #define of 1000) were used.

It's also a good idea to have the code compiled as C++ rather than C as C++ is much stringent about mixing of types and will call out things that C ignores.

When one first starts to work with MISRA it looks like a lot of really annoying nonsense. But greater minds than ours have contemplated all the things you can do in C (and C++) and the kind of things that often lead to problems (like mixing types) and have mandated a set of rules that makes sure you cannot do most of those things. So this makes for higher quality, safer code in the long run even if it does look like an uphill struggle to implement their directives.

The best idea is to learn MISRA then only write code that adheres to it in the first place. Sadly what happens in the real world is that large teams of programmers from all kinds of backgrounds collaborate on some code for a project using all kinds of approaches and implementations and then this is fed into a code analyser and some other team then spend week/months taking 10's of 1,000's of MISRA warnings and trying "solve" how to reimplement the same thing to be MISRA safe! (been there, done that, worn the T-shirt!)

BTW I notice some programmers use all upper case even when they use:

const uint16_t MAX_ITEMS = 1000;

For me that is a bit of a two edged sword. Sure when you later read:

if (entered_num < MAX_ITEMS) {

you are likely to read this as "MAX_ITEMS is clearly defined as an unchaging (const) value somewhere" but this kind of grates with the usual rule "only use all upper case for pre-pro macros". Of course if you live in a MISRA world where prepro can ONLY be use for header guards then I suppose it's OK to use upper case like this as it must be const.

BTW I forgot to say that you would usually want to limit the name scope of the const variable whatever you choose to name it. Othewise if you did something like:

const uint16_t MAX_ITEMS = 1000;

int main(void) {
    if (entered_num < MAX_ITEMS) {
        ...
    }
}

then while the intention is that nothing is really allocated in memory to create "MAX_ITEMS" the fact is that define in this way it is a global and the compiler cannot know whether another compilation unit might make an "extern" reference to this thing so it may be tempted to actually allocate storage. So in this case you would use:

static const uint16_t MAX_ITEMS = 1000;

int main(void) {
    if (entered_num < MAX_ITEMS) {
        ...
    }
}

so the compiler knows (in this case) that usage is limited to this file. When it sees no other access the optimiser will know it's safe to only generate a hard coded 1000 in the code that implements the if.

I am confused -

Dpes C disallow function calls from within functions? That is what it sounds like, above. Yet, this is something we do all the time:

void TopFunction(void) {
    FunctionOne();
    FUnctionTwo();
    FunctionThree();
}

What am I missing?

Thanks

Jim

static inline void stuff(int n) {
    x = n;
    count++;
}

void a_func(void) {
    switch(something) {
        case 0: {
            PORTB |= (1 << 3);
            stuff(3);
            break;
        }
        case 1: {
            PORTB |= (1 << 5);
            stuff(5);
            break;
        }
        case 2: {
            PORTB |= (1 << 1);
            stuff(1);
            break;
        }
        default: break;
    }
}

actually implemented as:

void a_func(void) {
    void stuff(int n) {
        x = n;
        count++;
    }

    switch(something) {
        case 0: {
            PORTB |= (1 << 3);
            stuff(3);
            break;
        }
        case 1: {
            PORTB |= (1 << 5);
            stuff(5);
            break;
        }
        case 2: {
            PORTB |= (1 << 1);
            stuff(1);
            break;
        }
        default: break;
    }
}

In this stuff() is a not just a function called from a function (we all do that all the time) but a function defined WITHIN a function. Andy pointed out previously that C does not allow this but...

https://gcc.gnu.org/onlinedocs/g...

So GCC has a special "extension" which you can access using -std=gnu99 rather than -std=c99 (and other gnu versus c options) that actually permits functions in functions.

As noted above C++11 expanded in 2011 to now add "lambda"s to C++ which is a more formal (and standard approved) way to define short functions (usually) within functions.

EDIT1: To be honest I cannot really see the appeal of any of this. I suppose it's about "scope" and locality when reading the source? My stuff() function is clearly something "private and personal" that is only involved in the implementation of a_func() so it's brought "inside" but for me it just confuses the legibility of a_func() by living there at the top.

EDIT2: Actually when you read that GCC manual page about their extension and it cites this as an example:

foo (double a, double b)
{
  double square (double z) { return z * z; }

  return square (a) + square (b);
}

notice the fairly nasty thing they have done here? To try and say "we don't want to overcomplicate foo() by having a big old function defined within it" they have crammed the entire function definition of square() onto one line. Not sure how that is supposed to help legibility? I would have written:

foo (double a, double b)
{
  double square (double z)
  {
      return z * z;
  }

  return square (a) + square (b);
}

which begins to look unwieldy. Not sure how this is really any "better" than simply:

static inline double square (double z)
{
  return z * z;
}

foo (double a, double b)
{
  return square (a) + square (b);
}

Sometimes you wonder if all these language extensions really help?!?

On that subject I read a brilliant interview with Bjarne Stroustrup yesterday:

https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/

In which he appears to be saying "a committee of 160 people reinventing MY language are creating a language that looks like it was designed by a committee"!

Is there some perceived benefit to having a function defined inside a function? Or, is it just "syntactic candy"?

Thanks

Jim

For me it would have been so that it had access to the local variables of that function.  Sure you can pass them back and forth, but that seems wasteful.  It always seems to make code larger anyway.