March 2009 - Boost - lists.preview.boost.org

[mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
by Larry Evans 13 Apr '09

13 Apr '09

The vault file: http://preview.tinyurl.com/cbr9k3 demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? TIA. -Larry

5 20

[convert] Version in the Vault ready for review.
by Vladimir.Batov＠wrsa.com.au 13 Apr '09

13 Apr '09

After listening to many views, opinions, suggestions I've re-done boost::convert and would like it scheduled for a review. It is certainly nowhere as MPL and still not perfect. However, I believe it will be very useful to many developers (like me) not satisfied with lexical_cast and not (yet?) needing (or ready for) something like upcoming Spirit 2.0. Overall, after weighing all pros and cons, I am reasonably happy with the current interface and implementation. It does not implement all that have been discussed and suggested. It is most unlikely implemented the way some would like it to see. However, I had to make choices I felt comfortable with and I feel the current interface is minimal, readable and allows for further growth. With that review-request I would like to avoid opening up another round of discussions if 'from' was a good, bad, mediocre choice. I feel we've exhausted that topic and I would like people to simply vote if they find the functionality needed. I am most certainly prepared to eat my humble pie if the vote is 'no'. Still, I am very much looking forward to any implementation-related suggestions/corrections or new ideas we have not discussed so far. The current interface can be summed up as with as little as int i = convert<int>::from(str); // Throws on failure int i = convert<int>::from(str, -1); // Returns -1 on failure More details can be found in the accompanying document (just remember I am not Shakespeare). If/when we decide to extend that by incorporating, say, Boost.Parameter and/or Spirit, then it might be as int i = convert<int>::from(str)(radix_ = 10, more_parm_ = ...); int i = convert<int>::from(str)(some Spirit related stuff); I am prepared to look into it further... if this initial proposal is accepted... otherwise, it'll be less work for me. :-) Thank you everyone who participated in the lexical_cast/convert discussions. Your views, opinions, suggestions were very helpful and educating and are very much appreciated. I hope I did not forget anyone in the "acknowledgements" list. The file called boost-string-convert.zip can be found in the Vault at http://www.boostpro.com/vault/. Thanks, Vladimir.

6 17

[mpl][docs]why use list?
by Larry Evans 13 Apr '09

13 Apr '09

Comparing the vector doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/vector.html which contains: supports constant-time insertion and removal of elements at both ends, and linear-time insertion and removal of elements in the middle. with the list doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/list.html which contains: supports constant-time insertion and removal of elements at the beginning, and linear-time insertion and removal of elements at the end and in the middle. shows these documents indicate no reason to prefer list over vector but does indicate a reason to prefer vector over list. Is there any reason to prefer list over of vector? -regards, Larry

4 13

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

[gsoc] improving any and variant
by Mathias Gaunard 07 Apr '09

07 Apr '09

A few little ideas that could eventually be joined to be a single GSoC project: - Allow visitation for Any. This can actually be generalized to any object that exposes a type_info, such as polymorphic objects. Techniques, including non-portable ones based on name mangling, could be experimented to get more efficient dispatch. - Add SBO to any. - Improve variant so that the functor doesn't require to expose a result_type. The result_type can be automatically deduced by "joining" all the possible return types obtained by boost::result_of. - Allow the easy construction of a visitor from lambda expressions, with a syntax like variant<int, std::string> a = "foo"; int b = match(a).with( args<int>(_1), args<std::string>(size(_1)) ); instead of the potentially more verbose struct my_visitor : static_visitor<int> { int operator()(int a) { return a; } int operator()(const std::string& b) { return b.size(); } }; variant<int, std::string> a = "foo";; int b = apply_visitor(my_visitor(), a);

5 5

[boost test] boost testing framework xml schema‏
by Daniel Carrara 06 Apr '09

06 Apr '09

I would like to know where I can find the xml schema for the test logs produced at the end of the testing with --log_level=all and _log_format=XML. Thanks, Daniel _________________________________________________________________ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009

2 1

[mpl][doc]bug: prior.html should have Bidirectional Iterator requirement.
by Larry Evans 06 Apr '09

06 Apr '09

The prior.html document: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/prior.html says prior requirement is that Iterator be a Forward Iterator; yet, http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/forward-iterato… makes no mention of prior. Also, compiling prior on a list iterator shows: /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/next_prior.hpp:40: error: no type named 'prior' in 'struct boost::mpl::l_iter<boost::mpl::list1<char> >' Hence, the prior requirement should be Bidirectional instead of just Forward Iterator. -regards, Larry

2 1

My ideas for GSoC project
by Balša Raičević 05 Apr '09

05 Apr '09

Hello, I'm a Computer Science student from Faculty of Mathematics, University of Belgrade. I am interested in working on The BGL. I have a lot of experience with C++ and code refactoring also, since I've done a lot of tutoring and encountered a lot of strange students' code :) I have taken a deep look at BGL ( which is why I'm writing my proposal so late :) ) and to some extend its extension - The Parallel Boost Graph Library. I am mostly interested in graph partitioning, as I find them very useful for parallel computing. I understood the importance of it when I had to do some major calculations for numerical approximations and wanted to use all the CPU power available :) In the project idea list ( https://svn.boost.org/trac/boost/wiki/soc2009#Graphpartitioning) it's said that it would be good to implement algorithms similar to those in METIS ( http://www.cs.umn.edu/~metis <http://www.cs.umn.edu/%7Emetis>). I've read some of George Karypis' "Publications Related to Graph Partitioning", so I was wondering if I could discuss with someone which algorithms would be good to implement, and of course, how. I found little, if any, discussion about that in mailing list archive. Other thing I would really like to see is hypergraph partitioning. I see that implementing hypergraphs in the BGL is one of GSoC projects, so I would like to know would it be possible, if that project is not awarded to anyone for this summer, to do basic implementation of a hypergraph, or (since I see there is already a discussion about that) if somebody else would do that project, to collaborate on hypergraph partitioning algorithms. Last, but not least, an important question: I would like to use this work as part of my Master's Thesis. I looked at GSoC FAQ ( http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#cours…) so I guess it is OK with the program, but I would still like to discuss it with potential mentor. Thanks ahead, Balsa

1 1

[GSOC] Regarding the project Boost.DeVector
by Satyam Shekhar 04 Apr '09

04 Apr '09

Hi, I am interested in doing the Boost.DeVector project for GSOC 2009. I had certain queries regarding this project: 1. Does the standard specify any sort of implementation for deque, or does it only specify the requirements and interface? I ask this because if we assume a dynamic array implementation which grows on both the sides, implementing 'reserve', and specifying the size of the chunk should be a trivial task. 2. What are the examples of the low-level operations for which this container is over-encapsulated? Regards Satyam

6 14