- Boost - lists.boost.org

[smart_ptr] enable_shared_from_this / sp_accept_owner / virtual dtor
by Daniel Frey 05 May '08

05 May '08

In case someone is interested: The attached enable_shared_from_this proves that it is possible to add sp_accept_owner without forcing a virtual dtor. It's compatible with the 1.35.0 features and overhead. Regards, Daniel

2 3

[smart_ptr] future shared_from_this
by Frank Mori Hess 05 May '08

05 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another idea would be to make a future<shared_ptr<T> > available in the constructor, the future would become ready with a shared_ptr from this when the object gets owned. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIH0d65vihyNWuA4URAoUeAKDIBtVOn2S9sdOiHvPXNNRHBIJu6gCfZN4X 69bJ4nlhOHSf6dfLaEKpQ5Q= =74HG -----END PGP SIGNATURE-----

1 0

[1.35][lexical_cast][concept check][range] Build error and warnings with MSVC8 on Warning Level 4
by Stephan Diederich 05 May '08

05 May '08

As we tried to update to 1.35 today, we found some warnings with MSVC on Warning Level 4 in: lexical_cast: There was a return statement after a call to throw_exception which causes a unreachable code warning. I can see no problem by just removing that return. see http://svn.boost.org/trac/boost/ticket/1791 concept_check: BOOST_concept(SGIAssignable,(TT)) causes two warnings: C4510: default constructor could not be generated C4610: object 'class' can never be instantiated - user-defined constructor required solved thorugh pragmas see http://svn.boost.org/trac/boost/ticket/1792 and an error in range/iterator_range: see http://svn.boost.org/trac/boost/ticket/1793 for details. The patch is attached, as I was not able to discuss with Akismet that it's no spam ;) "Submission rejected as potential spam (Akismet says content is spam)" cheers, stephan

4 7

1.35 + gcc4.3?
by Neal Becker 05 May '08

05 May '08

Will patches to build on gcc-4.3 make it into boost-1.35 release? Would be desirable. Fedora F9 is out soon and has gcc-4.3 - I think other distributions will follow soon.

2 1

Header only pro's and con's?
by Roland Schwarz 04 May '08

04 May '08

Please don't misunderstand this mail. I do not want to start a header contra lib war. I just want to learn about the pro's and the contras of header only. The issue has popped up in this list quite some times, but I was not able to find any document which tries to do a serious in-depth discussion of when to header only and when not. If anyone knows about such a document I would be pleased if he could point me at it. Thank you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

4 3

[random] Rician and Weibull distributions
by Matthias Schabel 04 May '08

04 May '08

If there's any interest, I've implemented these two distributions (attached). They have only been lightly tested at this point, but might be of interest to some users of Boost.Random. Cheers, Matthias

4 3

Macro which can determine size of tuple passed as argument
by 6orkup 04 May '08

04 May '08

Hi, I am trying to implement a macro which can determine size of tuple passed as argument. My first idea was to 1) remove parentheses from tuple using variadic macro (which I can afford for) 2) complement tuple elements list with "filler and marker" sequence 3) scan resulting arguments list right-to-left. Straightforward 1-3-arguments version using variadic macros and boost.preprocessor looks like: #include <boost/preprocessor/control/if.hpp> #define M4(a1,a2,a3,a4,...) BOOST_PP_IF(a4,3,M3(a1,a2,a3)) #define M3(a1,a2,a3) BOOST_PP_IF(a3,2,M2(a1,a2)) #define M2(a1,a2) BOOST_PP_IF(a2,1,M1(a1)) #define M1(a1) 0 #define M(...) M4(__VA_ARGS__,1,0,0,0) #define T(t) M t After preprocessing these invocations T((a,b,c)) T((a,b)) T((a)) expand to: 3 2 1 Unfortunately these macros do not allow to discriminate between 1 and 0 -element tuples: both T((a)) and T(()) invocations expand to 1 instead of 1 and 0 correspondingly. It seems that chosen approach might work if I had any way to append different filler to non-empty and empty tuple: with and without leading comma separator. Could you please advise me if it is possible to implement a macro which can determine size of tuple passed as argument ? Does boost.preprocessor allow this ? Can variadic macros be of any help ? Cheers, Yuri

1 0

[thread] Could mutex and condition_variable be movable?
by vicente.botet 04 May '08

04 May '08

Hi, I'm defining a class that is non copiable but movable. The class contains a boost::mutex and boost::condition_variable fields which are non copiable neither movable. I'd prefere not been forced to allocate all the class data in a pointer to make possible the move operation. Has a sens to make these classes movable? Thanks in advance --------------------------- Vicente Juan Botet Escriba

2 2

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 04 May '08

04 May '08

Hi Emil, > I don't want to turn this into an argument; I only asked if there is > an official Boost policy on the subject. Is there a requirement that > boost compiles with -Wall without warnings on all compilers? I don't know if there is a formal policy, but I know a couple of years ago boost wasn't clean for compiling with -Wall. In the meantime, someone must have worked pretty hard to eliminate all the warnings. It would be nice if that investment could be preserved. When developing new code, -Wall catches many problems that would otherwise go undetected until much later, when it is usually much more effort to figure out what's wrong since the mind has moved on to other things. I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight? I'm currently testing with the "virtual" added (below). This seems to eliminate all warnings. Ralf Index: boost/exception/detail/counted_base.hpp =================================================================== --- boost/exception/detail/counted_base.hpp (revision 45057) +++ boost/exception/detail/counted_base.hpp (working copy) @@ -34,6 +34,7 @@ protected: + virtual ~counted_base() throw() { } Index: boost/exception/detail/cloning_base.hpp =================================================================== --- boost/exception/detail/cloning_base.hpp (revision 45057) +++ boost/exception/detail/cloning_base.hpp (working copy) @@ -23,6 +23,7 @@ protected: + virtual ~cloning_base() throw() { }

9 12

sp_atomic_mt2_test: a test for mutex/shared_mutex/atomic access performance
by Peter Dimov 03 May '08

03 May '08

I've added sp_atomic_mt2_test.cpp: http://svn.boost.org/trac/boost/browser/trunk/libs/smart_ptr/test/sp_atomic… to the SVN; this is a reader/writer performance test that can be used to compare the performance of a detail::lightweight_mutex, boost::shared_mutex and the new atomic access operations for shared_ptr. It accepts command line options that can be used to achieve a variety of scenarios. I'm currently seeing a plain mutex (maps to a CRITICAL_SECTION) outperforming shared_mutex for the default configuration of read/write ratio 100:1, vector size (operation cost) 10000, no matter how many threads I use on a dual CPU box on Windows. This seems somewhat suspicious and may indicate a bug in the test. Any comments are welcome. :-)

1 0