Re: [Boost-users] finite state filters controlled ...

Subject: Re: [Boost-users] finite state filters controlled ...
From: raespi (raespi_at_[hidden])
Date: 2014-02-19 08:01:25

You mean avoiding the filters altogether ?? Yes I could do that, I was 
wondering if FSF could help me in the last stated scenario ...

On 02/18/2014 06:33 PM, Nat Goodspeed wrote:
> On Tue, Feb 18, 2014 at 4:18 PM, raespi <raespi_at_[hidden]> wrote:
>
>> Boost hi .. I'm using the finite state filter component in the iostreams
>> library to create a state machine that can easily help me process incoming
>> data streams from various medical sensors.
>>
>> 1- Constant datastream with no variation in datagrams.  Solution: use finite
>> state filters as they come, works ok !
>> 2- Variable datastreams with constant size in datagrams. Solution: use
>> finite state filters with a transition table that can interpret anything and
>> choosing in the processing function the right way to go, not very clean, but
>> works !!
>> 3- Variable datastreams with variable sizes.  Solution: trying to change the
>> finite state filter on the go, currently doesn't work.  I noticed that when
>> bytes are inserted into the state machine these don't get processed until a
>> certain buffer size is met internally, resulting in a behaviour where data
>> gets analyzed long after it has been inserted.  I saw that the flush()
>> function for the iostream that contains de state machine suffices when
>> called before inserting a new character with a line such as:
>>
>> io::flush<io::filtering_ostream> ( this->data );
>>
>> but the problem is that the only mechanism that can determine when a whole
>> package has been received and one can change state machines to analyze a new
>> state lies within the state machine itself (in the processing functions), I
>> can't issue a flush() from within a state machine since it won't execute
>> until a specific buffer size is met.
>>
>> Any ideas on how to go around this matter ??
> Disclaimer: I haven't used the state machine filter for iostreams, so
> I can't answer the problem as stated.
>
> However, you might consider using a coroutine to process your incoming
> data? The coroutine could make dynamic decisions (using normal C++
> control structures) about what to do with each new chunk of received
> data.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>