April 2012 - Boost - lists.preview.boost.org

[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