- Boost - lists.boost.org

[mpl?] loki -> boost
by Jody Hagins 27 Feb '04

27 Feb '04

I have a bunch of code that uses loki. I am trying to convert it to use boost instead. However, I am having a very difficult time finding concepts in boost to replace those in loki. I have looked for something to help in this, but I have not had much success. I have read through the MP documentation, and I am even more confused. For example, I use Loki::Int2Type, and according to a loose interpretation of section 2.3.6, mpl::int_c<> may be what I am looking for (at least for this one specific case). However, when I went to look at the source to make sure it does what I think it does, I could not find it anywhere. I have 1.31.0, extracted from the tar.gz file, and did a complete find, but the only place I can find reference to it is in .sgml files. Anyone know what this became, or how to correct my brain-dedness? shandalle:jody> md5sum boost_1_31_0.tar.gz c19ed169de6e76de91f2a1602fb1c688 boost_1_31_0.tar.gz shandalle:jody> find . | xargs egrep 'int_c[:space:]*<' ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_1>, mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: , mpl::int_c<16> ./libs/mpl/doc/paper/src/lambda.sgml: , mpl::bind< mpl::less<>, mpl::bind<mpl::sizeof_<>,_1>, mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/sequences.sgml: mpl::int_c<1> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<2> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<3> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<4> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<5> ./libs/mpl/doc/src/howtos.sgml:typedef mpl::lower_bound<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; ./libs/mpl/doc/src/howtos.sgml:typedef mpl::upper_bound<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; ./libs/mpl/doc/src/howtos.sgml:typedef mpl::binary_search<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; -- Jody Hagins What did Mickey Mouse get for Christmas? A Dan Quayle watch. -- heard from a Mike Dukakis field worker

7 8

Re: [boost] Proxy indirect container adaptor: 4 claims
by Jesse Booher 26 Feb '04

26 Feb '04

>> Christian Engström <christian.engstrom(a)glindra.org> writes: > 1) By using a proxy object, which is essentially a shared_ptr with the > pointer arithmetic removed and with the comparison operators redefined > to compare the elements, and storing such proxy objects in an STL > compatible container, we can use all the algorithms in the STL on the > Container< proxy<T> >, and get the same result as with a Container<T>. > (This works even with the standard STL iterators and in the absence of > any of the other components of the package, so it could be used as a > standalone feature if desired.) > 2) By making proxy<T> implicitly convertible to T&, a proxy<T> can be > used (almost) as a T when it comes to assignments and argument passing. > In the situations when it doesn't work, such as if a function takes a > U argument and was expecting another user-defined conversion from T to U > to let it handle a T arguments as well, the compiler will generate a > type error. > 3) By letting proxy_container define an extra variant for each member > function that would normally take a proxy<T> argument, and letting the > extra variant accept a T instead, we complete the last part of the > symmetry with direct containers as far as entire T objects are concerned. > 4) By defining operator-> in for proxy_container's iterators to do a > double dereferencing, the meaning of that expression remains the same > for a proxy_container iterator as it would for the direct container > iterator. operator* keeps its normal semantics and does a single > dereferencing. This definition is necessary to keep Claim 1 valid, and > to keep the proxy_container working as one would expect from an indirect > container in general. Your Proxy discussion has intrigued me and I took a look at the issue thinking I could come up with a quick solution. The problem is much more subtle than it appears at first blush, however. The main problem is that existing container classes have a fixed concept of what types of iterators that they process. There is no way to tell std::vector that its begin() method should return anything other than std:vector::iterator. If there were an easy way to change this behavior then your proxy problem would become trivial. Imagine for a moment that Iterator Types were part of vector's template arguments then vector<T, allocator<T>, vector<T>::default_iterator, vector<T>::default_reverse_iterator> and vector<S, allocator<S>, indirect_iterator<vector<S>::default_iterator>, indirect_iterator<vector<S>::default_reverse_iterator> >, with S being shared_ptr<T>, would be duals the first for direct access and the second for proxy access. Wonder what it would take to make this happen. Could perhaps be a solution worthy of standards submission. Regards, Jesse Booher

1 0

FC++ Formal review half way over today (ends 2/23)
by Mat Marcus 26 Feb '04

26 Feb '04

Reminder: the formal review for the FC++ functional programming library is now at the half way point - only 5 days remain. If you have an interest in the FC++ library now would be a good time to prepare a review. It would be useful to hear your opinion even if you are not an expert in the functional programming domain or you don't know what a monad is. You are not required to spend a lot of time with the code (although it can be helpful). Some seed questions, in addition to the usual ones referred to below (and at <http://www.boost.org/more/formal_review_process.htm>): Can you understand the intent of the library from the documentation and example code? What are your ideas about the relationship between FC++ and existing boost components? Would some or all of the facilities FC++ (lazy lists, monads, lambda, "prelude") make a useful, relevant addition to boost? Why or why not? If not, do you believe that the author should rework parts of the lib for possible later acceptance? Individual reviews are an essential part of the review process, so please consider spending some time with FC++ this week and then post your thoughts. Thanks, Mat The original notice is reproduced below for your convenience. ### The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

10 20

Proposal: type-promoting arithmetics for derivative types
by Max Motovilov 26 Feb '04

26 Feb '04

This is a long post, so please let me know if making it into a Web page and posting the URL is a better idea. ======================= [Terminology] Since I am not sure whether there is an accepted term for this kind of types, let me introduce one - "derivative arithmetic type": - D.A.T. is a templatized ADT with at least some arithmetic operations defined - D.A.T. is parameterized with a single type-parameter which has at least some arithmetic operations defined (usually it is a built-in numeric type, but not necessarily) - Arithmetic operations on D.A.T. are defined in terms of arithmetic operations on the base type - There is a conversion available between differently parameterized instances of D.A.T. The above certainly isn't a good "standardese" concept definition but it should be enough to illustrate the proposal. Examples of D.A.T.s are std::complex<>, boost::rational<>, boost::math::quaternion<> etc. However, the motivation for this proposal came from my experience with implementing geometric types such as point, rectangle etc. along with operations on them. [Proposal, Part I] Providing a facility that simplifies arithmetic type promotions for D.A.T.s. None of the examples above currently provide it, which means that you cannot expect std::complex<float>( 1, 0 ) + std::complex<double>( 0, 1 ) to yield std::complex<double>( 1, 1 ). So, expressions on D.A.T.s with mixed base types do not really behave the way the built-in numeric types do, even though the individual values can be converted from one instance of the same D.A.T. to another. In the ideal world, one should be able to write: template< typename T1, typename T2 > foo< typeof( T1() + T2() ) > operator+( const foo<T1>&, const foo<T2>& ); and then implement operator+ the way it is normally implemented for foo<T>, first converting foo<T1> and foo<T2> to foo< typeof< T1() + T2() >. I intentionally leave out the optimization issues such as defining operator+ in terms of operator+= etc. However, without typeof(), it would be nice to have a library solution yielding similar result, for example: template< typename T1, typename T2 > foo< promoted_type< T1, T2, std::plus > > operator+( const foo<T1>&, const foo<T2>& ); The third argument of promoted_type<> could be any kind of tag value or type associated with the type of arithmetic operation. Templates std::plus, std::minus, std::multiplies, std::divides and std::modulus do not cover the entire range of C++ arithmetic operations so some other tags may work better. The implementation of promoted_type will obviously be based on partial specializations along with a limited typeof() facility with the assumption that T1 op T2 always yields either T1 or T2 (which is the case for built-in base types). Here is a quick and dirty implementation for only one operation, operator+: template< typename T1, typename T2 > struct typeof_one_of_two { template<int N> struct select_type; template<> struct select_type<1> { typedef T1 type; }; template<> struct select_type<2> { typedef T2 type; }; static char (&typeof_fun( const T1& ))[1]; static char (&typeof_fun( const T2& ))[2]; }; template< typename T > struct typeof_one_of_two<T,T> { template<int N> struct select_type { typedef T type; }; static char typeof_fun( const T& ); }; template< typename T1, typename T2, template< typename _ > class Tag > struct promoted_type; template< typename T1, typename T2 > struct promoted_type< T1, T2, std::plus > { enum { tag = sizeof( typeof_one_of_two<T1,T2>::typeof_fun( T1() + T2() ) ) }; typedef typename typeof_one_of_two<T1,T2>::select_type< tag >::type type; }; (I tried it on MSVC++ 7.1 and it works, though for some reason it doesn't compile if I drag the expression for promoted_type<>::tag into the declaration for promoted_type<>::type. With the intermediate enum value it works fine - a compiler bug?) Note that promoted_type<> may be used not just in binary operators but in any external function or a D.A.T. method, possibly with different D.A.T. parameters, as long as one can make a reasonable deduction of the result type based on certain arithmetic operation over base type values. Also note that all built-in binary operators defined for a pair of built-in numeric types produce results of the same type. This means we wouldn't really need 3rd parameter for promoted_type<> if the base types were always built-in numerics, but user-defined base types may break this assumption. [Proposal, Part II] Going further, we might want to add type-promoting arithmetics to existing DATs that do not provide it. The best I could think of so far is introducing overly generic template operators into global namespace, along with a mechanism based on boost::enable_if to restrict their use to specific parameter templates. The model implementation follows. I find it ugly, but perhaps a better one may be immediately obvious to somebody else. template< template< typename _ > class DAT > struct promote_sum { typedef void tag; }; template< typename P, typename E=void > struct do_not { enum { value = false }; }; template< typename P > struct do_not< P, typename P::tag > { enum { value = true }; }; template< typename T1, typename T2, template< typename _ > class DAT > inline typename boost::disable_if_c< do_not< promote_sum< DAT > >::value, DAT< typename promoted_type<T1,T2,std::plus>::type > >::type operator+( const DAT<T1>& a, const DAT<T2>& b ) { typedef typename DAT< promoted_type<T1,T2,std::plus>::type > T; return T( a ) + T( b ); } To enable promoted-type operator+ for a specific DAT (that already has some flavor of operator+ though without mixing base types), write: template<> struct promote_sum< MyDAT > {}; The use, but not implementation, is similar to the technique suggested by David Abrahams in boost::operators. This one is uglier but, I believe, standard-compliant. Template do_not<> does a SFINAE trick of its own because I couldn't figure out how to do the same thing with enable_if. And again, MSVC++ 7.1 swallows it whole. Here's what I used to test it: template<typename T> struct MyDAT_1 { friend MyDAT_1<T> operator+ ( const MyDAT_1<T>&, const MyDAT_1<T>& ); MyDAT_1( T ); template<typename T1> explicit MyDAT_1( const MyDAT_1<T1>& ); }; template<typename T> struct MyDAT_2 { friend MyDAT_2<T> operator+ ( const MyDAT_2<T>&, const MyDAT_2<T>& ); MyDAT_2( T ); template<typename T1> explicit MyDAT_2( const MyDAT_2<T1>& ); }; template<> struct promote_sum<MyDAT_1> {}; Here MyDAT_1 and MyDAT_2 are identical types; both define an operator+ for uniform arguments. Promoted operator+ is only enabled for MyDAT_1. Now, MyDAT_1<double> a(( MyDAT_1<int>( 1 ) + MyDAT_1<float>( 2.0 ) )); compiles, while MyDAT_2<double> b(( MyDAT_2<int>( 1 ) + MyDAT_2<float>( 2.0 ) )); produces the following error: e:\tmp\t.cpp(77): error C2678: binary '+' : no operator found which takes a left-hand operand of type 'MyDAT_2<T>' (or there is no acceptable conversion) with [ T=int ] which looks rather on-the-money to me. The example implementation above only covers operator+( Foo<T1>, Foo<T2> ). It has an obvious extension to all operator@( Foo<T1>, Foo<T2> ) as well as to other things, for example: template<> struct promote_product2< Matrix, Vector > {}; which can be implemented in the same way. An important special case is support for things like operator*( Matrix<T1>, T2 ) where T2 is presumed to be a scalar type and Matrix<T1>*T2 is expected to yield a Matrix< promoted_type< T1, T2, std::multiplies > >. A generic operator* can be provided for this case but it will only discriminate based on its first argument, which may be dangerously generic for a general-purpose facility... ================================= Well, if anybody got this far, I have to confess that I'm not sure what to do with all this. The first part looks so trivial I may have well overlooked an equivalent facility in one of the existing Boost libraries. If I haven't, it hardly deserves a separate library, but I'm not sure which existing one would be a good place for it. The second part looks like it belongs in boost::operators, assuming that its benefits outweigh the dangers of introducing very generic operators into global namespace (or is there a way to do it otherwise and still get C++ to find the operator definitions?). Let me know whether it will be worthwhile to develop proposed facilities for subsequent Boostification. Regards, ...Max...

4 11

small bug in [date_time] library
by John Torjo 26 Feb '04

26 Feb '04

In date_time library, compiler_config.hpp, at line 53: // workaround for errors associated with wide string output // modifications. compilers affected are: // Borland 551, gcc295 (not stlport), msvc6, mingw // Any of these compilers *should* work if used with StlPort's streams #if ((defined(__GNUC__) && (__GNUC__ < 3)) || \ (defined(_MSC_VER) && (_MSC_VER <= 1200)) || \ (defined(__MINGW32__)) || \ (defined(__BORLANDC__) && (__BORLANDC__ <= 0x0551))) && \ !defined(_STLP_OWN_IOSTREAMS) #define BOOST_DATE_TIME_NO_WSTRING_CONVERSIONS #endif As a side note, the bug appears for VC7.1 as well, so you should update for this as well. Best, John

2 1

Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > > The experience in my case is very simple. I had two bugs > because constructor > is not explicit. I've just made it explicit locally, > recomplied and got no > complication errors, so convenience was not hurted. Yes, an explicit constructor is safer because it would cause those bugs to be detected at compile time, but convenience *is* hurt: std::vector<boost::any> vec; vec.push_back(5); With an explicit constructor, the above won't work. Bjorn

4 4

Please disregard this test message
by Larry Meehan 26 Feb '04

26 Feb '04

test

1 0

RE: [boost] Proxy indirect container adaptor: 4 claims
by Yitzhak Sapir 26 Feb '04

26 Feb '04

> -----Original Message----- > From: christian.engstrom(a)glindra.org > [mailto:christian.engstrom@glindra.org] > Sent: Thursday, February 26, 2004 4:40 PM > To: boost(a)lists.boost.org > Subject: [boost] Proxy indirect container adaptor: 4 claims > > --Is there a way to define a package for indirect containers, so that > one can take a program that uses a direct container, and > convert it to > using an indirect container just by changing the definition of the > container type? You could define a container adaptor that takes a container, and modifies the begin()/end() iterators to return indirect iterators to the original begin()/end(). Then instead of: typedef some_container container_type; you would have: typedef adaptor<some_container> container_type; > --Would it be any useful to be able to switch containers like that? > > The problem here is of course that "usefulness" is very much > in the eye > of the beholder, so all that I can say with certainty is that I > personally would find it quite useful, and that I don't see why other > people as well shouldn't sometimes find themselves in situations when > they would want to change container types easily. After all, > isn't one > of the great benefits of the STL containers that they have > (reasonably) > uniform interfaces, so that it's easy to switch between the different > container types, often by just changing a typedef? You might want to read "Beware the Illusion of container-independent code", by Scott Meyers in his book: http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2… The full book is at: http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407…

1 0

Re: Very odd Comeau C++ behavior
by Comeau Computing 26 Feb '04

26 Feb '04

Just a follow up that in addition to the work around previously sent below, there is now a patch that fixes the underlying problem. Holler if you need a revised compiler. - Greg At 08:40 PM 1/26/2004 +0200, Peter Dimov wrote: >While implementing operator== for boost::mem_fn, I found that the following >program, which I expected to print '1' six times, mysteriously outputs 1 0 1 >1 0 1 under Comeau C++, causing all mem_fn equality tests to fail: > >#include <iostream> > >struct X >{ > int mf0_1() { return 0; } > int mf0_2() { return 0; } >}; > >struct mf0 >{ > typedef int (X::*F) (); > F f_; > > explicit mf0(F f): f_(f) {} > > bool operator==(mf0 const & rhs) const > { > return f_ == rhs.f_; Thanks for the report, it appears you've uncovered a problem. It's being looked into further. For now, this should work: return f_ == rhs.f_ ? true : false; > } > > bool operator!=(mf0 const & rhs) const > { > return f_ != rhs.f_; As well as here: return f_ != rhs.f_ ? true : false; > } >}; > >int main() >{ > std::cout << ( &X::mf0_1 == &X::mf0_1 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) == mf0(&X::mf0_1) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ == mf0(&X::mf0_1).f_ ) << std::endl; > > std::cout << "--\n"; > > std::cout << ( &X::mf0_1 != &X::mf0_2 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) != mf0(&X::mf0_2) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ != mf0(&X::mf0_2).f_ ) << std::endl; >} > >Output: > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>como >testbed.cpp >Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 >Copyright 1988-2002 Comeau Computing. All rights reserved. >MODE:strict errors C++ > > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>aout.exe >1 >0 >1 >-- >1 >0 >1 > >Is this a known issue with Comeau C++ 4.3? Or is there something wrong with >the code? ------- Comeau C/C++ 4.3.3: Offering core language support for C++03 Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau(a)comeaucomputing.com http://www.comeaucomputing.com

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] [snip] > > Sorry, during shortening my previous mail before posting, > one sentence > > got lost :) I was suggesting to add is_iterator, > > If you can figure out how to do that, you will be a hero to many. [snip] One way would be to check if the required iterator_traits are defined for the type, i.e. iterator_traits<T>::difference_type etc, using BOOST_MPL_HAS_XXX_TRAIT_DEF. Too fragile? Bjorn

2 1