- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-05-08)
by Douglas Gregor 08 May '07

08 May '07

Boost Regression test failures Report time: 2007-05-08T01:11:32Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

Re: [boost] [Boost.Python] inconsistent use of function pointer typedef
by David Abrahams 08 May '07

08 May '07

on Sat May 05 2007, Sebastian Ramacher <s.ramacher-AT-gmx.at> wrote: > David Abrahams wrote: >> >> This is just a warning fix, right? >> > > Actually not. At least I haven't seen a warning here (msvc-8.0). > I just stumbled accross it while using boost::function for > convertible_function and got some unresolved symbol errors. I'm sorry, I don't understand. Is this a bugfix, or a stylistic improvement, or something else? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com

2 1

Improving PDF generation - a common look and feel?
by John Maddock 08 May '07

08 May '07

Folks, I've been working on improving our ability to generate PDF's from Quickbook/Docbook source using a "torture-test" consisting of a subset of the Math lib docs. I have some questions/feedback required, but first some observations: FO Generators: ~~~~~~~~~~~~~~ I've tried three FO processors: Apache FOP-0.23: lot's of flow control issues, and SVG rendering problems. Don't use unless you have to. Apache FOP-0.93 (latest stable release): Some flow control issues, but hugely improved compared to 0.23. Doesn't render symbol characters (Greek characters for example) correctly without manually editing the FO output. XEP from RenderX (www.renderx.com) Everything I've tried just plain works first time. It's command line compatible with FOP so it fit's into Boost.Build with just a trivial change to your user_config.jam. Only downside is that it's a commercial product and the free personal edition puts a small logo at the bottom of each page. Test outputs from each can be found in the vault: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=P… Improving Our Stylesheets ~~~~~~~~~~~~~~~~~~~~~~~~~ I've made some changes (not committed yet) to our fo.xsl stylesheet to: * Syntax highlight C++ code. * Put a box around code blocks and admonishments. * Improve the appearance of tables. * Added some keep-together instructions to improve flow-control around tables/code/admonishments. I've tried to mimic our HTML stylesheets as far possible, and the effects can be seen in the test PDF's. The Questions: ~~~~~~~~~~~~~~ 1) How do folks feel about the look and feel of these: are these heading in the right direction? 2) Do we want a consistent look/feel across all Boost-PDF's? If yes, is it OK to commit the stylesheet changes (diff's attached)? 3) Many of the page layout options (margins etc) I'm using are expressed as xsl-params in my Jamfile, should these be in the fo.xsl as well? Currently I have: # PDF Options: # TOC Generation: this is needed for FOP-0.9 and later: # <xsl:param>fop1.extensions=1 # TOC for XEP only: <xsl:param>xep.extensions=1 # TOC generation: this is needed for FOP 0.2, but must not be set to zero for FOP-0.9 or XEP! <xsl:param>fop.extensions=0 # No indent on body text: <xsl:param>body.start.indent=0pt # Margin size: <xsl:param>page.margin.inner=0.5in # Margin size: <xsl:param>page.margin.outer=0.5in # Yes, we want graphics for admonishments: <xsl:param>admon.graphics=1 # Set this one for PDF generation *only*: # default pnd graphics are awful in PDF form, # better use SVG's instead: <xsl:param>admon.graphics.extension=".svg" 4) Do we have a consistent location for PDF downloads: if not should we have? Outstanding Issues: ~~~~~~~~~~~~~~~~~~~ The biggest one is that PDF generation is a lot harder than it should be with bjam: if we could get FO's and PDF's placed in a "pdf" subdirectory that would help enormously - currently they get generated in a directory of bjam's choosing under bin.v2 which results in all links to images breaking :-( FO generation also fails if the FO file already exists. So basically I need a Boost.Build expert to help with these: or at least explain how the existing rules work! Anyway, thanks in advance for any feedback you may have, John.

4 6

Some thoughts on multi_array
by Marcus Lindblom 08 May '07

08 May '07

Hi, Multi_array is a really excellent piece of software. However, as I find myself using it as a simple xD-container it's a bit odd at times. I would very much like a smart swap operation to avoid doing resize & assign. Also, I don't fully understand the argument on genericity, but I haven't not worked with generic array algorithms. I do feel that having a STL-like behaviour is important. The suggestion on an additional template param would work (albeit, IMHO, it seems to be a bit hackish) but I would rather have that behaviour as default, because I and some others I know mostly use it as a very convenient xD-array with stl-properties. I was struggling a bit with swap/assignment, and found this discussion http://lists.boost.org/boost-users/2007/02/25243.php. It doesnt' seem to continue after that e-mail? Any progress/thoughts beyong that? I also agree with point 2 in this posting http://lists.boost.org/boost-users/2007/02/25576.php, which is something we've found lacking at a few times. Cheers, /Marcus

1 0

[thread] new thread_pool and dispatcher classes
by Yuval Ronen 08 May '07

08 May '07

Here are a few classes which I think are very useful: 1. A thread_pool class. I think there's not much I can tell you that you don't know about it. It's something that has threads, and can accept tasks to be pushed into a queue, and executed in turn when a thread is available. It can also be suspended (stop handling tasks, but keep the threads alive) and resumed. 2. Two 'dispatcher' classes, one for plain threads, and one for thread_pools. They accept a single task, or several tasks, to be executed, either by dedicated threads (the thread_dispatcher class), or by a thread_pool (the thread_pool_dispatcher class). These classes provide a wait() method that block until all tasks are done. IMO, these classes fill a hole in the Boost.Thread library, and can be a basic for the future<> template (I have to admit I didn't follow the future<> discussion, so I hope there's nothing here to contradict any consensus reached in that discussion, if any). A few notes: 1. The semahpore class is there because it was needed for the thread_pool_dispather, but I think it will be a good general purpose addition to Boost.Thread. If I'm the only one thinking so, it can be moved as implementation detail of thread_pool_dispather. 2. The thread_task typedef should really be removed. Instead, a 'task' typedef should be added to boost::thread. So all occurances of 'thread_task' should be replaced with 'thread::task'. 3. I'm not sure about the name 'dispatcher', but couldn't find anything I'm happy with. Something that catches the essence of the classes. Any suggestions are welcome. 4. The thread_pool class can benefit from two additional features: 4.A. add_threads(size_t) and remove_threads(size_t). I think I can add those if found useful. 4.B. pre_loop and post_loop hooks to be executed by each of the worker threads in the thread_pool, immediately after creation, and before termination. I actually have a use case for those, but I don't want to distract the discussion from the main things. 5. The asserts in thread_pool::~thread_pool, thread_pool::suspend, thread_pool::resume, thread_dispatcher::~thread_dispatcher, thread_pool_dispatcher::~thread_pool_dispatcher are supposed to catch user errors. These asserts are questionable. I'm not sure whether those use cases are indeed errors, and if so, should assert be the right way to deal with them. I chose to be a hard-liner for now, with an option to soften. 6. The other asserts are there to catch errors in my code. 7. Some or maybe all of the asserts should be replaced by BOOST_ASSERT. I'm not sure of the Boost convention here. I hope it will be found useful! #ifndef BOOST_THREAD_SEMAPHORE_HPP #define BOOST_THREAD_SEMAPHORE_HPP #include <cstdlib> #include <cassert> #include <boost/thread/mutex.hpp> #include <boost/thread/condition.hpp> namespace boost { class semaphore { public: semaphore(std::size_t count) : m_count(count), m_mutex(), m_condition() { } void lock() { mutex::scoped_lock sl(m_mutex); while (m_count == 0) m_condition.wait(sl); assert(m_count > 0); m_count--; } void unlock() { mutex::scoped_lock sl(m_mutex); m_count++; m_condition.notify_one(); } private: std::size_t m_count; mutex m_mutex; condition m_condition; }; } // namespace boost #endif #ifndef BOOST_THREAD_DISPATCHER_HPP #define BOOST_THREAD_DISPATCHER_HPP #include <cassert> #include <set> #include <algorithm> #include <boost/noncopyable.hpp> #include <boost/bind.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/thread_task.hpp> namespace boost { class thread_dispatcher : private noncopyable { public: thread_dispatcher(const thread_task &t) : m_threads() { create_thread(t); } template <typename FwdIter> thread_dispatcher(FwdIter task_begin, FwdIter task_end) : m_threads() { std::for_each(task_begin, task_end, bind(&thread_dispatcher::create_thread, this, _1)); } ~thread_dispatcher() { assert(m_threads.empty()); } void wait() { std::for_each(m_threads.begin(), m_threads.end(), bind(&thread::join, _1)); m_threads.clear(); } private: std::set< shared_ptr<thread> > m_threads; void create_thread(const thread_task &t) { m_threads.insert(shared_ptr<thread>(new thread(t))); } }; } // namespace boost #endif #ifndef BOOST_THREAD_POOL_HPP #define BOOST_THREAD_POOL_HPP #include <cstdlib> #include <cassert> #include <set> #include <deque> #include <algorithm> #include <boost/noncopyable.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/thread_task.hpp> namespace boost { class thread_pool : private noncopyable { enum state { active_, suspended_, terminating_ }; public: typedef function<void ()> task; thread_pool(std::size_t thread_count) : m_mutex(), m_condition(), m_threads(), m_tasks(), m_state(active_) { thread_task f = bind(&thread_pool::thread_func, this); while (thread_count > 0) { m_threads.insert(shared_ptr<thread>(new thread(f))); thread_count--; } } ~thread_pool() { { mutex::scoped_lock sl(m_mutex); assert(m_state == active_); m_state = terminating_; m_condition.notify_all(); } std::for_each(m_threads.begin(), m_threads.end(), bind(&thread::join, _1)); } bool suspended() const { mutex::scoped_lock sl(m_mutex); assert(m_state == active_ || m_state == suspended_); return m_state == suspended_; } void suspend() { mutex::scoped_lock sl(m_mutex); assert(m_state == active_); m_state = suspended_; } void resume() { mutex::scoped_lock sl(m_mutex); assert(m_state == suspended_); m_state = active_; m_condition.notify_all(); } void enqueue(const task &t) { mutex::scoped_lock sl(m_mutex); assert(m_state == active_ || m_state == suspended_); m_tasks.push_back(t); m_condition.notify_one(); } void discard_pending_tasks() { mutex::scoped_lock sl(m_mutex); assert(m_state == active_ || m_state == suspended_); m_tasks.clear(); } private: mutable mutex m_mutex; condition m_condition; std::set< shared_ptr<thread> > m_threads; std::deque< task > m_tasks; state m_state; void thread_func() { task t; while (t = get_task(), t) { t(); t.clear(); } } task get_task() { mutex::scoped_lock sl(m_mutex); while (m_state == suspended_ || m_state == active_ && m_tasks.empty()) m_condition.wait(sl); assert(m_state != suspended_); if (!m_tasks.empty()) { task t = m_tasks.front(); m_tasks.pop_front(); return t; } assert(m_state == terminating_ && m_tasks.empty()); return task(); } }; } // namespace boost #endif #ifndef BOOST_THREAD_POOL_DISPATCHER_HPP #define BOOST_THREAD_POOL_DISPATCHER_HPP #include <cstdlib> #include <cassert> #include <algorithm> #include <boost/noncopyable.hpp> #include <boost/bind.hpp> #include <boost/thread/semaphore.hpp> #include <boost/thread/thread_pool.hpp> namespace boost { class thread_pool_dispatcher : private noncopyable { public: thread_pool_dispatcher(const thread_pool::task &t, thread_pool &pool) : m_task_count(0), m_sem(0) { enqueue(t, pool); } template <typename FwdIter> thread_pool_dispatcher(FwdIter task_begin, FwdIter task_end, thread_pool &pool) : m_task_count(0), m_sem(0) { std::for_each(task_begin, task_end, bind(&thread_pool_dispatcher::enqueue, this, _1, ref(pool))); } ~thread_pool_dispatcher() { assert(m_task_count == 0); } void wait() { while (m_task_count > 0) { m_sem.lock(); m_task_count--; } } private: std::size_t m_task_count; semaphore m_sem; void enqueue(const thread_pool::task &t, thread_pool &pool) { m_task_count++; pool.enqueue(bind(&thread_pool_dispatcher::execute_and_notify, this, t)); } void execute_and_notify(const thread_pool::task &t) { t(); m_sem.unlock(); } }; } // namespace boost #endif #ifndef BOOST_THREAD_TASK_HPP #define BOOST_THREAD_TASK_HPP #include <boost/function.hpp> namespace boost { typedef function<void ()> thread_task; } // namespace boost #endif

4 9

[boost::proto] how to get the type of a proto expression?
by Maurizio Vitale 08 May '07

08 May '07

Eric, I can get the type of a proto expression (wrapped in a user-defined skin) using BOOST_TYPEOF, but then I noticed BOOST_PROTO_TYPEOF in context.hpp. Which one is supposed to be used? BOOST_PROTO_TYPEOF fails on me when trying to emulate the way it is used inside context.hpp. Here is code that shows what I'm trying. If BOOST_PROTO_TYPEOF is internal only, just let me know and forget the code below. Regards, Maurizio #include <iostream> #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_PROTO_MAX_ARITY 8 #define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 8 // GCC bug workaround, needs to be at least BOOST_PROTO_MAX_ARITY #include <boost/xpressive/proto/proto.hpp> #include <boost/xpressive/proto/context.hpp> #include <boost/xpressive/proto/extends.hpp> #include <boost/xpressive/proto/transform/arg.hpp> #include <boost/xpressive/proto/transform/construct.hpp> namespace proto=boost::proto; namespace mpl=boost::mpl; using proto::_; struct my_domain : proto::domain<struct my_grammar> {}; //struct my_domain : proto::domain<> {}; template<typename> struct my_context; template <typename Expr> struct my_expr : proto::extends<Expr, my_expr<Expr>, my_domain> { typedef proto::extends<Expr, my_expr<Expr>, my_domain> base_type; my_expr (Expr const& expr = Expr()) : base_type (expr) {}; using base_type::operator =; operator int () const { return static_cast<int>(proto::eval(*this, my_context<Expr> ())); } operator unsigned int () const { return static_cast<unsigned int>(proto::eval(*this, my_context<Expr> ())); } }; template<typename A, typename B, typename C, typename D, typename E, typename F, typename G, typename H> struct number { unsigned int m_data; }; struct my_grammar : proto::or_ < proto::terminal< number<_,_,_,_,_,_,_,_> > , proto::terminal<int>, proto::terminal<unsigned int>, proto::unary_expr<proto::_, my_grammar> , proto::binary_expr<proto::_, my_grammar, my_grammar> > {}; namespace boost { namespace proto { template<typename Expr> struct generate<my_domain, Expr> { typedef my_expr<Expr> type; static type make (Expr const& expr) { return type (expr); } }; } } // end namespace boost::proto template<typename Expr> struct my_context : proto::callable_context<const my_context<Expr> > { typedef unsigned int result_type; template<typename A, typename B, typename C, typename D, typename E, typename F, typename G, typename H> unsigned int operator () (proto::tag::terminal, number<A,B,C,D,E,F,G,H> n) const { return n.m_data; } }; template<int N> struct my_int : my_expr<typename proto::terminal< number<mpl::int_<0>,mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0> > >::type> { typedef number<mpl::int_<0>,mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0>, mpl::int_<0> > number_type; typedef my_expr<typename proto::terminal<number_type>::type> expr_type; my_int () {} my_int (int i) : expr_type (expr_type::type::make (i)) {} template<typename Expr> my_int& operator = (const my_expr<Expr>& e) { proto::arg (*this).m_data = static_cast<int>(proto::eval(e, my_context<Expr> ())); return *this; } template<typename T> my_int& operator = (T value) { proto::arg (*this).m_data = value; return *this; } }; template<typename T> struct dump; #define DUMP(T) typedef dump<T>::type t int main (int,char**) { my_int<6> i4(-22); int i; unsigned int j; i4 = 5; i4 = 5*i4; i = i4/i4+4; j = i4/i4; BOOST_PROTO_TYPEOF (i4+j+2, a_type); DUMP (a_type); // typedef BOOST_TYPEOF (i4*2) another_type; // DUMP(another_type); } /// Local Variables: /// mode:c++ /// comment-column:80 /// fill-column:160 /// compilation-read-command:nil /// compile-command:"g++ -I. -ope1 pe1.cpp" /// End:

2 4

[propertytree] - bug read/write empty ptree with xml parser?
by Oliver.Kowalke＠qimonda.com 08 May '07

08 May '07

Hello, I get an exception if I write an empty ptree to a stringstream and try to reconstruct a ptree from this stringstream. <unspecified file>(2): xml parse error test code: int main( int argc, char *argv[]) { try { std::stringstream ss; { pt::ptree p; pt::write_xml( ss, p); } std::cout << ss.str() << std::endl; { pt::ptree p; pt::read_xml( ss, p); // throws exception } return EXIT_SUCCESS; } catch ( std::exception const& e) { std::cerr << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled exception" << std::endl; } return EXIT_FAILURE; }

1 0

Re: [boost] Boost::Bigint header draft - suggestions are welcome!
by Arseny Kapoulkine 08 May '07

08 May '07

Hello, boost-request. > Date: Mon, 07 May 2007 17:19:36 +0100 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] Boost::Bigint header draft - suggestions are welcome! > Looks good. Some quick thoughts: > - Have you considered conversions to/from floating-point? Hmm, no. I'm putting it in the todo list, though this is not going to be in the base part I think. > - Have you considered using Boost.Operators? Yes. Quoting discussion with my mentor: >> See Boost.operators for a concept breakdown for Addable, Subtractable, etc. > > I started working on the header draft, and looked at boost.operators. > Am I correct if I say that they are not like traits (to be able to > determine if a type can be added to another one, etc.), but instead > provide implementation for all related operators if some basic ones > are provided (+ if += exists, all comparison operators if < and == > exist, etc.)? > > Because if that's true, the only thing I could use from it is the > group of operators that relate to comparison. > > The reason is simple - the suggested implementation for + in terms of > += > (T nrv( lhs ); nrv += rhs; return nrv;) > > is not as efficient as it could be even if compiler implements NRVO - > this function still always has extra copy (T nrv(lhs)). I referred to > it in my application btw. If I have a generic 3-register > implementation of an operation (add(dest, src1, src2)), I can do the > most efficient implementation. > > My implementation for + could look like (or well, it already does :)) > > bigint<I> result; > result.impl.add(lhs.impl, rhs.impl); > return result; > > So it utilizes NRVO, but does not have extra copy if the > implementation itself allows for it. So the call will have exactly the > same overhead as the user might expect if he knows what implementation > is used - there's no hidden overhead here, if the compiler implements > NRVO of course. And this does not require a lot of extra work, I was > planning to do 3-register implementations of every binary operation > anyway. > > As for <, <=, etc. - I don't see any benefit from boost operators for > me either. > > >= is implemented like this, for example: > > return lhs.impl.compare(rhs.impl) >= 0; > > And this "compare" function is more or less the same as operator< in > terms of implementation - not much harder. > > Though perhaps here the situation is different - in theory, providing > separate < and == allows the operations == and != be implemented > faster (not that I'm planning to do it), than via compare() == 0 way. So I guess the answer is - yes, I considered using Boost.Operators, but the current decision is not to use them. > - Are logical operations well defined for negative operands with > different numbers of bits? (e.g. -1 | 12345) Also, what does ~ do? > Are different signed and unsigned types needed? The semantics of logical operations for negative numbers is to be defined, they will most likely work with negative numbers as the 2-complement of their magnitude (regardless of the underlying implementation), either expanded at some amount of bits (max for bits in both operands, perhaps more than that) or negative numbers will just be treated as 2-complemented positive numbers with infinite number of '1' as a sign extension (so about -1 | 5: MSB first, LSB last -1 is treated as 1...(infinite number)..1111 5 is treated as 0...(infinite number)...0101 Oring them produces 1..(infinite number)..1111 so that's -1 Xoring them produces 1..(infinite number)..1010 that's the complement for 101, so that's -5). This will be outlined in the docs. I don't think providing both signed and unsigned types is reasonable, because without sign, special handling for underflows has to be decided on, and generally I don't see 'unsigned bigint' as something that should ever be used instead of 'signed' one. > - I take it that this class dynamically allocated enough memory for the > value. Can you quantify the performance penalty that this imposes > compared to declaring the number of bits in advance (e.g. bigint<256>) > and statically allocating that much memory? 'default' (pure C++ w/out third-party libraries) implementation will be useful with any storage strategy (I will include one based on std::vector, so it'll be possible to provide a custom allocator, and a stack-based one with the specified maximum number of bytes). 'gmp' one (based on GMP) is not customizable in this way now, though this is a feature in a todo list for the second part of the project (read: perhaps it will be implemented after all base features are). -- Best regards, Arseny mailto:arseny.kapoulkine@gmail.com

1 0

Re: [boost] [1.34.0-beta][Build] Problems with stagedir option
by Johannes Brunen 08 May '07

08 May '07

Thank, you. I missed this: Usage: bjam [options] [install|stage] Regards, Johannes "Eoin O'Callaghan" <eoinoc(a)iol.ie <mailto:eoinoc@iol.ie>> schrieb im Newsbeitrag <news:46403B24.5070308@iol.ie>...> Johannes Brunen wrote: >> Hi, >> >> today I tried building the beta version on win XP (VC 7.1) with the >> following bjam call: >> >> bjam --libdir=./stage --stagedir=./stage release debug threading=multi >> > > I think you just also need to add 'stage' to the commandline > > bjam --libdir=./stage --stagedir=./stage release debug threading=multi stage > > Regards, Eoin > > > _______________________________________________ > Unsubscribe & other changes: <http://lists.boost.org/mailman/listinfo.cgi/boost> >

1 0

[1.34.0-beta][Build] Problems with stagedir option
by Johannes Brunen 08 May '07

08 May '07

Hi, today I tried building the beta version on win XP (VC 7.1) with the following bjam call: bjam --libdir=./stage --stagedir=./stage release debug threading=multi All libraries build fine. However, the stagedir option seems not to work properly (in case I used it correctly). None of the libraries got copied to the ./stage directory, which I had created beforehand. Additionally, I tried bjam --stagedir=./stage release debug threading=multi with the same result. The following call bjam --version gives Boost.Build V2 (Milestone 11) Boost.Jam 03.1.14 Is there any usage failure on my side or is this an undiscoverd problem. With best regards, Johannes Brunen DataSolid GmbH

2 1