January 2011 - Boost - lists.boost.org

Boost.Filesystem v3 as default in Boost 1.46.0?
by Jeremiah Willcock 12 Jan '11

12 Jan '11

Will the default version of Boost.Filesystem be v3 in the Boost 1.46.0 release? The current release branch still has v2 as the default (at least in <boost/filesystem.hpp>). Also, if I want to write code that works for both v2 and v3, should I test the BOOST_FILESYSTEM_VERSION macro directly? -- Jeremiah Willcock

4 3

[spirit] semantic action for mismatches?
by caustik 12 Jan '11

12 Jan '11

I've come to notice that there seems to be a missing bit of symmetry in spirit with regards to semantic actions. If a rule matches, and thus executes it's semantic action(s), but a rule which includes that rule mismatches, there seems to be no way to "unwind" the code executed down the chain. For example, if one of your semantic actions allocates memory or increments a reference count, how do you free / release that reference in the mismatch scenario? I've thought about using something like a shared_ptr, but it seems like that gets pretty sloppy and unnatural. Is there something you can think of that would work? caustik

5 25

[move] abiguious ctor (msvc-10.0)
by Oliver Kowalke 11 Jan '11

11 Jan '11

I get error C2668 with msvc-10.0 - (gcc.4.x works). Any ideas? 1>test.cpp(44): error C2668: 'X::X': Mehrdeutiger Aufruf einer überladenen Funktion 1> test.cpp(19): kann 'X::X<boost::_bi::bind_t<R,F,L>>(Fn &&,size_t)' sein 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>>, 1> Fn=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::value<int>>> 1> ] 1> test.cpp(16): oder "X::X<boost::_bi::bind_t<R,F,L>>(Fn,size_t)" 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>>, 1> Fn=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::value<int>>> 1> ] 1> bei Anpassung der Argumentliste '(boost::_bi::bind_t<R,F,L>, int)' 1> with 1> [ 1> R=void, 1> F=void (__cdecl *)(int), 1> L=boost::_bi::list1<boost::_bi::value<int>> 1> ] test app: #include <cstdlib> #include <iostream> #include <boost/bind.hpp> #include <boost/move/move.hpp> class X { private: BOOST_COPYABLE_AND_MOVABLE( X); public: X() {} template< typename Fn > X( Fn fn, std::size_t i) {} template< typename Fn > X( BOOST_RV_REF( Fn) fn, std::size_t i) {} X( X const& other) {} X & operator=( BOOST_COPY_ASSIGN_REF( X) other) { X tmp( other); return * this; } X( BOOST_RV_REF( X) other) {} X & operator=( BOOST_RV_REF( X) other) { X tmp( boost::move( other) ); return * this; } }; void f( int) {} int main() { try { X x( boost::bind( f, 1), 1); return EXIT_SUCCESS; } catch ( std::exception const& e) { std::cerr << "exception: " << e.what() << std::endl; } catch (...) { std::cerr << "unhandled exception" << std::endl; } return EXIT_FAILURE; } -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

2 3

[local] local functions ready for review
by Lorenzo Caminiti 11 Jan '11

11 Jan '11

Hello all, A few months ago, I probed for interest in a library for local functions with Boost.ScopeExit's variable binding. Based on that discussion, I have now implemented the Boost.Local library. I have uploaded the source files boost-local_0_1_0-818.zip in the Boost Vault under Function Objects: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… The documentation on the web: http://contractpp.sourceforge.net/boost-local_0_1_0-818/libs/local/doc/html… Any comment? As far as I can tell, Boost.Local is ready for a formal review so I am looking for a review manager. Any volunteer? Thanks, Lorenzo ________________________________________________ P.S. A preview from Boost.Local's documentation: The Boost Local library implements local functions, local blocks, and local exits for the C++ programming language. INTRODUCTION Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts. Local functions therefore complement other structuring possibilities such as namespaces and classes. Local functions are a feature of many programming languages, notably Pascal and Ada, yet lacking from C++ (see also [N2511]). This library supports the following features for local functions (see the Alternatives section for a comparison between this library and features offered by C++ local class members, C++0x lambda functions, Boost.Lambda, Boost.Phoenix, and Boost.ScopeExit): * Local functions can access, or better bind, any of the variables from the enclosing scope. Furthermore, local functions defined within a member function can bind the enclosing object this. * The local function body is programmed using the usual C++ syntax. * Local functions can be passed as template parameters (so they can be conveniently passed to STL algorithms, etc). * However, local functions must be defined within a declarative context (e.g., at a point in the code where local variables can be declared) thus they cannot be defined within an expression. In addition to local functions, this library also supports the following features: * Local blocks which define blocks of code that bind variables from the enclosing scope. Local blocks allow programmers to bind variables as constants (constant binding) so to prevent local chunks of code from modifying selected variables. * Local exits which define blocks of code that are executed when the enclosing scope is exited (again with support for constant binding and binding of the object this). AN EXAMPLE The following example illustrates a simple use of this library and it starts introducing the library API (see the Tutorial section for more details on how to use this library): * A local function is passed to the STL std::for_each() algorithm to add together the values of an array. Variables in scope are bound to the local function by both constant value and non-constant reference. * A local exit is used to automatically release the array's memory at scope exit. * A local block is used to assert the correct final value of the summation in a constant-correct context (therefore preventing the assertion from mistakenly changing any of the variables in scope). #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT( (const bind)((&size)) (bind)((nums)) ) { if (size && nums) delete[] nums; std::clog << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); BOOST_LOCAL_BLOCK( (const bind)((&sum)) ) { // So far: sum = 10 * 100.0 + 10 * 90.5 + 10 * 7.0 = 1975.0 assert(sum == 1975.0); std::clog << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; }

2 5

[geometry] Excessive inspection report errors
by Beman Dawes 10 Jan '11

10 Jan '11

See http://boost.cowic.de/rc/inspect-trunk.html#geometry A bunch of these problems are related to documentation - Daniel James and some of the other Boost doc folks have dealt with similar problems in other libraries, so can probably help. Thanks, --Beman

2 3

[QuickBook] missing prev/next
by Lorenzo Caminiti 10 Jan '11

10 Jan '11

Hello all, I have generate the Boost.Units documentatiom using Boost.QuickBook from the latest Boost release 1.45.0 but the HTML pages are missing the prev and next page links. I only have the up and home links in the navbar. How can I get the prev and next links to show? Do I need to enable some XLS configuration in the Jamfile? Thank you very much. -- Sent from my mobile device Lorenzo

4 21

cygwin API: posix or windows
by vicente.botet 09 Jan '11

09 Jan '11

Hi, while trying to make Boost.System and Boost.Chrono configurable header only libs we need to include windows.h on some include files. To avoid the inclusion of this intrusive file, we decided sometime ago to include some files in detail/win that will present just the needed interfaces. In my humble opinion cygwin is a wrapper of posix intefaces under windows OS. So, boost libraries shouldn't use Windows interfaces when working under cygwin. What's the experience of others? Best, Vicente

10 10

[tasklets] new lib
by Oliver Kowalke 09 Jan '11

09 Jan '11

boost.tasklet is a split-up from old boost.fiber. The lib allow to execute micro-tasks (tasklets) in a thread and assigns each small task with a micro-thread/fiber - so tasklets are cooperativly scheduled. The API contains classes and functions to manage and synchronize tasklets (even if the tasklets are running on different threads). boost.tasklet is an example how boost.fiber could be used for cooperative scheduling ansd will be used by the threadpool from boost.task. Oliver

2 3

Workaround for clang-linux + GNU stdlib + Boost.Iostreams
by Bryce Lelbach 09 Jan '11

09 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's a discrepancy in the definition of wint_t between GCC and some later versions of clang (clang defines it as an int, GCC an unsigned int). This ends breaking Boost.Iostreams with a GNU GCC compiled version of the GNU stdlib and clang (I'll restrain myself from giving the lengthy technical explaination - if you have link-time errors with clang + GCC compiled stdlib + Boost.Iostreams, this is probably the issue). Unfortunately, I cannot patch this issue with a workaround in Boost easily. The right combination of clang flags can work around this by not using the clang intrinsic/builtin headers, but this has a good chance of causing other problems. The simplest solution here is to rebuild clang (building the GNU stdlib with clang is tricky at best). I think newer version of the mainstream clang trunk may have fixed this, but if not, you need to change the assignment to WIntType in the clang::TargetInfo ctor ($CLANG_ROOT/lib/Basic/TargetInfo.cpp, line 40-50ish). It should be UnsignedInt. You also need to hack $CLANG_ROOT/lib/Headers/stdint.h, around 630 - the macro definition of WINT_MIN and WINT_MAX need to be changed to: #define WINT_MIN 0u #define WINT_MAX __UINTN_MAX(__WINT_WIDTH__) If you'd rather not recompile clang, you can try hacking your clang intrinsic headers (not advisable, might break more stuff). Find the resource/intrinsic header directory (usually something like /usr/local/clang/2.9/include/), and make the change specified above to the stdint.h header there. In the stddef.h header, around like 60, you can change the wint_t typedef. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0fnjQACgkQO/fqqIuE2t7NVQCgowl7TqnCRgWyjRGN+/u3fh2R NywAoK59zWsZiB7vVvtKU0IehHiMIVdz =COrS -----END PGP SIGNATURE-----

4 5

[wiki] Warning Guidelines for VC
by Michael Caisse 08 Jan '11

08 Jan '11

A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link: <https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines> STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used. I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is? [1] <http://lists.boost.org/Archives/boost/2010/04/165531.php > michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 13