February 2006 - Boost - lists.boost.org

Re: [boost] [Release 1.34] Supported Compilers - another view
by Robert Ramey 03 Feb '06

03 Feb '06

I've come to believe that the huge amount of discussion regarding how compilers should be classified is another symptom of the (excessively?) close coupling of boost libraries. The first symptom is the disproportionate amount of effort required to make a new "release" which has been discussed on another thread. With a couple of caveats noted below I see no reason why all libraries have to support the exact same set of compilers at the same level. As an example consider a couple of libaries. spirite and lambda - these absolutley depend upon high compiler conformance. Anyone seriously interested in using tools like this and the techniques they embody will not be using msvc 6.0 . Demand and utility of msvc 6.0 for these libraries approaches nil. smart_ptr, iostreams and others. These have wide applicabilty and probably demand for those using MSVC. I'm sure that the developer of smart_ptr suffered with MSVC 6.0 - but its over now and I doubt that just keeping it up is a big problem. I suspect that msvc 6.0 compatiblity for iostreams issn't too bad. All in all I think its fine that each author decide what level of support to give each compiler. The current test system permits a compiler to be marked as supported/unsupported on a library by library basis. This is just fine. Of course library authors and the review process will have to resolve what level of support is appropriate for each combination of library and compiler. I just don't see how there is anyway to agree blanket policy "compiler X is supported/deprecated" etc. So now it comes down to individual libraries. The only time this comes up as a boost wide issue is for libraries which are used by other boost components. The current case is that of Boost Test. Lets consider this library in particular. Boost Test is used by ALL libraries in boost to test themselves. For it to be an effective in this role, it must be usable with any compiler that is supported by any library. This is not a suggestion or normative statement. Its just a recognition of the fact that it can't do the job it has been doing if it doesn't support older compilers. So Boost Test should be structured so that it doesn't break old tests. It can add new features that are supported only in new compilers but it should be able to continue to provide the support it has in the past. I realise that this is an extra burden that other libraries don't have to shoulder and maybe its not "fair" but it is part of the requirement for Boost Test to continue in its fundamental role in boost. A couple of random observations re boost test. It has been a fundamental contributer to a big change in the way I do my programming. It deserves full credit for that. I'd read the "continuous testing" mantra and believed it in theory - but without a fully implemented test sytsem with good documents to teach me how to do it and make it easy to do I wouldn't have been converted. I suspect that my experience is common in this regard. Boost Test is special it has to be almost universal in order or full fill its extremely important and special role in boost and in C++ development in general. I appreciate that the author of Boost Test thinks its a pain in the rear to address the "old compilers" but he is too modest in appreciation of his own work and I'm sure that if knew how important it really has been and he would just say "$%%&%&*" OK and accept his lot and keep it widely compatible. I think that boost test is plenty sophisticated an complete feature wise. Maybe too much - which is what might be creating the compatiblity issues. The main obstacle to "selling and promoting" boost test is that the documents need work to make boost test more obvious to a new user - (and to me as well). The perspective should be to "increase market penetration" of boost test rather than "increase functionality" of boost test. In my view, lack of ease of use is currently a larger obstacle to "increasing market penetration" than limited feature set and this is where effort should be invested. An and another thing. It damn annoying to find that all my tests suddenly fail on msvc because of a change in the test system. Oh I'm sure it was announced somewhere and I don't care - its annoying none the less. Now what am I to do? Stop supporting msvc? Shouldn't that be my decision? Re write my tests to not use boost test? I don't want to do that! Finally, I managed to get the serialization libraries test to work with comeau by commenting out some of boost test. unit_test_parameters.ipp // const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, argv ); // s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned int>( rs_str ); This apparently instantiates some basic_stream template that the serialiation library also instantiates. The comeau 4.3.3 prelinker complains about this - which I don't thnk it should - and build of serialization library fails. Commenting this out permits the serialization libary to be tested with comeau. Robert Ramey

13 58

pd darwin Symbol not found
by Locatelli Jérôme 03 Feb '06

03 Feb '06

I'am writing a application on MacOS 10.4.4 using darwin 8 with gcc 4, I compile and link my application without problem but when I run my application , I've got the error bellow. Has anybody got an idear?? Thanks. dyld: lazy symbol binding failed: Symbol not found: __ZN5boost6detail3tss4initEPNS_9function1IvPvSaINS_13function_baseEEEE Referenced from: /Users/locatelli/Projets/ics/IcsServer/obj.ics/../lib/ libIcsServerCommandSystem.0 Expected in: flat namespace dyld: Symbol not found: __ZN5boost6detail3tss4initEPNS_9function1IvPvSaINS_13function_baseEEEE Referenced from: /Users/locatelli/Projets/ics/IcsServer/obj.ics/../lib/ libIcsServerCommandSystem.0 Expected in: flat namespace Trace/BPT trap --------------------------------------------------- Locatelli Jérôme Institut Laue-Langevin Service Contrôle des instruments 6 rue Jules Horowitz, BP 156 38042 Grenoble cedex 9 http://www.ill.fr/ Tel: 33 (0)4 76 20 76 27 Fax: 33 (0)4 76 20 77 00 ---------------------------------------------------

1 0

Using Boost with C++/CLI?
by Paul A Bristow 03 Feb '06

03 Feb '06

Prompted by http://www.octopull.demon.co.uk/editorial/N8037_Objection.pdf, I have been trying to assess the potential impact of Microsoft C++/CLI on my projects which use many bits of Boost code. How much of Boost, if any, can be compiled and used with the /clr option in force? Perhaps others can give their experience & expertise to help guide me? Some advantages of C++/CLI are pretty obvious, but what are the gotchas? Thanks. Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

7 8

Re: [boost] Why use Boost?
by David Maisonave 02 Feb '06

02 Feb '06

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:<uvevxlggc.fsf(a)boost-consulting.com>... > "David Maisonave" <dmaisonave(a)commvault.com> writes: > > > I think there would be 10 times more boost users, if the boost > > developers put the same quality into the documents, as they do into > > the code. It would also help developers, if boost had a really GOOD > > template to do this, and it would serve as a check list for > > required/recommended documentation. > > > > What's the point of creating a great class, if only a handfull of > > developers ues it, because the majority have no idea how to use it? > > A short while ago we created the position of Boost Documentation > Wizard to help address this issue > (http://lists.boost.org/Archives/boost/2005/09/93946.php) > (http://lists.boost.org/Archives/boost/2005/10/96025.php) > Unfortunately, I think Rob Stewart just became too busy to make the > contribution he wanted to. Perhaps you'd like to step up? Actually, I would rather invest the time in creating an automated documentation wizard.

2 1

Re: [boost] Why use Boost?
by Matt Doyle 02 Feb '06

02 Feb '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of David Abrahams > "Matt Doyle" <mdoyle(a)a-m-c.com> writes: > > > A potential new user needs a way to find out what exactly is in > > boost. Right now if I want to solve a particular problem and I don't > > know which library to use, I basically have to drill down through > > the list and read the overview for each one. > > What would you propose as a better system? Well, I don't know if there is a silver bullet. I guess I would propose a section that could become a repository of "real life" examples. Not too far from the "who's using Boost" idea, have an area where users can upload examples of problems they had that Boost helped them solve. It would also serve Nigel's idea of a Boost cookbook. A solution center where people can come looking for ideas. Now I hear the question - how is digging through a solution repository better than digging through the docs? Human nature perhaps? As likely as not finding and implementing the right tool for the job is going to take changing your pre-conceived approach to some degree. If your pre-conceived approach is that problem must be solved using method A then it's unlikely you look at the correct one (B). But, now if you see a problem the look just like yours, and it's being solved with method B, not A, then the pre-conceived notions (hopefully :) go out the window. How's something along those lines sound? > > > Even then there's no guarantee that you'll find "the right > > thing". Would I have found explicit cast this way? Nope. > > Maybe because there is no boost::explicit_cast? oops, it obviously s/b implicit. My fingers don't always know what my brain is thinking :/ Scanned by McAfee GroupShield {X3BTB534}

1 0

Re: [boost] boost polling?
by Martin Bonner 02 Feb '06

02 Feb '06

From: David Maisonave > The poll results were suprising. I was responding specifically to the implication that it was suprising that the percentages added to >100%. > I would have thought by now there > would be more developers using 7.1/8.0 than 6.0. > If Boost decides to stop supporting VC++ 6.0, or reduce support, than > they're going to exclude at lot of developers. Not really. Changing boost library version is probably less painful than changing compiler version, but I wouldn't do either without compelling reason. VC6 users can use boost 1.33.1 (or perhaps even 1.34), and that isn't going to suddenly stop working just because 1.35 doesn't support VC6. Remember that although most developers are using 6.0, they are almost certainly using it on projects which are in maintenance mode. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

4 3

Re: [boost] Why use Boost?
by David Maisonave 02 Feb '06

02 Feb '06

"Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote in message news:<drtp38$3tu$1(a)sea.gmane.org>... > > "David Maisonave" wrote > > > What's the point of creating a great class, if only a handfull of > > developers ues it, because the majority have no idea how to use it? > > You cant escape the fact that writing documentation is the most > tedious, rotten, boring, miserable, mind-numbing job imaginable ***. > Thats why so much documentation is bad or non-existent. Thats why some > library is "nearly finished" after even a couple of years "except for > the documentation", which is going to be started "very soon now" Personally, to me the hardest part of doing documentation, is getting it started. Once I do get it started, the rest is not so painful. That's why I think it's important to have a really good template that can give developers a good starting point. One that can be a fill in the blank type.

1 0

Boost test tools using static library - operator new link problem
by Paul A Bristow 02 Feb '06

02 Feb '06

In release mode (debug to libboost_unit_test_framework-vc80-mt-sgd-1_34.lib is OK, and dll debug and release libs also OK) Compiling... test_tools_test.cpp Linking... libboost_unit_test_framework-vc80-mt-s-1_34.lib(exception_safety.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj) I:\boost-06-01-13-0500\libs\test\build\msvc71_proj\Release\test_tools_test_s tatic.exe : fatal error LNK1169: one or more multiply defined symbols found Suggestions about what I am doing wrong? Thanks Paul PS Trying to avoid transition to monitor defenestration mode ;-) -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

4 8

[bug] Error in optional's converting assignment operator
by Joe Gottman 02 Feb '06

02 Feb '06

There is an error in the implementation of the converting assignment operator for optional<T>. It is currently implemented as template<class U> optional& operator= ( optional<U> const& rhs ) { this->assign(rhs.get()); return *this ; } The problem with this is that if rhs is not initialized then rhs.get() asserts. This function should be rewritten as template<class U> optional& operator= ( optional<U> const& rhs ) { if (rhs.is_initialized()) this->assign(rhs.get()); else destroy(); return *this ; } Joe Gottman

3 4

[shmem] Shmem version 0.9 available
by Ion Gaztañaga 02 Feb '06

02 Feb '06

Hi boosters! I've just uploaded the latest stable version of Shmem to boost sandbox vault (http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo…) and boost sandbox cvs HEAD. This version finishes development changes previewed with the beta version posted the last day of December. Online documentation is available also as always here: http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html I would be glad if usual Shmem users could test it to see if there are portability problems, since I've tested it in linux/gcc-4.0.1 winxp/vc7.1. This version includes since the latest stable version (2005-10-12): -> Architecture and interface rework to allow future multi-segment shared memory support. -> Bug fixes and portability enhancements. -> Shmem iostreams to write/read formatted data directly to/from shared memory vectors/strings and memory buffers. -> Intrusive and scoped ptr for shared memory (I promise shared_ptr/weak_ptr for future versions, they are not ready yet). -> Better documentation, thanks to user suggestions. Enjoy! Ion P.D.: I can't login with my older "ion_g_m" account to sandbox vault. Would someone please delete files with "ion_g_m" username from Memory directory? Thanks.

4 7