February 2013 - Boost - lists.preview.boost.org

[thread] boost::thread and thread safety annotations
by Wladimir 04 Mar '13

04 Mar '13

Hello, The Clang C++ compiler project is currently working on a thread safety analyzer. By making use of so-called thread safety annotations within the source code, several problems with synchronization primitives can be found statically. For example: usage of a data structure without acquiring its guarding lock. See here for an overview of the available attributes: http://clang.llvm.org/docs/LanguageExtensions.html#threadsafety It is customary to use these attributes by defining macros, for compatibility: http://www.mail-archive.com/linuxkernelnewbies@googlegroups.com/msg01455.ht… At one time, it was also supposed to end up in G++, but this was abandoned in favor of clang (see http://gcc.gnu.org/wiki/ThreadSafetyAnnotation) But at least the annotations are fairly standardized. I think it would be useful to add these annotations to boost::thread, so that projects using that library can make use of the static checking. As I understand it, is only a matter of marking data structures that serve as lock/scoped_lock (such as boost::mutex, boost::recursive_mutex, ...), and methods that act upon the lock with the appropriate attributes. Any interest in this? Regards, Wladimir

2 1

[thread] barrier::wait() not marked as interruption_point
by Oliver Kowalke 04 Mar '13

04 Mar '13

In the documentation (1.53 beta) barrier::wait() is not marked as interruption-point nor that it will throw thread_interrupted if thread blocked inside barrier::wait() if it gets interrupted. Because barrier::wait() calls condition_variable::wait() and condition_variable::wait() is a interruption-point barrier::wait() should it be too - or do I miss something? Oliver

2 1

[persistent] Library preview: Persistent
by Stefan Strasser 04 Mar '13

04 Mar '13

Hi everyone, I'm thinking about finishing a library that was proposed a couple of years ago. It was pretty far along, and there is documentation available in the sandbox (somewhat outdated): https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html… It is a library with the goal of storing C++ objects on disk, with an interface that is as close as possible to accessing regular C++ objects in memory. A very simple example could look like this: shared_loc<person> p=...; { transaction tx; p->name="..."; p->address="..."; tx.commit(); } It is based on Boost.Serialization, but automatically maintains a consistent state on disk (ACID transactions), which can be updated incrementally. Part of its code was moved to a library named Transact to work alongside other transactional resources (like memory) and is available in the sandbox: https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/ I'd like to know whether the boost community is still interested in such a library, and I suppose there are quite a few new people here so your comments are welcome as well. Thank You!

6 9

[type traits] is_literal_type ?
by Robert Ramey 02 Mar '13

02 Mar '13

Any chance of a boost implementation for is_literal_type? Robert Ramey

4 6

Git Conversion Schedule
by Sebastian Redl 02 Mar '13

02 Mar '13

Hi, According to the timeline linked from the svn.boost.org frontpage, we're already using Git: https://svn.boost.org/trac/boost/wiki/ModCvtSchedule But I'm pretty sure that's not the case, right? What is the current schedule? Sebastian

3 2

[tweener] How to copy image files in documentation
by Julien Jorge 01 Mar '13

01 Mar '13

Hi, I wrote the documentation of Boost.Tweener in boostbook format. I have references to some images in the documentation but they are not copied in the target html directory when I type bjam html How can I make the image directory to be automatically copied in the target directory of the generated documentation? Since I am not familiar with the build process of Boost yet, I would accept a reason not to do this as an answer :) Regards, Julien Jorge

2 2

[type_erasure] overloading macro
by Christophe Henry 28 Feb '13

28 Feb '13

Hi all, I played a bit more with overloading and it started being annoying and error-prone to add more overloads of concept_map (with more arguments) so I wrote a small macro to 1) generate my overloads and 2) save myself the time reading compiler errors when I use BOOST_TYPE_ERASURE_MEMBER and make a mistake in the number of arguments. It's for C++11 (argument pack) as it's all I need at the moment but I suppose that with Boost.Preprocessor, it'd be for C++03 doable. Well, in case it'd be of any use to someone, here it is, with a small test (tested with g+ 4.5 with -std=c++0x). #include <boost/type_erasure/concept_interface.hpp> #include <boost/type_erasure/rebind_any.hpp> #include <boost/type_erasure/derived.hpp> #include <boost/type_erasure/is_placeholder.hpp> #include <boost/type_erasure/constructible.hpp> #include <boost/type_erasure/relaxed_match.hpp> #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/builtin.hpp> #include <boost/type_erasure/any_cast.hpp> #include <boost/type_erasure/detail/macro.hpp> #include <boost/mpl/vector.hpp> #include <iostream> #ifndef BOOST_NO_CXX11_VARIADIC_TEMPLATES #define BOOST_TYPE_ERASURE_MEMBER_VARIADIC_I(qualname,concept_name,member) \ BOOST_TYPE_ERASURE_OPEN_NAMESPACE(qualname) \ template <typename T, typename... Args> \ struct concept_name{ \ static void apply(const T& t, const Args... a) { t.member(a...); } }; \ BOOST_TYPE_ERASURE_CLOSE_NAMESPACE(qualname) \ namespace boost { namespace type_erasure { \ template<class T, typename... U, class Base, class Enable> \ struct concept_interface< BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U... >, Base, T, Enable> : Base { \ typedef void _fun_defined; \ void member(typename rebind_any<Base, U>::type... arg)const \ {call(BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>(), *this, arg...);} }; \ template<class T, typename... U, class Base> \ struct concept_interface< BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>, Base, T, typename Base::_fun_defined> : Base{ \ using Base::member; void member(typename rebind_any<Base, U >::type... arg)const \ {call(BOOST_TYPE_ERASURE_QUALIFIED_NAME(qualname)<T, U...>(), *this, arg...);} }; \ }} #endif #define BOOST_TYPE_ERASURE_MEMBER_VARIADIC(qualified_name,member) \ BOOST_TYPE_ERASURE_MEMBER_VARIADIC_I( \ qualified_name, \ BOOST_PP_SEQ_ELEM(BOOST_PP_DEC(BOOST_PP_SEQ_SIZE(qualified_name)), qualified_name), \ member) // supports overloading, does not require any number of arguments BOOST_TYPE_ERASURE_MEMBER_VARIADIC((n1)(n2)(foo),foo) namespace mpl = boost::mpl; using namespace boost::type_erasure; struct Test { void foo()const { std::cout << "foo() called" << std::endl; } void foo(int i)const { std::cout << "foo(int) called with: " << i << std::endl; } void foo(int i,char c)const { std::cout << "foo(int,char) called with: " << i << "," << c << std::endl; } void foo(double d)const { std::cout << "foo(double) called with: " << d << std::endl; } void foo(int i,double d)const { std::cout << "foo(int,double) called with: " << i << "," << d << std::endl; } void foo(int i,double d,char c)const { std::cout << "foo(int,double,char) called with: " << i << "," << d << "," << c << std::endl; } }; int main() { Test t; any< mpl::vector< n1::n2::foo<_self>, n1::n2::foo<_self, int>, n1::n2::foo<_self, double>, n1::n2::foo<_self, int, double>, n1::n2::foo<_self, int, char>, n1::n2::foo<_self, int, double, char>, copy_constructible<> > > x (t); x.foo(); // calls foo() x.foo(1); // calls foo(int) x.foo(1.0); // calls foo(double) x.foo(1,1.0); // calls foo(int, double) x.foo(1,'a'); // calls foo(int, char) x.foo(1,1.0,'a'); // calls foo(int, double,char) return 0; }

2 21

[ptr_container, crc, format] Open tickets - code patches available
by Joachim Faulhaber 28 Feb '13

28 Feb '13

Hi, there are open tickets: https://svn.boost.org/trac/boost/ticket/7430 (ptr_container: warning fixes) https://svn.boost.org/trac/boost/ticket/7433 (crc: runtime check issue) https://svn.boost.org/trac/boost/ticket/7435 (format: crash) that we have submitted 5 months ago. Along with the bug reports there are code patches for the reported issues, that have been tested and used in production code on different platforms. We would kindly ask the maintainers to look at these issues and to apply the patches to the library code, so they can be integrated in the next release. In case the maintainers do not have time to fix these issues within say the next 2 weeks, I (Joachim) would like to ask for permission to apply the patches. Fixing the issues would be very helpful for us, so we don't have to patch the code locally for every new version. Thanks a lot, Joachim & Franz -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 6

Releasing gil::io
by Christian Henning 28 Feb '13

28 Feb '13

Hi all, I have taken a look at the requirements to release a new library. There is some points I like to discuss. Technically speaking gil::io is a replacement of the older gil io extension. So, it's not really a new library. But of course, I don't mind fulfilling all the requirements. Here are the requirements before merging: * root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. Should I add a gil::io entry? * root/libs/maintainers.txt entry is OK. Should I add a gil::io entry? * The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs. Done * The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past. I'm using boostbook and the default templates. * Trunk inspection report is clean. I would need some help here to hook up gil::io test with general boost testing. * Trunk regression tests are reasonably clean or marked up. TODO Thanks, Christian

2 3

Fwd: [Thread] Solution to conflict with MFC?
by Thorsten Ottosen 28 Feb '13

28 Feb '13

Hi Thread maintainers, Anthony speaks about a patch to make this work. Does anyone know where it is? And could it be applied? Thanks -Thorsten -------- Original Meddelelse -------- Subject: [Thread] Solution to conflict with MFC? Date: Tue, 26 Apr 2011 13:28:56 +0200 From: Christian Larsen <contact(a)dword.dk> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Newsgroups: gmane.comp.lib.boost.user Hello, I know this has been asked before, but I could not find a good solution. I'm experiencing problems with an application using both MFC and Boost.Thread. Specifically the assertion ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); in AfxCoreInitModule() fails. I link Boost.Thread statically into a DLL in my project. From previous posts to this list and elsewhere, e.g. http://lists.boost.org/boost-users/2009/04/46929.php, I see that the issue is caused by setting _pRawDllMain in tss_pe.cpp. Commenting this line does "solve" the problem, but I would rather not have to hack the Boost source code this way. It seems there is a patch somewhere for this problem (referred to in http://lists.boost.org/boost-users/2009/04/47015.php) but it appears it never made it into the source. Is there any chance of this issue being solved in a better way? Best regards, Christian Larsen

5 9