On 2013-05-01 15:53, 姬 明超 wrote:
在 2013-5-2，上午3:34，legalize+jeeves@mail.xmission.com (Richard) 写道：
I think boost.multiprecision has a good example to follow: you specify a back-end as a template argument, where the backends can be an existing library or a boost licensed implementation. The boost licensed implementation needn't be as fast or memory efficient as the existing libraries, the emphasis should be on simplest implementation that can satisfy the backend requirements of the front end library, without beeing too slow or memory intensive. Thanks for your helpful instruction! I'll look into boost.multiprecision to see how it solve this problem.
I honestly doubt that making the choice of backend a template parameter is an appropriate approach, at least for boost.xml. Why would someone want to control this choice by means of a template parameter, as opposed to a configuration / build system flag ? Would you want to instantiate multiple backend bindings in the same application ?
But according to your explanation, boost still need its own xml library implementation. Am I correct?
That's exactly what I was referring to as a "foolish idea": XML is big, and implementing a conforming API a highly non-trivial (multi-year) task.
Currently, boost use rapidXML, a 3rd-party xml library, to read or write xml files.
I think boost uses a couple of implementations, none of which are truly XML compliant (mostly because they only care about subsets of the spec, depending on what use-case they are targeting).
Then I think this project can be divided into two parts. 1. Define a good API and map it to some 3rd-party libraries such as libxml2. 2. Implement a simple xml library for boost.
I think 2. is far too ambitious for a GSoC project. I'd thus focus on 1. Specifically, I would start with existing C++ XML APIs (including my boost.xml sandbox project, as well as arabica), and improve and refine them, as appropriate. Stefan -- ...ich hab' noch einen Koffer in Berlin...