Click here to Skip to main content
15,893,668 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
QuestionRe: Battleship game in C Pin
David Crow26-Jan-21 4:16
David Crow26-Jan-21 4:16 
Questiontypical NASM usage Pin
Calin Negru23-Jan-21 23:29
Calin Negru23-Jan-21 23:29 
GeneralRe: typical NASM usage Pin
Richard MacCutchan24-Jan-21 0:55
mveRichard MacCutchan24-Jan-21 0:55 
AnswerRe: typical NASM usage Pin
harold aptroot24-Jan-21 17:27
harold aptroot24-Jan-21 17:27 
GeneralRe: typical NASM usage Pin
Calin Negru24-Jan-21 20:23
Calin Negru24-Jan-21 20:23 
Questiondicom error Pin
sureshpondicherry21-Jan-21 7:46
sureshpondicherry21-Jan-21 7:46 
AnswerRe: dicom error Pin
Richard MacCutchan21-Jan-21 22:02
mveRichard MacCutchan21-Jan-21 22:02 
GeneralRe: dicom error Pin
sureshpondicherry25-Jan-21 5:05
sureshpondicherry25-Jan-21 5:05 
Questionswedish file read Pin
Member 1474115220-Jan-21 8:54
Member 1474115220-Jan-21 8:54 
AnswerRe: swedish file read Pin
trønderen20-Jan-21 9:11
trønderen20-Jan-21 9:11 
AnswerRe: swedish file read Pin
Richard MacCutchan20-Jan-21 21:11
mveRichard MacCutchan20-Jan-21 21:11 
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 

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.