September 2004 - Boost - lists.preview.boost.org

Geometric Algebra Library (again)
by Tony Juricic 05 Sep '04

05 Sep '04

I couldn't reply to the original post but I found Boost++ disussion on this topic between Ken Hagan, Jaap Suter and Hubert Holin on Google. Since quaternions and octonions are already part of the library I would second the opinion that more generic Geometric Algebra library would be one useful addition. Tony

2 2

[boost.range] renaming empty() to is_empty()
by Thorsten Ottosen 05 Sep '04

05 Sep '04

Dear all, John Torjo asks why don't rename the Range concepts empty() function to the more idiomatic and less embarrassing name is_empty()? My initial thoughts were if this could ceate more confusion, but I'm beginning to think John is right. So if people would cast some yes or no votes it would be great. br Thorsten

7 6

[1.32 Release] MPL has been merged into the main trunk
by Aleksey Gurtovoy 05 Sep '04

05 Sep '04

Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk. -- Aleksey Gurtovoy MetaCommunications Engineering

6 12

CodeWarrior and alignment_of (help!)
by Doug Gregor 05 Sep '04

05 Sep '04

Some of the Graph tests are failing on CodeWarrior due to some strange interaction within alignment_of, where it doesn't like mpl::size_t. I don't have the compiler to test on :( Here's one example of the failures: http://tinyurl.com/4dapg Doug

2 1

[1.32 Release] Summary of MPL changes
by Aleksey Gurtovoy 05 Sep '04

05 Sep '04

The HMTL version of the changelog is available at http://www.mywikinet.com/mpl/mpl_1_32_changelog.html MPL changelog for 1.32 release ****************************** The following summarizes major changes in the library interface and implementation from the previous release, with the accent on backward compatibility. Note that this is *not* a comprehensive list of all changes (yet). Apply/lambda semantics ---------------------- 1. Nullary metafunction classes are no longer special-cased, and are *not* identical to nullary metafunctions: +-------------------------+---------------+---------------------------+ | Nullary... | Before | Now | +=========================+===============+===========================+ | metafunction | ``f::type`` | ``f::type`` | +-------------------------+---------------+---------------------------+ | metafunction class | ``c::type`` | ``c::apply<>::type`` or | | | | ``c::apply::type`` [1]_ | +-------------------------+---------------+---------------------------+ This fixes a flaw in the metafunction/metafunction class algebra that long has been the major source of other inconsistencies throughout the library. 2. ``apply`` now automatically invokes ``lambda`` on its first argument, e.g. the following is well-formed now:: typedef apply< plus<_1,_1>, int_<2> >::type four; ``apply_wrap``\ *n* auxiliary metafunctions are available for rare cases when it's crutial to eliminate small overhead associated with lambda expressions while still avoiding various compiler bugs known to lurk in the obvious ``f::template apply<...>::type``. 3. Lambda implementation for broken compilers has been reworked to match as close as possible the semantics of the full-fledged version; consequently, there might be some incorrect code out there that will stop working with the new implementation. To get the detailed picture of the new apply/lambda semantics, please see the corresponding test case at http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/apply.cpp?v…. .. [1] The second form is available only on fully conforming compilers. Iterator protocol ----------------- The library no loger guarantees nor relies on the direct presence of ``advance`` / ``distance`` / ``next`` / ``prior`` / ``type`` members in iterator types; the following table summarises the new requirements: +-------------------------------+-------------------------------+ | Before | Now | +===============================+===============================+ | ``i::type`` | ``deref<i>::type`` | +-------------------------------+-------------------------------+ | ``i::next`` | ``next<i>::type`` | +-------------------------------+-------------------------------+ | ``i::prior`` | ``prior<i>::type`` | +-------------------------------+-------------------------------+ | ``i::advance<n>::type`` | ``advance<i,n>::type`` | +-------------------------------+-------------------------------+ | ``i::distance<j>::type`` | ``distance<i,j>::type`` | +-------------------------------+-------------------------------+ | ``i::category`` | ``i::category`` | +-------------------------------+-------------------------------+ Sequence traits protocol ------------------------ Sequence algorithms' traits protocol has been changed to that of metafunction classes: +------------------------------------------------+------------------------------------------+ | Before | Now | +================================================+==========================================+ | *name*\ ``_traits<Tag>::algorithm<...>::type`` | *name*\ ``_impl<Tag>::apply<...>::type`` | +------------------------------------------------+------------------------------------------+ Correspondingly, if your code implemented a custom sequence, it needs to be adjusted according to the above table; for example: +-----------------------------------------------+-------------------------------------------+ | Before | Now | +===============================================+===========================================+ |:: |:: | | | | | template<> struct begin_traits<my_tag> | template<> struct begin_impl<my_tag> | | { | { | | template< typename S > struct algorithm | template< typename S > struct apply | | { | { | | typedef ... type; | typedef ... type; | | }; | }; | | }; | }; | | | | +-----------------------------------------------+-------------------------------------------+ Numeric metafunctions protocol/infrastructure --------------------------------------------- The arithmetic, comparison and bitwise metafunctions are `polymorphic`, and can operate on a variety of numeric types, including rational, fixed-point and complex numbers. The metafunctions allow `mixed arithmetic`, meaning that you can perform an operation on the arguments of different types, and the result will yeild the largest/most general of the arguments types. The infrastructure is provided to allow easy plugging of user-defined numeric types which can be made freely intermixable with predefined library types. See http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/numeric_ops… for an illustrative example. If you were using MPL numeric metafunctions on your own integral wrapper class similar to ``mpl::int_``, you can plug it into the new infrustructure by extending the class with the following member:: typedef mpl::integral_c_tag tag; For example: +---------------------------------------+-------------------------------------------+ | Before | Now | +=======================================+===========================================+ |:: |:: | | | | | template< int n > struct my_int | template< int n > struct my_int | | { | { | | static int const value = n; | typedef mpl::integral_c_tag tag; | | typedef my_iny type; | static int const value = n; | | }; | typedef my_iny type; | | | }; | | | | +---------------------------------------+-------------------------------------------+ Renaming/cleanup ---------------- 1. ``apply_if`` metafunction has been renamed to ``eval_if``. 2. All ``_backward`` algorithm counterparts have been renamed to use ``reverse_`` prefix; e.g. ``fold_backward`` became ``reverse_fold``. 3. ``<boost/mpl/aux_/has_xxx.hpp>`` header has been made public and became ``<boost/mpl/has_xxx.hpp>``; correspondingly, the ``BOOST_MPL_NO_AUX_HAS_XXX`` macro was renamed to ``BOOST_MPL_CFG_NO_HAS_XXX``. 4. ``<boost/mpl/assert_is_same.hpp>`` header has been replaced by a more general ``<mpl/assert.hpp>``; the new asserts provide a significantly higher-quality diagnostics. See the table below for the new equivalents of the old macros: +-------------------------------------------+-----------------------------------------------------+ | Before | Now | +===========================================+=====================================================+ | ``BOOST_MPL_ASSERT_IS_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT(( boost::is_same<t1,t2> ))`` | +-------------------------------------------+-----------------------------------------------------+ | ``BOOST_MPL_ASSERT_IS_NOT_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT_NOT(( boost::is_same<t1,t2> ))`` | +-------------------------------------------+-----------------------------------------------------+ 5. All configuration macros has been renamed to include ``CFG`` prefix; in particular, ``BOOST_MPL_NO_FULL_LAMBDA_SUPPORT`` has become ``BOOST_MPL_CFG_NO_FULL_LAMBDA_SUPPORT``. 6. The following other public headers/components has been renamed or removed as obsolete:: iterator_tag.hpp (renamed to iterator_tags.hpp) project1st.hpp project2nd.hpp select1st.hpp select2nd.hpp Miscellaneous ------------- 1. ``vector`` has been re-implemented to support constant-time insertion at both the beginning and the end. For example, this is now well-formed:: typedef push_back<v,int>::type v1; typedef push_front<v1,int>::type v2; 2. The interface of some sequence building algorithms such as ``copy`` has been changed. Please see the corresponding headers for the details (updated docs are upcoming!). -- Aleksey Gurtovoy MetaCommunications Engineering

4 9

[mpl] problems with borland 5.6.4
by Hugo Duncan 05 Sep '04

05 Sep '04

Aleksey, The following does not compile, on bcc 564 with latest pserver CVS. The Variant definition is similar to the one Borland provides in their VCL headers (and the problem therefore exists with any code that uses the VCL). The error message is E2015 Ambiguity between 'operator !=(int,const Variant &)' and '!=' Removing the mpl include gets rid of the compile error. Any ideas? Regards, Hugo # include <boost/mpl/placeholders.hpp> struct Variant { Variant(int); }; bool operator!=(int, const Variant&); namespace // problem occurs both with and without unnamed namespace { enum Abc { abcd, abcde }; } int fn() { int x=0,y=1; if (x!=y) // OK return 1; Abc a; if (a!=abcd) // ERROR HERE return 1; return 0; }

2 1

repost: [mpl][multi_index][intel-8.0-linux] regression
by JOAQUIN LOPEZ MU?Z 05 Sep '04

05 Sep '04

I posted this a couple of days ago and got no response. Please help. Thank you. Newly merged MPL seems to be having problems in Intel 7.x/8.0 under Linux with BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN, as shown in http://tinyurl.com/5rj4d Appart from this, the merge is mostly working fine, as far as multi_index is concerned. There's another MPL-related problem, but it's due to a previously masked bug of mine. Congrats and thanks for the staggering effort. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

mpl::map not working?
by Max Khesin 05 Sep '04

05 Sep '04

I wanted to play with mpl::map, but I noticed that it is having problems on vc7.1 (http://tinyurl.com/3kr99) and many other compilers - is there a known fix? thanks, max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 2

[v2]command line argument feature treated as target
by Larry Evans 04 Sep '04

04 Sep '04

Based on the following example: borland/<runtime-link>static located at: http://boost.org/boost-build2/doc/html/bbv2.reference.commandline.html I tried the following: bjam --v2 gcc/\<link-runtime\>static error: Unable to find file or target named error: 'gcc/<link-runtime>static' error: referred from project at error: '.' I also tried <runtime-link> without success. I guessed <link-runtime> from looking at: tools/build/v2/tools/gcc.jam which contains: flags gcc.link OPTIONS <link-runtime>static : -static ; What am I doing wrong? TIA. Regards, Larry

1 1

Re: [boost.thread] Experimental alternative TLS implementation
by Tony Juricic 04 Sep '04

04 Sep '04

I just downloaded Roland's implementation and I quite like it. By the way, congrats Roland on resolving TLS callback issues for static link library for VC6 and VC7; after digging into it as I joined the group I was too busy but now I hope to have more time and, at least, help with more testing. While intentional TLS slot leak is not a big issue (one expects that OS will do proper cleanup on program exit) it may be confusing to the first-time reader who may have a hard time understanding the motivation for protecting programmers from some leaks, while leaving other leaks to the OS. Reference counting makes it quite clear to the reader what is intended by the code. I wonder what are current plans for the future of threads libray, after a lot of discussion about rewrite? My own perspecitive is colored by everyday practical use: for example, I never encountered any need for thread-specific pointer but I often had to pass a boolean to thread proc to make a thread stop. Consequently, and as I would like to use boost threads instead of my own concotion, I would like to see "thread stopping pattern", lacking better term and just for example, as the part of the interface. I understand these are difficult issues but after quite a few years of using threads I am not sure that I still find 'older' Java-like thread(s) interface particularly useful. Tony

2 2