May 2011 - Boost - lists.preview.boost.org

[PBGL] Distributed adyacency_list memory allocation
by Cosimo Calabrese 06 May '11

06 May '11

Hi to all, I'm working on WinXP, VS2010, boost 1.46.1. I've writed this short program: //---------------------------------- #include <boost/graph/use_mpi.hpp> #include <boost/graph/distributed/mpi_process_group.hpp> #include <boost/graph/distributed/adjacency_list.hpp> using boost::graph::distributed::mpi_process_group; typedef boost::property<boost::vertex_distance_t, long, boost::property<boost::vertex_name_t, std::string > > vertex_prop; typedef boost::property<boost::edge_weight_t, long > edge_prop; typedef boost::adjacency_list< boost::vecS, boost::distributedS<mpi_process_group, boost::vecS>, boost::directedS, vertex_prop, edge_prop > Graph; typedef boost::graph_traits<Graph>::edge_descriptor EdgeDescriptor; typedef boost::graph_traits<Graph>::vertex_descriptor VertexDescriptor; int main(int argc, char* argv[]) { boost::mpi::environment env(argc,argv); Graph g( 10 ); return 0; } //---------------------------------- When I launch it, every process allocates about 1 GB of memory. Why it allocates all that memory? Is it normal? Is there any tuning to the PBGL framework that I must made? I use it on a 2-core machine, and the command that I use is: mpiexec -n 2 .\test.exe I've tried with openMPI 1.4.3 and Microsoft HPC Pack 2008, but it seems irrilevant. Thanks in advance, Cosimo Calabrese.

2 1

Extending multi_index_container hash tables
by Vladimir Voznesensky 06 May '11

06 May '11

Hello there. Current implementation of hashed index has, at least, two issues, preventing me from re-using it in some places. First, the time for unlink operation in multi_index/detail/hash_index_node.hpp is O(m) where m is a occupancy of the given bucket. I'ts usually ok for unique index, but seems to hit performance of removing item in a non-unique index. It's all because of using single-linked list instead of double-linked one. Second, there is no possibility to use internal order of the records in the bucket, i.e. operations like popping the last element in the bucket's list. Such feature could be useful for, for example, priority queues. It could be realized by using such double-linked (or extra pointers in a bucket structure). Sure, I could get the current realization and write my own index, but it seems wiser to extend the current implementation to support custom bucket container or custom node as a template parameter. Thanks in advance. VV

2 1

Re: [boost] [review] string convert
by Vicente BOTET 06 May '11

06 May '11

Hi, are we discussing here a generic interface from type-to-type or one that uses an intermediary stream to make the conversion? If it is the first I could accept names as convert_cast or convert_to. If it is the second, I don't think it is appropriated to use this generic form and something in the name must recall this feature. lexical_cast is used for exactly this purpose and the name is appropriated. How could we rename the Boost.Convert library? Boost.StreamConvert? and the operations? Best, vicente

4 9

[autoindex] Rationale Question
by Artyom 06 May '11

06 May '11

Hello, It is not a review but rather questions about this tool rationale. Form the very brief look into AutoIndex documentation I see. > ... AutoIndex will automatically scan one or > more C/C++ header files and extract all the > function, class, macro and typedef names that > are defined by those headers, and then insert > the <indexterm>s into the Docbook XML document for you. > However, there is a tool Doxygen that already does this. Doxygen is fully capable system for indexing source files and providing references for them. For example: http://cppcms.sourceforge.net/boost_locale/html/namespacemembers.html http://cppcms.sourceforge.net/boost_locale/html/namespacemembers_func.html So there is a well debugged, tested, supported indexing tool (Doxygen) that as far as I know works fine and is already used by Boost. So the question are 1. How does it differs from Doxygen indexing? I'm not talking about the integration with various pars of Boost documentation toolchain but rather what it does differently. 2. Why have you decided to develop entirely new tool instead of using existing one. I probably miss some points but I rather see a great tool Doxygen that already does many things and does them well but still Boost creates its own tools (and this does not happen first time) Thanks, Artyom

3 2

[xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

10 17

FW: Registration Available
by Hartmut Kaiser 06 May '11

06 May '11

FYI... Regards Hartmut --------------- http://boost-spirit.com > -----Original Message----- > From: boostcon-plan(a)googlegroups.com [mailto:boostcon- > plan(a)googlegroups.com] On Behalf Of Marshall Clow > Sent: Friday, May 06, 2011 11:25 AM > To: boostcon-plan(a)googlegroups.com > Subject: Registration Available > > Oliver Mueller <oliver.mueller(a)gmail.com> has discovered that he will not > be able to attend BoostCon. > Unfortunately for him, it is well past the refund deadline (which was > 4./14), so he's looking for someone to use his registration. > > If you know someone who could take advantage of a deal on admission, they > should get in touch with Oliver and work something out. > > -- Marshall > > Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki

1 0

Re: [boost] [Boost-users] [Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

On 6 May 2011 10:33, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 5/5/2011 9:08 PM, Vitaly Budovski wrote: >> Greetings, >> >> On 28 April 2011 12:09, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >>> Thanks for this! >> >> Apologies for the long delay in replying. >> >>> >>> A couple of comments: >>> >>> 1) Is there a reason why you created separate components instead of simply extending the existing set of binary parsers/generators? >> >> It seemed like it would be a lot more work. I'm guessing I would need >> to add a new template parameter or maybe use the preprocessor, since >> the classes have a few integer<> types inside. Can you suggest a >> better way? >> >>> >>> 2) What's the rationale for not using/extending the endian classes in Spirit, but providing your own set of independent endian types? >> >> See response above :) Another thing I wasn't too happy with was the >> fact that they are in the integer namespace. Perhaps they should be >> moved out of there, since endianness doesn't apply only to integers. >> >>> >>> 3) If this is to be included into Spirit we'd need the corresponding docs as well. >> >> A few more test cases couldn't hurt either. I discovered I missed an >> asterisk in the generate_to line of bin_float_generator. >> Is there a guide for adding docs to boost? > > Boost Spirit uses quickbook. Please check out the Spirit docs. > Here's a link to quickbook: > http://www.boost.org/doc/libs/1_46_1/doc/html/quickbook.html > > Vitaly, the proper forum for this is the Spirit general or devel mailing list: > See Boost.Spirit lists here: http://www.boost.org/community/groups.html > Can we please move the discussions there? > > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://boost-spirit.com > Thanks Joel. Moving conversation to more appropriate location. Cheers, Vitaly

1 0

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

[foreach] Warning with gcc-4.6.0 and -Wconversion
by Philipp Reh 05 May '11

05 May '11

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously. Here is a simple program to reprdouce this: #include <boost/foreach.hpp> #include <iostream> #include <ostream> #include <vector> typedef std::vector< int > int_vector; int_vector const test() { int_vector ret(2, 2); return ret; } int main() { BOOST_FOREACH( int_vector::const_reference ref, test() ) std::cout << ref << '\n'; } This prints the following warning: test.cpp:21:2: warning: choosing ‘boost::foreach_detail_::rvalue_probe<T>::operator boost::foreach_detail_::rvalue_probe<T>::value_type() [with T = const std::vector<int>, boost::foreach_detail_::rvalue_probe<T>::value_type = const std::vector<int>]’ over ‘boost::foreach_detail_::rvalue_probe<T>::operator T&() const [with T = const std::vector<int>]’ [-Wconversion] test.cpp:21:2: warning: for conversion from ‘boost::foreach_detail_::rvalue_probe<const std::vector<int> >’ to ‘const int_vector’ [-Wconversion] test.cpp:21:2: note: because conversion sequence for the argument is better I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

3 3

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6