- Boost - lists.boost.org

quickbook formatting problem
by Arkadiy Vertleyb 29 May '05

29 May '05

Hi all, I am now having a problem formatting the source code in the quickbook. As documentation suggests, I put tab in front of the source code, and it appears preformatted in the browser, however there is no syntax hilighting nor gray backround. What could be wrong? Thanks, Arkadiy

7 16

Regression gone
by Victor A. Wagner Jr. 29 May '05

29 May '05

The regression page is missing "page not found" and has been for a while. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

lexical_cast with default value
by Dave Dribin 29 May '05

29 May '05

Hi all, I recently discovered lexical_cast, and it's very nice and elegant. I'd like to put in a feature request, though: the ability to use a default value rather than throwing an exception on conversion failure. Basically, it would take a second argument that would be the value returned if the conversion fails. This could be used directly in the example, like: std::vector<short> args; while(*++argv) { args.push_back(lexical_cast<short>(*argv, 0)); } This eliminates the throwing and catching of an exception for cases where conversion failure is not an exceptional. I've attached a patch to lexical_cast.hpp found in Boost 1.32.0 -Dave

6 18

Documentation error?
by Raz 28 May '05

28 May '05

I was looking in the Boost Assignment library and I noticed this code under the "Function operator+=()" heading: [CODE] #include <boost/assign/std/vector.hpp> // for 'operator+=()' #include <boost/assert.hpp>; using namespace std; using namespace boost::assign; // bring 'operator+=()' into scope { vector<int> values; values += 1,2,3,4,5,6,7,8,9; // insert values at the end of the container BOOST_ASSERT( values.size() == 9 ); BOOST_ASSERT( values[0] == 1 ); BOOST_ASSERT( values[9] == 9 ); } [CODE] Shouldn't the last assertion be BOOST_ASSERT(values[8]==9)? Unless my brain is tricking me, the last element in the container should be at the 8th slot. -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 2

Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs)
by JOAQUIN LOPEZ MU?Z 28 May '05

28 May '05

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Sábado, Mayo 28, 2005 8:06 pm Asunto: Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs) > On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote [...] > > I don't see this change as "breaking code" but rather detecting > code > > that is very likely already broken. > > > > So, as I said, its not that I'm unsympathetic to your point of > view, > > I just don't think everyone is sympathetic to mine. > > Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I > don't think > that Vladimir, myself, or the others that have posted on this > topic are > convinced that this change is really going to prevent people from > making the > error you are concerned about. For the record, not that I'm in love with the stricter const rules either, but I must confess that, when hit by them the first time, they actually uncovered a (potential) problem in my test code. So... I've been thinking about this issue, and my impression is that regular code won't be hit as much as one might think. Typically, serialization is used like this in a program: class my_class { // add serialziation capabilities }; void save(const my class&) { // some file-opening work prior to actual saving ... } void load(my_class&) { // some file-opening work prior to actual loading ... } A typical program will have a centralized point of usage of serialization, and the usual const-abiding rules won't collide with Boost.Serialization. Now, a test program like the ones we've been writing to check the serialization capabilities of our libs is more likely to follow this pattern: std::ofstream ofs(..); archive::text_oarchive oa(ofs); my_class_1 c1; ... my_class_n cn; ... oa<<c1; ... oa<<cn; std::ifstream ifs(..); archive::text_iarchive ia(ofs); my_class_1 cc1; ... my_class_n ccn; ... ia>>cc1; ... ia>>ccn; BOOST_CHECK(c1==cc1); ... BOOST_CHECK(cn==ccn); and here we *do* run into the const problem. The key difference is that, in the latter pattern of usage, we are creating local classes just to check whether they're properly archived and restored. In a real program, the serialization code is typically provided a class to archive from the outside, as serializating classes created on the fly doesn't make much sense after all. Get my point? So, to sum it up, although I think stricter const rules won't prevent as many problems as desired, I think most users won't notice anyway. We lib testers belong to a different flock. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

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