Ik wil voordeel halen uit recent advies van dit forum door mijn
project opnieuw te doen met behulp van de 'state machine'-logica,
in een poging om verspilling van processortijd en het gebruik van
variabelen te verminderen.
Ik start met de state-machine van Nick Gammons om de invoer
van de seriële poort te verwerken 'voorbeeld http://www.gammon.com.au/statemachine , die alle
verschillende mogelijke combinaties voor alle speciale
besturingstekens 'gebeurtenissen' tegen alle mogelijke
machinetoestanden toont - in wezen een tweedimensionaal raster.
Ik heb mijn doel verfijnd met het verwerken van seriële invoer
in een indeling van " opdracht [parameters]
[opties] ", vergelijkbaar met een
DOS-opdrachtregelindeling, bijvoorbeeld: DIR "c : \
programmabestanden "/ w/s . Dit zou me bevrijden van het
nodig hebben van een grote buffer [] en kop [] string, en vermijdt
elke paring,
Daarom zijn mijn besturingselementen voor gebeurtenissen:
spatie, komma, enkel aanhalingsteken, dubbele aanhalingstekens,
forward-slash, Carraige Return en mijn 'statussen' zijn
NULL, COMMAND, PARAMETER, OPTIONS
De status OPTIONS voegt tekens toe aan een tijdelijke tekenreeks
[] totdat een komma of spatie-scheidingsteken of Carraige Return
ervoor zorgt dat die optie naar behoren wordt verwerkt, waardoor de
waarde mogelijk wordt opgeslagen in een herkende variabele.
De COMMAND- en PARAMETER 'toestanden' voegen tekens toe aan hun
corresponderende commando [] en parameters [] strings, inclusief de
speciale controle karakters als ze zijn opgenomen in enkele of
dubbele aanhalingstekens (waardoor citaten deel uitmaken van een
string indien gebruikt binnen een paar van het andere type).
Er lijkt dus een tweede toestandsmachine nodig te zijn voor
NoQuotes, SingleQuotes en DoubleQuotes om de
werking van de COMMAND-, PARAMETER- en OPTIONS-staten te
wijzigen.
Hier heb ik geen neuronen meer, want het enige dat ik zie is een
onmogelijk complex 2-machine-toestand driedimensionaal raster met
te veel mogelijke permutaties.
Maar ik vermoed dat er een zeer praktische manier moet zijn om
dit te implementeren, omdat het de kern vormt van bijna alle
commandoregelhulpmiddelen die dateren uit een tijd dat
processorkracht en geheugenbeschikbaarheid zeldzamer waren dan die
van kippen, en die oude DOS-opdracht lijnhulpprogramma's moesten zo
klein mogelijk zijn als mogelijk was, inclusief het parseren van de
opdrachtregel.
Dus kan iemand een haalbaar model (machine-staat of anderszins)
voorstellen voor het verkrijgen van het commandoregel-type-formaat
uit de invoer?
BIJWERKEN
Oh lieverd ... ik heb zojuist een andere complicatie gezien die
ik nog niet eerder had gezien, namelijk dat '/' opties niet altijd
aan het einde zijn, wat betekent dat behalve als de opties staat
verandert door carraige-return, optietoestand verandering door
scheidingsteken moet terugkeren naar de staat voorafgaand aan de
wijziging van de optiestatus (pfff, ik hoop dat dat enigszins
logisch is). Hoe dan ook, ik denk dat het terug aan de tekentafel
is, omdat deze benadering waarschijnlijk te gecompliceerd lijkt,
zoals de 2 antwoorden al suggereren.