- Boost - lists.boost.org

cref(_1)
by David Abrahams 12 Apr '04

12 Apr '04

Hi, I have this code that isn't compiling because of the "forwarding problem" limitation of boost::bind: std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, _1)); The problem is that an implicit conversion is required between the reference type of the difference_iterator and the argument type of writeVInt. It seems to me that, since I know that binding to an rvalue is required, we ought to have a way to say "force this to be a const ref". I thought of something like std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, boost::cref(_1))); ^^^^^^^^^^^^ ^ I know it's not pretty, but it sorta does what we want. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 7

Signals documentation error
by Edward Diener 12 Apr '04

12 Apr '04

The documentation for the Signals library shows an Allocator type as the second template parameter to the signal template class when one looks in the Reference section. In the header file and in other references to the usage of the signal template class, no such template parameter exists, and the second parameter is the Combiner. I believe the Allocator type may have been in an early version of the signal template class and the doc was never corrected to take it out.

2 1

Formal Review: Assignment Library
by Tom Brinkman 11 Apr '04

11 Apr '04

The review of Assignment Library library, written by Thorsten Ottosen 2003 (nesotto(a)cs.auc.dk) starts today(April 1, 2004)and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/assignment/ (204 kB) or in the sandbox. What it is? The purpose of this library is to make it easy to fill containers with data by overloading operator the comma, () and operator()(). Example: To fill a vector with values you write: #include <boost/assign/stl.hpp// for operator+=() #include <vector> using namespace std; using namespace boost::assignment; vector<intvalues; values += 1,2,3,4,5,6,7,8,9; values += foo1(), foo2(), foo3(); History of the project: The idea for an initialization library is not new . The functionality of this library resembles Leor Zolman's STL Container Initialization Library a great deal, but it does not rely on string passing to achieve its goals. The library is non-intrusive and puts only a minimum of requirements on its supported classes. (change classes to types) The Initialization Library overloads the comma operator in a safe manner by letting free standing functions return an object that is responsible for the initialization. Therefore it takes explicit action from the programmer to begin using the overloaded operator,(). The operator comma is never overloaded for user-defined types. Portability: Library has been successfully compiled and tested with MVC++ 6.0, MVC++ 7.0, MVC++ 7.1, GCC 3.2 (under Cygwin) Comeau 4.3.0.1, Intel ICC 7.1 and Intel ICC 8.0. There are known limitation on platforms not supporting partial template specialization. Review Comments: Your review comments are welcomed. Found problems and suggestions for documentation are highly sought. Requests for new features requests will shape the way this library will evolve in future. 1. Where should the main libraries header files be placed. This is header only library and should be fairly easy to manage.Should it be placed in the utilty folder or its own folder? 2. Should the headers be broken up? This library has extensions to boost::array, boost::ublas and boost::graph. Should those headers be placed in their respective folder or kept together with the headers associated with the main Assignment library headers. Or, should the boost library extensions remain just as examples of how to extend the library. 3. Should the fixed_size_asssigner only throw on out_of_bounds exception or should it default initialize the remainning elements? Two classes can throw an exception in their destructor. This is done when detecting eg. a boost::array has not been initialized with enough elements. Should this be replaced by default initializing the remaining elements? 4. This library needs to use the boost test framework. Review Manager Tom Brinkman reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

8 21

BOOST_PP_IDENTITY
by David Abrahams 11 Apr '04

11 Apr '04

How come I can't find it in the documentation index? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

BCC weirdness
by Andreas Huber 11 Apr '04

11 Apr '04

Hi there While trying to port my fsm proposal to BCC5.6.4, I encountered the following compiler error: "simple_state.hpp": E2188 Expression syntax at line 389 The error is in the following code: // ... typedef typename context_type::outermost_context_type outermost_context_type; typedef typename context_type::inner_context_ptr_type context_ptr_type; typedef typename context_type::state_list_type state_list_type; // *** error on the following line *** typedef intrusive_ptr< inner_context_type > inner_context_ptr_type; typedef typename detail::make_list< InnerInitial >::type inner_initial_list; BOOST_STATIC_CONSTANT( detail::orthogonal_position_type, no_of_orthogonal_regions = mpl::size< inner_initial_list >::value ); typedef typename mpl::push_front< typename context_type::context_type_list, context_type >::type context_type_list; // ... I don't have a clue what BCC's problem is here, for the following reasons: - This code compiles just fine on MSVC7.1, GCC3.2 and Intel8.0 - The line on which the error is reported looks completely harmless to me - No amount of commenting out code following the problem line changes anything in BCC's diagnosis Does anyone have any hints on how to resolve this? Thanks & Regards, Andreas P.S. The full code can be found at http://boost-sandbox.sf.net/fsm.zip or in the sandbox CVS. The error appears while trying to compile the StopWatch example.

2 2

RE: [boost] Re: Assignment library: review
by Glen Knowles 11 Apr '04

11 Apr '04

From: Keith Burton [mailto:kb@xtramax.co.uk] >I trust that you are aware of the following quoted, from >MSDN for all Microsoft C++ compilers <snip> >See Knowledge Base article Q242192 for more information. The article says that it applies to MSVC 6, not "all". Glen Knowles Centor Software Corporation

1 0

test lib bugs
by David Abrahams 11 Apr '04

11 Apr '04

I am seeing these errors when compiling with como-win32: "c:\boost\libs/test/src/execution_monitor.cpp", line 42: error #735: using-declaration of function "strlen(const char *) C" conflicts with function "std::strlen(const char *)" (declared at line 30 of "c:/tools/como433\libcomo\cnames/cstring") namespace std { using ::strlen; using ::strncat; } ^ "c:/tools/como433\libcomo\cnames/cstring", line 30: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Placeholder in boost.lambda/boost.function
by Stefan Slapeta 10 Apr '04

10 Apr '04

Sorry it this has been asked yet, I didn't find anything. Currently placeholders are ambigous if you include boost/bind.hpp and boost/lambda/bind.hpp in the same translation unit. The compiler finds the _1 of the function library and the one of the lambda library. Could this be resolved (without specifying an explicit namespace for the placeholder?) Stefan

1 0

Generic non-derivable base class
by Matthew Vogt 10 Apr '04

10 Apr '04

Is there any interest in creating a generic base class to encapsulate the non-derivable class idiom, as recently discussed wrt Reece Dunn's error check component? Since the the idiom is on a similar complexity level to that of noncopyable, I feel it would be appropriate to encapsulate it, if a general solution is possible. The following simple base class implements the mechanism as dicussed on Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the class can be non-virtually inherited, removing the most obvious chance of implementation error. Will this code work on multiple platforms? I have only tested on gcc 3.2... //------------------------------- namespace boost { template <typename T> struct nonderivable; namespace detail { template <typename T> class nonderivable_base { private: template <typename X> struct identity { typedef X type; }; friend typename identity<T>::type; friend class nonderivable<T>; nonderivable_base() {} nonderivable_base(const nonderivable_base&) {} }; } //namespace detail template <typename T> struct nonderivable : public virtual detail::nonderivable_base<T> { }; } // namespace boost // ------------------------ struct A : public boost::nonderivable<A> {}; struct B : public A {}; A a; // Ok B b; // Error - cannot be instantiated // ------------------------ Matt

3 4

RE: [boost] Re: Formal Review: Assignment Library
by Powell, Gary 10 Apr '04

10 Apr '04

Finally I have some more time to look at this library. My first complaint is that by default it links in the world. I think for something like this, we need to not link in every standard container and graph and tuple etc include file. I'm glad that the library handles it but the dependency graph is ridiculous. And yes I know that I can link in just the necessary sub include files, but my complaint is that it will trap the unwary user by default. I think if the basic file boost/assign.hpp only linked the minimum necessary I'd be much happier. Of course who is to say what is the minimum? So how about changing the name to boost/assign_to_anything.hpp (blech!) or something similar with the name being more of a warning. The file boost/assign/stl.hpp also unnecessarily includes every std container. At a minimum the use of BOOST_NO_FUNCTION_TEMPLATE_ORDERING shows that only <queue>, and <stack> are required. The define should also be around the unnecessary include files. There also appear to be two useless files in the distribution, make.hpp and template.hpp that should be removed. (minor cleanup) I did a cursory look at the docs, and will try and get back to them. I ran the tests with gcc 3.2 and they all compiled fine and ran fine. I vote for acceptance with the qualification that the stl.hpp header be reorganized into sub headers. I may come back with more stuff about the docs but it won't be to change my vote. (Dang standard for not splitting out <vector_fwd> et.al. ) Yours, -Gary- powellg(a)amazon.com

2 1