- Boost - lists.boost.org

RE: [boost] Re: Customer Friendlier Boost Installation
by Brian Braatz 28 May '05

28 May '05

> -----Original Message----- > On Behalf Of Reece Dunn > Brian Braatz wrote: > > > Paul A Bristow a écrit : > > > * Finally, installing boost takes longer than installing VC++... Is > > > building from the source such an important point ? Would'nt it be > > > possible to provide pre-built libraries for the 3 or 4 main compilers > on > > > windows with each release ? The whole package, zipped, is 80mb on my > >VC8. > >[Brian Braatz Writes:] > >Thank you for also suggesting that. > > Why not make it configurable as part of the install: > > [0] Dependancies: check for Python, cygwin, xsltproc, doxygen, etc. > allowing the user to configure these ("I have Python installed here..."). > [1] Get Boost from... [local directory, boost-consulting, sourceforge, > CVS > (requires a CVS client), ...] > [2] Select the compilers/versions I want to use Boost on (auto-detected > and > configurable list -- add compilers/versions not on the list, select "(do > not) support" > [3] Select which parts of Boost the user whats to install/build > [4] Tools: get prebuilt version of bjam/wave/quickbook or build from > distribution (with compiler...) > [5] List prebuild libraries so I can select the compilers/versions I want > to support > [6] Build libraries for the compilers/versions I want to support (that I > haven't downloaded prebuild versions for) > [Brian Braatz Writes:] Yes that sounds good. The key is to REDUCE the barrier to entry. Especially #5, I know that is work to make it happen, But I believe this to be a major step in spreading boost.

1 0

[type_traits] is_pointer<noncopyable> fails on CodeWarrior 9.4
by Jonathan Turkanis 28 May '05

28 May '05

Hi, The following program produces a compiler error on CodeWarrior 9.4 (see error messages at end): #include <boost/noncopyable.hpp> #include <boost/type_traits.hpp> int main() { bool b = boost::is_pointer<boost::noncopyable>::value; } If I change this to: #include <boost/noncopyable.hpp> #include <msl_utility> int main() { bool b = Metrowerks::is_pointer<boost::noncopyable>::value; } everything is fine. What's up? Jonathan --------------------------- Error : illegal access from 'boost::noncopyable_::noncopyable' to protected/private member 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable &)' (point of instantiation: 'main()') (instantiating: 'boost::is_pointer<boost::noncopyable_::noncopyable>') (instantiating: 'boost::detail::is_pointer_impl<boost::noncopyable_::noncopyable>') (instantiating: 'boost::is_member_pointer<boost::noncopyable_::noncopyable>') (instantiating: 'boost::is_member_function_pointer<boost::noncopyable_::noncopyable>') (instantiating: 'boost::detail::is_member_function_pointer_impl<boost::noncopyable_::noncopyable >') (instantiating: 'boost::detail::is_mem_fun_pointer_select<false>::result_<boost::noncopyable_::n oncopyable>') is_member_function_pointer.hpp line 70 ));

6 12

boost::array fails ContainerConcept check in 1.32 [patch]
by Michael B. Edwin Rickert 28 May '05

28 May '05

I hope I've got the right list here (first time poster), my apologies if I don't :-). boost::array fails a ContainerConcept check in 1.32 due to it's lack of a const_pointer typedef: #include <boost/array.hpp> #include <boost/concept_check.hpp> int main ( void ) { using namespace boost; function_requires< ContainerConcept< array< int , 5 > > >(); } Resulting errors using MinGW's GCC 3.4.2: boost/concept_check.hpp: In instantiation of `boost::ContainerConcept<boost::array<int, 5u> >': boost/concept_check.hpp:48: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::ContainerConcept<boost::array<int, 5u> >]' ../main.cc:7: instantiated from here boost/concept_check.hpp:683: error: no type named `const_pointer' in `class boost::array<int, 5u>' I noticed the BCCL links to SGI's documentation for the Contanier concept, which actually does not appear to list a const_pointer (see http://www.sgi.com/tech/stl/Container.html) although it does include pointer, which array is lacking. As allready mentioned, I tried this with 1.32 - I also tried the CVS head version, no idea if that's the latest that I should be checking or what (CVS newbie), but this wasn't fixed in there. In any case, adding const_pointer to array allows the simple example to compile - here's a patch which adds this and pointer (hopefully in an OK format - I'm a solo hobbyist, not used to working on large projects) which adds them... let me know if I can be of any other help :-). Index: array.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/array.hpp,v retrieving revision 1.23 diff -u -r1.23 array.hpp --- array.hpp 9 Sep 2004 13:59:00 -0000 1.23 +++ array.hpp 28 May 2005 00:58:03 -0000 @@ -50,6 +50,8 @@ typedef const T* const_iterator; typedef T& reference; typedef const T& const_reference; + typedef T* pointer; + typedef const T* const_pointer; typedef std::size_t size_type; typedef std::ptrdiff_t difference_type;

2 2

RE: [boost] Re: [gauging interest] Windows GUI - semi-installer
by Brian Braatz 28 May '05

28 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Thursday, May 26, 2005 12:45 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [gauging interest] Windows GUI - semi-installer > > "Pablo Aguilar" <pablo.aguilar(a)gmail.com> writes: > > > Yesterday, when I decided to start this, I went and downloaded John > Torjo's > > Win32GUI library (www.torjo.com) and noticed that the build utility > > packaged with it, is very similar to what I originally had in mind. > > > > Like I said, I didn't conceive it as an installer, but rather as a tool > to > > build and setup directories, all this while assuming the user would be > > willing to download and extract boost on his own. > > Sounds helpful. [Brian Braatz Writes:] I restate my suggestion ifrom the past for John to take his Win32GUI library , boostify it, and turn it into a "min-gui" library. THE POINT is to scope it SMALL, I.e. this is a minimal gui library, not QT or WxWindows. Just a small thing that is cross platform but provides simple GUI functionality for boost tools. (similar in scope and concept the tinyxml lib buried in boost)

2 1

[serialization/vc7.1]: integral_c_tag not member of boost::mpl: need help!!
by Francis ANDRE 28 May '05

28 May '05

Hi Robert I ask again for any help on this point since I am now stack with this error. Join my previous mail and your answer about this integral_c_tag ---------------------------------------------------------------------- Hi Robert I got this error from error C2039: 'integral_c_tag' : n'est pas membre de 'boost::mpl' Here the beginning of level.hpp I got: ---------------------------------------------------------------------------- ------ #include <boost/mpl/int.hpp> #include <boost/mpl/integral_c.hpp> #include <boost/serialization/level_enum.hpp> #include <boost/serialization/traits.hpp> namespace boost { namespace serialization { // default serialization implementation level template<class T> struct implementation_level { template<class U> struct traits_class_level { typedef BOOST_DEDUCED_TYPENAME U::level type; }; typedef mpl::integral_c_tag tag; // <== problem here // #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) // typedef ---------------------------------------------------------------------------- -------- >From what I check of the latest HEAD release from CVS, it should be integral_c instead of integral_c_tag?? Regards FA _______________________________________________ Francis ANDRE wrote: > Hi Robert > > I got this error from error C2039: 'integral_c_tag' : n'est pas > membre de 'boost::mpl' > > >> From what I check of the latest HEAD release from CVS, it should be > integral_c instead of integral_c_tag?? > Hmmm - I looked into this and I don't think its an error. level and tracking are mpl "integer types" with special "sauce" and I think that this is what ineger_c_tag is meant to be used for. Also I note that none of our tests flag this as an error. I'm not all together sure about this so anyone is free to help out here. Robert Ramey

2 2

Electrical outage and downtime 6am-8pm June 5th
by David Abrahams 28 May '05

28 May '05

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] Re: compressed_pair requirements?
by JOAQUIN LOPEZ MU?Z 27 May '05

27 May '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Mayo 27, 2005 11:10 pm Asunto: Re: [boost] Re: compressed_pair requirements? > JOAQUIN LOPEZ MU?Z wrote: > > > IMHO, std::pair default ctor should be defined as > > > > pair():first(),second(){} > > This doesn't change things. pair() {} is what you probably want. Why? (This is not a rethoric question, my understanding of value-initialization matters is so poor.) > > What can I say, I'm glad that your and Howard's view didn't > prevail when > std::pair was being defined. If I had it MY way, > > typedef set<int> int_set; > pair<int_set::iterator,int_set::iterator> p; > > would have compiled on no compiler because int_set::iterator > wouldn't even > have had a default constructor. I think there's some value in having iterators being DefaultConstructible. Otherwise you're forced to have some container around everytime you construct an iterator. Defaut construction for iterators is roughly the equivalent of initializing to 0 in the case of pointers. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[bind] Usage with function templates
by Cromwell Enage 27 May '05

27 May '05

A new user may naively expect Boost.Bind to accept function templates just as it does ordinary functions. For example: std::map<Vertex,Vertex> vertex_map; boost::prim_minimum_spanning_tree( graph , boost::make_associative_property_map( vertex_map ) ); works just as well as std::map<Vertex,Vertex> vertex_map; boost::prim_minimum_spanning_tree( graph , boost::make_associative_property_map< std::map<Vertex,Vertex> >(vertex_map) ); However, when converting boost::make_associative_property_map to a function object, the following code: std::map<Vertex,Vertex> vertex_map; boost::bind( boost_make_associative_property_map , vertex_map ) map_maker; boost::prim_minimum_spanning_tree( graph , map_maker() ); will not compile. The correct code is: std::map<Vertex,Vertex> vertex_map; boost::bind( boost_make_associative_property_map< std::map<Vertex,Vertex> > , vertex_map ) map_maker; boost::prim_minimum_spanning_tree( graph , map_maker() ); It took me quite a while to realize a mistake I made like this. I'm sure others will commit the same sort of mistake as well. Would it be too much for the Boost.Bind documentation to provide a note of caution with regard to function templates? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: compressed_pair requirements?
by JOAQUIN LOPEZ MU?Z 27 May '05

27 May '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Mayo 27, 2005 7:47 pm Asunto: Re: [boost] Re: compressed_pair requirements? > Howard Hinnant wrote: > > > 2. Uninitialized is better because it is much faster, > especially if > > you have containers of such elements. You can always explicitly > > initialize if you want. > > Technically... you can't put an uninitialized (non-character) > scalar in a > container; copying an uninitialized scalar is undefined behavior. > A similar issue also renders the following snippet illegal (unless someone has filed a DR): typedef set<int> int_set; pair<int_set::iterator,int_set::iterator> p; According to 20.2.2.2, the default ctor of std::pair works as if implemented like pair():first(int_set::iterator()),second(int_set::iterator()){} and int_set::iterator(), being a singular value, cannot be copied. A technical nitpick save for the fact that I actually was once static asserted by an overzealous checked STL implementation (don't remember which, I think it was Comeau). IMHO, std::pair default ctor should be defined as pair():first(),second(){} Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[property_map] Template parameter disorder
by Cromwell Enage 27 May '05

27 May '05

According to <http://www.boost.org/libs/property_map/iterator_property_map.html>, ValueType and IndexMap should be the third and second template parameters, respectively. Should <boost/property_map.hpp> be fixed to match its documentation? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0