- Boost - lists.preview.boost.org

Re: [boost] [Boost-commit] svn:boost r67792 - in branches/release: boost/iterator
by Michel MORIN 19 Jan '11

19 Jan '11

Hi Marshall, It seems there are missing merges in changeset [67792]. <marshall(a)idio.com> wrote: > Author: marshall > Date: 2011-01-08 13:38:08 EST (Sat, 08 Jan 2011) > New Revision: 67792 > URL: http://svn.boost.org/trac/boost/changeset/67792 > > Log: > Merging fixes to release; fixes #2294 fixes #4918 fixes #3645 refs #2823 refs #1427 refs #2893 > Properties modified: > branches/release/boost/concept_check.hpp (contents, props changed) > branches/release/boost/fusion/container/list/detail/build_cons.hpp (contents, props changed) > branches/release/boost/iterator/iterator_facade.hpp (contents, props changed) > branches/release/status/explicit-failures-markup.xml (contents, props changed) > Text files modified: > branches/release/boost/concept_check.hpp | 166 ++++++++++++++++++++------------ > branches/release/boost/fusion/container/list/detail/build_cons.hpp | 3 > branches/release/boost/iterator/iterator_facade.hpp | 28 ++-- > branches/release/status/explicit-failures-markup.xml | 199 ++++++++++++++++++++++++++++----------- > 4 files changed, 261 insertions(+), 135 deletions(-) The log message says that the fixes for tickets #1427 and #2893 (#1427: transform_iterator should use boost::result_of to determine functor result type) (#2893: Function Input Iterator) are merged to release. But this changeset does nothing with iterator/transform_iterator.hpp and iterator/function_input_iterator.hpp. Regards, Michel

2 4

[Locale] Boost Locale looks for review manager:
by Artyom 19 Jan '11

19 Jan '11

Hello All, There had been recently several discussions about review process Unicode etc. I think that Boost.Locale would allow us going forward in all Unicode related stuff in Boost and it would help us to get to some standardization in all related to Unicode handling in Boost. So I'm calling for You boost users and developers to volunteer to be a review manager of Boost.Locale. Thank you very much, Artyom

3 6

[website] running_regression_tests.html
by Jim Bell 19 Jan '11

19 Jan '11

I made changes to the "Running Regression Tests" page, per the list discussions of a few weeks ago. <http://beta.boost.org/development/running_regression_tests.html> Comments welcome. Do I transfer this page to the live website myself? (If so, how? I see </development/website_updating.html>, but that doesn't quite cover it.) Please advise. Thanks in Advance, -Jim

2 1

Boost.Pool - Are you using this library, please can we have your input?
by Paul A. Bristow 18 Jan '11

18 Jan '11

Boost.Pool is the subject of a 'make-over' by Boost.Guild. (This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox). In order to permit any modification, the original (hand-written?) html documentation has been converted to Quickbook (and somewhat revised) at http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/ You can build the html docs using the jamfile.v2 in the normal way, but you will probably find it more convenient to go direct to the pdf version http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf This is fairly fully hyperlinked, and includes a reference section using Doxygen. Doxygen comments have been added to the header files (from the original html docs). (If you are a Doxygen fan, there is also a Doxyfile for generating Doxygen-style docs in the /doc/Doxygen/ folder). We are now considering some better tests, and perhaps some enhancements to the code. We'd like input from users about: 1 Things missing or wrong from the docs. More up to date references? 2 Things missing (or don't work well) from Pool. 3 New things that you would like (this is not a promise!). 4 Examples of your use. Perhaps you built some during your development that could be used? 5 Better tests. Thanks. Paul PS Don't panic - the release version will not be changed without a mini-review. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 2

[1.46.0] [units] test_output failing all release regression compilers
by Beman Dawes 18 Jan '11

18 Jan '11

http://beta.boost.org/development/tests/release/developer/summary.html is looking pretty good for most libraries, but units test_output is failing all release regression compilers. Can we get a fix for this before the beta next week? Thanks, --Beman

4 9

Showstoppers?
by Marshall Clow 18 Jan '11

18 Jan '11

Looking in the Trac, I see 43 bugs marked as "Showstoppers". Are any/all of them worth holding up the release of 1.46 for? [ If not, I suggest that they should not be marked as 'showstopper' ] https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re… -- 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

1.46 closed for major changes
by Vladimir Prus 18 Jan '11

18 Jan '11

Boosters, per our calendar, 1.46 is now closed for major changes. What constitutes a major change is up to your judgement, but please excercise care with commits. 1.46 will be closed for all changes next Monday. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

Re: [boost] [Boost-commit] svn:boost r68201
by Bryce Lelbach 18 Jan '11

18 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 16 Jan 2011 23:52:02 -0500 (EST) steven(a)providere-consulting.com wrote: > Author: steven_watanabe > Date: 2011-01-16 23:51:54 EST (Sun, 16 Jan 2011) > New Revision: 68201 > URL: http://svn.boost.org/trac/boost/changeset/68201 > > Log: > Revert addition of BOOST_NIX, etc and everything tied to it. ([66696], > [66783], [66804], [66833], and [66834]) Removed: fenv.h is not a part of the C++ standard library; it is specified in ISO/IEC 9899, section 7.6 (the C99 standard). It's implementation is tied not only to the underlying C library in use, but also to a number of other factors, including but not limited to: - The operating system - The kernel - The compiler's method of implementing header search Attempting to detect the presence of the fenv.h header and the toolchains support for using said header cannot be achieved naively by defining a macro if the GNU, vacpp, sgi or stlport standard library implementation is found. The changes you have introduced will break Boost support for (at least) the following compilers and toolchains: - Sun, HP, Pathscale - Clang on linux or darwin using libc++ - Any compiler using the Apache/Roguewave standard library I am sincerely sorry to have stepped on toes here at Boost, especially yours, as you seem to be hellbent in purging Boost of my contributions, instead of helping to improve upon them. You told me last night in an email that you went back and reviewed every commit that I have ever made to Boost. I would appreciate it if you would let me know how much of my work you have in your crosshairs. Anyone here who knows me is aware that I am young and inexperienced at working on a large-scale open source project. I have been a little over-enthusastic and unintentionally inconsiderate, but I have done my best to fit in here and make contributions to Boost. I do not think that reverting my commits without consulting me first encourages the SVN policies that you and others assert that I have blatantly violated. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0z11gACgkQ9cB/V3/s9EyXJQCfesVXrNkhAeNoYCmgWODv0Z7m 6fMAni0Sb7gdtQWHyIj7EVFhrwqvBjCv =Sr5U -----END PGP SIGNATURE-----

5 7

Review Manager Assistant Role (reloaded)
by Joachim Faulhaber 18 Jan '11

18 Jan '11

Dear list, There have been discussions around the review process currently with some positive results and initiatives. There is a general dissatisfaction with the slow speed of processing libraries in the queue, the difficulties to find review managers and the accumulation of "stale" libraries of unclear status. Thanks to the activities of Volodya, Vicente and others this seems to improve currently. I appreciate this very much. Still I think, we should consider changing some of the rules of the review process to make it more efficient in the long run. A few points that are important to me: (1) Public statements on the Boost web page should be true. (Currently at least one is not.) (2) Only libraries that conform *all* requirements for boost libraries should be included into the review schedule. (3) The time a library stays in the review schedule should be as short as possible and it'll be limited to a maximum. (4) The throughput of libraries on the list shall be driven by the contributors activities. (5) The processing of a library contribution can be stopped by rejection (no-votes) and vetoes, but *not by inaction*. The principles that I regard to be most relevant are: (p1) Contribution must not be discouraged by mere inaction. (p2) Harness the motivation where it is: Development and library contribution. Don't expect it to be where it is not: Administration duties of seasoned boosters. I think that we can achieve point (1) to (5), if we shift more of the time consuming work of the Review Manager to the contributers by creating the Review Manager Assistant Role as proposed at BoosCon http://lists.boost.org/Archives/boost/2010/05/166423.php And every *first contributor* has to take on a Review Manager Assistant job once. Since there was reasonable support for those ideas, specifically by Dave Abrahams and Robert Stewart, I would like to come back on them, to see if there is still interest. Specifically I'd like to hear what the Review Wizards think. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[Serialization] can BOOST_ASSERT have method calls?
by Patrick Horgan 18 Jan '11

18 Jan '11

I noticed in serializations basic_iarchive that when you're not building for debug the next line here (317 in basic_iarchive.cpp) has a warning for unused variable new_cid. The BOOST_ASSERT is instantiated as ((void)0) so new_cid really isn't used. Could the register_type call be moved into the assert? class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); int i = cid; cobject_id_vector[i].bpis_ptr = bpis_ptr; BOOST_ASSERT(new_cid == cid); Something like: BOOST_ASSERT(register_type(bpis_ptr->get_basic_serializer()) == cid); Then the new_cid variable wouldn't be needed and the call to register_type would disappear with the BOOST_ASSERT if you aren't building for debug. Or, does the call to register_type have an important side effect that is required? Patrick

3 3

[signals] failure to build with recent gcc
by Patrick Horgan 18 Jan '11

18 Jan '11

I get a number of the same failures when doing a clean build of boost trunk with a recent gcc (4.6.0). libs/signals/src/named_slot_map.cpp:105:23: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: error: call of overloaded ‘erase(std::map<boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair>, boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group> >::iterator&)’ is ambiguous /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: note: candidates are: /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:763:7: note: void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator = std::_Rb_tree_const_iterator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >] /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1490:5: note: std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(const _Key&) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type = unsigned int] Patrick

2 1

[Boost Graph Library] Having trouble constructing necessary parameters for the isomorphism algorithm
by Alexander Bock 18 Jan '11

18 Jan '11

Hi all, First of all, I new to the mailing list, so please excuse me for any beginner's mistakes I may make :) I am also new to the Boost Graph Library. I am having some trouble implementing the Boost Graph Library isomorphism algorithm under MSVC++ 2008 Express Edition. Since I am using MSVC++, I cannot use the named parameter method, as specified in the docs. I am not entirely sure, but I think my problem is the vertex invariants that I pass to the algorithm. I am using Boost 1.43. My graph and relevant typedefs look like this: typedef adjacency_list<listS, listS, undirectedS, VertexProperty, EdgeProperty, no_property, listS> UndirectedGraph; typedef graph_traits<UndirectedGraph>::vertex_descriptor VertexDescriptor; I am using bundled properties: struct VertexProperty { string id; int index; }; struct EdgeProperty { string id; int weight; }; Here's my code that tries to call the isomorphism algorithm: bool BoostGraph::Compare(BoostGraph& comparableGraph) { vector<VertexDescriptor> f(GetNoVertices()); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap1 = get(&VertexProperty::index, uGraph); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap2 = get(&VertexProperty::index, comparableGraph.GetGraph()); return isomorphism(uGraph, comparableGraph.GetGraph(), isomorphism_map(make_iterator_property_map(f.begin(), indexMap1, f[0])), ???, ???, vertex_invariant2.max(), indexMap1, indexMap2); } The two '???' are where I need to pass the vertex degree invariants, but I do not know how to construct them. I hope I have supplied sufficient information for you. Thanks in advance!

2 13

Review manager volunteer
by Edward Diener 18 Jan '11

18 Jan '11

I am willing to be a review manager to help expedite the review of libraries in the review schedule which do not have a review manager assigned to it. Looking at the review process web page it says that the review wizards, whom the page says are currently John Phillips and Ronald Garcia, maintain a list of review manager volunteers. I do not know if that means I should be e-mailing directly the review wizards, so I decided to post this here first instead. I have been a programmer for 33 years, am very good with C++, and have a pretty good understanding of the basic Boost libraries ( MPL, Type Traits, PP, Function Types etc. ) with which other programmers may be working in order to produce a library for Boost. I have also put two libraries in the sandbox and am working on a third which I will eventually upload, so I have gained some experience in producing a potential library for Boost. Whether that qualifies me for being a review manager others can decide. My heart will not be broken if it does not, but if I am accepted as a potential review manager I know I can do a good job. Looking at the documentation of the libraries currently in the queue which do not have a review manager as yet, I believe I am familiar enough with the ideas of some of the libraries to be a review manager for any of these: bitfield conversion join endian string_convert pimpl My own point of view, unlike what others have generally expressed, is that the review wizards should assign reviews to potential review managers, after e-mailing them to see if they would be available for a particular library, rather than the library implementer directly asking someone to review their library. I feel that way because I think there may be too much influence on the review manager to accept a reviewed library when the library implementer and the review manager are joined by the direct asking process. But perhaps I am wrong, especially as many libraries have no review manager and the review wizards do not seem to be assigning review managers to those libraries from some volunteer list which they have. I believe it is important to break the logjam which is the current review schedule without keeping library implementers waiting for a longer and longer period of time to get their libraries reviewed, much less added to a Boost distribution in the future if it is accepted. The lack of review managers seems to be one of the major reason for this jamup and I would like to alleviate it in my own way, especially as I would like to eventually get my own libraries reviewed in the near future when I request it.

3 3

[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

[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