- Boost - lists.boost.org

[mpl] weird interaction between mpl::set and mpl::map headers
by Joaquín Mª López Muñoz 13 Oct '05

13 Oct '05

The following snippet #include <boost/mpl/set/set0.hpp> #include <boost/mpl/map.hpp> int main() { return 0; } produces the following in GCC 3.2: In file included from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:18, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:34: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_key_impl. hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_impl.hpp: 19, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:22, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:33: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/begin_end_impl. hpp:20, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:30, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:41: parse error before `<' token /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:62: parse error before `<' token but if I reverse the order of the #includes, everything works OK. I suspect this problem is also showing in the GCC 3.4.x family. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Toolset for VC8.0 and stlport
by Thierry Miceli 13 Oct '05

13 Oct '05

Did somebody make a toolset for VC8.0 and stlport? Thanks, Thierry

2 1

[MPL.Math] partial comeback of big_integral
by Cromwell Enage 13 Oct '05

13 Oct '05

I've rewritten mpl::math::big_integral_impl so that, instead of being a heavyweight mpl::vector, the mantissa (formerly magnitude) is treated as a nullary metafunction containing the integral constant expressions digit_0...digit_N, where N is one less than the mantissa size, which is now directly configurable. Arithmetic operations are now much faster as a result. The functionality that converts integral_c et. al. to a big_integral_impl is now moved to mpl::math::enlarge_integral. All I need now is a *much* more efficient division algorithm and, of course, mpl::math::big_integral itself. BTW, there may be extraneous files in the <mpl_math.zip>boost/ directory; ignore them, I was using them for study purposes. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

[concept_check.hpp] unreferenced formal parameter line 227
by Kevin Wheatley 13 Oct '05

13 Oct '05

Hi, I was wondering if anybody has thought about adding a #else to the #if !defined(_ITERATOR) to ignore the unused variable warning in AssignableConcept::const_constraints() you get when compiling on VC7.1 ? (Or am I missing something subtle about the situation) Thanks Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

3 4

singleton_ptr
by Jason Hise 13 Oct '05

13 Oct '05

Due to the fact that to get a bachelors degree in computer science at my university I need 4 semesters of a foreign language, I currently have run out of time to keep working on singleton. I have no idea why C++ couldn't count as my foreign language... for whatever reason I just have to learn French instead :-P. I definitely plan to resume work on this library in the future, but in order to avoid keeping everyone else waiting I am uploading the current code to the sandbox. I think that although I have not yet had time to create html docs, the comments document the functionality reasonably well. The only real things missing are some sort of timeout_lifetime and multiton_ptr. As a jumping off point, here is some sample code to demonstrate example usage: #include <boost/singleton_ptr.hpp> class MyClass { public: void DoSomething ( ) { } }; typedef boost::singleton_ptr < MyClass > MySingletonPtr; void foo ( ) { MySingletonPtr ptr; ptr->DoSomething ( ); } singleton_ptr uses named template parameters to specialize functionality. The following policies are provided: factory - determines how instances are created and destroyed, also responsible for memory allocation threading - determines how member access is serialized lifetime - determines how instance is automatically destroyed storage - determines where and how the singleton policies themselves are stored name - allows multiple singletons of the same type to coexist, even if their other policies aren't different. also used to specify segment names in the case of shmem. you may specify any or all of these, in any order, as follows: using boost::singleton_ptr; using boost::singleton::name; using boost::singleton::factory; using boost::singleton::threading; using boost::singleton::lifetime; using boost::singleton::storage; typedef boost::singleton_ptr < MyType, name < /*instance name here*/ > factory < /*factory policy here*/ >, threading < /*threading policy here*/ >, lifetime < /*lifetime policy here*/ >, storage < /*storage policy here*/ > > MySingletonPtr; When you declare a singleton_ptr, you can also throw manual_creation, lazy_creation, or greedy_creation anywhere into the policy list. This is a special argument, and multiple singleton_ptr types which differ only by this specification will still point to the same instance (this cannot be said about any of the other arguments). Choosing one of these allows you to control when pointers of that type will perform automatic creation (if the instance does not yet already exist). Since there is not yet any official documentation, I encourage everyone to use me as documentation and pummel me with questions :) If you wonder if something can or can't be done with the library, want clarification on some of its features, or have ideas for code improvement please let me know. The code is in the sandbox under the "Patterns" folder. -Jason

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by Eric Niebler 13 Oct '05

13 Oct '05

Joel de Guzman wrote: > > Docs: http://tinyurl.com/77pz5 > Doc bug regarding QuickBook shorthand notation for strike-through in the Include Files table, in section "Supported Operators". http://tinyurl.com/b25hr (I've been bitten by this strike-though issue with QuickBook several times. I'm considering ripping the short-hand notation for strike-through out of QuickBook.) Also, I'm not wild for the names val(), var() and invar(). "val" and "var" look too much alike, and could lead to subtle bugs; "invar" doesn't read well, or it isn't evocative of what it does. Have you considered using val(), ref() and cref()? -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[MPL.Math] tribool
by Cromwell Enage 12 Oct '05

12 Oct '05

Any interest in compile-time tribooleans? Functionality is currently limited by the fact that mpl::and_, mpl::or_, and mpl::not_ are not implemented in terms of any respective *_impl metafunction classes. (That means no nested expressions, no lambda expressions, and no 3+-arg expressions.) Any desire to change this? Cromwell D. Enage __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

1 0

[Review] TR1 library accepted
by Beman Dawes 12 Oct '05

12 Oct '05

John Maddock's TR1 library is accepted by Boost. Coincidentally, ISO has just announced that TR1 unanimously passed its final ballot, and so is now official. There were four reviews of John's submission, all urging acceptance. For most of the relatively few issues raised during review, John has already responded. Unless I missed it, however, John hasn't responded to Jonathan Wakely's review comments yet, anduld do so when he gets a chance. For example: It might be useful to list all the BOOST_HAS_TR1_XXX macros on the Configuration page, so you can glance at them all at once (most people will know what components each macro relates to.) Otherwise you have to read through a lot of text on the "TR1 By Subject" page to see what's available. Congratulations to John, and thanks to our reviewers! --Beman Dawes, Review Manager

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 12 Oct '05

12 Oct '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Hi, > > Here's a pre-release package of Phoenix-2. Jaakko and I agreed > that it will be the basis of the Phoenix and Boost Lambda > merger. This version is Phoenix 1 + Lambda + a lot more. > > Take note though that this is not a drop-in replacement of > Phoenix-1 for Spirit users. In particular, there is no > closure support. Phoenix-2 has true local variables. The > plan for Spirit-2 is to replace closures with local variables. > > Docs: http://tinyurl.com/77pz5 > > The pre-release package is here: > http://spirit.sourceforge.net/dl_more/phoenix_v2.zip > > Just drop it where Phoenix-1 is and run the examples/tests. > Comments, feedback very welcome! arg1 // evaluates to a unary function arg2 // evaluates to a binary function arg3 // evaluates to a ternary function I am surprised. Shouldn't arg1 be a one-or-more argument function that returns its first argument, and arg3 be a three-or-more argument function that returns its third argument? Also, I think you can drop "evaluates to" and put something more descriptive in the comments. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Yet another FOREACH
by A. Azuma 12 Oct '05

12 Oct '05

Hi, Boosters. First, sorry for my bad English and the long post. I have been much inspired by Eric Niebler's FOREACH. It is very nice and useful. However, I think there are some drawbacks in his implementation. First, Eric's FOREACH should explicitly specify the value type of the range. It is still bothering me in some cases. For example, std::map or a range of ranges. Second, the reference type should be declared when a value is written into the range. It seems unclear. Then, I show yet another idea to implement FOREACH. My implementation can provide the following syntax. vector<int> v; ..... FOREACH(iter, v){ cout << *iter << endl; } The code above can be considered that `iter' is declared as an iterator. In this syntax, the first problem I picked up is clearly solved. Moreover, when writing a value into the range, the code whould be int i = 0; FOREACH(iter, v){ *iter = i++; } It seems very clear. The second problem is solved, too. This syntax would be reasonable and familiar to C++ programmers. Of cource, all the stuffs in the macro and operator* are calculated in compile-time, and compilers can optimize at the same level as an equivalent handwritten for-loop. On the other hand, there is a very serious limitation in my code. A number of FOREACH in each translation unit is limited. With the implementation in the attached file, the number is limited up to 100. This number can be easily increased, but increasing it burdens a compiler. In addition, member access operator (operator->) cannot be used. I use a subtle implementation of compile-time global counter to emulate auto/decltype, and subtly hides them in FOREACH macro and iterator syntax. Please see the attached code for more detail. The attached code has been tested on GCC3.4.2, MSVC7.1 and MSVC8.0 beta 2. All the implementations are compliant to the standard, I believe so at least. By the way, my idea contains auto/decltype emulation, so such a syntax as followings can be also provided by using my idea. AUTO_ANY(less, boost::lambda::_1 < boost::lambda::_2); sort(v1, v2, auto_cast(less)); // the type of the lambda functor is restored. Of course, this does not look so nice. I would like to ask boosters how useful, portable and interesting my idea is. Thanks in advance.

3 4