- Boost - lists.boost.org

Moving the include directory to $BOOST_ROOT/include? (again)
by Peter Dimov 04 Jun '15

04 Jun '15

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include. This has the following benefits: - it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now, - when building Boost, the message given at the end would be The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib instead of the current The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib which is more in line with a user's expectations. - it's more consistent because it builds the virtual include/ subdirectory from the contents of the multiple libs/*/include/ subdirectories. For backward compatibility, "b2 headers" could create a boost/ symlink to include/boost/. Also for backward compatibility, monolithic releases can continue to ship the headers in boost/ if moving the directory would be seen as too disruptive. Failing acceptance of the above proposal, can we at least use a path constant (BOOST_INCLUDE?) somewhere in Jamroot or boostcpp.jam that identifies where the header links are to be placed? Its current contents would be "." but I would be able to change that to "include" instead of locating and patching all the places that refer to the include path.

8 19

[metaparse] review
by Gordon Woodhull 04 Jun '15

04 Jun '15

Hi all, I believe that Metaparse should be accepted into Boost. > - What is your evaluation of the potential usefulness of the library? As mentioned by others, Metaparse is a library for library developers. In terms of functionality, it is closest to Boost.Proto, although it allows defining arbitrary EDSLs as strings, instead of using the built-in C++ operators. In order to test the effectiveness of Metaparse, I built a parser for the Graphviz "dot" language [1]. This is of practical importance to me, because I have an interest in graph metaprogramming [2], specifically generating types and networks of types from graph metadata. Having a nice language for defining graphs in metadata, to support a syntax beyond angle brackets, would be very helpful. One limitation of this class of EDSL is that it can produce arbitrarily complex types, but it can't refer to any existing types. E.g. you might have the string "int" in your EDSL, but in order for it to refer to the C++ int type, you are going to need an mpl::map from type-strings to types. I didn't get this far in my evaluation, but it's really beyond the scope of the library. > - Are you knowledgeable about the problem domain? Fairly knowledgeable. I have built an experimental parser for compile-time EDSLs over type expressions called "Angly" [4] (presented at C++Now 2012). I have learned from the considerably simpler design of Metaparse, and hope to apply it to my own library (in particular using recursive descent rather than trying to wrangle a deterministic finite automaton). > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent about 5 hours getting set up and working through the tutorial, and about 7 hours getting up and running with my own parser. Once I "got it", it only took an hour or two to implement the rest of the grammar (and about 4 hours to write this review). My results (grammar and a few basic tests) are in a Gist available here: [3]. My grammar is able to parse "dot" graph descriptions that look like this "graph g { A [x=y]; \ B->C [y=z, w=a]; \ D->E; \ F; \ G->H [a=b, b=c, c=d, d=e, e=f, f=g]; \ I->J; \ }" Because I ran out of time, my parser only produces an AST; it does not yet produce MPL.Graph or Fusion.Graph types. > - Did you try to use the library? > - With what compiler? > - Did you have any problems? I mostly used metashell for my evaluation, but I also tested compilation times with clang 3.5 once I had something running. Any problems I had were the usual difficulties of TMP. I was not expecting the compile times to be tolerable, but even in metashell, the turnaround was usually around 15-20s. Compiling my longest test with clang, just shy of 256 characters, took only about 4-5 seconds. > - What is your evaluation of the documentation? Excellent. Working through the tutorial was enough for me to absorb the particular constructs needed for building grammars and semantic actions. I also used the reference documentation when building my own parser. This documentation is more terse, very much in the style of the MPL documentation. But it functions. I only skimmed the user manual, since the content looks a little bit stale (doesn't mention build_parser) and somewhat redundant with the tutorial. As Andrzej mentions, there may need to be an introduction concerning the scope of the library and what you can and can't do with this kind of EDSL, where you would use Proto instead of Metaparse, etc. I think that as the library evolves, the documentation will probably need more general parsing background, of the sort you will find in Spirit documentation. For example, the tutorial covers the unary `-` operator, but it doesn't mention why there is no ambiguity with the binary `-` operator. Also, it seems (as mentioned in the design discussion below) that the grammar must be unambiguous, and this is mentioned nowhere. Overall, the documentation is stronger on the meta- than the -parse. > - What is your evaluation of the implementation? I did not peer into the code very much, beyond finding some examples I needed. My impression from Abel's walk-through at C++Now 2012 is that the implementation is quite simple and straightforward, based on established techniques from parsers in Haskell. > - What is your evaluation of the design? Very good. However, I think the API might be fleshed out a little bit once the library gets more usage. In particular, I found myself writing a few helper metafunctions that looked like this: template<typename EdgeDecl> struct declare_edge { typedef edge_decl<typename mpl::at_c<EdgeDecl, 0>::type, typename mpl::at_c<EdgeDecl, 2>::type, typename mpl::at_c<EdgeDecl, 3>::type> type; }; invoked from a transform like this: using edge_stmt = transform< sequence<ID, arrow_token, ID, opt<attr_list, mpl::vector<>>>, mpl::quote1<declare_edge> >; It may be my inexperience, but it struck me that it would be helpful to have a "spread" or "apply" transform so that the items in the mpl::vector produced by sequence would be supplied as parameters to declare_edge, instead of having to pull them out using mpl::at_c. There may be some trick I don't know here. I will mention two other points of confusion. These are probably not design flaws in the library, but I thought I would bring them up in case they are. First, I started out defining my AST nodes like this: template<typename Tail, typename Head, typename Attrs> struct edge_decl {}; Seems like a reasonable basic type-holder to me. As shown above, this is instantiated and returned by a helper metafunction invoked by the transform which pulls stuff out of an mpl::vector. But then somewhere in metaparse, it tries to again "invoke" this result with ::type when appending it to another mpl::vector. Really? So my transform needs to return not the value, but a metafunction which returns a value? I couldn't figure this out, so I gave each of my AST nodes a self-referential ::type in the way that mpl::vector has: template<typename Tail, typename Head, typename Attrs> struct edge_decl { typedef edge_decl type; //why? }; Something is not right here! The second problem I encountered is about ambiguous grammars. For the "dot" language it seems natural to define a statement this way: using stmt = one_of<node_stmt, edge_stmt>; where a node statement looks like ID [attr=value, attr=value]; and an edge statement looks like ID -> ID [attr=value]; But there's an ambiguity here, and once the parser successfully reads a node, it is going to get upset if it sees a `->`. So the rule has to be written the other way: using stmt = one_of<edge_stmt, node_stmt>; Similarly, the `;` separator for declarations is optional in the "dot" language, but I couldn't figure out how to implement this, because if you try to have an optional element at the beginning of a rule: template<typename Parser, typename Default = void> using opt = one_of<Parser, return_<Default>>; using stmt_list = foldlp< sequence<opt<semi_token>, stmt>, transform<stmt, mpl::quote1<mpl::vector1>>, // ... then the parser will greedily eat the epsilon and have nowhere to go (at least according to my amateur understanding of parsers). I gave up here and made the separator mandatory. Again, this is probably not a flaw in the design, but the documentation should describe what kinds of grammars will work, and perhaps give pointers to other resources about disambiguating grammars. Probably there is a different construct which would help here. Cheers, Gordon [1] http://www.graphviz.org/doc/info/lang.html [2] http://metagraph.info/wp-content/uploads/2011/05/mpl.graph_.pdf [3] https://gist.github.com/gordonwoodhull/dcbb332eea06dd3279b9 [4] https://github.com/gordonwoodhull/metagraph

2 5

[build] Error building bjam on cygwin
by Emil Dotchevski 03 Jun '15

03 Jun '15

I'm trying to build bjam from Boost 1.56.0 under cygwin. Running ./build.bat mingw errs with: gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c filent.c:46:20: fatal error: direct.h: No such file or directory #include <direct.h> ^ compilation terminated More errors follow. What am I doing wrong? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[thread] Problem with thread test 'failed to write output file'
by Edward Diener 03 Jun '15

03 Jun '15

Attempting to run the 'thread' tests locally I get: failed to write output file '..\..\..\bin.v2\libs\thread\test\upg_lock_cons_move_ctor_sh_lock_untl_p_lib.test\msvc-12.0\debug\threading-multi\sync\mutual_exclusion\locks\upgrade_lock\cons\move_ctor_shared_lock_until_pass.obj.rsp'! This is with the --abbreviated-path option. If I try using --hash or not using either on the b2 command line I still get the same result of 'failed to write output file ... etc,' probably because the output file spec is still too long. This happens on Windows thread tests with msvc-12.0 but not with gcc-4.9.2. Any ideas how I can get this to run successfully ?

1 1

[admin] General Boost email?
by Rene Rivera 02 Jun '15

02 Jun '15

I've been experimenting with the various cloud based CI systems out there in an effort to make it easy to have all Boost libraries CI tested. As part of that I'm trying to set up an organization account in Appveyor and I'm stuck.. As I need a global org email to register. Hence I would like to request that we set up an "owners(a)boost.org" email that we can use for such circumstances (that just forwards to the git boostorg owners). Does that sound OK? Whom would set up such an email? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[test] possible bug in 1.47.0
by Damian Vicino 02 Jun '15

02 Jun '15

Hi, I’m working in the safe_float library and while working on it I defined a partial specialisation of numeric_limits for safe_float. I wanted the safe_float<T> to mimic the T numeric_limits in most of the values and just change a few, but nothing complex, one liners only. Then, I created a test for validating those methods/attributes mimicking the internal T are equal to those on T, as follows: //types to be tested using test_types=boost::mpl::list< float, double, long double >; using namespace boost::safe_float; BOOST_AUTO_TEST_CASE_TEMPLATE( safe_float_numeric_limits_basic_fp_types, FPT, test_types){ BOOST_CHECK_EQUAL(std::numeric_limits<safe_float<FPT>>::is_specialized, std::numeric_limits<FPT>::is_specialized); } The test does not even compile: Undefined symbols for architecture x86_64: "std::__1::numeric_limits<boost::safe_float::safe_float<double, boost::safe_float::policy::check_addition_overflow, boost::safe_float::policy::on_fail_throw, boost::safe_float::policy::cast_none> >::is_specialized", referenced from: safe_float_numeric_limits_suite::safe_float_numeric_limits_basic_fp_types<double>::test_method() in numeric_limits_test.o After looking at the numeric_limits specialisation for a while, I tried changing the test as follows: if (std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized){ BOOST_CHECK(true); } else { BOOST_CHECK(false); } And as follows: BOOST_CHECK(std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized); Both alternatives work. Is there something wrong with BOOST_CHECK_EQUAL? I’m using version 1.47.0 Best regards, Damian

2 1

Boost.Test v3 is here
by Gennadiy Rozental 02 Jun '15

02 Jun '15

Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html) We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental

8 12

Running regression tests locally
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi Everyone, I need an advice here. When I look at the test matrix online, I can easily see how many tests failed. In contrast, when I run the tests locally (call b2 in folder 'test') I get a bunch of output, but I cannot easily figure out if and how many tests have failed. Is there a way to do it? Or to build a summary of some sort? Regards, &rzej

2 1

[b2] Need help with b2
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi everyone, Today after doing a `git pull --rebase` on modular Boost, b2 stopped working for me. I keep getting the following error. Can someone help me figure out what this is? Regards, &rzej C:/source/modular-boost/tools/build/src/build\feature.jam:139: in feature.feature from module feature error: unknown attributes: hidden error: in feature declaration: error: feature "deduced-address-model" : "32" "64" : "propagated" "optional" "composite" "hidden" C:/source/modular-boost\boostcpp.jam:570: in load from module boostcpp C:/source/modular-boost/tools/build/src/kernel\modules.jam:289: in modules.import from module modules C:/source/modular-boost/tools/build/src/build\project.jam:1024: in import from module Jamfile<C:\source\modular-boost> ..\..\..\Jamroot:124: in modules.load from module Jamfile<C:\source\modular-boost> C:/source/modular-boost/tools/build/src/build\project.jam:311: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:145: in project.find from module project C:/source/modular-boost/tools/build/src\build-system.jam:535: in load from module build-system C:\source\modular-boost\tools\build\src/kernel\modules.jam:289: in import from module modules C:\source\modular-boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\source\modular-boost\boost-build.jam:17: in module scope from module

2 2

Correct Mutext Destroy Behaviour, Pthreads and Boost
by Robert Bell 01 Jun '15

01 Jun '15

If an object is implemented to support reference counting, and has an internal raw pthread mutex, the open group is pretty clear in the pthread_mutex_destroy doc on what different implementations must ensure (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_dest…) Note the following statement at the bottom: "A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:" obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C)." On moving some of my underlying libraries to Boost, I took a look at Boost's Mutex object. The implementation of the Mutex object's destructor call does: ~mutex() { int const res = posix::pthread_mutex_destroy(&m); boost::ignore_unused(res); BOOST_ASSERT(!res); } My question centres on whether Boost's implementation violates the open group's requirement. The calls to posix::pthread_mutex_destroy (Boost's wrapper), usually perform a straight-through call to ::pthread_mutex_destroy, but it occurs inside the destructor, and so does this call occur "immediately after" an unlock by the group's definition? In straight pthreads, if I want to make sure I can rely on various implementations of the standard, I can simply do exactly what the open group says, unlock, and the next line destroy. But in the case of Boost, is it safe to do something like: mutex->unlock(); delete mutex_; One thing I did note of interest is that Apple's implementation seems to lock the mutex from within the destroy call, which is curious: int pthread_mutex_destroy(pthread_mutex_t *mutex) { int res; LOCK(mutex->lock); if (mutex->sig == _PTHREAD_MUTEX_SIG) { if (mutex->owner == (pthread_t)NULL && mutex->busy == (pthread_cond_t *)NULL) { mutex->sig = _PTHREAD_NO_SIG; res = ESUCCESS; } else res = EBUSY; } else res = EINVAL; UNLOCK(mutex->lock); return (res); } There seems, generally, to be a good deal of confusion surrounding when it is safe to destroy the resources associated with a mutex, and most people offer widely inaccurate comments based largely on opinion. My question points to whether code adjacency is a requirement of correct behaviour in some implementations, and if not, why not? If I have missed an obvious explanation somewhere, my apologies. I read through the different patterns of Boost threading listed in the documentation, but was not convinced the question was addressed. Thanks in advance…

4 5