April 2010 - Boost - lists.boost.org

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 20 Apr '10

20 Apr '10

Thomas Jordan wrote: > [snip] > Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > Roland Bock replied: ************************************ Hi Thomas, we don't say it isn't possible :-) Here you go: // ----------------------------------------------------------- #include <boost/bind.hpp> #include <boost/bind/protect.hpp> #include <boost/function.hpp> #include <vector> #include <iostream> using namespace std; using namespace boost; int initValue = 0; class myClass { public: myClass(): mValue(initValue) {} myClass(const myClass& rhs): mValue(initValue++) { } void func() { cout << mValue << endl; } private: int mValue; }; typedef vector<myClass> vocType; typedef vector<vocType> vovType; int main() { vovType vov(10, vocType(10, myClass())); for_each(vov.begin(), vov.end(), bind(for_each< vocType::iterator, function<void (myClass&)> >, bind<vocType::iterator>(&vocType::begin, _1), bind<vocType::iterator>(&vocType::end, _1), protect(bind(&myClass::func, _1)) ) ); } // ----------------------------------------------------------- Please let me know if this is working for you. Regards, Roland ************************************************************** Thanks a lot, Roland, this looks good. I felt there must be some way to do it, but it was just beyond my grasp. Always learning! Regards, Tom.

2 1

[config] Compiler defects value-initialization
by Niels Dekker - address until 2010-10-10 20 Apr '10

20 Apr '10

The Config/trunk regression page currently shows some detailed information of various compiler defects regarding value-initialization: http://www.boost.org/development/tests/trunk/developer/config_.html If anyone wants to have a look at these results, please do so quickly! The output is from boost_no_complete_value_initialization::test(), which tests whether a specific compiler should have a new defect macro defined, BOOST_NO_COMPLETE_VALUE_INITIALIZATION. In a few days, I'm planning to add this definition to the Boost Config files of those compilers [Boost #4080], and then the test output will disappear automatically. According to the current test results, two compilers do an excellent job w.r.t. value-initialization: Intel (10.1, 11.0, 11.1) on Mac OS X, and GCC 4.4.3 (both on Linux and Windows). Compilers that don't completely do value-initialization include Microsoft Visual C++ (including msvc-10.0), Borland (including CodeGear 2010), Sun 5.10, and IBM XL V10.1. The MSVC defect was reported back in 2005 [Visual Studio #100744]. I recently reported the value-initialization defects I encountered on Embarcadero CodeGear [Embarcadero #83751, #83851] and IBM XL. The Windows version of Intel 11.1 doesn't do so well either, according to results from Huang-Vista-x86_32_intel. I still wonder why, because on Mac OS X, Intel does so well. GCC also has regression failures w.r.t. value-initialization, but those are only on earlier GCC versions, like gcc-4.2.4 and gcc-4.3.4. The last GCC bug in this area, AFAIK, [GCC #30111] was fixed for GCC 4.4. As far as I have seen, any compiler supports value-initialization of integers, floating point numbers and pointers correctly. However, problems occur for structs, classes, and arrays. Objects of those types may be left partially or entirely uninitialized, when they should have been value-initialized, depending on the compiler. I hope to have the test and the defect macro included with Boost 1.44. Please let me know if you have any comment or question about them. https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_i… Kind regards, Niels References: [Boost #4080] "Various compilers need BOOST_NO_COMPLETE_VALUE_INITIALIZATION", https://svn.boost.org/trac/boost/ticket/4080 [Visual Studio #100744] "Value-initialization in new-expression", reported by Pavel Kuznetsov: https://connect.microsoft.com/VisualStudio/feedback/details/100744 [Embarcadero #83751, #83851] Two value-initialization bugs I recently reported: http://qc.embarcadero.com/wc/qcmain.aspx?d=83751 http://qc.embarcadero.com/wc/qcmain.aspx?d=83851 [GCC #30111] "Value-initialization of POD base class doesn't initialize members", reported by Jason Merrill: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type offor_each?
by Thomas Jordan 19 Apr '10

19 Apr '10

Thomas Jordan wrote: > Thanks a lot for the suggestion, I did take a look at Lambda library, and > I saw that it used some extra type information in its STL > algorithm wrappers (the 'sig') to help it figure out the return types. > However, I am against using the Lambda library > for other reasons, I only want to use the bind library. I'd appreciate > some specific advice on how to get the type deduction > with the Boost.bind library. Or is this just not possible with > Boost.bind? Peter Dimov replied: ----------------- It's not. Boost.Bind only supports function objects with a specific, fixed type. There is no mechanism to tell it that the return type of struct myForEach { template <typename II, typename F> F operator()(II begin, II end, F function) const { return std::for_each(begin, end, function); } }; is the same as its third argument. In this specific case I'd just use struct myForEach { typedef void result_type; template <typename II, typename F> void operator()(II begin, II end, F function) const { std::for_each(begin, end, function); } }; -------------------- Thanks, Peter, and thanks to everyone else who replied, for their helpful suggestions. FWIW, I'm putting together a presentation for my colleagues, to show the facilities for higher-order programming in STL and Boost, and I wanted to show a couple of 'out-there' examples to illustrate their power. I'm a bit of an arriviste and my C++ is 'improving,' but I'm really impressed that you can do functional-style programming so nicely in C++. Regards, Tom.

2 1

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