- Boost - lists.boost.org

autolinking and serialization status
by Robert Ramey 28 May '05

28 May '05

Just in case anyone's interested: I've been struggling to reconcile the problem whereby including a header from boost/serialization/* provokes the autolinking code to request that one of the serialization libraries be included in the link. The problem is that this library is requested even though there are no pending undefined symbols. So what works fine without autolinking - no missng symbols so the serialization*.lib is not needed fails with autolinking where the library is requested even though it contains no undefined symbols. This shouldn't add any code but it is a pain in the neck to require a library when it is really not needed. I'm still working on this - but it turns out harder than it looks for reasons that are too tedious to go into here. Robert Ramey

2 1

RE: [boost] Re: IDE projects/extensions to support Boost.Build
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 Shishir Ramam > Sent: Friday, May 27, 2005 11:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: IDE projects/extensions to support Boost.Build > > On 5/27/05, Andrey Melnikov <melnikov(a)simplexsoft.com> wrote: > > Reece Dunn wrote: > > > David Abrahams wrote: > > > > > What is really needed is a project-generation toolset so you could do > > > something like: > > > > > > bjam release debug msvc-project-7.1 > > > bjam release eclipse-3.0 # release only project files > > > > > > And you end up with the requested project/solution files. I will have > a > > > go at writing such a toolset. > > > > Is it really needed? Earlier in the street Reece proposed two > > *alternative* solutions: > > > > * conversion tool to convert to your favorite IDE format; > > * hook-ins to allow BBv2 projects to be managed in your favorite IDE. > > > > > > P.S. Can anyone look at BCB/CW extension capabilities and find the > > easiest way to get them supporting Boost.Build projects? > > Why not generate CMake (http://cmake.org) input from bjam? > It seems to work well from my limited experience on VC projects and > Makefiles. > > Support exists for Borland and various Visual Studio flavors. > XCode and CodeWarrior seem to in the works. > > Other pros: It's open source, and support from developers on the list has > been > excellent in my experience. > > -shishir [Brian Braatz Writes:] Interesting thought, though what is fuzzy for me is the value of using CMAKE over Bjam. (Cmake appears to take a mini-dsl lang to generate specific make files- whereas bjam, concepeptually seems to do this internally) (<< please don't flame me if I have this wrong :) ) What I do: I have a SED script with vcproj file templates and generate solution files for VC70,VC71, and VC80. If all of your targets are of the same type (i.e. console application), this works reasonably well. Example: C:\temp>MakeBoostTest Me Creating .\Me Creating .\Me\_Prj Creating .\Me\_Prj\MsVc_V71 Creating .\Me\_Prj\MsVc_V70 Creating .\Me\_Prj\MsVc_V80 Creating .\Me\_Prj\DevCpp_V4991 Generate cpp file at .\Me\Test_Me.cpp Generate project file at .\Me\_Prj\MsVc_V70\Test_Me.vcproj Generate project file at .\Me\_Prj\MsVc_V71\Test_Me.vcproj Generate project file at .\Me\_Prj\MsVc_V80\Test_Me.vcproj Generate project file at .\Me\_Prj\DevCpp_V4991\Test_Me.dev Generating cvsadd bat file cvsadd_Me.bat The "TestMe.cpp" is a console app which is all setup for building against boost test. (attached to this mail) All the user has to do after typing "MakeBoostTest" is open the appropriate proj file in the IDE and start typing. I would be happy to share the vcproj files I use, and the SED scripts which generate these. This could be used to generate vcproj files (and any other ide from any other vendor). In MY shop we are not yet jusing Boost.build. Eventually we will get there. Most of my developers work straight out of the MSVC ide. I eventually want to bring in Boost.build and use it for our projects and I eventually want to make this generation script also spit out bjam. In the FAR off future, I would like to build a tool which lets me generate a .vcproj file FROM a JAMFILE and vice versa. The JAMFILE is nice for running tests against multiple compilers, the vcproj file is nice inside because that is what our people work out of. If anyone is interested I will share these scripts.

1 0

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