Additional porblems with TutorialApplication

What steps will reproduce the problem?
1.Run: TutorialApplication template.txt messages.fast (attached files 1 
and 2)

The output I obtained from fixprotocol.org decoder @ 
http://fast.fixprotocol.org/templates.html is in msg_decoded.xml (attached 
file 3).

The output from TutorialApplication is and attached file 4 and shows that 
TutorialApplication was able to process only the first of four messages.

Versions of products:
 - FASTFix: quickfast_win_src_1_2
 - Boost: 1.42
 - Xerces: c-3.1.0
 - Operating system: MS XP Professional, 5.1.2600 Service Pack 2 Build 2600
 - Visual Studio: C++ 2008 Version 9.0.21022.8 RTM

Original issue reported on code.google.com by vvayng...@gmail.com on 13 Apr 2010 at 1:47

Attachments:

The problem happens because the TutorialApplication resets the decoder between 
every 
message.  This data does not expect that to happen.

TutorialApplication is not a general purpose application it was intended show 
the 
various pieces of QuickFAST in use in one situation.  

[Of course that would be lot more effective if I had tutorial templates and 
tutorial 
data to go with the tutorial application -- that's on my todo list]

If you comment out the assembler.setReset(true); statement in the 
TutorialApplication, it will work.

Or alternatively you could use the InterpretApplication.  This application 
hides more 
of the details -- it's intended to get the job done, not to teach.  When I 
tried it 
with your data and templates, the result was:

InterpretApplication -t template.txt -file messages.fast
Record #1  Field1[1]=10.550000000000001 Field2[2]=22.200000000000003 
Field3[3]=234.40000000000001 Field4[4]=34.200000000000003 
Field5[5]=345.20000000000005 Field6[6]=5200
Record #2  Field1[1]=10.540000000000001 Field2[2]=23.200000000000003 
Field3[3]=33.399999999999999 Field4[4]=24.200000000000003 
Field5[5]=34.200000000000003 Field6[6]=5200
Record #3  Field1[1]=10.534000000000001 Field2[2]=3.2000000000000002 
Field3[3]=33.450000000000003 Field4[4]=24.452000000000002 
Field5[5]=354.20000000000005 Field6[6]=5200
Record #4  Field1[1]=-10.23 Field2[2]=-235.20000000000002 Field3[3]=-
353.40000000000003 Field4[4]=-4.2000000000000002 Field5[5]=-374.20000000000005 
Field6[6]=5200

----------------------
Looking at this I see a formatting issue that happened because the Decimal 
class 
converted it's values to doubles in order to take advantage of the standard 
library 
formatting capabilities.  That led to some rounding errors which showed up in 
the 
above output.  

I decided to fix that by hand-coding a Decimal formatting routine that produces 
a 
string which exactly represents the Decimal value.   With that change in place, 
I get 
this:

Record #1  Field1[1]=10.55 Field2[2]=22.2 Field3[3]=234.4 Field4[4]=34.2 
Field5[5]=345.2 Field6[6]=5200
Record #2  Field1[1]=10.54 Field2[2]=23.2 Field3[3]=33.4 Field4[4]=24.2 
Field5[5]=34.2 Field6[6]=5200
Record #3  Field1[1]=10.534 Field2[2]=3.2 Field3[3]=33.45 Field4[4]=24.452 
Field5[5]=354.2 Field6[6]=5200
Record #4  Field1[1]=-10.23 Field2[2]=-235.2 Field3[3]=-353.4 Field4[4]=-4.2 
Field5[5]=-374.2 Field6[6]=5200

With a little work on the MessageInterpreter class you could produce results 
that are 
byte-for-byte identical with the FPL sample decoder's output.

The Decimal formatting change is checked into subversion as revision 392

Original comment by dale.wil...@gmail.com on 14 Apr 2010 at 8:03

Changed state: Invalid

zhaopuming / quickfast

Additional porblems with TutorialApplication #45