- Boost - lists.boost.org

[errorinfo] RFC
by Don G 11 Apr '05

11 Apr '05

Just curious if anyone has had a chance to look at the errorinfo.zip or think about the previous email on this subject. I am looking at putting together a straw man for a general asynchronous library and shared_ptr<errorinfo> would play much better in that space than shared_ptr<std::exception>. Thanks for any feedback! Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

The state of the review process
by Arkadiy Vertleyb 11 Apr '05

11 Apr '05

Hi all, I am wondering why the review process doesn't seem to be moving since the FSM library was accepted, more than three weeks ago. Can anybody shed some light on this? Regards, Arkadiy

2 1

[Wave]
by Matt Hurd 11 Apr '05

11 Apr '05

Do you think Wave could be used for adding some syntatic sugar that would allow easy compile time programming of strings? If I remember the main issue with such thoughts it was the clumsiness of the typelist of characters. A little non-standard sugar from Wave might solve that. Been thinking about a compile time packet parser and how something like a spirit-like but at compile time would fit the bill. Thoughts? Matt. matthurd(a)acm.org

2 2

[Boost-bugs] [ boost-Bugs-1180413 ] MT seed algorithm needs fix applied
by SourceForge.net 11 Apr '05

11 Apr '05

Bugs item #1180413, was opened at 2005-04-11 10:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1180413&group_… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel van der Zee (oblomovska) Assigned to: Jens Maurer (jmaurer) Summary: MT seed algorithm needs fix applied Initial Comment: The version of Mersenne twister in Boost 1.32 is a reimplementation of the original MT code. That version turned out to have a bug in its seeding algorithm. A description of the bug as well as fixed c implementations can be found at: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html See also: http://lists.boost.org/MailArchives/boost/msg78304.php for a proposed fix to boost::random. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1180413&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

property library
by Stefan Strasser 10 Apr '05

10 Apr '05

Hi, I'd like to know if there is interest in developing a small library for inclusion in boost to emulate properties, something like: struct A{ void SetVar(int a){ cerr << "set " << a << endl; } int GetVar() const{ cerr << "get" << endl; return 0; } BOOST_PROPERTY(A,int,Var,SetVar,GetVar); }; A a; a.Var=3; //calls SetVar here's a proof-of-concept implementation which works with gcc 3.4 and intel cc: #define BOOST_PROPERTY(ClassT,T,name,setter,getter) \ struct _##name##_offset; \ property<T,ClassT,_##name##_offset,&ClassT::setter,&ClassT::getter> name; \ struct _##name##_offset{ \ size_t operator()() const{ \ return (size_t) &((ClassT *)0)->name; \ } \ } template<typename T,typename ClassT,typename offset,void (ClassT::*setter)(T),T (ClassT::*getter)() const> class property{ public: property &operator=(T const &t){ unsigned int temp=(unsigned int)this; temp-=offset()(); ClassT *this_=(ClassT *)temp; (this_->*setter)(t); return *this; } }; Regards, -- Stefan Strasser

2 3

[mpl] BOOST_TYPEOF and real operators
by Andy Little 10 Apr '05

10 Apr '05

Hi again, With BOOST_TYPEOF in place, the mpl operators (boost::mpl::plus etc) could be augmented by actual operators( + etc) As below:---> Whats the point of this? Well first its fun and more legible and second brings mpl further into runtime programming. Maybe also fits in with Alexey Gurtovoys round lambda: http://thread.gmane.org/gmane.comp.lib.boost.devel/77267 /* Example */ #include <boost/utility/enable_if.hpp> #include <boost/typeof/typeof.hpp> #include <boost/mpl/plus.hpp> #include <boost/mpl/int.hpp> #include <boost/mpl/or.hpp> // a useful addition to BOOST_TYPEOF ? #define BOOST_AUTO_TYPEDEF(name, expr) typedef BOOST_TYPEOF(expr) name #define BOOST_AUTO_TYPEDEF_TPL(name, expr) typedef BOOST_TYPEOF_TPL(expr) name namespace boost{namespace mpl { // naive implementation of is_integral for demo only template <typename T> struct is_integral_c :false_{}; template <int N> struct is_integral_c<int_<N> > : true_{}; template <int N> struct is_integral_c<integral_c<int,N> > : true_{}; template <typename Lhs, typename Rhs> typename boost::enable_if< boost::mpl::or_< is_integral_c<Lhs>, is_integral_c<Rhs> >, typename plus<Lhs,Rhs>::type >::type operator + (Lhs lhs, Rhs rhs) { BOOST_AUTO_TYPEDEF_TPL(result, Lhs() + Rhs()); return result() ; }; }}//boost::mpl #include <iostream> int main() { typedef boost::mpl::int_<1> one; typedef boost::mpl::int_<2> two; typedef boost::mpl::int_<3> three; typedef boost::mpl::int_<4> four; BOOST_AUTO_TYPEDEF(result , one() + two() + three() + four() ) ; std::cout << typeid(result).name() <<'\n'; std::cout << one() + two() + three() + four() <<'\n'; } reagrds Andy Little

1 0

range\config.hpp and regression tests broken
by Victor A. Wagner Jr. 09 Apr '05

09 Apr '05

I arbitrarily rolled back (effectively) the 1.6 version of boost\range\config.hpp (see attached) C:\Projects\boost\boost\range>cvs diff config.hpp Index: config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/config.hpp,v retrieving revision 1.6 diff -r1.6 config.hpp 36c36,37 < #if BOOST_WORKAROUND( BOOST_MSVC, <= 1200 ) || __MWERKS__ <= 0x3003 --- > //#if BOOST_WORKAROUND( BOOST_MSVC, <= 1200 ) || __MWERKS__ <= 0x3003 > #if _MSC_VER <= 1200 && !defined( __COMO__ ) && !defined( __GNUC__ ) && __MWERKS__ <= 0x3003 Note that I commented out the "new" line and added the old. I hope someone can tell me how these two lines are supposed to be equivalent, or if there was a bug in the original (current) then how the "new" line was supposed to fix it. Perhaps a much larger problem is that after this change, there was NO change in the regression I was reporting, even thought the logs clearly showed compile errors (the old log should still be ftp://rudbek.com/pub/boost ) My normal testing automatically kicked off 25 minutes ago, so it won't be there forever (the last run took FIVE(5) hours (the tests _had_ been running in about 2)). I also changed two other files in iostream which suddenly got \r\r\n line endings (vc8.0 doesn't like those for some reason) The fact that the change would likely have gone unnoticed if I hadn't been working on some updates for a client and _known_ that the program had compiled 26.5 hours ago, and failed 16 hours ago and could chase down who'd changed what is rather disturbing. We _must_ make some changes in how the regression tests are run (or perhaps how the results are analyzed) if we ever hope to have reliable stuff going out the door. I believe this throws into serious question whether it is reasonable to expect to do a release of a new version of boost in the immediate future (starting a freeze in 7 days). Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

[shared_ptr] PPC implementations updated
by Peter Dimov 09 Apr '05

09 Apr '05

I have fixed a 970-specific problem with the PPC implementations that was pointed to us by Philip Koch. Thanks to Miro Jurisic for getting his attention. So the tests will need to be re-run. I hope I didn't make any stupid mistakes. -- Peter Dimov http://www.pdimov.com

4 21

[timer] progress_timer's dtor - strange behavior
by Pavel Chikulaev 09 Apr '05

09 Apr '05

Hi all, I'm just happened to use boost::progress_timer for the first time, and was shocked by strange behavior of the progress_timer dtor: Surprisingly, it puts two newlines in the stream ('\n', then endl). So, I've got question - it is a bug or it is a feature? Using current implementation I just can't get the output look like: the first block took 2.34 s the second block took 5.67 s IMO this's a bug, and it should be fixed. Also I would like to be able to specify that no newlines in dtor are needed at all. This is very useful for stringstreams for example. Here's the fixed progress_timer: class progress_timer : public timer, private noncopyable { public: explicit progress_timer(std::ostream & os = std::cout, bool putnewline = true) : m_os(os), m_putnewline(putnewline) {} ~progress_timer() { try { std::istream::fmtflags old_flags = m_os.setf( std::istream::fixed, std::istream::floatfield ); std::streamsize old_prec = m_os.precision( 2 ); m_os << elapsed() << " s"; if (m_putnewline) m_os << std::endl; m_os.flags( old_flags ); m_os.precision( old_prec ); } catch (...) {} } private: std::ostream & m_os; bool m_putnewline; }; -- Pavel Chikulaev

1 0

[boost::serialization] - serialization + shared_ptrs
by Martin Slater 09 Apr '05

09 Apr '05

Hi there, After fixing header include orders for the umpteenth time to ensure boost/serialization/shared_ptr.hpp is included before shared_ptr.hpp so it can do it's #define private public hack I wondered if this was any closer to an acceptable resolution? I know this is brought up periodcally but it really needs to be sorted out in someway, currently I have just hacked my local boost source to make shared_ptr's private declarations public to avoid the issue but obviously this is far from ideal. Thanks Martin

7 23