Have the Embedded world gone ape? 10 years time?

[legacy]

Which I basically interpret as "if you're not using the bloated parts of C++, you're not doing it right."

what do you mean with "bloated parts of C++"? which parts do you mean? 

[nctnico]

Pointers aren't evil.

Pointers are prone to errors. Probably because they are appearantly difficult to grasp by many. Why do you think many higher level languages don't have pointers?

[c4757p]

Because higher-level languages are more abstract and pointers are a low-level construct.

[Dielectric]

Pointers aren't evil.

Indeed, I posit that pointers are the shiz-nit for MCUs.  Note the qualification.  You can utterly hose yourself, or just trip the MPU, on a regular processor and I can see where they get a bad rap.  Of course, you can still hose yourself with a badly handled pointer on an MCU, but the good part is being able to pass-by-reference and stuff like that.

I just did a project where most of the stuff was done by structure passing.  Keeps scope and concurrency nice and contained because it was a multi-channel thingy.  I could make any number of channels this way, just allocate a few more structs. 

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

[janoc]

You'll find development a lot more enjoyable if you stop avoiding things because something somewhere doesn't support them. C++ has rather a lot of nice stuff you could use. Come to the dark side, we have cookies.  O0

  I am actually doing C++ development for living for the last 15 years or so, on multiple platforms, including some embedded ones, my friend. So I dare to say that I know what I can and cannot expect from this language. 

[c4757p]

Excellent! Well, you should be able to tell us which platforms incur runtime overhead for unused features, then.

[miguelvp]

C++ or C++11?

After all, they are in different ball parks.

[tggzzz]

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

Function pointers are indeed a very good implementation technique for FSMs. I first used that technique in 1982 on a Z80.

[Howardlong]

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

Function pointers are indeed a very good implementation technique for FSMs. I first used that technique in 1982 on a Z80.

Real men used E9h. I just stunned myself that I could even remember the opcode.

[Marco]

Pointers are prone to errors. Probably because they are appearantly difficult to grasp by many. Why do you think many higher level languages don't have pointers?

Making it harder to reason about small parts of code makes programs prone to other kinds of errors, in this case programmers can assume it was passed by value for instance. Higher level languages have distinct types of errors related to this kind of obfuscation. Last year both a Python and a PHP library meant to sanitize SQL input were exploited for instance for much the same reasons in my opinion. Dynamic typing makes it very difficult to completely think through how code might execute.

This is why I think Rust is almost right in it's design intention (implementation remains to be seen). Except for "asynchronous" message passing as the default, they got that one all wrong. Almost all the reasons to avoid GC apply to "asynchronous" message passing. "Asynchronous" message passing will eventually turn into synchronous message passing in production and then it will start exposing bugs which you might have found if only you had developed it as synchronous in the first place.

[legacy]

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

Function pointers are indeed a very good implementation technique for FSMs. I first used that technique in 1982 on a Z80.

can I see an example, please ?

[Howardlong]

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

Function pointers are indeed a very good implementation technique for FSMs. I first used that technique in 1982 on a Z80.

can I see an example, please ?

FWIW, even if you use a case statement in an FSM, it's pretty common for compilers to turn them into computed jumps, especially if the states tend to be incremental. A computed jump is barely a step away from using a function pointer. Whether it's more understandable to look at a case statement compared to explicitly using a function pointer I'll leave for another day...

[tggzzz]

Function pointers?  Yes please!  I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space.  Cortex M0 with GCC, for the record.

Function pointers are indeed a very good implementation technique for FSMs. I first used that technique in 1982 on a Z80.

can I see an example, please ?

I'm sure you can find one on the net; my example is lost in time.

Basic principle is:

• you have events and states, and it is necessary to specify what happens when each event occurs in each state
• it is also necessary for someone else to unambiguously read, determine and change what happens with each state/event combination
• it is also necessary that someone have made exactly the right change and only the right change - and that is very error-prone with if-the-else statements
• there is a 2D array, one dimension for each state, the other dimension for each event
• each element in the 2D array contains a function pointer to the action which occurs when one of the events occurs in one of the states
• where appropriate the action can be "do nothing"
• where appropriate the action can be "should not happen, log message and shutdown"
• you can also have a parallel 2D array specifying the next state, or it can be encoded in the action, whichever is easier to read and correctly modify
• debugging with breakpoints is easy, obviously
• debugging via printf is easy, just consisting of the state-event indexes
• "how did we get to an error" audit trail is easy if the x-y indices are stored in a buffer, being dumped in the "should not happen" action

[tggzzz]

FWIW, even if you use a case statement in an FSM, it's pretty common for compilers to turn them into computed jumps, especially if the states tend to be incremental. A computed jump is barely a step away from using a function pointer. Whether it's more understandable to look at a case statement compared to explicitly using a function pointer I'll leave for another day...

I have seen a commercial product where an if-the-else state machine was the central control-flow mechanism. Over the years it gradually mutated due to customer requests until it was hundreds of lines long and statements were nested 10 deep! Nobody dared refactor it. (I imagine each mutation was individually commercially justifiable.)

Inept? Sure. That's the way of the world, and engineers (cf hackers) develop techniques to deal with real-world "sub-optimalities".

[nctnico]

Now you are opening an old wound in my memory! One of my first projects involved making changes to such a program. It was written by someone who was a wood worker. I decided to print the program (still using a matrix printer!) and draw lines in the margin where each if-then-else block started and ended with numbers to keep track. I think some IF statements spanned several pages (printed 100 lines per page). I recall combining several half-page long spaghettis into just a few lines doing exactly the same. The customer wasn't happy with the amount of hours I had to put in...

I agree with Howardlong though on statemachines and function pointers. It is hard to follow a statemachine based on function pointers because the cause is detached from the resulting action. I have implemented an ISDN protocol stack that way but my co-workers didn't really want to dive into it because they found the concept hard to grasp. It worked blazingly fast though!

[Kalvin]

My preferred way of implementing state machines is to use a function pointer "current_state" pointing to the function of the current state handler. Thus, there is one function for each state. Inside the state handler function there is a simple switch-case-structure which will catch & handle each event. There is also a default handler which will do either nothing or it can propagate the event to some where else if needed. The state handler function will also return the the next state if a state change is required because of an event. My state machine implementations typically have also predefined events like, STATE_INIT, STATE_ENTER, STATE_EXIT and STATE_TIMEOUT which are invoked automagically by the state machine during the state transitions or timeouts. To me this is mentally most easiest way to keep the things in order.

[legacy]

@tggzzz
do you mean something like this ?

[Dielectric]

@tggzzz
do you mean something like this ?

From that page, this is a great example:

Code: [Select]

typedef void transition_func_t( instance_data_t *data );

void do_initial_to_foo( instance_data_t *data );
void do_foo_to_bar( instance_data_t *data );
void do_bar_to_initial( instance_data_t *data );
void do_bar_to_foo( instance_data_t *data );
void do_bar_to_bar( instance_data_t *data );

transition_func_t * const transition_table[ NUM_STATES ][ NUM_STATES ] = {
    { NULL,              do_initial_to_foo, NULL },
    { NULL,              NULL,              do_foo_to_bar },
    { do_bar_to_initial, do_bar_to_foo,     do_bar_to_bar }
};

state_t run_state( state_t cur_state, instance_data_t *data ) {
    state_t new_state = state_table[ cur_state ]( data );
    transition_func_t *transition =
               transition_table[ cur_state ][ new_state ];

    if ( transition ) {
        transition( data );
    }

    return new_state;
};


[tggzzz]

It is hard to follow a statemachine based on function pointers because the cause is detached from the resulting action.

I have no idea what you mean by that.

[Howardlong]

I use both methods for FSMs, but when reading someone else's code almost always I find it easier to follow if it's a case statement rather than a function pointer, it's right there in your face. I use "clever" things like function pointers less and less as I get older, not because I'm going senile particularly (!) but because I know when I go back to look at even my own code several months down the line stuff like this sometimes unnecessarily gets in the way of comprehending quickly what is happening.

My concern is usually around whether some piece of language functionality is used to show off one's chops because at the time you might think it's more elegant rather than whether it's easily maintainable. If you have to spend time reverse engineering your own or someone else's algorithms and data structures, rather than following simple program flow, then for me at any rate the simple in your face version wins. That is not to say there's a time and a place though!

I remember when I was younger re-coding a whole bunch of Windows code from an enormous number of event driven case elements and putting it into an array of function pointers back in the 80s (when Windows was still 16 bit and MFC didn't exist my friends) because I thought it was more "elegant". The problem was that nobody else understood the code as that wasn't the way Charles Petzold did it.

Having said all that, the concept of function pointers is inherently locked up inside polymorphism in OO languages like C++, it's just that as humans we choose not to see them as function pointers.

[tggzzz]

I use both methods for FSMs, but when reading someone else's code almost always I find it easier to follow if it's a case statement rather than a function pointer, it's right there in your face. I use "clever" things like function pointers less and less as I get older, not because I'm going senile particularly (!) but because I know when I go back to look at even my own code several months down the line stuff like this sometimes unnecessarily gets in the way of comprehending quickly what is happening.

As I said, I've seen undisciplined use of if-the-else statements in complex FSMs "blossom" into unmaintainable cancers And no, those statements weren't autogenerated from a higher level description.

As for re-comprehending, if the design pattern is remembered and suitable names are given, then I've found it easy to pick up. Of course if those aren't followed, all bets are off!

My concern is usually around whether some piece of language functionality is used to show off one's chops because at the time you might think it's more elegant rather than whether it's easily maintainable. If you have to spend time reverse engineering your own or someone else's algorithms and data structures, rather than following simple program flow, then for me at any rate the simple in your face version wins. That is not to say there's a time and a place though!

Completely agree, but I'll add some constraints for what consititues "maintainable" for FSMs. When an event occurs in a state, I want to be able to

• determine which piece of code gets executed
• change what happens, in the knowledge that I haven't affected any other state/event's action
• log the state/event for debugging and for live-system audit trails

The latter is invaluable when a problem occurs and you need to demonstrate the problem is with other manufacturer's equipment.

Having said all that, the concept of function pointers is inherently locked up inside polymorphism in OO languages like C++, it's just that as humans we choose not to see them as function pointers.

The standard OO FSM design pattern is extremely useful since, with some boilerplate it enables all the valuable attributes I've previously mentioned.

[nctnico]

If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines. 

[Kalvin]

If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines. 

Programming is all about communication. Otherwise you could scrap the source code, ignore the language to be used (you could always use assembly, Forth, Brainfuck, Whitespace etc. instead of C/C++), ignore the comments, ignore the source code formatting, ignore using meaningful names, ignore asserts and test cases, ignore documentation and instead deliver your work to your collegues in the form of the hex or binary code.

Design patterns improve communication as they provide common language inside the team/organization, improves productivity as one doesn't have to invent the wheel for each project requiring specific "pattern" but the designer can instead concentrate on solving the actual problem at hand instead composing the solution with a help of the known patterns, reduces bugs by using proven patterns and avoiding antipatterns, improve software architecture design as the software structure can be expressed in known patterns, and make the software maintenance easier  due to the sum all of the previous arguments. Of course, one could also argue that the canvas and the colors available will make an artist a monkey coloring white canvas between the frames.

[tggzzz]

If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines.

How do you suggest we distinguish the current state of programming from "monkey coloring within the lines"?

I suggest you study where design patterns originated and why they are regarded as standard operating procedures in engineering disciplines. Programming != engineering, unfortunately. Cue standard jokes about "if buildings were designed by programmers"...

[c4757p]

Put simply: design patterns keep you safe from being murdered by other developers