April 2012 - Boost - lists.boost.org

regression test link broken?
by lcaminiti 18 Apr '12

18 Apr '12

Hello all, Are the regression tests broken? When I go to: http://www.boost.org/development/tests/trunk/developer/summary.html I get: Error extracting file: The specified zipfile was not found. Same for both trunk and release tests. I hope it wasn't me ;) --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-test-link-broken-tp4565… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 6

[type_traits][exception][interlocked][smart_ptr] Intel XE 2011 SP1 compiler warnings
by Beman Dawes 18 Apr '12

18 Apr '12

Compiling libs/test/src/execution_monitor.cpp is producing a lot of warnings from the Intel XE 2011 SP1 compiler for Windows: [type_traits] ..\..\..\boost/type_traits/detail/is_mem_fun_pointer_tester.hpp(74-2608): remark #693: calling convention specified here is ignored yes_type is_mem_fun_pointer_tester(R (__stdcall T::*const volatile*)( ...)); with the error marker under the start of __stdcall. There are about a gazillion lines with the same error. [exception] ..\..\..\boost/exception/exception.hpp(258-260): remark #367: duplicate friend declaration friend struct exception_detail::get_info<throw_function>; [interlocked] ..\..\..\boost/detail/interlocked.hpp(79-83): warning #1879: unimplemented pragma ignored # pragma intrinsic( _InterlockedIncrement ) [smart_ptr] ..\..\..\boost/smart_ptr/detail/yield_k.hpp(33): warning #1879: unimplemented pragma ignored #pragma intrinsic( _mm_pause ) It would be nice to clear these warnings. Thanks, --Beman

1 0

[math] Numeric constants docs out of date?
by Beman Dawes 17 Apr '12

17 Apr '12

The docs for Numeric Constants seems out-of-date compared to the <boost/math/constants/constants.hpp> header. See http://www.boost.org/doc/libs/1_49_0/libs/math/doc/sf_and_dist/html/math_to… For example, the docs list 15 constants, but the header supplies 65 or so constants. Beyond simply missing some functions, the description is so scanty it looks like it may be for a much less capable older version of the header. Am I missing something? --Beman

5 8

Re: [boost] [Boost-commit] svn:boost r78033 - trunk/libs/context/src
by Joshua Boyce 17 Apr '12

17 Apr '12

On Tue, Apr 17, 2012 at 5:31 PM, <oliver.kowalke(a)gmx.de> wrote: > Author: olli > Date: 2012-04-17 03:31:34 EDT (Tue, 17 Apr 2012) > New Revision: 78033 > URL: http://svn.boost.org/trac/boost/changeset/78033 > > Log: > icontext: use snprintf in seh handler > > Text files modified: > trunk/libs/context/src/seh.cpp | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > Modified: trunk/libs/context/src/seh.cpp > > ============================================================================== > --- trunk/libs/context/src/seh.cpp (original) > +++ trunk/libs/context/src/seh.cpp 2012-04-17 03:31:34 EDT (Tue, 17 > Apr 2012) > @@ -26,7 +26,7 @@ > { > const char * accessType = ( info[0]) ? "writing" : "reading"; > const ULONG_PTR address = info[1]; > - _snprintf_s( description, len, _TRUNCATE, "Access violation %s > 0x%08X", accessType, address); > + snprintf( description, len, "Access violation %s 0x%08X", > accessType, address); > return description; > } > case EXCEPTION_DATATYPE_MISALIGNMENT: return "Datatype > misalignment"; > @@ -52,8 +52,7 @@ > case EXCEPTION_INVALID_HANDLE: return "Invalid handle"; > } > > - _snprintf_s( description, len, _TRUNCATE, "Unknown (0x%08X)", code); > - > + snprintf( description, len, "Unknown (0x%08X)", code); > return description; > } > > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit This breaks building under MSVC which does not have 'snprintf', only '_snprintf'. http://msdn.microsoft.com/en-us/library/2ts7cx93.aspx

1 0

Range to boost::array / make_array?
by Olaf van der Spek 16 Apr '12

16 Apr '12

Hi, Is there a convenient function to make an array from a range? I got a map with string keys which I'd like to replace with array<char, 32> keys, but I'm missing said function. -- Olaf

2 2

[Serialization] Is there a way to "stop" a polymorphic serialization at a given class level
by nico 16 Apr '12

16 Apr '12

Hello. I admit the subject is not really understandable, but you'll see it's not so obvious to summarize the question... I use the boost serialization system and its polymorphic base serialization feature. For that, and for serialization code instantiation, I use the registration macros BOOST_CLASS_EXPORT_KEY and BOOST_CLASS_EXPORT_IMPLEMENT. If I have a concrete class A in a inheritance tree like that : C is base of B is base of A ( C <|---B <|---A ) C is not instanciable (it has pure virtual functions) B is instanciable Is there a way to "stop" the serialization of a A object to B level? I mean: If I have this code: C* obj = new A(); // declare boost archive ar to serialize obj ar & obj; Is there a way to tell to boost serialization to serialize only until B. Why ? This obj serialized is deserialized in another application, where only C and B are known and used. A only defines technical stuff, but nothing with data (and serialization), so it will never be used as A*. I try with something like that : template<class Archive> void A::serialize(Archive & ar, const unsigned int version) { B* b = new B(static_cast<B*>(this)); ar & b; delete b; } but is there a more "boost-serialization-system" way ? (I expect no...) What do you recommend ? Thanks for help. Nicolas.

2 1

[thread] Move semantics and deprecation
by Vicente J. Botet Escriba 15 Apr '12

15 Apr '12

Hi, I have updated Boost.Thread to make use of Boost.Move with some significant improvements. Up to now the boost/thread/config.hpp file made use of Boost.Move by default. #if ! defined BOOST_THREAD_DONT_USE_MOVE #define BOOST_THREAD_USES_MOVE #endif After the discussion about deprecated features I think that it would be more convenient to don't change the default for the next release and let the users define this macro. There are some tests that need BOOST_THREAD_USES_MOVE. I will either add it explicitly on the test source code or define it when BOOST_THREAD_VERSION==2. What do you think? BTW, unfortunatly I've considered that the preceding Boost.Thread version was 1, while it was 2 (the first been the original one by William Kempf). Should the breaking changes be included using version BOOST_THREAD_VERSION==3? Anthony? Best, Vicente

1 0

[graph] Disjoint Sets - the secret library
by Daniel James 14 Apr '12

14 Apr '12

I was just comparing the library list on the website to the one in the repo, and I noticed 'disjoint sets' is listed on the website but not in 'libs/libraries.htm'. I think it either needs to added to 'libs/libraries.htm', or removed from the site. The header is in the 'pending' directory, and it doesn't seem to have been reviewed, so it looks like it should be removed from the site. It seems to be mainly used by the graph library, so maybe it could be subsumed by that? Also, the documentation isn't quite right as it says the header is at 'boost/disjoint_sets.hpp': http://www.boost.org/libs/disjoint_sets/ Does anyone have an opinion? (btw. I'm not suggesting removing the header, as that would break things) Daniel

2 2

Support for Boost.Hash in Boost.Array
by Marshall Clow 14 Apr '12

14 Apr '12

(In [77976]) I added support for Boost.Hash to Boost.Array I also added a basic set of tests. Please let me know if you see any problems. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

[context/coroutine] split into two libs in trunk?!
by Oliver Kowalke 14 Apr '12

14 Apr '12

Hi, unfortunetly Giovanni decided to discontinue its boost.coroutine library and I was ask be several members of the boost community to provide a coroutine implementation using boost.context. I've refactored class context from lib boost.context so that I can provide coroutine<> and generator<> (following Giovannis interface proposal) based on context now. I'd like to split it into two libraries: - boost.context provides only context jumping facility (a.g. struct fcontext_t, start_fcontext()/jump_fcontext()/make_fcontext() and stack helper) - boost.coroutine contains coroutine<> and generator<> Might this be appropriate? regards, Oliver -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

6 19