August 2007 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[IOStreams] Opinion on test case needed
by Frank Birbacher 06 Jan '08

06 Jan '08

Hi! I had problems using iostreams::stream<file_descriptor> with Windows and MSVC 8 Express. The file_descriptor had a bug and failed seeking. But the error had gone unnoticed. Because of this I wrote a test case for this in hope to discover an error in IOStreams (source: see below). I did not discover one. Instead the test runs fine on linux/gcc 4.1.2 but fails on Windows/MSVC8Express (test run: see below). I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something? Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iost… Result of test case on platform Windows/MSVC 8 Express: > ...using <p..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug>error_test.exe... > testing.capture-output ..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug\error_test.run > ====== BEGIN OUTPUT ====== > Running 12 test cases... > error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekg>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekg>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > error_test.cpp(81): error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekp>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekp>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > > *** 24 failures detected in test suite "Master Test Suite" > > EXIT STATUS: 201 > ====== END OUTPUT ====== Any opinions on this? Any suggestions on what to do about it? Frank

4 16

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

[soc] Boost.extension/reflection project advances
by Mariano Gabriel Consoni 16 Oct '07

16 Oct '07

Hi Community...! As some of you may know, I'm working on a SoC project called "Boost.extensions and reflection". This mail is just to keep you informed about the project advances. At this time, we have very good news. The library is now near completion, and we expect submitting it for revision in the next days. We've been worked the last two weeks in the following tasks: - Code style: continued improving the code style according Boost guidelines. - Build: improved the Jamfiles to work well in more platforms. - Boost::function: migrated some code to (optionally) use boost::function. - Benchmarks: made new benchmarks to test the new integrations. - Performance analysis: documented the results of the benchmarks. - Preprocessor: replaced a lot of boiler-plate code with (optional) boost::preprocessor macros. - Dependencies flags: documented the optional dependencies and how to enable them. As I have finished all the tasks planned in my proposal (and a lot more :) ) I will advance to Reflection part and Jeremy (Pack, original author) will finish some remaining tasks of Extension. Bye! -- Mariano

4 6

[ANN] Xpressive 2.0 pre
by Eric Niebler 12 Oct '07

12 Oct '07

It's a poorly kept secret that I've been adding new features to Xpressive on CVS HEAD for a while now. So here are the features already implemented (documentation forthcoming) for Xpressive 2.0: << Semantic Actions >> Specify code to execute when parts of a regex match, a-la Spirit's semantic actions. Eg.: if you want to parse a string of name/value pairs into a std::map, you might: std::map<std::string, int> result; std::string str("aaa=>1 bbb=>23 ccc=>456"); // Like "(\\w+)=>(\\d+)": sregex pair = ( (s1= +_w) >> "=>" >> (s2= +_d) ) [ ref(result)[s1] = as<int>(s2) ]; sregex rx = pair >> *(+_s >> pair); if(regex_match(str, rx)) { assert(result["aaa"] == 1); assert(result["bbb"] == 23); assert(result["ccc"] == 456); } The actions are placed on a queue and executed in order only when the regex match succeeds. << Custom Assertions >> Use the check() function to create a boolean predicate that can participate in the match. Here's a regex that recognizes two integers only if the first is less than the second: sregex rx = ( (s1= +_d) >> ' ' >> (s2= +_d) ) [ check( as<int>(s1) < as<int>(s2) ) ]; Unlike actions, predicates execute immediately. You can also define the predicate out-of-line as a function object. << Dynamic Regex Grammars with Named Regexes >> Using regex_compiler, you can map a name to a regex object, and then refer to that regex from another by name. In this way, you can build grammars from regexes at runtime. sregex_compiler comp; sregex rx = comp.compile("^bar(?$RE)baz$"); comp.compile("(?$RE=)\\d+ \\d+"); There's an alternate syntax for associating a name with a regex that you can use to nest a static regex in a dynamic one. Eg., the last line above could be: comp["RE"] = +_d >> ' ' >> +_d; With these changes, you can now nest static and dynamic regexes within each other freely, giving you lots of flexibility to build grammars and modify them on the fly. << Named Captures >> For dynamic regular expressions, you can create a named capture with (?P<name> ...). You can refer back to the named capture with (?P=name). In substitution strings (for use with regex_replace()), you can refer back to a named capture with \\g<name> when using the format_perl or format_all flags. And more .... I'd like to give props to Dave Jenkins who has been doing m4d things with this stuff already, and who has given me a laundry list of other features he'd like. The new features are only available in CVS HEAD, for now. Feedback is welcome. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 7

Boost threadsafe singleton?
by Robert Ramey 21 Sep '07

21 Sep '07

I'm review the serialization library with the eye of making it threadsafe. I think that very useful in this effort would be lightweight threadsafe singleton. There are tons of cyberbits spilled on this topic - but much to my suprise and disappointment, no boost library for this purpose. Someone please tell me its here but that I just haven't found it. Robert Ramey

12 43

Variable Preprocess Metaprogramming?
by Atry 20 Sep '07

20 Sep '07

As we known, there is a preprocess metaprogramming library in boost, but it is not flexible enough. we are unable to define an custom preprocess loop(something like #for or #while ?), and we are also unable to use recursion. I have an idea to do that, C/C++ allows recursion of #include, so we can put the codes we want to evaluate repeatedly to a head, and include itself depends on a preprocess condition. But if we wrote code below, we would meet a error of macro redefinition. /**** foo.hpp ****/ #if FOO < 10 // do something with I # define FOO FOO + 1 # include "foo.hpp" #endif /**** foo.hpp ****/ /**** bar.hpp ****/ #define FOO 0 #include "foo.hpp" /**** bar.hpp ****/ The problem is that an macro must not depends on itself. Thus, to change a preprocess variant, I use a bit of #if to transfer value of a macro to some temporary macro. see my code below: /**** begin_set_value.hpp ****/ #if (BOOST_VPP_VALUE & (1 << 0)) == 0 #define BOOST_VPP_TEMPORARY_BIT_0 0 #else #define BOOST_VPP_TEMPORARY_BIT_0 1 #endif #if (BOOST_VPP_VALUE & (1 << 1)) == 0 #define BOOST_VPP_TEMPORARY_BIT_1 0 #else #define BOOST_VPP_TEMPORARY_BIT_1 1 #endif /* ... */ #if (BOOST_VPP_VALUE & (1 << 30)) == 0 #define BOOST_VPP_TEMPORARY_BIT_30 0 #else #define BOOST_VPP_TEMPORARY_BIT_30 1 #endif #if (BOOST_VPP_VALUE & (1 << 31)) == 0 #define BOOST_VPP_TEMPORARY_BIT_31 0 #else #define BOOST_VPP_TEMPORARY_BIT_31 1 #endif #undef BOOST_VPP_VALUE #define BOOST_VPP_VALUE \ (BOOST_VPP_TEMPORARY_BIT_0 << 0 ) \ + (BOOST_VPP_TEMPORARY_BIT_1 << 1 ) \ + (BOOST_VPP_TEMPORARY_BIT_2 << 2 ) \ + (BOOST_VPP_TEMPORARY_BIT_3 << 3 ) \ /* ... */ \ + (BOOST_VPP_TEMPORARY_BIT_29 << 29 ) \ + (BOOST_VPP_TEMPORARY_BIT_30 << 30 ) \ + (BOOST_VPP_TEMPORARY_BIT_31 << 31 ) \ /*BOOST_VPP_VALUE*/ /**** begin_set_value.hpp ****/ Now, the BOOST_VPP_VALUE is depends on some of BOOST_VPP_TEMPORARY_BIT_n, and can be used to change the former macro: #define FOO 0 #define BOOST_VPP_VALUE FOO #include "begin_set_value.hpp" #undef FOO #define FOO (BOOST_VPP_VALUE + 1) But, FOO depends on BOOST_VPP_TEMPORARY_BIT_ns, and can not be change again, the solution is that A must a variant depends on some other BIT_n definition instead of directly depends on BOOST_VPP_VALUE. Actually, I implements an variant stack to allocate and release these variant. I think the concept of variable preprocess is useful, if Boost.Typeof or Boost.Bind use that, these code they need would be less than copying same codes. I have upload a sample on vault, file name is variable_preprocess.zip. http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=P… http://boost-consulting.com/vault/index.php?action=downloadfile&filename=va… All code is validated by wave, thank you for your attention.

6 12

Threadsafe singleton - questions
by Robert Ramey 19 Sep '07

19 Sep '07

I'm going through the documentation and now have some questions. I would hope that the documentation could be expanded to include answers to these questions. a) reference is made to a "lease" which sounds like a mutex to me. But its not obvious to me how this should be used. How does the compare with the pattern that I am more familiar with class s : singlton mutex m_mutex ... my_function(...){ scoped_lock(m_mutex); ... } OK - I've looked again and I think its clear to me how this is to be used. We need a tutorial here !!!! b) reference is made to boost::restricted which I couldn't find anywhere. Robert Ramey

4 8

[SVN Configuration] Request an additional MIME type to support Scalable Vector Graphics (SVG)
by Peter Foley 17 Sep '07

17 Sep '07

To upload Scalable Vector Graphics (SVG) images to the Sandbox do I simply update my local subversion configuration (as mentioned here http://tinyurl.com/2zqoqm) to include the MIME details for SVG files or will something need to be updated on the server as well? As mentioned at http://tinyurl.com/2dteq2 RFC 3023 (http://www.ietf.org/rfc/rfc3023.txt) has this to say about the SVG MIME type: ---------- RFC info on SVG ------------- 8.19 Image/svg+xml Content-type: image/svg+xml <?xml version="1.0" ?> Scalable Vector Graphics (SVG) documents are XML documents whose content describes graphical information, as defined by [SVG]. As a format based on XML, SVG documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for SVG and so this media type should not be used until such registration has been completed. ---------- END RFC info on SVG ------------- Should I simply update my local configuration file to include the line: *.svg = svn:eol-style=native; svn:mime-type=image/svg+xml Any advice would be greatly appreciated. Thanks, Peter.

2 1

Development and Release Practices
by Beman Dawes 14 Sep '07

14 Sep '07

A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_… Comments welcomed! The proposed process refinements are meant to complement the parallel ongoing efforts to improve our tools, but don't depend on any tool improvements. Thus we can get started as soon as we reach sufficient consensus. That said, I think tools are very important, and hope we can rapidly make improvements in both process and tools. --Beman

16 36

Release Tools Analysis Part I: Build systems
by David Abrahams 13 Sep '07

13 Sep '07

This is part 1 of my analysis of our prospects for improving the Boost release process by improving the tools. I'll post something based on this to the wiki after y'all give me an earful about what I got wrong or overlooked. Build System ============ I'm only considering BBv2 and cmake here, because we currently use the former and Doug and Troy have been putting lots of effort into the latter, and Kitware has volunteered to support it for us. Cmake has lots of advantages over BBv2 for developers (e.g. instant build startup time, use favorite development environment) and packagers (e.g. one-line installer target declaration), but these factors are more important for day-to-day development than they are for testing. Instant build startup time would improve test turnaround time, of course, but build startup does not dominate our testing time yet. BBv2 also has overall speed/memory-consumption problems. These might be addressable using the Boehm GC, but the last attempt resulted in crashes (more investigation needed). BBv2 has a few advantages over Cmake for testing. 1. BBv2 can build with multiple toolsets and/or variants in one invocation. That, however, is trivially overcome by using a wrapper script over cmake. 2. BBv2 serializes the output of simultaneous tests, which makes it possible to run tests in parallel with -jN. This is really important for test turnaround time. Even uniprocessors benefit from a low N (like 2) IME, due to disk/cpu tradeoffs. The IBM testers are currently using -j16 to great effect on their big iron. However, output serialization is only important because both Boost's process_jam_log and ctest/dart currently use a parse-the-build-log strategy to assemble the test results. This approach is hopelessly fragile in my opinion. Instead, each build step in a test should generate an additional target that contains the fragment of XML pertaining to that test, and the complete result should be an XML file that is the catenation of all the fragments. Rene is working on that feature for BBv2. I don't expect it would take more than a couple of days to add this feature to either build system, so the advantage of serialization may be easily neutralized. 3. Platform/compiler-independent build specification. This one seems pretty important on the face of it. If library authors' tests won't run on platforms to which they don't have direct access, we'll need to find people to port and maintain test specifications for the other platforms. On the other hand, very few tests are doing anything fancy when it comes to build configuration. To understand the real impact of this BBv2 feature, someone would have to objectively analyze the cmake build specifications Doug and Troy have been working on for complexity and portability. If either of those guys can be objective, it would be fastest if they'd do the analysis. 4. Cmake's built-in programming language is even more horrible, IMO, than bjam's. I bet you get used to it, like anything else, but it does present a barrier to entry. On the other hand, it's my impression that most programming jobs can be done more simply and directly under Cmake because it lacks BBv2's multiple-toolset/variant builds, and so has no need for virtual targets. Neither systems can trace #include dependencies through macros (e.g. #include SOME_MACRO(xyz)), which occasionally leads to inaccurate results from incremental testing. This is an important problem that should be fixed. Based on the above points, I'd say either build system has the potential to work for Boost's testing needs and neither one is substantially closer to being ideal for us (for testing). Since our systems use BBv2 now, it makes sense to concentrate effort there. However, if cmake were to suddenly acquire the XML fragment generation and the analysis of point 3 above showed that portable build specification is easily accomplished in cmake or not very important to our testing needs, I'd probably be vote the other way. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

18 68

[date_time, asio, range] Unused argument warning fixes
by Caleb Epstein 12 Sep '07

12 Sep '07

Attached is a patch against the SVN trunk that fixes several unused argument warnings from gcc. With one exception the changes are just commenting out the argument name in the function definition. but there is a more ugly fix in <asio/detail/strand_service.hpp> that is only required when building with NDEBUG defined (e.g. when assert is a noop). Can the owners of the code take a look and either commit the appropriate fixes or give me the go-ahead to do it myself. I don't want to step on any toes. -- Caleb Epstein

1 1

asio forcing the use of handlers?
by Roland Schwarz 11 Sep '07

11 Sep '07

I am just about to find out how I could make use of the asio library, and am wondering if async io also can be done without using handler functions. I recognize that it is possible to use it in a blocked manner as follows: assuming we have an open socket: sock read(sock, buf); ... use the buffer contents ... Now I am wondering if I could also accomplish something like: cp = async_read(sock, buf); ... do something useful ... cp.wait(); .. use the buffer contents ... Thank you, Roland aka speedsnail

2 4

[proto] Calculator Arity Transform and function varargs
by Felipe Magno de Almeida 08 Sep '07

08 Sep '07

Hi, I can't make it out how to do the arity transformation for proto::functions varargs too. Could anybody shed some light? Thanks and best regards, -- Felipe Magno de Almeida

2 3

[test] BOOST_CHECK_NOT_EQUAL wanted
by Kevin Sopp 08 Sep '07

08 Sep '07

Hello, I found this old thread http://lists.boost.org/boost-users/2006/06/20028.php where it said bring up the issue again after 1.34 is released. I intuitively expected a BOOST_CHECK_NOT_EQUAL to exist and typed it in, but it wasn't there! So, here's one more person requesting macros for all comparison operators for the test tools. regards, Kevin Sopp

6 9

Updated Development and Release Practices for 1.35.0
by Beman Dawes 07 Sep '07

07 Sep '07

The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users. I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0. Comments appreciated. --Beman

18 83

1.34 boost::filesystem::size() issues on OSX PPC (works on OSX Intel though)
by John Zorko 07 Sep '07

07 Sep '07

Hello, all ... When I use v1.34s boost::filesystem::size() implementation on Mac OSX (10.4.10, Intel and PPC), I get different results. It appears to be a byte-ordering issue (since on little-endian machines (I tested on Windows and OSX Intel) it returns the correct result, while on big- endian machines (I tested on OSX PPC) it does not). While this is easy enough to code around, I don't recall reading anything about byte-ordering issues in the boost::filesystem portability guide, so i'm wondering if this is intentional? Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com

5 6

Can SVN Check for too long and CamelCase file names?
by Paul A Bristow 06 Sep '07

06 Sep '07

I have recently had my wrist slapped by John Maddock, not once, but twice :-(( My offences were committing both Too long filenames, and CamelCaseFileNames. Are either of these crimes that could be prevented by SVN pre-commit rules? Paul PS I have submiited a Trac ticket for Quickbook documentaiton update http://svn.boost.org/trac/boost/ticket/1221 --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

8 17

[thread] RFC standard proposed mutex, read-write mutex, condition
by Howard Hinnant 06 Sep '07

06 Sep '07

Here is a link to a reference implementation and a FAQ for mutexes, locks and condition variables I am currently anticipating proposing for C++ standardization (or subsequent TR). http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html I am posting this link here because this work draws heavily on the boost experience, and I believe feedback from boost users would be valuable. The documentation is scant, chiefly consisting of a "FAQ" which largely centers around questions regarding design decisions that differ from the boost threads package. I'm looking for both agreement and disagreement (and why) on these design decisions from users of the boost threading package. One big difference between this threading package and the boost threading package is the ability to use C++0X language features such as rvalue reference and variadic templates. The rvalue reference is used to make lock types movable but non-copyable. This comes in especially handy with the "upgrade" mutex/locks (see faq). Variadic templates are used for generic locking algorithms which can take an arbitrary number of locks. This code is compiled using Doug Gregor's conceptgcc. So far, only mutexes (including read/write mutexes), locks and conditions are addressed. Yes, C++0X will have a std::thread. It isn't covered in the link above. Any further questions you may supply, I may add to the FAQ (unless there are objections). Anyone is welcome to "boostize" any and all of this code. The reference implementation is intended to be freely shared. However it is currently only addressing POSIX systems. No problems are anticipated in porting to Windows, largely due to the existing boost thread libraries (for which I am extremely grateful to all of those who have worked in this area). Thank you for your time and comments. -Howard

16 139

[graph] SoC update
by Andrew Sutton 05 Sep '07

05 Sep '07

To those interested, // sorrt Alas summer is over. and the students have returned to clog the hallowed (and somewhat narrow) halls of my building... No more quiet days in my lab hacking out Boost.Graph code and documentation. On the brighter side, I have finished - at least to the satisfaction of mentor Jeremy Siek and myself - the goals that I had originally planned for my Summer of Code project. The end results are: - Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers - A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients. - An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction). - An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected. - Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch). - An exterior_property class that helps hides some of the weirdness with exterior properties. - A constant-valued property map - useful for naturally unweighted graphs. - A noop-writing property map - useful when you have to provide an argument, but just don't care about the output. There are also a couple of other informal introductions that need to be polished, documented and tested. These include: - Graph cores - Implemented by David Gleich (@Stanford University) - Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet. There are also some introductions in this package that can - or probably should be - backported to existing code. Specifically, issues dealing with vertex and edge indices and how they are mapped into exterior properties. There are also a couple of changes to the current codebase that can be immediately applied. Specifically, this includes new and updated concept checking classes and a completely new archetype system for concept coverage testing. I've also written quickbook docs for much of the new code - and have been slowly folding the older docs in - it's a long process. Also, if you aren't on a Linux box, you can't build the new docs since I'm using Makefiles, graphviz and latex to generate images. So, the up-to- date stuff is here: http://warhol.sdml.cs.kent.edu/~asutton/boost/libs/graph/doc/html/ Most of the "good" docs are toward the bottom of the ToC. I have more to say on the topic, but I will split it into a second email since this is pretty long. Andrew Sutton asutton(a)cs.kent.edu

6 14

SVN update issue
by Vladimir Prus 05 Sep '07

05 Sep '07

Hi, in SVN trunk checkout I'm getting this: ghost@wind:~/Work/Boost/boost-svn/tools/boostbook$ svn up -r38168 svn: REPORT request failed on '/svn/boost/!svn/vcc/default' svn: Target path does not exist I *think* this is caused by renamed of trunk to devel and back to trunk that I observe in "svn log". However, I'm not sure what's the right way to do what I want. Any ideas? - Volodya

3 4

SVN performance issues
by Vladimir Prus 04 Sep '07

04 Sep '07

I have just run this: svn diff http://svn.boost.org/svn/boost/branches/RC_1_34_0/boost/tools/build/v2 http://svn.boost.org/svn/boost/trunk/tools/build/v2 > RC_HEAD.diff and it took about 13 mins. On another machine (with another network), it took 15 mins. I've asked for confirmation on IRC, and two people are at 11 and 13 mins as a write this (and still running). Is there some network or setup issue with SVN server? Maybe the apache connection limit is set too low? - Volodya

8 12

Clang: Open-source C/C++ front end under development
by Doug Gregor 03 Sep '07

03 Sep '07

Hello fellow Boosters, The need for an extensible, complete open-source C++ parser has been discussed on Boost over the years. There are myriad projects that parse approximations to C++ suitable for specific tasks (e.g., documentation generation), but there has never been a community project meant to handle all of C++ or serve as a common platform for new C++ tools. That is going to change, and I hope Boost will be involved. Apple has begun development of "Clang", which aims to be a high- quality C/C++ parser and compiler. Clang is designed as a library for C++ tools, from IDE-supported tools like indexing, searching, and refactoring to documentation tools, static checkers, and a full C++ front end to the Low Level Virtual Machine (LLVM). LLVM is an advanced, open-source compiler infrastructure supporting all of the back-end functionality needed for a C++ compiler. Like LLVM, Clang is written in a modern C++ style, with a clean separation between the different phases of translation in C++ (lexical analysis, parsing, semantic analysis, lowering, code generation, etc.), all of which make Clang a pleasure to work with. Clang is still in the early stages of development. At present, it parses and type-checks most of C, with code generation for some simple constructs. C++ support is not available yet, but Apple has dedicated significant resources to making Clang a successful C++ parser and compiler. That said, Clang needs our help. Collectively, Boost developers have more knowledge about and a deeper understanding of C++ than any other community within C++. We have the C++ expertise to help implement the language well, and the library-design savvy to help build powerful, accessible interfaces that simplify the task of building new and improved tools for C++. The Clang team is asking for help implementing C and C++ features and are very open to new contributors. Clang has the potential to be a top-notch, open-source C++ compiler and tool platform, from which we would all benefit. Let's help Clang get there sooner! Links: Clang: http://clang.llvm.org/ LLVM: http://llvm.org/ Steve Naroff's talk motivating Clang: - Video: http://llvm.org/devmtg/2007-05/09-Naroff-CFE.mov - Slides: http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf Clang announcement: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007- July/009817.html Cheers, Doug

21 59

Can some check fix for #766; note on bug reports
by Daryle Walker 03 Sep '07

03 Sep '07

I just fixed and closed the issue at <http://svn.boost.org/trac/boost/ticket/766> with <http://svn.boost.org/trac/boost/changeset/39062>. The changes were only in the comments, but could someone else give them the once over to make sure I didn't mess anything up. BTW, this bug report affected two separate components independently. And the issue with the second component was added via a comment. Please don't do either one of these. It complicates issue assignment. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 4