- Boost - lists.boost.org

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

[bbv1] MkDir rule broken on Win32!?
by Bertolt Mildner 04 Sep '04

04 Sep '04

When started form a Windows Commandline (cmd.exe) bjam tries to create existing directories and of curse failes to do so! For example when building boost::thread: ------------------------------------ ...found 205 targets... ...updating 20 targets... MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading-multi Ein Unterverzeichnis oder eine Datei mit dem Namen "..\..\..\bin\boost\libs\thre ad\build\boost_thread.dll\cw\\threading-multi" existiert bereits. mkdir "..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading- multi" ...failed MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threa ding-multi... ------------------------------------ (the german error-msg means "directory or file "..." allready exists") As this causes targets to be skipped this is getting pretty annoying ... As far as i understand the root of the problem is that the nativ "mkdir" on Win32 does not take any options to be quiet if the directory exists ("-p" on Unix). It looks like allyourbase.jam tries to address this in the MkDir rule, but fails to. Bertolt PS: I have tried to post this in gmane.comp.lib.boost.build but i always got mail that i should join <jamboost(a)yahoogroups.com>!

2 3

[utility] value_init fails on CW*
by Stefan Slapeta 04 Sep '04

04 Sep '04

see http://tinyurl.com/5639d Has anybody a solution for this? Seems that all CWs have problems with casts in combination with conversion functions. Stefan

4 4

Boost serialization: release configuration linker errors
by Robert Ramey 04 Sep '04

04 Sep '04

I assume you're using the version currently in the main CVS tree. Or are you using the version 1.31? I've always had this problem. It manifests itself differently with different compiliers. In often related to linkers removing "dead code" that really isn't dead - the linker isn't smart enough to see that in fact the code is used. One of the ways I've found to address this is to mark certain templates for export (dllexport). Unfortunately, the way of doing this varies from compiler to compiler. So, I occasionally re-run all tests in release mode to detect these problems. Usually this is enough. Recently, I've fixed up export to work regardless of idiosyncrasies of various compilers and I may have broken something. I'll retest and recheck this. Robert Ramey >Ive been using Boosts serialization library with MSVC 7.1 (the first time >that Ive used it). For most of my project I put the load / save function >declaration in the class header (the .h file) and the definitions in the >.cpp file VC 7.1 allows this for templated functions, unlike some older >compilers. In debug mode this compiled and linked fine except for abstract >base classes through trial and error I found that for abstract classes >the functions had to be defined in the .h file to avoid linker errors. >My project built fine in Debug mode and I then tried to compile / link it >in Release mode this threw up quite a few LNK2001 errors relating to just >a few of the serialization load / save functions in just some of the >classes most of the classes that declared the load / save functions >evidently linked fine (as they all did in Debug mode). After much double >checking of the compile / link project configurations I tried the >following: >1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the >.h files in which the load / save functions were not linking. On >recompiling / linking most of the linker errors were gone, but a few >remained. >2. For the remaining classes that were not still not linking, I moved the >load / save functions from the .cpp file into the .h file (these were not >abstract classes). This fixed the remaining linker errors and my >application compiled / linked / ran fine. >I can't see why this occurred. I havent checked yet (its very time >consuming to rebuild this application) but possibly option (2) would have >worked for all the affected classes. For most of this project, the load / >save functions remain defined in the .cpp file and clearly link fine in >both debug and release configurations. Before someone asks, I did complete >clean / rebuilds for both configurations anybody any ideas?

1 0