- Boost - lists.boost.org

libzeep
by Maarten L. Hekkelman 19 Apr '10

19 Apr '10

As I announced earlier, I've released a library that can be used to create SOAP servers. Since this code relies heavily on XML, I've implemented a full XML parser and XPath implementation as well. I've read a bit in the discussion on this forum regarding the implementation of XML parsers and I get the feeling some don't fully appreciate the amount of work that goes into writing a validating parser. There really is more to XML than the characters < and >. :-) If there's a DOCTYPE, the results of parsing a file can be surprising since the DTD can e.g. specify default attribute values. To test libzeep I'm using the 1808 test files provided by the w3c organisation. Of these I only test against 1490 since the others only check unicode characters that are allowed since XML version 1.1. Of the remaining 1490 only 14 produce dubious output, I'm not really sure if these tests are wrong or that my code is incorrect. Anyway, libzeep performs quite nicely. The code has not yet been profiled but I've been able to replace libxml2 in all my projects and see hardly any performance degradation and my code looks much better now. All in all, I think libzeep is quite feature complete, robust and performs nicely. I've released the code and minimal documentation at http://www.cmbi.ru.nl/libzeep Now suppose people here are interested in this library, I'm willing to spend some time to upgrade the code to boost quality standards and write more documentation. And if the boost community prefers another approach I'm willing to provide help based on my recent experience. I'm looking forward to your feedback. -maarten

9 15

[exception] [shared_ptr] ADL problem with msvc 10
by Steven Watanabe 19 Apr '10

19 Apr '10

AMDG I just tried to compile the following #include <boost/exception_ptr.hpp> void f() {} msvc 10 complains, 1>c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(48): error C2660: 'f' : function does not take 1 arguments 1> c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(66) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(171) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(188) : see reference to function template instantiation 'const E &boost::exception_detail::set_info<E,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(132) : see reference to function template instantiation 'const boost::unknown_exception &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(111) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 1> with 1> [ 1> E=std::exception 1> ] This appears to be because type_info is defined in the global namespace, so ADL for boost::error_info<boost::tag_original_exception_type, const type_info *> picks up the global f. I don't have a fix for this yet. In Christ, Steven Watanabe

3 5

Fwd: [Boost-users] [Review] [ITL] ITL formal review results
by Joachim Faulhaber 19 Apr '10

19 Apr '10

---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2010/4/19 Subject: Re: [Boost-users] [Review] [ITL] ITL formal review results To: boost-users(a)lists.boost.org Hi Hartmut, list, 2010/4/18 Hartmut Kaiser <hartmut.kaiser(a)gmail.com>: > Hi all, > > The formal review of the Interval Template Library (ITL) written by Joachim > Faulhaber started February 18th and ended March 7th, 2010. We saw a lively > discussion resulting in 14 votes: 10 people voted unconditionally YES, 3 > voted conditionally YES, and 1 reviewer voted NO. > > The overwhelming majority of the votes was YES which reflects the overall > discussion and the general consensus of this library being worth to be > included into Boost. > > Based on this result and the discussions we saw the Interval Template > Library is now formally accepted into Boost. > > > Detailed results > ---------------- > > Pros: > > Almost all reviewers highlighted the general usefulness of the library. The > more experience the reviewers had with the library in real world > applications the more they emphasized its usefulness. Here are some quotes: > - "ITL solved this problem for me, in a way that honestly freed me from > having to think about a lot of the unsavory low-level details." > - " Until now, we only used the library for intervals of date-times (coded > as integers), but I'm sure, that its usefulness goes far beyond." > - " Very useful. I mentioned two projects where the library would have > helped me if it had been into Boost earlier, and I'm considering rewriting > them such that the problems make use of the library, and simplify them in > that way." > > The comments on the quality of the documentation are unanimous: "impressive > and quite complete", "I couldn't ask for more". It seemed to be generally > helpful to understand the concepts of the library and to get started. Some > people asked to add more simple quick-start examples to the documentation > and the distribution. > > Overall, the library is mature and easy to use. All reviewers actually > utilizing the ITL library for real world use cases reported they were able > to start quickly and without problems. > > All reviewers using ITL in real world applications stated that no > performance problems were encountered. This is important to note as the NO > vote was based on the current lack of a interval tree implementation, which > was considered to result in suboptimal performance for certain use cases. > > > Cons: > > Some aspects of the design have been criticized: "OO-type design decisions", > "fat 'one size fits all'-interval class template", and "incomplete > extraction of global functions" are the major points of critique. These > points have real merit. In order to make the design and interface more > flexible and more durable these have to be rectified before the final > inclusion of the library into Boost's code base. Joachim already agreed to a > list of things to change addressing those problems. > > For certain use cases, specifically for interval map of collections, the > current implementation has suboptimal complexity characteristics that leads > to O(n^2) space usage in the worst case. OTOH, for the majority of > applications of the library the worst case scenario seems to be (reportedly) > irrelevant. This issue has been discussed at length and Joachim plans to add > an implementation with a better worst case performance of the affected class > templates as later optimizations. This is not considered to be a > precondition to full inclusion into Boost's code base as it is not > anticipated to cause any interface changes. > > Last but not least people suggested to change the name of the library as > having the word template in the name does not carry any useful information. > Joachim already agreed to this. > > Regards Hartmut > Review Manager Thank you, Hartmut, for summarizing the review and declaring the results. I am of course happy to hear that my library of interval containers is now accepted. Concerning the review itself, I'd like to say that it was a very valuable experience for me. I definitely learned a lot during the process. So I'd like to thank all the reviewers and other participants in the discussion for taking so much time to examine my project and to share their knowledge and assessments. I'd like to emphasize two points: (1) For me as contributor is has been very rewarding to see, that my library has found quite a few users who not only use the ITL in real world applications but also confirm the usefulness of its concepts and patterns (e.g. aggregate on overlap), that simplify writing programs for problems that reoccur in a variety of problem domains. It was this basic feeling of usefulness that made me undertake the journey of boostifying, refactoring, documenting, polishing and submitting my code, which was much more work than I initially expected. But reading those reviews made me feel that it was worth the effort. So special thanks to my "real world"- users among the reviewers: Peter Wuttke, Eric Jonas, Michael Caisse and Jeff Flinn. (2) A review on the boost list is probably a challenge for most contributors. The important part is to encounter once own limitations and blind spots. Because these are the fields where one can learn most. We find these kinds of (at first) mostly unpleasant information within a boost review, when fellow developers examine the project closely and share their view on its flaws and problems. I have learned very much from that and I am currently really having fun applying those improvements to the library. So special thanks for sharing critique and objections to Phil Endecott, Luke Simonson, Jeff Flinn, John Reid and Barend Gehrels. And last but not least, I'd like to thank Rob Stewart who gave me feed back about some lingual pitfalls and oddities offlist. Very nice and helpful :) I have reworked the design on the interval concept already. I hope to be able to complete the discussed changes and improvements, as summarized by Hartmut above, within a few weeks after BoostCon2010. Cheers Joachim

1 0

[result_of] propose: change of maintainer
by Eric Niebler 19 Apr '10

19 Apr '10

Daniel Walker has volunteered to take over maintainer duties of utility/result_of from Doug Gregor, and Doug has agreed. Does anybody object? If not, I'll update the maintainers list. -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 5

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

How to manage Graph Property ?
by nguyen vu tri 19 Apr '10

19 Apr '10

Hi everyone, I really need help to figure out the following problem. -------------------------------------------------------------------------------- First, I create a Vertex Property: typedef property < vertex_index_t, int> VertexProperties; Then, I create an adjacency graph type: typedef adjacency_list < vecS, vecS, directedS, VertexProperties > Graph; Now I can call: VertexProperties V1; --------------------------------------------------------------------------------- My question is: Is there anyway that I can access *VertexProperties *through * Graph* to create the same variable *V1* ?. Thanks, in advance, for your time. I appreciate all suggestions, Tri Nguyen.

3 5

Requesting permission to merge r61326 into release branch
by Jeremiah Willcock 18 Apr '10

18 Apr '10

This change is a one-line fix to a trivial bug where the wrong number of arguments was used in a function call. May I please merge it so it gets into 1.43.0? -- Jeremiah Willcock

3 12

Idea: Boost.Allocator
by joel falcou 18 Apr '10

18 Apr '10

I recently had to use Boost Iterator Facade and its relatives and found the idea great. It occured to me whiel lookign at my X different, hand written allocaotrs for various project that maybe such a system for writing std allocator could be great. Buildign a new allcoator will just be impelemnt some allocator_facade<> adn fill some small scale methods. Moreover, it could be the opportunity to add new allocator concept like allocator supporting resize calls, allcoator with state, allcoator with a allocated() method etc... and reality-check them in the boost framework. How does it sounds ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 5

Re: [boost] [GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
by Stephan T. Lavavej 18 Apr '10

18 Apr '10

[Christian Buchner] > We found that GCC 4.4 on Linux was about 100% faster than Visual C++ > 2008 on Linux without modifying the code. Wow, I didn't know that VC9 could target that platform. ;-) > we attributed much of the performance difference to sub-optimal memory > heap management of Visual C++ 2008. VC's default implementation of ::operator new() calls malloc(), which calls HeapAlloc() from the Windows API. HeapAlloc()'s implementation is mostly a mystery to me, but there are a couple of things about it that you should probably be aware of. First, on WinXP and higher (note that VC9 supported targeting Win2K, but VC10 doesn't), Windows implements the Low Fragmentation Heap (LFH). The LFH services "small" allocations (definitely sub-KB; I'd have to ask around in order to figure out the precise limit) from buckets, so applications that allocate lots of small chunks of memory (like nodes) can benefit significantly from the LFH. I believe it performs other wizardry which I'm not aware of. However, on some platforms, the LFH is not enabled by default. You can request it by calling HeapSetInformation() on the CRT heap. There are two situations where the LFH is enabled by default. First, VC enables the LFH for its CRT heap when targeting x64. (For obscure reasons, we can't do this for x86.) Second, WinVista and higher automagically enable the LFH when they detect allocation patterns that would benefit from this. I've spoken to the LFH's maintainers, and they say that this automagic machinery is sufficiently smart, that enabling the LFH manually is no longer necessary (i.e. they have never seen that produce an observable benefit). > Then we tried recompiling the project with Visual C++ 2010 Ultimate > Release Candidate (RC). The speed gain of the algorithm was 900% (not > joking) and the results still appear to be correct. This greatly amuses me, as I talked about seeing order-of-magnitude performance improvements but never expected to actually see one in the real world. This is almost certainly due to rvalue references, as nothing else that we did could possibly have had so large of an effect. VC10 implemented rvalue references (v2, but not the stuff in the FCD that automatically generates move ctors/assigns), and we updated the Standard Library to take advantage of them (both by providing move ctors/assigns on Standard Library types like vector, and by taking advantage of move ctors/assigns during operations like vector reallocation). > Is anyone else seeing similar speedups in boost or in the geometry > library when compiling with Visual C++ 2010 RC (HINT: it's a free > download, so anyone can try it out until end of June 2010). Note that VC10 RC is perfectly representative of VC10 RTM. The compiler and linker are unchanged, and the Standard Library received exactly one bugfix (for obnoxious compiler errors in shared_ptr). Also note that while GCC 4.3 and higher support rvalue references (v1 in 4.3 and 4.4, v2 in 4.5), they are not enabled by default. You must compile with either -std=c++0x or -std=gnu++0x in order to activate their C++0x mode. I'd be interested to learn how VC10 fares against GCC in C++0x mode. (I'm unsure as to when and to what extent rvalue references were applied to GCC's Standard Library implementation libstdc++. As GCC 4.5 was released mere days after VC10, that would generate the most fair comparison.) About _SECURE_SCL, the worst performance penalty that I've ever seen it exact is 2x. It could have been responsible (along with allocator mumbo-jumbo) for the 100% difference you observed between GCC 4.4 and VC9, but not for the 900% difference between VC9 and VC10 (unless you have discovered a truly astounding pathological case). _SECURE_SCL (now combined with _HAS_ITERATOR_DEBUGGING into _ITERATOR_DEBUG_LEVEL) in VC10 is now disabled by default in release mode. (In debug mode, _HAS_ITERATOR_DEBUGGING, aka _ITERATOR_DEBUG_LEVEL=2, is still enabled by default - it can affect performance significantly, but provides exhaustive correctness checks, and debug performance isn't especially important unless it's 1000x slower and renders the program too slow to debug.) VC10's linker now deterministically detects when you're mixing translation units compiled with different settings of _ITERATOR_DEBUG_LEVEL, so that (combined with the new default of 0 in release mode) will put an end to the bad old days of incomprehensible ODR violations triggered by attempting to disable this machinery in some but not all libraries. Do note that mixing major compiler versions (e.g. VC9 and VC10) is still completely forbidden when you're using the C++ Standard Library, as we break binary compatibility between every major version and will continue to do so for the foreseeable future. Unfortunately, the linker's new feature (#pragma detect_mismatch) is unable to detect VC9 and VC10 mixing, so you'll just have to be careful. (The machinery is in place for us to detect VC10 and VC11 mixing.) [Barend Gehrels] > I've asked last year during BoostCon to Microsoft, present there, if > they knew this issue, but apparently they didn't, and told me it would > surprise him because the compiler basically was the same. (That was me.) > When I used after that once the VC 2008 command line compiler (so not > from Visual Studio) the problem disappeared. So it was fast. So it was > not the compiler itself, it was some setting in the IDE or VPROJ. I've > never managed to find which setting, though I studied it carefully. According to my understanding, the VS 2008 IDE had a bug when upgrading VS 2005 projects, where optimization settings would be lost. I'm unsure of what the exact symptoms of the bug looked like (I thought it was just the /O options), but your experience (that it disappeared when you used the command line) perfectly fits with this hypothesis. Alternatively, you could create a VS 2008 project from scratch. I believe that VS 2010's project system (which underwent a massive overhaul) does not suffer from this bug when upgrading either VS 2005 or VS 2008 projects, but I don't know what happens when you take a project that was damaged by the VS 2005 to VS 2008 upgrade, and then upgrade it to VS 2010. I suspect that in that case, the damage persists. My understanding of this is vague because I don't use IDE build systems. Stephan T. Lavavej Visual C++ Libraries Developer

2 1

[call-traits][param_type] why is sizeof(void*) chosen as the limit for passing by value?
by Thorsten Ottosen 17 Apr '10

17 Apr '10

Hi Boosters, It seems to me that many other slightly larger types could benefit from pass by value. For example, I rarely write foo( const double& ); but always foo( double ); So param_type<T>::type don't even follow this guideline. I tried a simple example program for the auto_buffer (vector like) class I'm implementing: #include <boost/auto_buffer/auto_buffer.hpp> int main() { boost::auto_buffer<double> buf( 2001u ); buf.push_back(42.); } When I pass by value in push_back(), the assembler is somewhat different, and as far as I can tell, better. Basically my compiler (vc9) can inline the load of 42. into push_back() whereas in the call by reference, the parameter is passes by a pointer (in a register). In the by-value version the compiler is able to optimize away completely the call to alllocate and delete memory whereas this is not so for the by-reference version. This makes me wonder why we shouldn't expect e.g. std::pair<int,int> and std::bitset<64> to be easily passable in registers. With this in mind, I think we should consider changing the limit for param_type to sizeof(long double) or even 2*sizeof(int). Of course, we should only pass types with a trivial assignment operator by value. Any thoughts? -Thorsten

4 4