- Boost - lists.preview.boost.org

tru64cxx65 regression tests temporarily disabled
by Markus Schöpflin 06 Sep '04

06 Sep '04

The regular regression tests for Compaq C++ 6.5 on Tru64 V5.1 have been temporarily disabled. They will be reactivated as soon as possible. Markus

1 0

RE: [boost] Re: New design proposal for boost::filesystem
by Reece Dunn 06 Sep '04

06 Sep '04

Vladimir Prus wrote: >Martin wrote: > > > Vladimir Prus <ghost <at> cs.msu.su> writes: > > The current path implementation doesn't > > allow you to handle more than one type (i.e. winfs or posixfs). You >can't > > store a registrypath in a fs::path since it can't handle a hkey.. root. > >Why? Can't I put literal "HKEY_CURRENT_USER" in boost::path? I don't think he's questioning that, but the case where you can use a HKEY handle as the root, for example: // note: not sure on exact calls HKEY hkCU, hkBase; ::OpenKey( null, "HKEY_CURRENT_USER", &hkCU ); ::OpenKey( hkCU, "software\\microsoft\\windows", &hkBase ); boost::fs::path regwin( hkBase ); // oops: error boost::fs::path spyware = regwin / "CurrentVersion" / "Run" / spyware_app; if( exists( spyware )) // does the registry key exist { // display the value std::cout << "removing: " << boost::fs::get_regval( spyware ) << '\n'; boost::fs::delete( spyware ); // delete the registry entry } Also, iterating through registry entries requires different API calls to that of iterating through files. > >> Actually, I think it is very desired to have boost::path usable in more > >> contexts than the filesystem. For example > >> > >> fs::path base("http://my_site.org"); > >> ..... get_file(base / "foo" / "bar") ..... > >> > >> would be great. But I'm just don't sure this requires all that drastic > >> changes. > > > > Why do you think it is a drastic change? > > Changing operations will not take much time since it is only to move the > > things inside "#ifdef BOOST_POSIX" and "#ifdef BOOST_WINDOWS" into > > separate overloads. > >And #ifdef the overloads ;-) I don't think Win32 API calls can be compiled >on Linux. > >I really think that win32/posix distinction should say as it is. For other >types of path, I'm not sure. I *think* that boost::fs::path can accomodate >all of them. Of course, if you stick URL into boost::fs::path, the name >'native_file_path' becomes questionable ;-) Why not have a class like std::char_traits (e.g. boost::fs::path_traits) that abstracts the API used by path. That way, you can have: template< typename CharT > struct posix_path_api { typedef ... file_handle; typedef ... directory_iterator_handle; static bool exists( file_handle ); static void delete( file_handle ); static directory_iterator_handle get_next( directory_iterator_handle ); }; This would then simplify the Win32/posix API problems and allow for internet_api, winregistry_api, etc. to be included, e.g. boost::fs::path< char, internet_api< char > > boostweb( "http://www.boost-consulting.com/boost" ); Regards, Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

warning in boost::program_options
by Rodolfo Schulz de Lima 06 Sep '04

06 Sep '04

Hi, I'm using boost::program_options for the first time and noticed that when compiling a program that uses it using gcc's -Wall, it spits out a warning about an unused function parameter: /usr/include/boost-1_32/boost/program_options/value_semantic.hpp:137: warning: unused parameter 'value_store' Can this be corrected? It's just annoying when using -Werror. Since I've seen warnings in other libraries as well, I wonder why those ones aren't being caught in boost's test summary (on the home page). Just adding -Wall to the compiler option would suffice. Regards, rod

2 1

another warning in boost::program_options
by Rodolfo Schulz de Lima 06 Sep '04

06 Sep '04

Oops... another warning: /usr/include/boost-1_32/boost/program_options/detail/value_semantic.hpp:78: warning: unused parameter 'target_type' There might be others...

1 0

Is there any interest in a simple template for streaming in/out primitives and STL Containers of them?
by Boris Kats 05 Sep '04

05 Sep '04

I am using it for some time and hope that other will benefite from it. One file streamline.h will help user to stream out/in an arbitrary item of primitives or STL containers of them. It is very simple to use; just type like this: #include "streamline.h" using namespace hekate; ....... typedef std::pair<std::string, std::vector<int> > element; element one,other; And stream it out as: streamline(cout,one); or stream it in as: streamline(cin,other); . User will find a lot of examples in the streamtest.cpp file at streamline.tar in "Files section". The streaming templates were tested with gcc version 3.3.2, msvc7 and ibm89 c++ compiler. Boris Kats. boriskats(a)yahoo.com __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 1

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