- Boost - lists.boost.org

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

[test lib] request for new features
by Thorsten Ottosen 27 May '05

27 May '05

Hi Gennadiy, I would like to see these functions added to the test library: BOOST_CHECK_NOT_EQUAL(x,y) BOOST_CHECK_NOT_CLOSE(x,y) and any similar functions that makes sense. I don't see how we can get the variables printed in the failed test without these functions. Thanks Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 7

build from cvs, what is ICU_PATH?
by Neal Becker 27 May '05

27 May '05

I'm trying to build from cvs on Linux. Here's what I get: PYTHON_ROOT=/usr PYTHON_VERSION=2.4 bjam -sTOOLS=gcc stage ****************************************************** Building Boost.Regex with Unicode/ICU support disabled. HINT: define the environment variable ICU_PATH to point to the root directy of your ICU installation if you have one. Couldn't find utypes.h in ****************************************************** locate utypes.h /usr/include/schily/utypes.h Is this what it wants? How to I use it?

3 2

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

27 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Loïc Joly > Sent: Thursday, May 26, 2005 2:23 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Customer Friendlier Boost Installation > > Paul A Bristow a écrit : > > > Recently we had a flurry of discussion of why Boost is not more > widely used. > > > > I have used some bits of Boost happily for years, but recently I felt > I had > > to use it 'properly' so concluded it was time I used the bjam build > system - > > something I had felt looked a bit clever. > > > > > <SNIP> > > * 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. > > -- > Loïc [Brian Braatz Writes:] Thank you for also suggesting that. Somewhere, someplace, an angel just got his wings.. :)

2 1