- Boost - lists.boost.org

Pending Patches [ Post 1.35.0 work ]
by Marshall Clow 30 Mar '08

30 Mar '08

Now that 1.35 is "out the door" (thanks to everyone for their hard work!), I'd like to call people's attention to the contributed patches in the Trac system. If any of these are assigned to you - please take a look at them and: * Apply them * Decide if they would make things worse * Decide that they are no longer needed [ In general, resolve them ] Thanks! Patches 11 dave 6 az_sw_dude 5 None 4 dgregor 4 agurtovoy 3 rogeeff 3 no-maintainer 3 doug_gregor 3 bemandawes 3 anthonyw 2 matias 2 kaalus 2 igaztanaga 2 hljin 2 grafik 2 danielw 1 vladimir_prus 1 ramey 1 pavol_droba 1 jsiek 1 fcacciola 1 dlwalker 1 djowel 1 chris_kohlhoff None 1116 disable some warnings in msvc build None 1182 Specifying character-set by the guideline and the inspect program None 1335 g++ errors and warnings processing Boost.archive None 1462 Missing/wrong includes None 1526 [PATCH] Building boost 1.34 with Visual C++ 9_0 (Orcas) agurtovoy 1049 Getting mpl/has_xxx.hpp to compile on AIX agurtovoy 637 Adjusts mpl::pair concept to be compatible with STL pairs agurtovoy 761 [mpl] evc4 port agurtovoy 861 Detect nested template members with has_template_xxx anthonyw 1556 Missing initialisations_ thread code now warning free anthonyw 802 [thread] MSVS: Allow use of thread headers with /Za anthonyw 868 [thread] thread_specific_ptr::element_type ? az_sw_dude 1261 Boost.DateTime patch to support STLport's _STLP_NO_IOSTREAMS mode az_sw_dude 1336 Accessing months with wrong namespace az_sw_dude 1615 date_time g++-4.3 fix az_sw_dude 1659 DateTime documentation - Fix a link to the serialization library az_sw_dude 1728 [date_time] unreferenced formal parameter warnings from VC9 az_sw_dude 827 Unused variable in format date parser bemandawes 1090 scoped_file class that deletes file at end of scope bemandawes 1609 patch to suppress warnings if _CRT-/_SCL_SECURE_NO_DEPRECATE were already defined bemandawes 1681 patch for NTFS symbolic links chris_kohlhoff 1341 unused argument and another g++ warning danielw 1541 [parameter] Patch for missing includes danielw 863 [parameter] fix operator|| for lazy binding dave 1020 Boost.Iterator proposal to add is_constant_iterator dave 1066 Patch to make Boost.Python compile on SunCC dave 1271 unused parameter warning in release build dave 1296 std::advance and std::distance for Boost.Iterator traversal categories dave 1297 std advance and std distance for Boost.Iterator traversal categories dave 1316 Support for generic function(*args_ **kwds) call operator. dave 1519 lvalue-ness resurrection in transform_iterator dave 1533 boost/function.hpp unneeded in transform_iterator.hpp dave 1684 [python] Documentation patch dave 857 add shared_ptr< const T> support dave 903 inconsistent usage of function pointer typedefs dgregor 1338 g++ warnings and incomplete header inclusions dgregor 1664 Enhance configure to better conform to autotools conventions dgregor 1685 [numeric/conversion] Fixed link dgregor 1700 graph/floyd_warshall_shortest.hpp.patch djowel 1529 Missing include statement dlwalker 653 [integer] add support for integers longer than long doug_gregor 1087 Mismatch between BBv2 and bjam toolsets in configure script. doug_gregor 862 [utility] Make result_of handle lambda expressions doug_gregor 870 boost::graph::graph_utility.hpp is_connected() bad call fcacciola 1687 [optional] Fix some links grafik 1031 AmigaOS fixes for bjam grafik 1074 FreeBSD specific patches to boost 1.34.0 hljin 1377 Add ability to save RGBA image as TIFF with associated-alpha (premultiplied) transparency channel. hljin 1520 Missing include statements igaztanaga 1661 [interprocess] Update some links for the combined documentation igaztanaga 1709 message_queue documentation typos jsiek 1591 Documentation Corrections - Non-Member Functions kaalus 1536 Add missing template keyword to dependent type name template instance kaalus 1605 property_tree gcc-4.3 fix matias 1521 Missing #include statements matias 1690 [bimap] Small documentation issues no-maintainer 1437 normal_distribution.hpp_ improvements to distribution and possibly speed no-maintainer 1702 serialization for Mersenne twister no-maintainer 864 [lambda][utility] Make lambda support result<> pavol_droba 1506 [string_algo] C4512 warnings from VC8.0 ramey 1418 polymorphic archive performance improvement rogeeff 1169 errors in tutorial for test framework "new_year_resolution" rogeeff 1432 Missing includes and same compiler warnings rogeeff 998 prg_exec_fail2 fail on ppc vladimir_prus 1534 Add support for winsdk 6.1.6000 to Boost.Build.v2 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[1.36.0] Suggestions for 1.36.0
by Beman Dawes 30 Mar '08

30 Mar '08

While the 1.35.0 experience is fresh in my mind, I've jotted down suggestions for the 1.36.0 release process. See http://svn.boost.org/trac/boost/wiki/SuggestionsForOneDotThirtySix Comments welcome, --Beman

6 11

Documentation page of new web site
by Edward Diener 30 Mar '08

30 Mar '08

This is just a headsup to say that the documentation page of the new Boost web site for 1.35 says "Standard Build & Link: Header Only" for all libraries.

2 2

Boost 1.35.0 released
by Beman Dawes 29 Mar '08

29 Mar '08

Boost is pleased to announce the availability of release 1.35.0. This is a major release that includes 12 new libraries, and coincides with an upgrade and reorganization of the www.boost.org web site. The new libraries are: * Asio: Portable networking, including sockets, timers, hostname resolution and socket iostreams, from Chris Kohlhoff. * Bimap: Boost.Bimap is a bidirectional maps library for C++. With Boost.Bimap you can create associative containers in which both types can be used as key, from Matias Capeletto. * Circular Buffer: STL compliant container also known as ring or cyclic buffer, from Jan Gaspar. * Function Types: Boost.FunctionTypes provides functionality to classify, decompose and synthesize function, function pointer, function reference and pointer to member types. From Tobias Schwinger. * Fusion: Library for working with tuples, including various containers, algorithms, etc. From Joel de Guzman, Dan Marsden and Tobias Schwinger. * GIL: Generic Image Library, from Lubomir Bourdev and Hailin Jin. * Interprocess: Shared memory, memory mapped files, process-shared mutexes, condition variables, containers and allocators, from Ion Gaztañaga. * Intrusive: Intrusive containers and algorithms, from Ion Gaztañaga. * Math/Special Functions: A wide selection of mathematical special functions from John Maddock, Paul Bristow, Hubert Holin and Xiaogang Zhang. * Math/Statistical Distributions: A wide selection of univariate statistical distributions and functions that operate on them from John Maddock and Paul Bristow. * MPI: Message Passing Interface library, for use in distributed-memory parallel application programming, from Douglas Gregor and Matthias Troyer. * System: Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. Among existing libraries, Boost.Threads has been upgraded to reflect changes made by the C++ committee in the process of including Boost.Threads in C++0x. Dozens of people contribute to each Boost release. Rene Rivera, Daniel James, and John Maddock were instrumental in readying this release. It wouldn't have happened without them. --Beman Dawes, Release Manager

1 0

[pool] A pool object as allocator to std container?
by Gregory Dai 29 Mar '08

29 Mar '08

I was able to use something like the following: boost::object_pool<std::set<int> > front; but I'd instead want to be able to use: boost::object_pool<int> back; boost::object_pool<std::set<int, boost::object_pool<int> > front(back); which is not possible because the object_pool does not conform to the standard allocator interface. For the time being it's possible to do: boost::object_pool<std::set<int, boost::pool_allocator<int> > front; but an element set from the pool does not interact well with a plain std::set<int>. Any suggestion on a solution? Thanks, Greg

1 0

Re: [boost] [Proto] very small review (repost)
by Eric Niebler 29 Mar '08

29 Mar '08

Cédric Venet wrote: > The title of my first post was misleading, so I repost it. Thank you, I missed it the first time. > I am not sure to be qualified to make a review but I will give it a try. Your feedback is valuable. > First, I think the library should be accepted. Thanks. >> - What is your evaluation of the design? > > Seems good. I must say I didn’t read or try the transform part of proto. > >> - What is your evaluation of the implementation? > > Didn’t read the code > >> - What is your evaluation of the documentation? > > I think there is some (more) work to do on it. > I had some probleme with > users_guide\expression_construction\construction_utils.html > Because it was not clear to me how to put it in pratice. I'll probably redesign the users' guide to be more example-driven. I've gotten a lot of feedback about that. > In fact after a fast read of the doc, I mostly used the exemple as reference > of how to do something. > > So, I don't know exactly what can be done but some ideas may be: > > *Provide more basic example > *Refer to the example in the documentation to show the practical use of what > is described. > *make a FAQ OK. > One difficulty I didn't had time to study is how to do polymorphic grammar > or semantic checking. (perhaps I should not put this in the review). Mor > clearly, I add two example: > > First I would like to have a grammar which can work on any terminal but can > only have compatible terminal in a one expression (for example, you can't > have vector and list in one expression but you can have one expression with > lists and one with vector and they would follow the same grammar). > My idea was to do a basic proto grammar which just check operator use and > then to use a transform to fold the type of the terminals, checking they are > all compatible. Proto grammars are context-free, so I think that forces you to do the compatibility checking as a separate step with a transform, as you suggest. It would be an interesting exercise to try to imagine what a context-sensitive Proto grammar might look like, but for now we have to make do. Since Dave also wants to do terminal-based compatibility checks, I banged together an example. The following transform checks to see if all terminals have the same type. It uses a state parameter that is callable ... you stuff terminal types into it and it keeps track of whether they're all the same or not. Pretty simple. The only tricky bit is treating the result of the _state transform as callable and invoking it. I use proto::bind for that (to be renamed proto::lazy). #include <iostream> #include <boost/assert.hpp> #include <boost/mpl/or.hpp> #include <boost/mpl/and.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/type_traits/is_void.hpp> #include <boost/xpressive/proto/proto.hpp> #include <boost/xpressive/proto/transform.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; template<typename IsValid = mpl::true_, typename Value = void> struct Accumulator : IsValid { template<typename Value2> struct validate : mpl::and_< IsValid , mpl::or_< boost::is_void<Value> , boost::is_same<Value, Value2> > > {}; template<typename Sig> struct result; template<typename This, typename Value2> struct result<This(Value2)> { typedef Accumulator<validate<Value2>, Value2> type; }; template<typename Value2> typename result<void(Value2)>::type operator ()(Value2 const &) const { return typename result<void(Value2)>::type(); } }; struct SameTerminals : proto::or_< proto::when< proto::terminal<proto::_> // treat the current state as a callable // object and pass it the value of the terminal. , proto::bind<proto::_state(proto::_arg)> > , proto::otherwise< proto::fold<proto::_, proto::_state, SameTerminals> > > {}; int main() { int dummy = 0; proto::terminal<int>::type i = {0}, j = {1}, k = {2}; proto::terminal<short>::type s = {42}; BOOST_ASSERT( SameTerminals()(i+j*k, Accumulator<>(), dummy) ); BOOST_ASSERT(!SameTerminals()(i+s*k, Accumulator<>(), dummy) ); } Note that this example exposed a bug in the proto::make transform, which is already fixed. Be sure to get the latest, either from the file vault or subversion. > Second, I have a grammar where I can add terminals 'a+b' and index terminal > 'a[b]'. you can have '(a+b)[c]'. some terminals may be indexable but other > not. I could make a grammar for indexable terminal and another for not > indexable but it would be duplicated. And if I add more properties to my > terminals (for example Boolean, integer or float), the number of grammar > explode. I was thinking to again use a transform to check the 'semantic' of > the expression. If I understand correctly, I think you can do this with a Proto grammar. See below. #include <vector> #include <iostream> #include <boost/type_traits/is_array.hpp> #include <boost/xpressive/proto/proto.hpp> #include <boost/xpressive/proto/transform.hpp> namespace proto = boost::proto; using proto::_; struct IndexableTerminals : proto::or_< proto::terminal<std::vector<_,_> > , proto::and_< proto::terminal<_> , proto::if_<boost::is_array<proto::_arg>() > > > {}; struct NonIndexableTerminals : proto::and_< proto::terminal<_> , proto::not_<IndexableTerminals> > {}; template<typename TerminalGrammar = NonIndexableTerminals> struct MyGrammar : proto::or_< TerminalGrammar , proto::subscript< MyGrammar<IndexableTerminals>, _ > , proto::nary_expr<_, proto::vararg<MyGrammar<TerminalGrammar> > > > {}; template<typename Expr> void assert_valid(Expr const &) { BOOST_MPL_ASSERT((proto::matches<Expr, MyGrammar<> >)); } template<typename Expr> void assert_not_valid(Expr const &) { BOOST_MPL_ASSERT_NOT((proto::matches<Expr, MyGrammar<> >)); } int main() { proto::terminal<std::vector<int> >::type vi; proto::terminal<int[4]>::type ai = {{1,2,3,4}}; proto::terminal<int>::type i = {0}; assert_valid(i + i * 1); assert_valid(vi[1]); assert_valid((vi + ai)[1]); assert_valid(i + (vi + ai)[1]); assert_not_valid(i + vi + ai); assert_not_valid((i + vi)[1]); } > > Is it the way to go? I didn't see any reference to this in the > documentation, but this seems a common pattern to me? The proto grammar > would only check the 'parsing' and one transform would check the semantic. > > A yes, I would add two note which seem relevant for VS user: > * the compiler flag -Zm (for example -Zm150) to change the maximum size of > the precompiled header > * the pragma inline_recursion and inline_depth (default off and 8) OK. >> - What is your evaluation of the potential usefulness of the library? > > Extremely useful. > >> - Did you try to use the library? With what compiler? Did you have any >> problems? > > I used it with VS2005. I didn’t had any problem (at least not one which > wasn’t my fault) > >> - How much effort did you put into your evaluation? A glance? A quick >> reading? In-depth study? > > I read the doc and started writing a small test. Didn’t had the time to try > transform. Thanks for your feedback. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

[gsoc 2008] JSON Archives for Boost.serialization - Draft Proposal published
by Kasun Indrasiri 29 Mar '08

29 Mar '08

Hi all, I have published the draft proposal for JSON Archives for Boost.serialization on the following google page. http://kasun147.googlepages.com/jsonarchivesforboost.serialization <http://kasun147.googlepages.com/jsonarchivesforboost.serialization>Waiting forward for the comments on the proposal. Regrads, Kasun Indrasiri.

2 1

[Proto] very small review (repost)
by Cédric Venet 29 Mar '08

29 Mar '08

The title of my first post was misleading, so I repost it. Hi, I am not sure to be qualified to make a review but I will give it a try. First, I think the library should be accepted. > - What is your evaluation of the design? Seems good. I must say I didnt read or try the transform part of proto. > - What is your evaluation of the implementation? Didnt read the code > - What is your evaluation of the documentation? I think there is some (more) work to do on it. I had some probleme with users_guide\expression_construction\construction_utils.html Because it was not clear to me how to put it in pratice. In fact after a fast read of the doc, I mostly used the exemple as reference of how to do something. So, I don't know exactly what can be done but some ideas may be: *Provide more basic example *Refer to the example in the documentation to show the practical use of what is described. *make a FAQ One difficulty I didn't had time to study is how to do polymorphic grammar or semantic checking. (perhaps I should not put this in the review). Mor clearly, I add two example: First I would like to have a grammar which can work on any terminal but can only have compatible terminal in a one expression (for example, you can't have vector and list in one expression but you can have one expression with lists and one with vector and they would follow the same grammar). My idea was to do a basic proto grammar which just check operator use and then to use a transform to fold the type of the terminals, checking they are all compatible. Second, I have a grammar where I can add terminals 'a+b' and index terminal 'a[b]'. you can have '(a+b)[c]'. some terminals may be indexable but other not. I could make a grammar for indexable terminal and another for not indexable but it would be duplicated. And if I add more properties to my terminals (for example Boolean, integer or float), the number of grammar explode. I was thinking to again use a transform to check the 'semantic' of the expression. Is it the way to go? I didn't see any reference to this in the documentation, but this seems a common pattern to me? The proto grammar would only check the 'parsing' and one transform would check the semantic. A yes, I would add two note which seem relevant for VS user: * the compiler flag -Zm (for example -Zm150) to change the maximum size of the precompiled header * the pragma inline_recursion and inline_depth (default off and 8) > - What is your evaluation of the potential usefulness of the library? Extremely useful. > - Did you try to use the library? With what compiler? Did you have any > problems? I used it with VS2005. I didnt had any problem (at least not one which wasnt my fault) > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I read the doc and started writing a small test. Didnt had the time to try transform. Regards, -- Cédric

1 0

Visitation using RTTI
by Mathias Gaunard 29 Mar '08

29 Mar '08

Boost.variant provides visitation over an object whose types is within a certain set. To identify the type of the object, it uses an additional int that uniquely identifies the type of the object within the set. However, RTTI already provides unique identification for objects of polymorphic types within all types. I'm well aware that typeid(SomeType) is not a constant expression (which is quite a shame really, especially since I can't see any technical reason why it couldn't be) but it is still possible to do something like this: switch(typeid(o).name()[0]) { case 'F': switch(typeid(o).name()[1]) { case 'o': switch(typeid(o).name()[2]) { case 'o': switch(typeid(o).name()[3]) { case 0: // object of type "Foo" break; default: // unknown type } default: // unknown type } default: // unknown type } default: // unknown type } By providing the name of the types as a compile-time string, it could be possible to generate the implementation-specific mangled name and, from it, this kind of switch statement. This would allow O(1) (but with a possibly large constant) visitation of objects of polymorphic types non-intrusively. An utility could provide something like this: struct Base { virtual ~Base() = 0; }; struct Derived1 : Base { virtual Derived1() {} }; struct Derived2 : Base { virtual Derived2() {} }; struct Derived3 : Base { virtual Derived3() {} }; typedef mpl::map< mpl::pair< mpl::string<'D', 'e', 'r', 'i', 'v', 'e', 'd', '1'>, Derived1 >, mpl::pair< mpl::string<'D', 'e', 'r', 'i', 'v', 'e', 'd', '2'>, Derived2 >, mpl::pair< mpl::string<'D', 'e', 'r', 'i', 'v', 'e', 'd', '3'> Derived3 > > derived_types; struct Visitor { typedef void result_type; template<typename T> void operator()(T&) const { // something useful } }; // b can actually be of any type derived from Base void foo(const Base& b) const { poly_visit<derived_types>(b, Visitor()); } Is there some interest in such a tool?

5 10

[config] BOOST_HAS_NRVO not defined for VC++ 8.0 and later?
by Beman Dawes 28 Mar '08

28 Mar '08

Looking at config_info results, BOOST_HAS_NRVO doesn't appear to be defined for VC++ 8.0 and later. But see http://msdn2.microsoft.com/en-us/library/ms364057(VS.80).aspx. According to that, 8.0 and later does support the named return value optimization. What am I missing:-? --Beman

2 3