- Boost - lists.boost.org

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

03 Feb '06

"Paul Giaccone" <paulg(a)cinesite.co.uk> wrote in message news:<43E1D46C.7000500(a)cinesite.co.uk>... > There is a thread on the Boost-users mailing list at the moment asking > what users needed to know when they got started with Boost. > > One of the points raised is that, while pretty much all users of Boost > think it is great, they didn't know when they started using it why it > was so great and why it would be to their advantage to use it. One of > the reasons for this is that the front page of the website does not > really sell the product. > > I agreed with this point. Here's a summary of my posting: > > "What the site needs, in my view, on the front page is some sort of > material selling Boost. Why was Boost set up in the first place? I totally agree 100%. IMHO, for the most part, the site is setup as if users already know about boost. Most of the help documents seem to be targeted for more advanced C++ programmer. They make no real attempt to sell the library. Although I knew about boost for a long time, I didn't start using it until recently, because I was under the impression, that I would need to add additional *.cpp or lib files to my project in order to use boost. I also thought my binary would increase substantially if I linked to boost just to use a specific object like boost::shared_ptr. IMHO, the help documents waist too much space in giving details that really don't help the average user to figure out how to use an interface. Take intrusive_pr document for an example: http://www.boost.org/libs/smart_ptr/intrusive_ptr.html There's no example usage at all. It waist a lot of space giving details Synopsis and Members, but very little space for an introduction, or a good explanation on how to use it. As a user, why would I care about the Synopsis or Members, if I can't figure out how to use the interface. There should be more focus on introduction and example usage, and less focus on Synopsis and Members section. Moreover, IMHO, in Members section, each member should have an example usage. Take a look at weak_ptr http://www.boost.org/libs/smart_ptr/weak_ptr.htm Look at the members section for lock and rest. There's no usage example and no explanation of their purpose. Why would I care that it throws nothing, if I don't know what it's for. 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?

7 13

1.34 Release Plan
by Thomas Witt 03 Feb '06

03 Feb '06

Hi, with 1.33.0 now five months old it is time to get the 1.34.0 release going. Well to be honest it's probably more than time. In order to improve our release process we are planning to adopt a staged release process that is modelled partly after the gcc release process. By and large it can be seen as a formalization of things already done in past releases. A description of the different stages will be given at the end of this mail. But lets get the important issues out of the way first: schedule. I think that we have enough features in CVS already to make 1.34 worthwhile. For that reason the main focus for 1.34 will be a release within reasonable time. For that reason I am going to aim for a feature freeze (Stage 3) in two weeks from now. I ask anybody who can not make that deadline for one reason or another to contact me directly and we try to figure something out. Furthermore for this release feature freeze will also be the cut off date for addition of new libraries. I am planning to flesh out the further schedule in a few days once I got an idea how we are doing with the feature freeze. Thanks Thomas Boost Release Procedure (by Doug Gregor) ==================== Boost development for each release will be divided into four stages, influenced by the GCC development model. The stages move from a very loose, open development model where major changes can be made toward a much more tightly-controlled model as the release date nears. Release managers are appointed for the duration of the release process for a particular version of Boost, and several Boost versions may be in progress at any point in time. However, actual release dates will be staggered to allow testing resources to be allocated to the most imminent release. Stage 1 - Open Development -------------------------- Major changes to libraries or infrastructure may be performed, including large updates or additions to core libraries (e.g., type traits) and tools (e.g., Boost.Build). New libraries and new features can be added freely. Stage 2 - Intracomponent Open Development ----------------------------------------- This stage restricts Stage 1 slightly by banning far-reaching changes to Boost. Major changes to libraries or infrastructure, or the addition of new features and libraries, can be made in the stage. However, the changes must be limited in scope and may not have far-reaching affects. For instance, the build or regression testing systems in Boost cannot be changed at this point, and Boost libraries on which other major components of Boost depend (such as MPL, Type Traits, and Config) may not have large interface changes or be fundamentally rewritten. The Release Manager has final say regarding the classification of changes as "far-reaching" or not; if you are unsure, please ask. Stage 3 - Feature freeze ------------------------ This stage is a bug-fixing stage. Bug fixes may be freely applied to Boost, even if they require substantial changes. Interfaces may not be changed (unless required to fix bugs) and new features should be added only sparingly and with Release Manager approval. New libraries may be introduced at this stage with Release Manager approval, but the introduction of new libraries is tentative: if the new library fails a significant number of its regression tests, it will be removed from the release. Stage 4 - Release preparation ----------------------------- Only bug-fixes and documentation changes may be applied, and the changes should be as minimal and as safe as possible. If a change is large, or has the potential to cause additional failures, consult the Release Manager before applying the change to the repository. Changes that cause failures will be reverted after 48 hours if the failures are not addressed to the Release Manager's satisfaction. The beginning of stage 4 will be marked by the creation of a new CVS branch for the release. At this point, the old CVS branch falls back to stage 1 (for major releases, e.g., 1.XX.0) or stage 3 (for minor releases, e.g., 1.XX.Y). Final Freeze ------------ 7 days prior to a release, the Release Manager will call for a final freeze on the CVS branch corresponding to the release. At this point, no changes may be made to the branch with explicit Release Manager approval. Post-Release ------------ After a release is made, the changes made on the release branch should be merged back into its parent branch. The release branch reverts to stage 4; should another minor release be scheduled on that branch, the Release Manager for that minor version may revert to stage 3 or remain in stage 4 until the point release is imminent. Thomas Witt witt(a)acm.org

22 77

Fwd: 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

Bind comparisons
by David Abrahams 03 Feb '06

03 Feb '06

Is it really true that I can write bind(f, _1) > _2 but can't write _1 > _2 ?? I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 25

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

03 Feb '06

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:<umzh9idhm.fsf(a)boost-consulting.com>... > "David Maisonave" <dmaisonave(a)commvault.com> writes: > > > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > >> 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. > > Great! Any contribution that you can make will have a huge impact. > What do you have in mind, if I may ask? I was thinking of a web based form. But I'm flexable

2 1

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