- Boost - lists.boost.org

[ratio] Moved to trunk
by vicente.botet 17 Jan '11

17 Jan '11

Hi, I have moved Boost.Ratio to trunk and I have managed with all the requested points. From: "Anthony Williams" > These changes should be addressed before the library appears in a > Boost release. > > * Some of the macros had names with RATIO_RATIO in. These should be > changed to just RATIO DONE > * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates > should derive from the resulting ratio type as well as providing the > nested ::type member, in order to closely emulate the template alias > facility from C++0x DONE. While dreiving solve most of the issues ::type is needed yet to match a template parameter. > * The typos in the documentation should be fixed, and the documentation > reviewed for correctness and clarity (though several of the reviewers > made positive comments on the quality of the documentation). DONE even if there are always some improvements. > * The library needs more tests under the Boost Software License. DONE, thanks to Howard and the LLVM community for changing its license and making it compatible with Boost. > * All references to names from the boost namespace should be qualified > with boost:: to avoid potential name clashes and ambiguity with names > from the global namespace. DONE > * Sections commented out with #if 0 should be removed DONE > * The extensions beyond the facilities required by the C++0x draft > should be able to be enabled or disabled through use of a > configuration macro. DONE, BOOST_RATIO_EXTENSIONS needs to be defined. > * References to the tests, examples and documentation from within the > code should be checked for correctness. > DONE I have tried to solve some of the usual portability issues and even if there are yet some issues on the regression report, I consider that the library is globaly ready. I have added some extensions that Joel requested during the review. The extensions are related to viewing ratio<> as a Rational Constant. Rational constants can be mixed with other MPL Integral Constants when using the MPL numeric metafunctions. Paul A. Bristow has reviewed the documentation and fixed most of the editorial isues. The pdf documentation is available here https://svn.boost.org/svn/boost/trunk/libs/ratio/doc/ratio.pdf. If the html file is needed I can commit it temporarilly. It would appreciate if others can take a look and check if everything is right before moving to release. Thanks, Vicente

1 0

[Boost][BGL] New isomorphism test algorithm contribution
by Carlos Cardeñosa Pérez 17 Jan '11

17 Jan '11

Hi, I have been developing a new implementation for test graphs isomorphism, named conauto <http://sites.google.com/site/giconauto/> algorithm (based on José Luis López Presa thesis). I would like to contribute it to BGL. This is a more efficient algorithm than the current one. You can study all its details from conauto thesis at here<http://www.diatel.upm.es/jllopez/tesis/thesis.pdf> . Once developed the first conauto BGL-style version, I am sure that there are many advises and comments that could help to enhance it and eventually will be acceptable for BGL maintainers. Find attached both the source code and some measurements graphics. Please, do not hesitate ask me for any additional information. Best regards, Carlos Cardeñosa.

2 7

[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