On Wed, Jan 14, 2015 at 10:07 PM, Julien Nitard wrote:

On 15 Jan 2015 02:58, "Gottlob Frege" wrote:

...

[snip]

...

My gut instinct is that FIX is too domain-specific, whereas Boost is typically domain-agnostic libraries. Nut maybe I'm wrong about that?

No you're not. I use fix at work and that's the last thing we'd expect from boost.

I don't feel the same way. I have been thinking of writing a FIX protocol parser based on boost.spirit for boost for a while already.

Julien

Regards, -- Felipe Magno de Almeida

15.01.2015 20:14, Gottlob Frege пишет:

>> In the future we will see more libraries of narrower application - because
>> we've already made libraries for the wider applications.
> Even when I wrote that FIX seemed to domain specific, I was thinking
> the same thing - if we've tackled the wide stuff, only the narrow
> stuff is left.
There are many general-purpose standards that are not supported by the 
C++ standard library yet:
- Unicode
- XML
- JSON
- HTTP
- Cryptography
- (you can look at the standard libraries of other languages for a more 
complete list)

I think that it is a good idea to support these standards in the Boost. 
Unfortunately, I think that FIX is far too domain-specific. As a boost 
user, I'm not against mentioning boost-licensed domain-specific 
libraries somewhere at the Boost web site but I don't think that these 
libraries should be included into the default boost distribution. The 
reasons are:

1. The library size does matter.
2. The boost community has to support everything that is included into 
the boost library. What if a maintainer of some library abandons it? For 
a general-purpose library, there are chances that someone will take 
responsibility for it. For a domain-specific library, such chances seem 
to be negligible.


--
Best regards,
Sergey Cheban

16.01.2015 0:10, Robert Ramey wrote:

...

1. The library size does matter. The above is predicated that Distribution of Boost Libraries will continue indefinately to be distributed as a complete package. Our recent efforts including modularization, reduction of dependencies, etc. will eventually result in a deployment model in which acceptance into boost and deployment will be decoupled. Users will install subsets of boost that they actually use. Well, we can invite some libraries into Boost after modularization. Or, someone could try to implement the boost.finance as a module for the modularized Boost.

So I think that trying too keep boost small - though attractive - doesn't look forward to the future. I think the main challenge to Boost and C++ in the future is to find a way to produce better quality libraries. It's not about keeping the library small. It's about benefits and costs of the decision to include a library into the Boost. Even after modularization, the costs will not completely disappear.

For those who wants just a set of independently maintained modules, we already have Github.

...

2. The boost community has to support everything that is included into the boost library. What if a maintainer of some library abandons it? For a general-purpose library, there are chances that someone will take responsibility for it. For a domain-specific library, such chances seem to be negligible.

True - and we need to find a way to address that. But that's no reason for keeping the library small or letting it grow - it's a different question. Good, big, cheap. Choose 2 of 3. Boost is cheap. I'd like it to be rather good than big.

-- Best regards, Sergey Cheban

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> { 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" 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

On 15 January 2015 at 20:33, Eelis wrote:

On 2015-01-12 23:55, Marius Dobrea wrote:

...

Let me know what you think.

It is very unlikely that a Boost FIX library would make the specific combination of interface/efficiency/complexity/configurability/extensibility compromises/tradeoffs/choices that suit the specific requirements we have for a FIX library at the trading company I work for. Nor would we benefit from integration with our other libraries and conventions. So a Boost FIX library would probably not be of much use to us.

I suspect that the above comment is true of most of the target audience. The deficiencies in the existing open-source libraries would be of significance primarily to those seeking to have edge in their implementation. It additionally would have the effect of making it harder for some of us to work on Boost. I have been able to get IP amendments to employment contracts because I have been able to show that Boost is not in competition with my employer. If Boost contained solutions to problems in the financial domain I would have been forced to decide between resigning from my job or continuing with Boost. I don't think I am alone in having had difficulty convincing my employer to make IP alterations to allow me to work on Boost. I am grateful that my recent employers (Aris, GETCO, and Tibra) have been prepared to go through the time and expense to provide accommodation to allow me to continue to contribute. I worry that if we start to include libraries that are for specific business domains that we would create barriers for programmers that want to work on Boost. I'm all for the development of a better open-source FIX library, but not as part of Boost. Regards, Neil Groves