- Boost - lists.boost.org

Trunk Boost Jam version users need to recompile.
by Jurko Gospodnetić 05 May '08

05 May '08

Hi all. Just a heads up that anyone using the trunk version of Boost Build newer than revision 45158 and the trunk version of Boost Jam (version 3.1.17) older than that revision needs to recompile their Boost Jam. Note that this does not affect people using the current release version (3.1.16) as the new Boost Build code preserves old behavior for older versions. This includes testers since they use the release version of Boost Jam. Without this recompile the thing that can happen is that some paths get parsed incorrectly. Best regards, Jurko Gospodnetić

1 0

Re: [boost] [Boost-build] BJam-Plugin for Eclipse
by Darren Garvey 05 May '08

05 May '08

On 05/05/2008, Frank Birbacher <bloodymir.crap(a)gmx.net> wrote: > > > > So, did you figure if you have trunk access? > > I did now: > > $ svn mv > http://svn.boost.org/svn/boost/sandbox-branches/birbacher/eclipse_contrib > > http://svn.boost.org/svn/boost/trunk/tools/build/v2/contrib/eclipse_plugins > -m "moved Eclipse plugins into trunk" Just a guess: try the same with https:// (note the 's'). -- Darren

2 1

throw_exception: gcc 3.2 errors
by Ralf W. Grosse-Kunstleve 05 May '08

05 May '08

Thanks a lot for the gcc warning workarounds! It is highly appreciated. Unfortunately, now g++ 3.2 doesn't work anymore. See below. I think gcc 3.3 and higher are fine. Ralf g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) boost svn rev. 45087 % cat te.cpp #include <boost/throw_exception.hpp> % g++ -Wall -Iboost -c te.cpp In file included from boost/boost/exception/enable_error_info.hpp:9, from boost/boost/throw_exception.hpp:39, from te.cpp:1: boost/boost/exception/exception.hpp: In instantiation of `boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>': boost/boost/exception/exception.hpp:75: instantiated from `boost::detail::sp_enable_if_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/exception/exception.hpp:75: instantiated from here boost/boost/exception/exception.hpp:75: invalid use of undefined type `struct boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/detail/sp_convertible.hpp:27: declaration of `struct boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/exception/exception.hpp:75: enumerator value for `value' not integer constant

2 1

[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