Click here to Skip to main content
15,886,873 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
AnswerRe: swedish file read Pin
CPallini21-Jan-21 0:25
mveCPallini21-Jan-21 0:25 
AnswerRe: swedish file read Pin
Gerry Schmitz21-Jan-21 4:55
mveGerry Schmitz21-Jan-21 4:55 
QuestionState Machine to C code and back Pin
NelsonGoncalves14-Jan-21 0:30
NelsonGoncalves14-Jan-21 0:30 
AnswerRe: State Machine to C code and back Pin
Richard Andrew x6418-Jan-21 12:11
professionalRichard Andrew x6418-Jan-21 12:11 
GeneralRe: State Machine to C code and back Pin
NelsonGoncalves18-Jan-21 23:09
NelsonGoncalves18-Jan-21 23:09 
AnswerRe: State Machine to C code and back Pin
trønderen20-Jan-21 9:29
trønderen20-Jan-21 9:29 
GeneralRe: State Machine to C code and back Pin
NelsonGoncalves21-Jan-21 21:17
NelsonGoncalves21-Jan-21 21:17 
GeneralRe: State Machine to C code and back Pin
kalberts21-Jan-21 23:31
kalberts21-Jan-21 23:31 
My approach is to do all model editing in the FSM editor. Anything related to state transitions, testing whether a transition is legal, possible transfer to an error state etc. etc.

When the general FSM logic has done its job identifying a transition to be taken, there frequently is a set of updates to state variables, beyond the ID of the new state - it could be things like starting a timer, zeroing a buffer or setting flags that are tested by future state transitions. These are all specified in a general way in the FSM - think of it as quite formalized pseudocode. This is where code editing comes it: For that specific set of state variable updates, the coder writes a "real" implementation. This usually goes little beyond simple assignment statements.

Then a transition may have side effects - generally: raising events in other FSMs. Sending a message is an example. Even this is specified in formalized pseudocode in the FSM, and the developer translates that logic to some real code.

The FSM is edited as a state table - a set of squares in the crosspoint between current state and event. Each square identifies a condition for the transition to be legal (as a logic expression on a restricted set of bool functions). Then comes the ID of the next state if the transition is taken, followed by the ID of the function updating the state variables (which also is usually a limited set), and the ID of the function taking care of the side effects. Clicking on either of these four fields to take you to the details of the function.

One thing I picked up from rather complex OSI protocol state machines: If the test on the state variables shows that a transition is not legal, maybe some other transition is legal. (The very trivial case: If a state variable x is true, make this transition, otherwise make that transition.) Purists say that this should be treated as two completely indepenent states, but allowing tests on other variables than just the current state is essential to avoid an explosion of states.

The general FSM editing is independent of programming language. From the tables, a code skeleton can be genereated, calling those functions for testing and updating state variables and causing side effects that the programmer wrote. So you may have one common FSM model for different languages, provided that you have written a skeleton generator for each relevant language.

One remaining "problem" (if it is): My generator will produce a complete set of source files that may be set up e.g. as a Visual Studio project for complilation. What happens when the compiler reports a syntax error? Or debugging reports a logic error in one of the functions? As is is now, the developer must go back to the FSM editor to make the correction there, generate a new set of files, and recompile / rerun. This is not acceptable in the long run. I plan to learn how to write VS plugins, to attach the FSM editor to VS, let the user edit each function and then, based on coded comments in the source, bring the edits back into the FSM model. If the problem is not in a single function, but in the FSM logic, then you skip into the FSM editor, doing the changes there. This is certainly some way from being completed...

If you have been thinking along simlar paths, feel free to present an introduction.
GeneralRe: State Machine to C code and back Pin
Greg Utas22-Jan-21 1:30
professionalGreg Utas22-Jan-21 1:30 
QuestionMessage Closed Pin
12-Jan-21 11:59
Member 1496877112-Jan-21 11:59 
AnswerRe: C++ template function returning "vector" ? Pin
Greg Utas12-Jan-21 12:24
professionalGreg Utas12-Jan-21 12:24 
AnswerRe: C++ template function returning "vector" ? Pin
CPallini12-Jan-21 21:20
mveCPallini12-Jan-21 21:20 
GeneralMessage Closed Pin
13-Jan-21 4:57
Member 1496877113-Jan-21 4:57 
GeneralRe: C++ template function returning "vector" ? Pin
Richard MacCutchan13-Jan-21 5:40
mveRichard MacCutchan13-Jan-21 5:40 
GeneralRe: C++ template function returning "vector" ? Pin
CPallini13-Jan-21 7:05
mveCPallini13-Jan-21 7:05 
QuestionCCombox Pin
JM225111-Jan-21 20:19
JM225111-Jan-21 20:19 
AnswerRe: CCombox Pin
Richard MacCutchan11-Jan-21 22:41
mveRichard MacCutchan11-Jan-21 22:41 
QuestionCMFCRibbonComboBox Pin
Member 1325158811-Jan-21 16:31
Member 1325158811-Jan-21 16:31 
AnswerRe: CMFCRibbonComboBox Pin
Richard MacCutchan11-Jan-21 22:39
mveRichard MacCutchan11-Jan-21 22:39 
GeneralRe: CMFCRibbonComboBox Pin
Member 1325158812-Jan-21 9:18
Member 1325158812-Jan-21 9:18 
GeneralRe: CMFCRibbonComboBox Pin
Victor Nijegorodov12-Jan-21 10:12
Victor Nijegorodov12-Jan-21 10:12 
GeneralRe: CMFCRibbonComboBox Pin
Member 1325158812-Jan-21 16:23
Member 1325158812-Jan-21 16:23 
GeneralRe: CMFCRibbonComboBox Pin
Victor Nijegorodov12-Jan-21 21:07
Victor Nijegorodov12-Jan-21 21:07 
GeneralRe: CMFCRibbonComboBox Pin
Richard MacCutchan12-Jan-21 21:24
mveRichard MacCutchan12-Jan-21 21:24 
QuestionC Programming code to build an echo varient that hopefully can be used in WinXP Pin
jackngill11-Jan-21 10:49
jackngill11-Jan-21 10:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.