December 2007 - Boost - lists.boost.org

Beta Distribution for boost::random
by Jeremy Bruestle 17 Dec '07

17 Dec '07

Hello, I have implemented support for the beta distribution for boost::random. I was wondering who I should send it to for examination and possible acceptance into boost? The method is based on the paper "Generating Beta Variates with Nonintegral Shape Parameters" ( http://portal.acm.org/citation.cfm?id=359460.359482) by R. C. H. Cheng, which was the best performing fully general purpose method I could find. It uses a reject method whose success rate varies based on the parameters, but whose worst case expected number of samples is 4. If anyone knows of a better method please let me know. -Jeremy Bruestle

6 16

[vault] ctor_shared_from_this()
by Robert Sitton 17 Dec '07

17 Dec '07

I've posted a modification to enable_shared_from_this() to support calling shared_from_this in a constructor and destructor. d Any feedback? Abrahams) 16. Re: Trac open bug summary mailings missing new tickets (Rene Rivera) 17. BoostCon 2008: May 4-9 (David Abrahams) 18. Re: Reporting bugs at Trac? (Olaf van der Spek) 19. Re: [serialization] serialization used in multiple DLL problems (Felipe Magno de Almeida) 20. [review] Formal Fast-Track review of the Boost.Functional/Factory library begins today (John Torjo) Michael Marcin wrote: > John Torjo wrote: >> Eames, Andrew wrote: >>> Hi, >>> >>> I apologize if this is a FAQ - I couldn't find much on other compilers >>> >>> >>> >>> I am interested in using boost with a compiler for a DSP - The compiler >>> is somewhat archaic - I'm not using RTTI or exceptions (the compiler >>> supports them but it is currently broken) - the STL has old iostreams >>> and no doubt I will find some other musty corners. I don't have any >>> illusions about getting the whole of boost to compile but I'm sure there >>> are some large pieces that will work OK. I have no problem doing the >>> port myself. >>> >>> >>> >> RTTI is pretty useful, and I think quite a few libraries rely on >> dynamic_cast at least once. >> >> For instance Boost Logging Lib ( http://torjo.com/log2/) relies on it >> once - I guess you could get 'round it. >> >> I guess the 1M$ question is : why do you need that specific compiler? >> > > I'm in a similar situation where I have to use a specific compiler > because it's the only compiler supported by the closed SDK for the > platform we're developing for. > > Right now I, unfortunately, can only use the Torjo logging library for a > windows port of the application because the target platform doesn't > support RTTI (exceptions are fine). This is annoying because the > debuggers for these embedded devices are sometimes flaky and logging on > device is sometimes the only way to fix bugs. So we have to have another > simple homegrown logging library for on device logging. > > There are many other Boost libraries that we can't use, at least out of > the box, because they use RTTI in one or two places where they probably > don't have to. For instance lexical_cast uses it to provide extra > information to the bad_lexical_cast exception but functions just fine > without it. I didn't dig enough into the implementation but it looks > like Boost.Function and Boost.Variant may be in a similar boat. > > I think shared_ptr used to have this issue but got changed after 1.34. I > wish more libraries would follow its lead if possible. You can raise the viability of the issue by submitting patches. Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present. But the default would be to user RTTI on the theory it is usually available. --Beman Beman Dawes: > Where RTTI is useful, but not essential, I'd personally rather not > remove it entirely. Instead, the code could respond to a macro > (BOOST_NO_RTTI perhaps) and avoid usage when present. In non-essential scenarios, often the proper macro to test is BOOST_NO_TYPEID: http://svn.boost.org/trac/boost/ ticket/1104 since typeid(T) does not require the R in RTTI and may be supported even when RTTI is off (under MSVC for example). Joaquin M Lopez Munoz skrev: > Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes: >> I would use it as a lightweight and more convenient replacement for >> boost::shared_ptr<const T>. >> >> In my application I might have < 50 objects that needs to by flyweights. >> They are almost never identical, and if they are, the memory occupied by >> the factory would probably be much larger than that of duplication. > > Well, then you might not need using the flyweight idiom > after all... Well, it's lower overhead (if no factory and forwarding constructors/operations makes it a better choice than shared_ptrconst T>. -Thorsten Thorsten Ottosen: > Joaquin M Lopez Munoz skrev: >> Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes: > >>> I would use it as a lightweight and more convenient replacement for >>> boost::shared_ptr<const T>. >>> >>> In my application I might have < 50 objects that needs to by flyweights. >>> They are almost never identical, and if they are, the memory occupied by >>> the factory would probably be much larger than that of duplication. >> >> Well, then you might not need using the flyweight idiom >> after all... > > Well, it's lower overhead (if no factory and forwarding > constructors/operations makes it a better choice than shared_ptrconst T>. It might be possible to do this using a custom factory along the lines of: template<class T> struct sp_factory { typedef boost::shared_ptr<T const> handle_type; handle_type insert( T const & t ) { return handle_type( new T( t ) ); } void erase( handle_type ) {} T const & entry( handle_type p ) { return *p; } }; but there's no way to tell from the documentation; it never describes how the Factory template parameter is actually used. http://svn.boost.org/svn/boost/ sandbox/flyweight/libs/flyweight/ doc/reference/flyweight.html#fly weight As I read it, a flyweight<> can ignore all of its template parameters beyond T and still conform to its spec, which is probably not what's intended. Peter Dimov wrote: > Beman Dawes: > >> Where RTTI is useful, but not essential, I'd personally rather not >> remove it entirely. Instead, the code could respond to a macro >> (BOOST_NO_RTTI perhaps) and avoid usage when present. > > In non-essential scenarios, often the proper macro to test is > BOOST_NO_TYPEID: > > http://svn.boost.org/trac/boost/ ticket/1104 > > since typeid(T) does not require the R in RTTI and may be supported even > when RTTI is off (under MSVC for example). Good point. --Beman There's a file called 'madshell.phtml' in the Vault that is probably an exploit. I see a few other .phtml's as well. -- Peter Dimov http://www.pdimov.com >>> So you can call it whatever you like and still be right :-) >>> >>> BTW I believe the min and max cases are basically just mirror >>> images of each >>> other about the location parameter? >> >> So names aside, it's all the extreme value distribution, but there >> are minimum and maximum variations of it. I found this... It was a nice overview of some of the distribution. Section 1.2 has a nice overview of the type 1, 2 and 3 distributions and how they relate (and how they're related to Weibull, for example). I wonder if I can find this book in our math library... http://www.worldscibooks.com/ mathematics/p191.html Andrew Sutton asutton(a)cs.kent.edu Peter Dimov wrote: > There's a file called 'madshell.phtml' in the Vault that is probably an > exploit. I see a few other .phtml's as well. Thanks for pointing those out. I've adjusted the cleanup filter accordingly. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo More about http://svn.boost.org/svn/boost/ sandbox/flyweight/libs/flyweight/ doc/reference/flyweight.html#fly weight I don't understand the source of the complexity at the flyweight<> level. A "naive" flyweight<> could look like: template<class T, class F = default_factory> class flyweight { typedef typename F::handle_type handle_type; handle_type handle_; public: flyweight( ... args ): handle_( F::insert( T( args... ) ) ) {} T const& get() const { return F::value( handle_ ); } }; It seems to me that this provides the same amount of expressive power as the current interface. Locking/tracking/holding can be made parameters of the Factory if so desired, and a factory_core<F',L,T,H> template may be provided as a convenience in a separate header, but in the majority of the cases the user will never need it. In fact flyweight<> is already implemented in a similar way, it uses a flyweight_core<> class as F. Note that the above simpler flyweight<> allows me to pass the aforementioned template<class T> struct sp_factory { typedef boost::shared_ptr<T const> handle_type; static handle_type insert( T const & t ) { return handle_type( new T( t ) ); } static T const & entry( handle_type p ) { return *p; } }; as F; there's no need to invent a locking policy, a tracking policy, a holder, or a stateful factory. ----- Mensaje original ----- De: Peter Dimov <pdimov(a)pdimov.com> Fecha: Domingo, Diciembre 16, 2007 8:27 pm Asunto: Re: [boost] [flyweight] some minor comments Para: boost(a)lists.boost.org > Thorsten Ottosen: > > Well, it's lower overhead (if no factory and forwarding > > constructors/operations makes it a better choice than > shared_ptrconst T>. > > It might be possible to do this using a custom factory along the > lines of: > > template<class T> struct sp_factory > { > typedef boost::shared_ptr<T const> handle_type; > > handle_type insert( T const & t ) { > return handle_type( new T( t ) ); } > void erase( handle_type ) {} > T const & entry( handle_type p ) { return *p; } > }; This approach would work (except for a technical issue I comment later) but it's overkill because it provides its own tracking, which is already taken care of by the Tracking policy. One would use then in conjunction with the no_tracking and no_locking policies, sort of like this: template<class T> using no_factory_flyweight= flyweight<T,sp_factory<_1,_2>,n o_tracking,no_locking>; An alternative would be to provide an even simpler factory: template<typename Entry,typename Value> struct trivial_factory { typedef const Entry* handle_type; handle_type insert(const Entry& x){return new Entry(x);} void erase(handle_type p){delete p;} const Entry& entry(handle_type p){delete p;} }; // default tracking is ref_counted template<class T> using no_factory_flyweight= flyweight<T,trivial_factory<_1,_2 >,no_locking>; Either of these two alternatives *almost* works, but for a detail: equality of flyweight objects is defined in terms of equality of reference, i.e. x==y iff &x.get()==&y.get(). sp_factory (and trivial_factory) interpret every value as distinct for any other: no_factory_flyweight<std:string> x("hello"), y("hello"); assert(x!=y); //assertion passes which results in no value sharing, except when a flyweight is copied from another. Nothing wrong with this as long as it is known and accepted, of course. > bu ... This message is too long, the rest is truncated. On 12/17/07, boost-request(a)lists.boost.org <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." >

1 0

can't use replace_all under solaris
by Amr Shahin 17 Dec '07

17 Dec '07

hello im trying to use the replace_all function defined in boost/algorithm/string.hpp header, but when i try to compile it under solaris, i get following error: "/usr/include/boost/algorithm/string/detail/sequence.hpp", line 34: Error: Could not find a match for std::string::insert(char*, std::deque<char>::iterator, std::deque<char>::iterator) needed in boost::algorithm::detail::insert<std::string, std::deque<char>::iterator>(std::string &, char*, std::deque<char>::iterator, std::deque<char>::iterator) this is the source code: #include<cstring> #include<iostream> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main( ) { string s = "Amr Yassir Shahin"; replace_all( s , "Yassir" , "Adel" ); cout << "s now: " << s << endl; return 0; } and this is the command i use to compile g++ file.cpp my machine is : SunOS suntest 5.9 Generic_118558-26 sun4u sparc SUNW,Sun-Fire-V240 anyone can help ?

1 0

[iterator, test] Patches for PA_RISC HP-UX 11.11 compatibility
by Jurko Gospodnetić 17 Dec '07

17 Dec '07

[I am repeating this post as no one replied to it and I guess it could have gotten overlooked in the original thread.] Hi. I'm attaching two patches - one for the Boost test and one for the Boost iterator library to make them compatible with HP-UX PA_RISC 11.11 system headers. These headers define global preprocessor macros R1, R2, ... so the patches rename similarly named identifiers in Boost code. Patches have been prepared based on SVN revision 41987. They are simple local variable and template parameter renames which should not cause any problems. New names are a bit more verbose to eliminate possible conflicts with headers on other system. Could someone please apply them? And could they be applied to the 1.35 branch as well? These patches in additional to two slight tweaks inside Boost ASIO will allow Boost ASIO to compile and pass all tests on this platform. Hope this helps. Best regards, Jurko Gospodnetić --- C:\Documents and Settings\Jurko\Desktop\SVN_41987\boost\iterator\iterator_facade.hpp 2007-12-12 11:50:30.000000000 +-0100 +++ C:\Documents and Settings\Jurko\Desktop\Modified\boost\iterator\iterator_facade.hpp 2007-12-12 12:13:51.000000000 +-0100 @@ -428,34 +428,34 @@ }; } // namespace detail // Macros which describe the declarations of binary operators # ifdef BOOST_NO_STRICT_ITERATOR_INTEROPERABILITY -# define BOOST_ITERATOR_FACADE_INTEROP_HEAD(prefix, op, result_type) \ - template < \ - class Derived1, class V1, class TC1, class R1, class D1 \ - , class Derived2, class V2, class TC2, class R2, class D2 \ - > \ - prefix typename mpl::apply2<result_type,Derived1,Derived2>::type \ - operator op( \ - iterator_facade<Derived1, V1, TC1, R1, D1> const& lhs \ - , iterator_facade<Derived2, V2, TC2, R2, D2> const& rhs) +# define BOOST_ITERATOR_FACADE_INTEROP_HEAD(prefix, op, result_type) \ + template < \ + class Derived1, class V1, class TC1, class Reference1, class Difference1 \ + , class Derived2, class V2, class TC2, class Reference2, class Difference2 \ + > \ + prefix typename mpl::apply2<result_type,Derived1,Derived2>::type \ + operator op( \ + iterator_facade<Derived1, V1, TC1, Reference1, Difference1> const& lhs \ + , iterator_facade<Derived2, V2, TC2, Reference2, Difference2> const& rhs) # else -# define BOOST_ITERATOR_FACADE_INTEROP_HEAD(prefix, op, result_type) \ - template < \ - class Derived1, class V1, class TC1, class R1, class D1 \ - , class Derived2, class V2, class TC2, class R2, class D2 \ - > \ - prefix typename boost::detail::enable_if_interoperable< \ - Derived1, Derived2 \ - , typename mpl::apply2<result_type,Derived1,Derived2>::type \ - >::type \ - operator op( \ - iterator_facade<Derived1, V1, TC1, R1, D1> const& lhs \ - , iterator_facade<Derived2, V2, TC2, R2, D2> const& rhs) +# define BOOST_ITERATOR_FACADE_INTEROP_HEAD(prefix, op, result_type) \ + template < \ + class Derived1, class V1, class TC1, class Reference1, class Difference1 \ + , class Derived2, class V2, class TC2, class Reference2, class Difference2 \ + > \ + prefix typename boost::detail::enable_if_interoperable< \ + Derived1, Derived2 \ + , typename mpl::apply2<result_type,Derived1,Derived2>::type \ + >::type \ + operator op( \ + iterator_facade<Derived1, V1, TC1, Reference1, Difference1> const& lhs \ + , iterator_facade<Derived2, V2, TC2, Reference2, Difference2> const& rhs) # endif # define BOOST_ITERATOR_FACADE_PLUS_HEAD(prefix,args) \ template <class Derived, class V, class TC, class R, class D> \ prefix Derived operator+ args --- C:\Documents and Settings\Jurko\Desktop\SVN_41987\boost\test\test_tools.hpp 2007-12-12 11:49:19.000000000 +-0100 +++ C:\Documents and Settings\Jurko\Desktop\Modified\boost\test\test_tools.hpp 2007-12-12 12:27:50.000000000 +-0100 @@ -643,24 +643,24 @@ //____________________________________________________________________________// template <class Left, class Right> inline predicate_result bitwise_equal_impl( Left const& left, Right const& right ) { - predicate_result res( true ); + predicate_result res( true ); std::size_t left_bit_size = sizeof(Left)*CHAR_BIT; std::size_t right_bit_size = sizeof(Right)*CHAR_BIT; - static Left const L1( 1 ); - static Right const R1( 1 ); + static Left const leftOne ( 1 ); + static Right const rightOne( 1 ); std::size_t total_bits = left_bit_size < right_bit_size ? left_bit_size : right_bit_size; for( std::size_t counter = 0; counter < total_bits; ++counter ) { - if( ( left & ( L1 << counter ) ) != ( right & ( R1 << counter ) ) ) { + if( ( left & ( leftOne << counter ) ) != ( right & ( rightOne << counter ) ) ) { res = false; res.message() << "\nMismatch in a position " << counter; } } if( left_bit_size != right_bit_size ) {

4 12

[functional/forward]howto do Abraham's new_ attached to review post
by Larry Evans 17 Dec '07

17 Dec '07

I've been trying, unsuccessfully, to use the forward library to do what the template<class T> inline std::auto_ptr<T> new_ (/*variadic number args passed to T CTOR/*) function shown in the attachment to: http://lists.boost.org/Archives/boost/2007/12/131251.php However, so far all I've got is shown in the attachment. But that's not what, AFAICT, Abraham's new_does. Could someone show me how to do Abraham's new with functional/forward?

1 2

[patch] mersenne_twister serialization
by Neal Becker 17 Dec '07

17 Dec '07

This is an improved patch for mt serialization, using the serialization collection stuff

1 0

Trac open bug summary mailings missing new tickets
by David Abrahams 17 Dec '07

17 Dec '07

http://svn.boost.org/trac/boost/report/9 shows that although I have accepted 9 tickets, my libraries have many more open tickets than that against them. I think the total number is more interesting than the number I've actually accepted. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

[iterator] lvalue-ness resurrection in transform_iterator?
by shunsuke 17 Dec '07

17 Dec '07

Hi, Assume a base iterator is an InputIterator with RandomAccessTraversalTag. boost::make_zip_iterator often returns such iterators. boost::transform_iterator sometimes resurrects lvalue-ness of its base iterator. For example, char & to_lvalue(boost::tuple<char &, int &> const &t) { return boost::get<0>(t); } can return a lvalue from zip_iterator dereference. Therefore, if boost::transform_iterator extracts "pure" traversal tag from its base iterator, it can be not an InputIterator but a RandomAccessIterator. The patch will be something like this: template <class UnaryFunc, class Iterator, class Reference, class Value> struct transform_iterator_base { // ... typedef iterator_adaptor< transform_iterator<UnaryFunc, Iterator, Reference, Value> , Iterator , cv_value_type - , use_default // Leave the traversal category alone + , typename pure_traversal_tag<typename iterator_traversal<Iterator>::type>::type , reference > type; }; } Is there any pitfalls? Regards, -- Shunsuke Sogame

2 5

[Announce] Boost Testing Integrated with Trac
by David Abrahams 16 Dec '07

16 Dec '07

Pursuant to the conclusions of http://lists.boost.org/Archives/boost/2007/08/125724.php that our reporting system ought to be integrated with Trac, Daniel Wallin and I have installed a modified Bitten plugin (http://bitten.edgewall.org/) on the boost-consulting Trac server. We are using it with a few slave machines to test (a mirror of) the Boost subversion repository. You can see the results at: https://boost-consulting.com/trac/projects/boost/build https://boost-consulting.com/trac/projects/boost/build/trunk https://boost-consulting.com/trac/projects/boost/build?view=inprogress and by following the obvious links on those pages. Some features (I'm probably forgetting something; please poke around and see what you can discover): * runs tests for each atomic Boost checkin. * slaves can run incremental or from-scratch tests * failure markup is processed very quickly in Python on the machine doing the testing and used to alter the effect of failures, with no horrendous and time-consuming XSLT step * no tests are run for libraries that are marked unusable on a given os/compiler * no unreliable jam log processing is involved: Boost.Build is directly generating XML which is processed by python and shipped up to the Trac server * only failed tests that aren't marked up are shown in most views * a record of each build run is kept in the Trac server's database * reorganizing the system so that several machines can contribute to a single test run with a given OS/toolset is fairly straightforward. There are obviously a few rough edges and things we could do better in the UI, but I really believe this overall approach is a winner. Daniel and I are fairly competent Trac and Bitten hackers, so we should be able to make this system do whatever Boost needs, feed back the improvements to the Bitten community, and leave us with a maintainable codebase that isn't permanently tied to one or two people. It's time to open a discussion of exactly how the system should evolve, what features we want to see in the UI, etc. I hope those of you with an interest in the quality of Boost testing tools will join us on the boost-testing list to discuss this project's future. If anyone wants to run an additional testing slave, please let me know; once you have Python on your system, it's extremely easy to set up. Regards, Dave Postscript: Quick Overview of Bitten for Boost people ===================================================== Bitten is a continuous integration system that's integrated with Trac. Testing machines (called "slaves") run a Python script (part of the Bitten distribution) that checks periodically with the server to see if anything needs to be tested. The server manages a set of testing "recipes," each of which is associated with a directory in the subversion repository and a set of slave criteria (such as "are you running Linux?"). If a recipe has criteria matching the inquiring slave and there have been changes in the associated part of the repository, the slave executes the recipe. A recipe is divided into a series of "steps," each of which is composed of commands (http://bitten.edgewall.org/wiki/Documentation/commands.html) Slaves report back to the server as they execute each step, so the server can tell you about the progress of each slave. If any step fails, the build fails and the slave stops. Recipes are expressed in XML and stored in the server's Trac database. Trac users with the right privileges can create, edit, and delete recipes. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 4

[vault] Suspicious file: madshell.phtml
by Peter Dimov 16 Dec '07

16 Dec '07

There's a file called 'madshell.phtml' in the Vault that is probably an exploit. I see a few other .phtml's as well. -- Peter Dimov http://www.pdimov.com

2 1