January 2011 - Boost - lists.boost.org

[serialization] Dealing with any tainted types.
by David Sankel 17 Jan '11

17 Jan '11

The serialization library allows for the painless serialization of most data types and even polymorphic types like variants and vectors. There is one type, however, that doesn't have a serialize function that makes sense. That type is any. It is easy to see that if we make an any serialize function, we're going to need to make some assumptions at least about which subset of types it might contain. I have a complex algebraic datatype, lets call it C, that has a member (that has a member...) of type T. T is "tainted" with a member of type any. I'm looking at the possible ways to serialize C with boost.serialization. We can know, at runtime, which subset of types the any member of T can contain and how to serialize each of those types. Lets call the dictionary type that has that information D. Here are the options I've come up with so far... Option 1: Make some global variable of type D, called d. Before calling any serialization of C, I ensure d has the correct value. The serialize function for T uses d to figure out how to serialize the any member. This option would certainly work, but I'm using a global variable as a workaround of the fact that I cannot add arguments to T's serialize function. No points for beauty here. Option 2: Instead of serializing a value of type C, serialize a value of type "struct CWithDict { C c; D d; }". In this serialization function I can use d whenever I need. Unfortunately the contents of this serialize function would need to duplicate most of the functionality of boost.serialize in the first place since T is buried deep within C's structure. Although this option works, it requires rewriting a bunch of serialize which isn't attractive. Option 3: Make an archive wrapper: template< typename Archive > struct DArchive { Archive a; D d; }; DArchive would model the Archive concept by forwarding functionality to a. However, the T serialize function could access DArchive's d member for serialization of the any. This would solve the problem at the expense of extending the meaning of Archive a bit. It seems pretty elegant to me. So, that's what I've come up with. I'm interested in comments. Does anyone know of a better way to do this? Could this possibly lead to a general mechanism for similar problems? TIA, David -- David Sankel Sankel Software www.sankelsoftware.com

2 4

Review communication
by Mateusz Loskot 17 Jan '11

17 Jan '11

Folks, I've been collecting results after the recent review of Boost.GIL extensions and I noticed that some reviewers notified the library author directly about some significant changes in their reviews/votes, without sending CC to ml/review manager. It means, review manager hasn't received those updates what means biased results of review. Dear reviewers, please check To/CC fields carefully while posting your comments during reviews. p.s. Regarding the Boost.GIL extensions review, we're negotiating a few details with Christian and the results will be available very soon. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Is there a way to debug python C++ extensions in Eclipse on Linux?
by Raul Durand 17 Jan '11

17 Jan '11

Hi guys, Is there a way to debug python C++ extensions in Eclipse on Linux? I want to debug a Python script that imports my module mmm.so and be able to step into my C++ code when necessary using Eclipse. I installed CDT and PyDev and tried different configurations but nothing works. Do I need to create different projects? a PyDev project and a CTD project? Do I need to recompile Python with debug symbols? Is there another tool than Eclipse to achieve this? Thanks, Raul Durand

2 1

Re: [boost] Compiler error in gcc3+ involving template template parameter and default parameters
by Brent Spillner 17 Jan '11

17 Jan '11

On 01/16/2011 8:34 AM, Edward Diener wrote: >That is very nice to say, but the library is for Boost which does try to >still support gcc3+. I know it compiles without error in gcc4+. I should >have been more explicit when I notated 'gcc3+' to ex0plain that I meant >gcc3 versions and not gcc4 versions. I would have dropped the '+' ;-) I'm all about supporting the widest possible variety of compilers, but note that the last GCC 3 release was nearly five years ago. I'm sure that there are plenty of other things in Boost that it can't handle. >Those are just specializations of: > >template<class T> >struct eval; > >There is no reason SFINAE should be involved. It's the same principle; rather than attempting to substitute class members, the compiler is substituting the parameters of the template class F. At any rate, I don't know another name for the concept. >> template<class T, class P = noparam> >> struct ptmf { >> typedef int type; >> typedef ptmf<T, P> is_unary; >> }; >> >> template<class T, class P1, class P2> >> struct other { >> typedef int type; >> typedef other<T, P1, P2> is_binary; >> }; >> >> template<template<class> class F, class P1> >> struct eval<F<P1> > : typename F<typename P1::type>::is_unary {}; >> >> template<template<class,class> class F, class P1, class P2> >> struct eval<F<P1, P2> > : typename F<typename P1::type, typename >> P2::type>::is_binary {}; > >I do not follow this. Your is_unary and is_binary are typedefs within >'ptmf' and 'other' templates. The idea was to give g++ a little more information to help resolve the eval<> ambiguity; when 'ptmf' is substituted for 'F', there is no nested ::is_binary and the second specialization cannot apply, but the first specialization resolves and in fact yields the same type that it would have without the '::is_unary'. Unfortunately, that doesn't seem to be enough help for GCC 3.4.6. I did, however, get your example to compile by refactoring a bit: if you change the template parameters for ptmf to 'template<class T, class P = noparam, class Unused = noparam>', then you can eliminate the first specialization of eval<> but provide additional specializations for the cases where P2 is noparam or P1 and P2 are both noparam, e.g. struct nullary_op {}; struct unary_op {}; struct binary_op {}; template <template<class,class> class F, class P1, class P2> struct eval<F<P1,P2> > : F<typename P1::type,typename P2::type> { typedef binary_op category; }; template <template <class,class> class F, class P1> struct eval<F<P1,noparam> > : F<typename P1::type,noparam> { typedef unary_op category; }; template <template <class,class> class F> struct eval<F<noparam,noparam> > : F<noparam,noparam> { typedef nullary_op category; }; where ::category is just a type tag to help you differentiate between the types of eval<> elsewhere in the framework. This compiles as-is under GCC 3.4.6, and requires that you change the first declaration of eval ('template <class F> struct eval;') to a concrete definition ('template <class F> struct eval {};') under GCC 4.4.4 and 4.5.2 (also legal under 3.4.6.) I don't know how well this solution fits into the rest of your library, but I hope it at least provides some ideas.

2 1

[bitfield] documentation does not build
by Edward Diener 17 Jan '11

17 Jan '11

My mistake: it should be the bitfield library, not bitset. Attempting to build the documentation for bitfield, I get a bunch of errors: "C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1079 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p..\..\..\bin.v2\libs\integer\doc\msvc- 10.0\debug\threading-multi>bitfield.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-bitf ield.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-bitfi eld.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: added properties: <preserve-test-targets>on <python-debugging>off <python >2.6 <threadapi>win32 error: removed properties: none C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1078.actualize from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1087.actualize from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1088.actualize from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1092.actualize from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1093.actualize from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:748: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module C:\Programming\VersionControl\sandbox\boost-build.jam:66: in module scope from m odule" The docs need to be buildable for anyone to use the library or be willing to review it.

4 8

[Thread] thread::interrupt of the death
by Gaetano Mendola 16 Jan '11

16 Jan '11

Hi all, I think a thread after getting an interrupt the first think to do before to throw a boost::thread_interrupted (passing or being on an interruption point) has to disable interruption, indeed think what happens if during a stack unwinding the thread passes again on an interruption point and it receives a second interrupt. This scenario is not that hard to happen. Regards Gaetano Mendola

2 5

Re: [boost] [msm] triggering of a transition on a subclass event does not work on sub state machines in case of favor_compile_time policy is used.
by Christophe Henry 16 Jan '11

16 Jan '11

> Hi All > > I have run it to a problem that feature : Event Hierarchy see doc : > http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1108 > > Does not work in case of sub state machine with favor_compile_time > policy. No trans get called on the sub state machine even it has a row > with event type to the event base class. > > This now hit me badly because compiler runs out of heap if > favor_compile_time policy is not used but when it is used I can not > dispatch based on base type and I have about 150 different event so > declare a transition for it is a no go. > > Is there any workaround for this problem ?. Hi Richard, It took a while but I now committed a solution into the trunk (rev. 68194). Could you please give it a try? It passes my tests but double-checking cannot hurt. It's actually a complete reimplementation of the feature, without boost::any. The advantages: - it supports event hierarchy - it compiles slightly faster - it runs much faster - it requires no rtti I hope it solves your problem. Please let me know. It's not a major change so I could merge it into 1.46, but only if you manage to test it until Monday evening. Otherwise, you'll have to use the trunk version until 1.47. Regards, Christophe

1 0

Compiler error in gcc3+ involving template template parameter and default parameters
by Edward Diener 16 Jan '11

16 Jan '11

I am showing this gcc3 bug just in case any other Boost developer has run into it and knows some easy workaround. It will save me some time as the workaround in the actual case, which is more complicated, is very laborious as I envision it ( I have not yet attempted to code up the laborious workaround ). I ran into this type of case as the problem in my tti library which is keeping it from supporting gcc3+. Here is the simplified code, called TestGcc3.cpp. I have removed all Boost dependencies to make it as simple as possible to see: "template<class T> struct eval; template < template<class> class F, class P1 > struct eval<F<P1> > : F<typename P1::type>{}; template < template<class,class> class F, class P1, class P2 > struct eval<F<P1,P2> > : F<typename P1::type,typename P2::type>{}; struct noparam { typedef noparam type; }; template < class T, class P = noparam > struct ptmf { typedef int type; }; template < class T, class P = noparam > struct tkf : eval<ptmf<T,P> >{}; template <class T> struct ATemplate { typedef T type; }; int main() { tkf<ATemplate<int> > aVar; return 0; }" The compiler command line, which is essentially what bjam generates, is: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c "TestGcc3.cpp" The error message is: "TestGcc3.cpp: In instantiation of `tkf<ATemplate<int>, noparam>': TestGcc3.cpp:52: instantiated from here TestGcc3.cpp:42: error: ambiguous class template instantiation for `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:19: error: candidates are: struct eval<F<P1, P2> > TestGcc3.cpp:10: error: struct eval<F<P1> > TestGcc3.cpp:42: error: invalid use of undefined type `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:2: error: declaration of `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp: In function `int main()': TestGcc3.cpp:52: warning: unused variable 'aVar'" I am looking for a workaround for gcc3+ compilers which does not involve getting rid of the default parameters. If I remove the default parameters, and change the instantiation of tkf to: tkf<ATemplate<int>,ATemplate<int> > aVar; the compile is successful and there is no error. This is of course a very simplified illustration of much more complicated code and maintaining default parameters within the more complicated situation is a much cleaner syntax than an alternative, even if I can get an alternative to work correctly without default parameters.

2 2

[interhreads] Could not build the documentation
by Edward Diener 16 Jan '11

16 Jan '11

When I attempted to build the docs for the interthreads library up for review I received: "C:\Programming\VersionControl\sandbox\interthreads\libs\interthreads\doc\interth reads.qbk:1: warning: Invalid attributes for 'article document info': purpose, category reference/act_traits.qbk: error: Could not open input file. reference/fork.qbk: error: Could not open input file. reference/fork_after.qbk: error: Could not open input file. reference/fork_all.qbk: error: Could not open input file. reference/wait_for_all.qbk: error: Could not open input file. reference/wait_for_any.qbk: error: Could not open input file. reference/algorithm.qbk: error: Could not open input file. reference/wait.qbk: error: Could not open input file. reference/wait_until.qbk: error: Could not open input file. reference/get.qbk: error: Could not open input file. reference/is_ready.qbk: error: Could not open input file. reference/has_value.qbk: error: Could not open input file. reference/has_exception.qbk: error: Could not open input file. reference/wait_all.qbk: error: Could not open input file. reference/wait_all_until.qbk: error: Could not open input file. reference/get_all.qbk: error: Could not open input file. reference/are_all_ready.qbk: error: Could not open input file. reference/have_all_value.qbk: error: Could not open input file. reference/have_all_exception.qbk: error: Could not open input file. reference/detach.qbk: error: Could not open input file. reference/joinable.qbk: error: Could not open input file. reference/join.qbk: error: Could not open input file. reference/join_until.qbk: error: Could not open input file. reference/interrupt.qbk: error: Could not open input file. reference/interruption_requested.qbk: error: Could not open input file. reference/detach_all.qbk: error: Could not open input file. reference/join_all.qbk: error: Could not open input file. reference/are_all_joinable.qbk: error: Could not open input file. reference/join_all_until.qbk: error: Could not open input file. reference/interrupt_all.qbk: error: Could not open input file. reference/interruption_requested_all.qbk: error: Could not open input file. reference/basic_threader.qbk: error: Could not open input file. reference/launcher.qbk: error: Could not open input file. reference/threader.qbk: error: Could not open input file. reference/scheduler.qbk: error: Could not open input file. reference/typeof/futures.qbk: error: Could not open input file. reference/typeof/launcher.qbk: error: Could not open input file. reference/typeof/threader.qbk: error: Could not open input file. reference/typeof/basic_threader.qbk: error: Could not open input file. reference/typeof/scheduler.qbk: error: Could not open input file. reference/asynchronous_executor_decorator.qbk: error: Could not open input file. reference/basic_threader_decorator.qbk: error: Could not open input file. reference/launcher_decorator.qbk: error: Could not open input file. interthreads.qbk: error: Error count: 43."

3 5

Re: [boost] [General] Always treat std::strings as UTF-8
by Artyom 16 Jan '11

16 Jan '11

> From: Dave Abrahams <dave(a)boostpro.com> > > Peter Dimov wrote: > > > > Alexander Lamaison wrote: > > > I'm opposed to this strategy simply because it differs from the way > > > existing libraries treat narrow strings. > > > > It differs from them because it's right, and existing libraries are > > wrong. Unfortunately, they'll continue being wrong for a long time, > > because of this same argument. > > Does the "right" strategy come with some policies/practices that can > allow it to coexist with the existing "wrong" libraries? If so, I'm > all +1 on it. > Combining old libraries with new ones: ====================================== It would be simple to combine a library that uses old policies with new ones. namespace boost { std::string utf8_to_ansi(std::string const &s); std::string ansi_to_utf8(std::string const &s); std::wstring utf8_to_wide(std::string const &s); std::string wide_to_utf8(std::wstring const &s); } - If it supports wide strings call boost::utf8_to_wide **under Windows platform** and nothing is lost. - If it supports only narrow strings: a) if it is encoding agnostic: like some unit-test that only open files named with ASCII names, then you can safely ignore and pass UTF-8 string as ASCII and ASCII as UTF-8 as is the subset of it. b) Do following: 1. Fill a bug to library owner on not-supporting Unicode strings under Windows. 2. Use utf8_to_ansi/ansi_to_utf8 to pass strings to this library under Windows. Current State of Using Wide/ANSI API in Boost: ============================================== I've did a small search to find which libraries use what API: Following use both types of API: ------------------------------- thread asio system iostreams regex filesystem According to new policy they should replace ANSI api by wide api and conversion between UTF-8 and UTF-16 Following libraries use only ANSI API -------------------------------------- interprocess spirit test random The should replace their ANSI api by Wide one with a simple glue of utf8_to_wide/wide_to_utf8 Following libraries use STL functions that are not aware of unicode under windows --------------------------------------------------------------------------------- std::fstream - Serialization - Graph - wave - datetime - property_tree - progam_options fopen - gil - spirit - python - regex Need to replace with something like: boost::fstream and boost::fopen that work with UTF-8 under windows. The rest of the libraries seems to be encoding agnostic. Artyom

5 10