April 2012 - Boost - lists.boost.org

[Proto] Errors due to narrowing conversions in matches.hpp
by Michel Morin 22 Apr '12

22 Apr '12

Some tests of Boost.Phoenix fail on clang trunk in a C++11 mode due to narrowing conversions of non-type template arguments, which are prohibited in C++11. Specifically, the narrowing conversions occur at Line 354 and 363 in boost/proto/matches.hpp. They can be simply resolved using `static_cast<bool>(...)`. Regards, Michel

2 3

[thread] Do we need thread_group now?
by Vicente J. Botet Escriba 21 Apr '12

21 Apr '12

Hi, now that we have Boost.Container and Boost.Thread (trunk) uses Boost.Move, boost::thread_group has less sense. I was thinking on replacing it by some generic algorithms as join_all, interrupt_all that work with generic containers so that the user can use the best containers adapted to her own needs. typedef boost::container::vector<boost::thread> thread_vector; { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } join_all(threads); } { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } interrupt_all(threads); } Could boost::thread_group be deprecated once these generic algorithm are released? Or, is there something really useful on the thread_group class that needs to be preserved or even improved? Best, Vicente

7 13

[iterator] iterator-category logic
by Jeffrey Lee Hellrung, Jr. 21 Apr '12

21 Apr '12

I'd like to ask Boosters' opinions on this. boost::iterator_facade determines the iterator_category via the logic outlined in http://www.boost.org/doc/libs/1_49_0/libs/iterator/doc/iterator_facade.html… In particular, if (a) CategoryOrTraversal is a Boost traversal tag; and (b) Reference is not a "real" C++ reference (i.e., a proxy reference); then iterator_category is at best convertible to std::input_iterator_tag. This ends up being surprising to users who use boost::iterator_adaptor (note that, by default, iterator_adaptor passes the Boost traversal tag of the adapted iterator down to iterator_facade) to adapt, say, a pointer, define their adapted iterator to return a proxy reference, and find out that their standard library functions don't recognize their adapted iterator as a random access iterator. The usual workaround tends to be to just override the iterator_facade logic yourself to use a more refined iterator_category and hope your standard library functions don't barf. For better or for worse, the present logic in iterator_facade is strictly (more or less) correct given the C++03 iterator requirements, but I just looked up the N3290 draft of C++11 and it appears that any requirements that *i return a real reference have been dropped, thus allowing for proxy references in all iterator categories. (a) Am I interpreting the C++11 iterator requirements correctly? (b) If so, should iterator_facade's iterator-category logic be reworked to account for the new requirements? (c) If so, how should it be determined when to use the C++03 requirements and when to use the C++11 requirements? Thanks, - Jeff

3 3

[review schedule] Broken link to Coroutine documentation
by Mateusz Loskot 21 Apr '12

21 Apr '12

Hi, There is Coroutine library by Oliver Kowalke proposed for review. The link to Documentation points to...the review schedule at http://www.boost.org/community/review_schedule.html Is there any chance to have it fixed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost.Variant swap performance
by David Sankel 21 Apr '12

21 Apr '12

It seems as though Boost.Variant doesn't take advantage of pointer swaps when it comes to use of recursive variants. In the attached file I declare a simple int list type and include two implementations of a function that adds an int to the front of a list. The first implementation, I would expect to be O(N) on the size of the list and the second implementation to be O(1) on the size of the list. Unfortunately, the output I get is: unoptimized ilPushFront: 129 unoptimized ilPushFront w/ larger list: 363 optimized ilPushFront: 211 optimized ilPushFront w/ larger list: 653 Any ideas why this might be happening? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

2 3

[shared_ptr] [intel] Compile Errors with '#include <atomic>'
by Joshua Boyce 20 Apr '12

20 Apr '12

Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have). The problem is simple to repro: #include <atomic> #include <boost/shared_ptr> int main() { } The problem has been reported previously, but even in the latest version of the compiler (created and released well after the bug report) the problem seems to remain: http://software.intel.com/en-us/forums/showpost.php?p=160114 Here is a patch which I have used locally to successfully work around the problem, but I get the feeling that there is a better solution I'm overlooking... http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-shared_ptr-intel-fix-… Has anyone else run into this problem who has come up with a better solution? Alternatively, if this is as good as it's going to get (maybe using a BOOST_WORKAROUND would be better so it can be disabled when/if the issue is fixed), would anybody be able to apply this to trunk? Thanks.

1 1

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 20 Apr '12

20 Apr '12

> >> I believe that a portable implementation of the proposed std::decimal > >> (eg Decimal Types for C++ would be useful. > Of course this is definitely something Boost needs in its tool chest. > But to 'sell' it to Boost, I think it is important to relate to commercial offerings and > previous proposals to WG21 C++ Standards. > > So say how and why you have done it differently? > > Paul I do not intend to create an implementation - I am simply wiring up the existing DecNumber, Intel Decimal Float implementations (both IEEE compliant) to the std::decimal interface. I believe the associated licences are compatible with boost being able to distribute this, but that would be the first thing to be checked. I have no idea how this differs from any other offering (apart from saying I hope it gives identical results to gcc's standard decimal) apart from pointing out I haven't found any C++ wrappers for the decimal floats that I would use 'off the shelf' in the same way I use boost libraries. I'm working on a somewhat blind assumption that if gcc is implementing this interface, it is probably the closest thing to what will eventually end up in the standard. If there are other implementations that do roughly the same thing, I'd be really interested to take a look, as I've no desire to reinvent the wheel!

2 1

Release branch merge
by Dave Abrahams 20 Apr '12

20 Apr '12

Since we're within the 7-week window, I'm asking permission to patch the release branch per the enclosed: -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[coroutine][context] coroutine_specific_ptr proposal
by Taylor Goodhart 19 Apr '12

19 Apr '12

With the context/coroutine library making great progress, in my mind it is only natural to wonder whether something analogous to thread local storage could be implemented for coroutines. I would propose using the existing thread_specific_ptr as a starting point. As for an initial design proposal, it seems to me like one could have a single static atomic integer in the constructor of coroutine_specific_ptr that is incremented for each new instance. This will allow each instance to know their index, and to also know the total number of pointers. Then when a new coroutine is created, a block of pointers of this size would be created and placed before stack memory. If a coroutine were to try to dereference a coroutine_specific_ptr then the index into this block would be looked up and if NULL, create a new instance on the heap. If not NULL, it would simply return the previously created value. Comments and feedback would be appreciated. If this seems like something people might use I'd be willing to take a crack at implementing it, provided Oliver's blessing. -Taylor Goodhart

1 0

[decimal] Proposed portable implementation of std::decimal
by Josh Quigley 19 Apr '12

19 Apr '12

Hi, I believe that a portable implementation of the proposed std::decimal (eg Decimal Types for C++ <http://tiny.cc/63ovcw> for older draft) would be useful. Since the standard specifies a class, a library should be able to achieve close to full compliance. At the moment I believe only gcc supports this. I'm currently working on this for my own purposes, and if there is sufficient interest (and guidance!) might try to expand it into a draft submission. Roadmap: 1. Implement std::decimal (see gcc version, for example) using Intel FP Decimal, DecNumber, native gcc, (maybe .NET Decimal depending on how close it is to complying with interface) 2. Some preprocessor trickery to make it easy to compile all implementation as separate classes (eg extension::decimal::Intel::decimal64), or a given implementation as the 'one true' class (extension::decimal::decimal64). This means unit tests and performance tests can be written using one implementation against another, and for production code, a given implementation can be used under the hood depending on the architecture. 3. Create performance and standards-compliance benchmarks for implementations. 4. Choose default implementation for each supported architecture, based on benchmarks. The above is a personal roadmap, of which a subset may be of interest to the boost community. Please let me know if you think this would be of value, and in particular if you would like to be involved in creating / testing / using this. Regards, Josh.

4 3

Google Groups
by Mark Snelling 19 Apr '12

19 Apr '12

Hi, Has anyone noticed that the Google Groups feeds of both boost-users and boost-devel have stopped updating? There was this posting to the Boost devel archive on the 18th regarding message bounces https://groups.google.com/forum/?fromgroups#!topic/boost-devel-archive/Ip24… Mark.

1 0

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 19 Apr '12

19 Apr '12

Thanks for link to more recent draft. I've finished a rough implementation using the Intel lib, and am currently working on unit tests to at least cover the std::decimal interface. What is the preferred way to share this (when ready)? Josh.

1 0

[Serialization] How to force an archive to store true_type even if it is this_type?
by nico 18 Apr '12

18 Apr '12

Hello. When we serialize a polymorphic object, an archive stores the information about true_type (i.e. the concrete type of an object) only if it is not equal to this_type (i.e. the type of the serialized object). I.e. : the type of the serialized object is stored only if it is serialized from a base class. How can I force the archive to always store the type? Let's illustrate with a sample, I'm not sure the above text is so obvious...: Let's have 2 classes serializable: class Base { ... }; class Leaf : public Base { ... }; If I do : std::stringstream ios(std::ios_base::binary | std::ios_base::out | std::ios_base::in); * Base** b = new *Leaf*(); boost::archive::text_oarchive ar(ios); ar & b; Then the archive contains: 22 serialization::archive 9 0 4 *Leaf* 1 0 0 0 0 0 0 0 0 It contains the Leaf concrete type information. However if I do : * Leaf** b = new *Leaf*(); boost::archive::text_oarchive ar(ios); ar & b; Then the archive contains: 22 serialization::archive 9 0 1 0 0 0 0 0 0 0 0 It doesn't contain Lef type info. How can I produce an archive WITH the true_type all the type? I search 2 ways: - calling a method of archive type (register_type, save_pointer, ...) unsuccessfully - directly change the boost/archive/detail/oserializer.hpp file: in struct polymorphic, in function template<class T> static void save(Archive &ar, T & t) I comment out if(*this_type == *true_type){ const basic_pointer_oserializer * bpos = register_type(ar, t); ar.save_pointer(vp, bpos); return; } unsuccessfully. Thank you for help. Nicolas. PS : a word about why I'm trying to do that. When the true_type is "registered" (I'm not sure register is the right word), we can deserialize the object to any base class. Exemple: SERIALIZATION: Leaf* leaf = new Leaf(); ar & leaf; SERIALIZATION: Base* b = 0; ar & b; // would work only if Leaf has been saved in the archive as true_type For tools in a multi-team project, it' powerfull : data for tests has been serialized by a team, and the other team can deserialize, let's say an image, to the interface class IImage without asking: what was the true_tyep : an Image3D, an AImage2D, an Image2DRGB, an Image2DRAW, and so on.

2 1

[disjoint_sets] 1.49.0 docs out-of-date? pending?
by Jeffrey Lee Hellrung, Jr. 18 Apr '12

18 Apr '12

I noticed that http://www.boost.org/doc/libs/1_49_0/libs/disjoint_sets/disjoint_sets.html references boost/disjoint_sets.hpp but, AFAICS, no such file exists; however, clicking on the file nonetheless redirects to boost/pending/disjoint_sets.hpp which presumably is the intended reference. So, aside from what looks like a slight error in the present disjoint_sets docs, what is the purpose of this pending directory? I had never noticed it before and I don't remember stumbling upon a reference to it until now. Looks like it contains a hodgepodge of miscellaneous headers... Thanks, - Jeff

4 4

[test] Am I supposed to be able to use std::wstring in BOOST_CHECK_EQUAL?
by Michael Kochetkov 18 Apr '12

18 Apr '12

Hello, Am I supposed to be able to use std::wstring in BOOST_CHECK_EQUAL? I.e. std::wstring s1,s2; BOOST_CHECK_EQUAL(s1,s2); -- Michael Kochetkov

6 7

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