Question about useful libraries
Hello all! I want to ask an important question to the leading developers of Boost. The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost. But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library. Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today? Thanks. - Denis
2011/6/28 Denis Shevchenko <for.dshevchenko@gmail.com>:
Hello all!
I want to ask an important question to the leading developers of Boost.
The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost.
But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library.
Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today?
Thanks.
- Denis _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
If I understand correctly you want people to chip on what they feel is missing? If that's the case I do feel there's room for a fully featured XML parser / writer library, and that is for numerous reasons. First of all XML usage is very wide spread and I do believe it's a fairly common 3rd party dependency. Secondly an XML parser / writer can be written to a very high quality using the libraries already present in boost ( spirit & iostreams comes to mind ), because of this I think it could double as a great example for those libraries as well as proving their viability. Furthermore I don't think there's any really high quality C++ xml libraries out there, having been forced to use a few. They're either written in C or severely flawed in some way, sometimes both. Kind regards, Sebastian Karlsson
On 06/28/2011 01:17 PM, Sebastian Karlsson wrote:
Secondly an XML parser / writer can be written to a very high quality using the libraries already present in boost ( spirit& iostreams comes to mind )
A spirit-based XML parser doesn't seem that great. If using semantic actions, it would necessarily be SAX-like. If using attributes, it would be like the DOM, and you would have to be careful not to copy everywhere. My impression was that Pull-like interfaces -- lazy parsing of XML as it is being iterated -- were more popular.
2011/6/29 Mathias Gaunard <mathias.gaunard@ens-lyon.org>:
On 06/28/2011 01:17 PM, Sebastian Karlsson wrote:
Secondly an XML parser / writer can be written to a very high quality using the libraries already present in boost ( spirit& iostreams comes to mind )
A spirit-based XML parser doesn't seem that great.
If using semantic actions, it would necessarily be SAX-like. If using attributes, it would be like the DOM, and you would have to be careful not to copy everywhere.
My impression was that Pull-like interfaces -- lazy parsing of XML as it is being iterated -- were more popular.
Can't say I'm an expert on lazy parsing of XML, but there's certainly pros & cons between SAX & DOM based parsers, and I would assume the same holds true for lazy parsers ( which I presume would have a DOM like interface ). For example, access which is non linear would perhaps have inferior runtime characteristics compared to eager variants as the media access often becomes the bottleneck. In any case I think there's a lot of interesting implementation details which no C++ XML library seems to have got quite right yet, using spirit or not naturally would come down to whomever would be interesting to have a go at it. Another detail which could be interesting is parametrizing the tag/attribute name, as there's usually quite a few duplicates boost::flyweight<> could be a big win in a lot of use cases for a fairly small effort. Overall I'm very confident that a top notch XML library would get a ton of use and be a popular addition. I also certainly agree with Joel, I would even go as far as saying there's perhaps a few libraries which should be kicked out of the distribution. Overall I feel there's a few libraries which have no place in a production environment, having gone to far down their own rabbit hole so to speak. Some are to close in what they're trying to solve and should be merged.
On Wed, Jun 29, 2011 at 2:40 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 06/28/2011 01:17 PM, Sebastian Karlsson wrote:
Secondly an XML parser / writer can be written to a very high quality using the libraries already present in boost ( spirit& iostreams comes to mind )
A spirit-based XML parser doesn't seem that great.
If using semantic actions, it would necessarily be SAX-like. If using attributes, it would be like the DOM, and you would have to be careful not to copy everywhere.
I didn't get a chance to read this before my last post. These are some good points.
My impression was that Pull-like interfaces -- lazy parsing of XML as it is being iterated -- were more popular.
This couldn't be accomplished with Spirit? That sounds like a challenge...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Jun 28, 2011 at 7:17 AM, Sebastian Karlsson <sairony@gmail.com> wrote:
I do feel there's room for a fully featured XML parser / writer library.
Doesn't Boost.PropertyTree have some of this functionality? The first step you might want to take is to diff what you consider "fully featured" with what's available in PropertyTree (with which I admittedly have only passing familiarity). If it were not the case that Boost.PropertyTree is or could be extended to a "fully featured" XML parser, then Boost.Spirit.Qi/Karma could certainly do the trick. Actually, one of the examples in the Spirit.Qi docs is a simple XML parser if I'm not mistaken.
Kind regards, Sebastian Karlsson _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 28/06/11 05:09, Denis Shevchenko wrote:
Hello all!
I want to ask an important question to the leading developers of Boost.
The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost.
But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library.
Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today?
Thanks.
Well, I'll probably looks like a party crasher here but. I think currently Boost dont require *more* library, it requires a consolidated base of more *stable* libraries. I remember that I was drawn to the Boost Community because of its willingness to contribute to how C++ is used properly, pushing compiler limits out of bounds and, de facto, making compiler vendors improve their compilers. Boost also spawned a lot of standard worthy library, languages feature or good practices. What I will find worthy to be done is actively move toward C++11 and starts putting the pressure back on compilers and explore the new practice C++11 can bring or see how it will modify existing one. I think it is Boost role to promote this new standard by force feeding it a bit so it gets accepted. If not it'll basically be C99 all over again. I think the time is right now to pause a bit, look at the road we walked and consolidate ourselves, both a community and as a software project before engaging into the next part of the journey C++11 just opened. My 0,02 euros.
On 28 June 2011 18:25, Joel falcou <joel.falcou@gmail.com> wrote:
On 28/06/11 05:09, Denis Shevchenko wrote:
Hello all!
I want to ask an important question to the leading developers of Boost.
The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost.
But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library.
Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today?
Thanks.
Well, I'll probably looks like a party crasher here but.
I think currently Boost dont require *more* library, it requires a consolidated base of more *stable* libraries.
I remember that I was drawn to the Boost Community because of its willingness to contribute to how C++ is used properly, pushing compiler limits out of bounds and, de facto, making compiler vendors improve their compilers. Boost also spawned a lot of standard worthy library, languages feature or good practices.
What I will find worthy to be done is actively move toward C++11 and starts putting the pressure back on compilers and explore the new practice C++11 can bring or see how it will modify existing one. I think it is Boost role to promote this new standard by force feeding it a bit so it gets accepted. If not it'll basically be C99 all over again.
I think the time is right now to pause a bit, look at the road we walked and consolidate ourselves, both a community and as a software project before engaging into the next part of the journey C++11 just opened.
My 0,02 euros.
Since I'm writing a library for inclusion into boost I hate to say this, but I agree. People seem to be getting tired of reviews which will lead to one of two things: 1: Nice libraries not being included because of a lack of votes, or worse 2: Libraries which wouldn't normally be accepted but which are, again because of a lack of votes. Neither of these are very appealing and I hope the newly appointed Steering Committee can do something about this. Jeroen
Jeroen Habraken wrote:
People seem to be getting tired of reviews which will lead to one of two things:
1: Nice libraries not being included because of a lack of votes, or worse 2: Libraries which wouldn't normally be accepted but which are, again because of a lack of votes.
Neither of these are very appealing and I hope the newly appointed Steering Committee can do something about this.
The Steering Committee isn't likely to intervene in this area. Overseeing reviews is the job of the Review Wizards. You should address your concerns to them. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Joel falcou <joel.falcou <at> gmail.com> writes:
On 28/06/11 05:09, Denis Shevchenko wrote:
[…] Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today?
Thanks.
Well, I'll probably looks like a party crasher here but.
I think currently Boost dont require *more* library, it requires a consolidated base of more *stable* libraries.
[…]
What I will find worthy to be done is actively move toward C++11 and starts putting the pressure back on compilers and explore the new practice C++11 can bring or see how it will modify existing one
[…]
I think the time is right now to pause a bit, look at the road we walked and consolidate ourselves, both a community and as a software project before engaging into the next part of the journey C++11 just opened.
While I agree with you on the need to "consolidate ourselves" on *stable* (as in stabilizing for future standardization), I think that we should *also* be "engaging into the next part of the journey C++11 just opened" at the same time (if only to keep having libraries to stabilize), just the same as GNU/Linux distributions have stable and experimental release at the same time. I'd see boost as both a place to explore how to solve new areas of interest (the OP point of view) and a place to find a stable consensus on the state-of-the art (your answer as I understand it). FWIW, to answer the OP question, I'd like to see boost solve unicode processing in C++ (I find current state-of-the art a failure except for the work of Mathias Gaunard) and multithread friendly data structures (could persistent data structures be implemented with smart pointers memory managment ? I'd like to give it a try, but for now I'm moving to Clojure for this kind of code). Best Regards, B.
On Tue, Jun 28, 2011 at 6:09 AM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
Hello all!
I want to ask an important question to the leading developers of Boost.
The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost.
But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library.
Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today?
I am not a "leading developer of Boost" by any measure, but since I don't see a "-dev" in the list address, I think I'm ok to respond. I think that Boost could definitely use a framework for describing constraint satisfaction problems. Actually, I think such a framework could readily be built on top of Boost.Graph. I had planned to work on such a library once I felt comfortable enough with C++ and the way things are done in the Boost community, so that I don't end up embarrassing myself too much. I'd be glad to see it, though, whether it was my creation or not. Greg
participants (8)
-
BernardH -
Denis Shevchenko -
Greg Rubino -
Jeroen Habraken -
Joel falcou -
Mathias Gaunard -
Sebastian Karlsson -
Stewart, Robert