On Mon, Oct 12, 2009 at 7:43 AM, Wim Dumon <[email protected]> wrote: > Looking forward to your contribution... When did Spirit2 make its > intro? Currently we depend on boost >= 1.35, and I'm wondering if we > should support Spirit.Classic for backward compatibility reasons. > There's no need to put parts of boost in Wt.
Boost.Spirit2.0 (missing many features over Classic, but is still faster in execution speed, slower in compile speed) was released with Boost 1.39. Boost.Spirit2.1 (includes all of the features and much more, faster execution speed, faster compile speed) will be released in Boost 1.41. Boost.Spirit2.2 (adds customization feature points that make writing grammars with very odd constructs really easy, Wt would not need that feature) will be released in Boost 1.42. Boost has a tool called bcp. bcp allows you to say what parts of boost you want to use and it will extract those parts, dependencies, and etc... into a directory of your choosing; it can also rename the boost namespace to something else; and all extracted headers are designed to co-exist with any installed Boost of any version as it is completely self-contained. Boost is designed to be split up like this, take the parts you want and include it in your own projects, where boost can still be installed on the system itself for if the library user wants to use other things that were not extracted by bcp. But yes, Boost.Spirit2.1+ is *tremendously* faster then Classic, and thus far it is tremendously faster then any other parser we have tested from ANTLR (ANTLR is slower then heck we found out) to decade-old hand-grown company parser code (where the Spirit2.1 code was about a hundred the length and outperformed it from between 2x to 8x, and was never slower) and many things in between (if you happen to find something that is faster, give it to us and we will make Spirit2.1+ faster then it as well). On Mon, Oct 12, 2009 at 7:47 AM, Wim Dumon <[email protected]> wrote: > The speed improvements are probably not worth switching to the new > signals, as this is not the area where the library spends a lot of > time. Better thread-safety would be a good thing (but the model of > boost.signal suits current Wt fine). I haven't looked at signals2 yet; > I hope it's a switch we can do under the hood without API changes. Regardless, any speed improvements are beneficial. The API is mostly the same, the changes are minor, and should not cause any front-end code changes from what I have seen thus far (except perhaps if people made their own signals they would need to change it to signal2 or so, can probably be worked around with a typedef or something). ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
