- Boost - lists.preview.boost.org

[interprocess] operator>> for offset_ptr
by Markus Schöpflin 24 Oct '07

24 Oct '07

Hello, offset_ptr.hpp:291 contains the following code for operator>>: template<class E, class T, class Y> inline std::basic_istream<E, T> & operator>> (std::basic_istream<E, T> & os, offset_ptr<Y> & p) { Y * tmp; return os >> tmp; p = tmp; } The last assignment is never executed as there is a return statement before it. This smells fishy. Regards, Markus

2 1

[interprocess] Problematic interface for intrusive_ptr
by Markus Schöpflin 24 Oct '07

24 Oct '07

Hello, as part of its interface intrusive_ptr requires the user to supply two functions: void intrusive_ptr_add_ref(T * p); void intrusive_ptr_release(T * p); These are called from within the implementation of the intrusive_ptr class. When compiling intrusive_ptr_test, cxx complains that intrusive_ptr uses undeclared functions, because the test includes the header file for intrusive_ptr before declaring those two functions. A quick and dirty fix for this would be to move the inclusion of intrusive_ptr.hpp after the declaration of those two functions, and indeed this fixes the compilation error on cxx, but in the long run maybe this implicit interface (relying on the user to somewhere provide two functions before the template is instantiated) should be turned into an explicit interface. Regards, Markus

6 13

[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

Relocating boost to a different namespace?
by Eric Niebler 24 Oct '07

24 Oct '07

I have heard unconfirmed rumors that someone has a script that takes Boost code and moves it into a different top-level namespace. Does such a script really exist? The goal is to be able to automatically munge Boost code so that several versions can be used in parallel without conflicts. If anybody is currently doing this, I'd love to hear from them. -- Eric Niebler Boost Consulting www.boost-consulting.com

6 25

random and TR1
by Eric Niebler 24 Oct '07

24 Oct '07

I infer from the wrappers in tr1/random.hpp that Boost.Random is not TR1-compliant. What are the differences, and what is the plan for bringing Boost.Random into conformance? Also, are the wrappers in tr1/random.hpp TR1-compliant, or are there still some differences? Thanks, -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[thread] build path names change
by Juergen Hunold 24 Oct '07

24 Oct '07

Hi Anthony ! The latest change to Boost.Thread: URL: http://svn.boost.org/trac/boost/changeset/40348 introduced "feature.feature thrd-api" as "symmetric" feature, adding "thrd-api-pthread" to the build paths on linux. I'd like to have it asymmetric, so build paths will be as short as possible. The problem with the "symmetric" property is that you can't use "feature.set-default" to change the default value so the path element will disappear. Please find "thread.diff" with propose patch attached. Also thread.txt with output without patch and thread2.txt will patched Jamfile.v2. The other thing I noticed is the usage of "os.name" to distinguish between nt/unix/cygwin. I think this should use "target-os" in order to enable cross-compilation, but I don't know how to code this. Therefore cross-post to Boost.Build list in order to get some pointer on how to change if [ os.name ] = NT to if target-os = windows or something similar. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[thread] Failed assertions under Borland?
by John Maddock 24 Oct '07

24 Oct '07

I'm seeing new regex regressions caused by assertions being fired in Boost.Thread: http://tinyurl.com/2okqzn Any ideas? Thanks, John Maddock.

2 5

[1.35.0] Progress report
by Beman Dawes 24 Oct '07

24 Oct '07

Most of the bigger infrastructure issues that were getting in the way have now been solved. The tarballs are working again, the missing files in the release/branch have been found, and both trunk and release branch regression reporting is cycling smoothly. There are still some outstanding testing issues, but they are at the level of individual test platforms rather than the whole testing system. Both developers and patch submitters have been active, so it isn't like we are starting from scratch, but the emphasis for release management is shifting to focus on reducing test failures in individual libraries. Looking at the regression test results, I'd like to call attention to these failures: conversion: lexical_cast_loopback_test on many platforms graph: csr_graph_test on many platforms python: import_ on many platforms range: iterator_range and sub_range on many platforms typeof: experimental_* on many platforms These are particularly worrisome from the release management standpoint because they affect many platforms and because I'm not seeing any attempts to fix or markup by their developers. For many of the other failures that affect a lot of key platforms, the developers are actively committing fixes on a regular basis so I assume these failures will be fixed or marked up in the near future. I'll be traveling Thursday through Tuesday, and will start moving libraries to the release branch when I get back. --Beman

9 11

Boost.Test issues
by Vladimir Prus 24 Oct '07

24 Oct '07

Looking at program_options failures, it seems like two platforms are fully not working due to issues in Boost.Test. First is MIPS: http://tinyurl.com/3c8avh Second is Sun: http://tinyurl.com/2yjlpd Can those issues be fixed in near future? Thanks, Volodya

3 5

BGL: traveling sales man
by Michael Held 24 Oct '07

24 Oct '07

hi boost, is there any traveling salesman implementation in BGL available or is anything in this direction planned? I could need such an implementation and would like to volunteer to help implementing/porting such an algorithm. with the help of this community - of course ;-) thank you & cheers, michael

6 7

[fusion] Getting rid of the incomplete type error for vector
by Markus Schöpflin 23 Oct '07

23 Oct '07

Hello, a number of platforms fail when fusion vectors are used with an error message like this: cxx: Error: ../boost/fusion/sequence/conversion/detail/as_vector.hpp, line 41: incomplete type is not allowed (incompletetyp) return vector<>(); -------------------^ Removing the inclusion of boost/.../detail/as_vector.hpp in the header file boost/.../vector/vector.hpp (line 12) solves the issue for me. Could the fusion author please indicate if this is the right fix, and if yes, could this fix please be committed ASAP? TIA, Markus

5 8

boost::optional<T &>::get_ptr()
by Preston A. Elder 23 Oct '07

23 Oct '07

When was this made to NOT work? I am compiling an app against the CVS head of boost, because I want to use things like property_tree, and I don't plan on releasing my app before boost 1.35 is released anyway. But apparently, boost::optional<T&>::get_ptr() no longer works. Now instead I have to use if (myopt && &myopt.get() == &obj) instead of the terser: if (myopt.get_ptr() == &obj) I can't see anything about this in the dev list, and the docs on boost.org (which granted are for 1.34.1) still list get_ptr() as working for both optional<T> and optional<T&>. Preston

1 0

[review] Exception - review period extended
by Tobias Schwinger 23 Oct '07

23 Oct '07

The review period of the proposed Exception library has been extended until October 20th. Although several people seemed interested in the submission, we only have two votes, so far. So we really need more votes. Further, I'm concerned about some potential issues, which I wouldn't want to bless into Boost without being sure there has been a thorough investigation (see below). So, I want to encourage you to evaluate the submission, in particular regarding the following questions: 1. Should the library be accepted as a Boost library? For a guideline on what to include in your evaluation see http://www.boost.org/more/formal_review_process.htm 2. Is the design of the 'enable_error_info' function (see http://www.revergestudios.com/boost-exception/boost-exception.htm#existing_… and http://www.revergestudios.com/boost-exception/boost-exception.htm#enable_er… ), using multiple inheritance, really sound? 3. Does the current implementation use appropriate data structures? We are looking forward to your reviews! Regards, Tobias Schwinger - Review Manager -

7 17

Exception late review
by Alexander Nasonov 23 Oct '07

23 Oct '07

I don't know if review manager still accepts reviews as review period is over but I'd like to share my ideas with others. I'm very interested in this library but I don't think that this version is good enough for inclusion into boost. As already pointed out by many people, library name is misleading. I'd expect from a library named Boost.exception that: - it provides functionality missing in std::exception (clone is one example), - it recommends deriving all boost exception classes from boost::exception and - wrapping standard exceptions with correspondent boost exceptions in boost::throw_exception. The library doesn't have enough features to cover problem domain or they are not well documented. Example shows how to attach additionaly information to FILE but it would be much better to demonstrate how information is added at each layer and then presented to end user. One example is RDBMS where some exception is raised at OS layer (e.g. file system full), then caught at db storage layer, rethown, then caught at higher layere up to SQL layer where it's nicely presented and send to a user. This case should cover tags associated with layers. Other important case is stacking up information as an exception is being processed. Stack trace is a good example. Also, it should be clear how library handle bad_alloc. In some situations, it's fine to rethrown bad_alloc instead of original exception but more fine tuned behavior is require in other situations. One example is stop adding info to a stack and just count all not added stack entries. Sorry for not very well detailed review and for being too late. I was hoping to find time and think thoroughly about interface but I couldn't find enough time. -- Alexander

2 3

[xpressive] Failures on the release branch
by Darren Garvey 23 Oct '07

23 Oct '07

It looks like a lot of the xpressive test fails come from missing files. See: *http://tinyurl.com/276jfw* eg. ../boost/xpressive/detail/static/compile.hpp:26:65: error: boost/xpressive/detail/static/productions/visitor.hpp: No such file or directory ../boost/xpressive/detail/static/compile.hpp:27:69: error: boost/xpressive/detail/static/productions/domain_tags.hpp: No such file or directory In file included from ../boost/xpressive/xpressive_static.hpp:24, from ../boost/xpressive/xpressive.hpp:18, from ../libs/xpressive/test/misc1.cpp:9: ../boost/xpressive/regex_primitives.hpp:24:69: error: boost/xpressive/detail/static/productions/productions.hpp: No such file or directory These three particular files are in svn release branch (and always seem to have been), but they're not all in the trunk. The fails are for the release branch apparently, so I'm not sure why they break. visitor.hpp is in the trunk, but is 'one directory up' (ie. cp visitor.hpp..), while the 'productions' dir isn't in the trunk at all. Regards, Darren

2 2

build boost 1.34.1 with stlport ?
by Bernd Martin Wollny 23 Oct '07

23 Oct '07

Hello, I just tried to upgrade from boost 1.33 to 1.34.1 In the old boost version you can use -sTOOLS=msvc_71-stlport -sSTLPORT_VERSION=51.4 .,...... It's seemd that the syntac has changed but .. you can not find this changes in the documentation. Can some one help me how i can compile boost 3.1.4 with MS VC7.1 and stlport ??? bye bernd -- Bernd Martin Wollny TRIOPTICS GmbH - www.trioptics.com b.wollny(a)trioptics.com Hafenstrasse 39, 22880 Wedel/GERMANY Software Designer Geschäftsführer: Dipl.-Ing. Eugen Dumitrescu phone / fax: +49 (0)4103 18006-26 /-20 Amtsgericht Pinneberg HRB 3215 All E-Mails from bm.wollny(a)trioptics.com are digital signed. If you get a unsigned E-Mail, this E-Mail are a fake. Look at http://www.gnupg.org .

2 2

[interprocess] managed_memory_impl.hpp
by Markus Schöpflin 23 Oct '07

23 Oct '07

This file contains at line 246: return instream.read(detail::char_ptr_cast(this->get_address()), (std::streamsize)this->get_size).good(); This most probably should read this->get_size(), but as no compiler besides cxx caught this error, I'm wondering if this code is ever used at all? Regards, Markus

2 1

For inclusion to boost::function
by Preston A. Elder 23 Oct '07

23 Oct '07

(repost, I accidentally posted this to boost::build list ... ugh). I have written code to solve this problem: I have class foo, like so: class foo { boost::function<void (foo *)> func_ptr; void call() { func_ptr(this); } }; I want func_ptr to be either a free-standing function (or class static), OR a class member function of a derived class, so: void bar(foo *f) { ... } OR: class baz : public foo { public: baz() { func_ptr = &baz::doit; } void doit() { } }; The obvious problem with the latter is that it needs to be downcast implicitly, and some kind of exception thrown if the wrong type is passed. I have created a boost::function proxy class to handle exactly this problem. It uses a lot of boost::function's own tricks with the pre-processor and such. I also had to use another suggestion I saw on this list to work around the fact boost::function does not accept member function pointer syntax (argh! That took a lot to figure out). My solution is this: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils… Which is included by a boost preprocessor iteration here: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils… As I mention, I use a lot of boost::function's own tricks. I think this would be a lot cleaner if done as part of boost::function, rather than me re-implementing the same macros and such. I have made sure my implementation works, and more importantly, has all the tests you would expect (ie. that the return value arguments except the class are the same, that the class is derived from the original function typedef's first argument, and so on). Here is my test case: http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/test/schedul… Any way, feedback is as always appreciated, but if someone could look at this for an addition to boost::function it would really be great PreZ

3 2

[system] Possible breakage: naming changes to conform to C++ std
by Beman Dawes 23 Oct '07

23 Oct '07

At the Kona meeting two weeks ago, the C++ committee accepted most of the Diagnostics changes proposed in N2415. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2415.html Most of Boost.System doesn't change since it already reflects N2415. The committee did, however, change the name of the nested "posix" namespace to "posix_error". For consistency, that means the "Linux" namespace changes to "linux_error" and the "windows" namespace changes to "window_error". As a consequence, the "linux_error" enum changes to "linux_errno". To minimize code breakage, I've added namespace aliases to error_code.hpp: # ifndef BOOST_SYSTEM_NO_DEPRECATED namespace posix = posix_error; # endif # ifndef BOOST_SYSTEM_NO_DEPRECATED namespace Linux = linux_error; # endif # ifndef BOOST_SYSTEM_NO_DEPRECATED namespace windows = windows_error; # endif That was sufficient to prevent any code breakage in the Boost.System and Boost.Filesystem test code, but any user code that actually mentions the linux_errno enum (rather than its constants) will have to be changed. --Beman

1 0

License in boostbook generated HTML pages
by John Maddock 23 Oct '07

23 Oct '07

I note we have a requirement - enforced by the inspect tool - for all HTML doc pages to display the boost license somewhere. However, quickbook/boostbook generated docs only place the license info on the first page. Is this something that needs fixing, or are our requirements too strict? While we're at it, it would be nice if the revision information was in the footer of each page as well :-) John.

1 0

[math] typo in special_functions/fpclassify.hpp rev. 40321
by Boris Gubenko 23 Oct '07

23 Oct '07

math library tests failed on HP-UX because of typo in math/special_functions/fpclassify.hpp rev. 40321. I've fixed it in rev. 40323. Thanks, Boris

2 1

[sunpro][patch] execution_monitor.ipp
by Simon Atanasyan 23 Oct '07

23 Oct '07

Sun C++ cannot compile execution_monitor.cpp on Solaris (Linux is ok). % CC -library=stlport4 -fast -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -DNDEBUG -I. -c libs/test/src/execution_monitor.cpp "./boost/test/impl/execution_monitor.ipp", line 177: Error: va_list is not defined. "./boost/test/impl/execution_monitor.ipp", line 178: Error: Cannot assign void* to int. "./boost/test/impl/execution_monitor.ipp", line 180: Error: The function "vsnprintf" must have a prototype. 3 Error(s) detected. There are two problems: 1. va_list is in the std namespace and do not introduced into the global namespace by default. 2. On Solaris vsnprintf is declared in the stdio.h only. Patch fixes that bug is attached to this mail. -- Simon Atanasyan

1 0

[test] --output_format parameter doesn't work?
by David Abrahams 23 Oct '07

23 Oct '07

setting BOOST_TEST_OUTPUT_FORMAT=XML gives me XML output. passing --output_format=XML on the command line doesn't. Gennadiy, can you explain? Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 2

[Test] Build failures on Mac OS X
by Doug Gregor 23 Oct '07

23 Oct '07

The Test library is failing to build on the Subversion trunk with the following error: darwin.compile.c++ ../../../../bin.v2/libs/test/build/darwin/debug/ link-static/execution_monitor.o ../../../../boost/test/impl/execution_monitor.ipp: In member function 'void boost::detail::system_signal_exception::report() const': ../../../../boost/test/impl/execution_monitor.ipp:426: error: 'SIGPOLL' was not declared in this scope ../../../../boost/test/impl/execution_monitor.ipp: In constructor 'boost::detail::signal_action::signal_action(int, bool, bool, char*)': ../../../../boost/test/impl/execution_monitor.ipp:527: error: expected id-expression before '(' token ../../../../boost/test/impl/execution_monitor.ipp: In constructor 'boost::detail::signal_handler::signal_handler(bool, int, bool, char*)': ../../../../boost/test/impl/execution_monitor.ipp:608: error: 'SIGPOLL' was not declared in this scope The definition of SIGPOLL in Mac OS X's signal.h is conditional: #if defined(_POSIX_C_SOURCE) #define SIGPOLL 7 /* pollable event ([XSR] generated, not supported) */ #else /* !_POSIX_C_SOURCE */ #define SIGIOT SIGABRT /* compatibility */ #define SIGEMT 7 /* EMT instruction */ #endif /* !_POSIX_C_SOURCE */ I'll be happy to test fixes, if that would help, but I'm too confused about the handling of SIGPOLL in execution_monitor.ipp to come up with my own patch. In one place, the use of SIGPOLL is guarded by ! defined(__CYGWIN__), in other places there doesn't seem to be such a guard. A little Googling notes that SIGPOLL is also missing on Cygwin, so I assume the Test library is broken on that platform, too. - Doug

2 2

borland failure
by Gennadiy Rozental 23 Oct '07

23 Oct '07

Does any one can help me to find workaround for borland, so this unit test http://tinyurl.com/2kxobo will work? Genandiy

1 0