Re: [boost] Interest in a FIX Protocol Library?

Subject: Re: [boost] Interest in a FIX Protocol Library?
From: Marius Dobrea (mldobrea_at_[hidden])
Date: 2015-01-15 17:48:33

Let me give you one example I was thinking of recently.

Let's assume that you decide you want to use these fields types in your 
application: char, int, unsigned, double, std::chrono::time_point, 
boost::container::string.
You could define a basic 'component'  class as a mapping between the tag 
and a recursive variant of the types you chose and the 'component' itself.

class component : public boost::container::flat_map<traits::tag_type, 
boost::variant<char,int, unsigned, double,std::chrono::time_point, 
boost::container::string>>
{
public:
     using tag_type = traits::tag_type;
     using Base=boost::container::flat_map<...>;
     using field_type=boost::variant<...>;

     template<typename T>
     void putField(tag_type tag, T t)
     {
         Base::insert(Base::value_type{tag, field_type{t});
     }

     template<typename T>
     T& getField(tag_type tag)
     {
         Base::iterator it = Base::find(tag);
         if(it == Base::end())
             throw std::error("unexisting tag");
         return boost::get<T>(it->second);
     }
};

This seems to me a very powerful abstraction and please correct me if I 
am wrong. You have a stl-like container, you can iterate, apply 
algorithms, use Boost Range to chain them, etc.
Now the actual messages can be generated using the 'component' class. 
The ExecutionReport members provide among others syntactic sugar and 
compile time checking for field types and you already have most of the 
fields alloc free.

class ExecutionReport : public component
{
public:
     using Base = component;
     using tag_type = traits::tag_type;
     using amt_type = traits::amt_type;
     using int_type = traits::int_type;
     using string_type = traits::string_type;

     // observers
     const string_type& getAccount() { return 
Base::getField(tags::Account); }
     int_type getAccountType() { return Base::getField(tags::AccountType); }
     amt_type getAccruedInterestAmt() { return 
Base::getField(tags::AccruedInterestAmt); }
     // ...

     // modifiers
     void setAccount(string_type Account) { 
Base::setField(tags::Account, Account); }
     void setAccountType(int_type AccountType) { 
Base::setField(tags::AccountType, AccountType); }
     void setAccruedInterestAmt(amt_type AccruedInterestAmt) { 
Base::setField(tags::AccruedInterestAmt, AccruedInterestAmt); }
     // ...
};

> How would this be different from the quickfix library?
> On Jan 12, 2015 10:55 PM, "Marius Dobrea" <mldobrea_at_[hidden]> wrote:
>
>> Hello Boost,
>>
>> I have been following the boost email lists for a while now and would like
>> to contribute to Boost too.
>>
>> Since it matches at best my experience it would be probably most
>> beneficial if I contribute to a BOOST/FIX library. FIX comes from the
>> "Financial Information eXchange" Protocol and it represents a standard that
>> is used a lot in the Financial Industry. For more information see the
>> related Web Site: http://www.fixtradingcommunity.org.
>>
>> Firstly I would like to ask the community if there is interest in such a
>> library and if anyone is doing any work on it. It seems to me that although
>> there are a lot of firms and institutions in the world providing software
>> or using FIX there are too few open source C++ libraries for that.
>>
>> Secondly I would like to receive feedback on what functionality would be
>> interesting to be part of this library. For instance it could contain:
>> - basic components that can be used to build bigger blocks: e.g.: raw data
>> iterators, message components, field types;
>> - conversion functions from FIX to C++ types and vice versa;
>> - code generators for Messages, Enums, Constants based on XML
>> specification files;
>> - implementations for various FIX Session types: Tag-Value, FAST, FIXP,
>> user defined messages, etc;
>> - transformers which based on some configuration could convert messages
>> automatically between various FIX versions;
>> - message persistence, etc.
>>
>> FIX is very well documented and as such various functionality could be
>> probably easily split into interesting projects that are to be part of the
>> GSoC.
>>
>> Let me know what you think.
>>
>> Thanks,
>> Marius Dobrea
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/
>> mailman/listinfo.cgi/boost
>>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>