- Boost - lists.boost.org

true64cxx regresion reports
by Fernando Cacciola 10 Oct '04

10 Oct '04

Hi, While adding failure markups, I noticed that the Optional library is shown as failing with true64cxx. However, looking at the error I can see that it is using an older version of the library (one which indeed is defective) I'm also seeing similar results for this toolset and the Numeric Conversion Library Can anyone fix this? TIA Fernando Cacciola SciSoft

4 7

The Concept Traits Library: naming - opinions sought
by Terje Slettebø 09 Oct '04

09 Oct '04

Hi all. In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious. The library will be put in a CVS at the http://www.neoscientists.org/ server, and we're not sure how to deal with the maximum filename length. The current directory structure is, e.g.: #include <boost/concept_traits/std/is_default_constructible.hpp> #include <boost/concept_traits/std/is_random_access_container.hpp> #include <boost/concept_traits/std/is_random_access_iterator.hpp> #include <boost/concept_traits/std/is_generator.hpp> Tobias suggested the following (the "model" part is still not decided, and may be considered separately): #include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp> The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>. To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there. The same goes for PP-lib. However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject. What do you think? Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits) and "utility" (for components to define new traits), so "model" might more clearly separate out that these are the concept traits, themselves. Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular). Regards, Terje

6 11

Re: [boost] Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 09 Oct '04

09 Oct '04

In-Reply-To: <ck6la2$kki$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > Conclusion: disallowing 0 will not only lead to simpler, safer > programs, but it will probably also boost performance. The null object pattern can only be used if all the object's member functions have trivial post-conditions. If instead I have code like: dog.walk_to( pTree ); assert( dog.location() == pTree ); // ... more code assuming the dog's location. then it is not going to work with a null_dog. If people use it anyway there will be tears before bedtime. Of course, this is no more an argument against ptr_vector<Dog> than it is against std::vector<Dog>. I think the problem here is the name. "ptr_vector" sounds so much like a vector of pointers that people expect null pointers to be supported. There is a gap between what those people want and what ptr_vector supplies. The null object pattern is not a solution here. It just papers over the crack. -- Dave Harris, Nottingham, UK

2 1

shared_object
by Andy Little 09 Oct '04

09 Oct '04

Hi, Any interest in a shared_object? In this case its the object that is shared, not the pointer.... Nah... too obvious ;-) regards Andy Little

3 5

Trial history file; error in Boost CSS file
by Daryle Walker 09 Oct '04

09 Oct '04

I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? Pretend that the file is at 'BOOST_ROOT/more/version_history.html'. The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. The problem is in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: <p>Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah.</p> That way people who need the default space-collapsing attribute of CODE (like me) don't get screwed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[review] Formal review of the Smart Container library starts today
by Pavol Droba 08 Oct '04

08 Oct '04

Hi all, The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

13 57

people page
by Fernando Cacciola 08 Oct '04

08 Oct '04

Hi, Should mantainers of released libraries (like me) add themselves to the people page, or we need to be explicitely invited for this? And in that case, should we upload ourselves the photos or should we send them to one of the moderators instead? TIA Fernando Cacciola SciSoft

4 7

Re: Removing dots from toolset names
by Aleksey Gurtovoy 08 Oct '04

08 Oct '04

Jürgen Hunold writes: > Hi ! Hi Jürgen, > > On Tuesday 05 October 2004 15:10, Aleksey Gurtovoy wrote: > > Hi All, > > > > As you probably already know, we also need to take care of these: > > Why ? Can someone point me to the rationale for this ? The original rationale was "to ensure file and directory names are relatively portable": http://www.boost.org/more/lib_guide.htm#Directory_structure. Beman might be able to clarify whether ISO 9660/Level 2 requirements in particular were one of the motivating factors back then or not, but currently those are the primary driving force for getting Boost codebase to conform to these rules: We want to be able to put a Boost distribution on a CD in the unpacked form, and for that CD to be readable on the maximum number of platforms. > Where can I find out which platforms have which limits ? WWW :). Here, for instance -- http://www.zplace.com/crashtips/filename.html. > > > intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars, filename > > contains more than one dot character ('.') intel-win32-7.1-vc6-tools.jam: > > Some of these toolsets exist in current 1.31.0 with _more_ than one dot. > Take vc7.1-stlport-tools.jam for example. Sure. The requirements weren't strictly inforced until now. > > > I suggest we either replace the dots with underscores, or get rid of them > > completely (besides the last one, of course), i.e. either: > > > > borland-5_5_1-tools.jam > > borland-5_6_4-tools.jam > > como-win32-4_3_3-vc7-tools.jam > > -1 > > > borland-551-tools.jam > > borland-564-tools.jam > > como-win32-433-vc7-tools.jam > > ... > > Preferences? > > +1 Thanks! > > > [I also know that there is more to this than just renaming of the files; > > any help with the whole matter would be greatly appreciated.] > > Just one curious question: > AFAIK, all of the platforms these toolsets are _for_ support both filenames > with more than 31 characters and more than one dot. > I just wonder if we should break and repair the whole V1 build system when > the offending toolsets are for platforms which don't _have_ these limits. The changes are not that drastic, but it's a reasonable question to ask. Ignoring the fact that we already have nonconforming names fixing which requires some work, IMO all the current requirements except 31-character limit are not hindering us in any significant way, are easy to satisfy, and in general have a good cost/benefit ratio. I don't feel strongly about maximum length of 31, in particular since MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the limit. Being able to read a Boost CD on, let's say, Linux versions released before 1999 is definitely going to be appreciated by _somebody_, but there is a certain cost to that, and personally I'm starting to feel that may be it's not worth it. But then, as a release manager who has to take care of this issue, I'm biased. > > Just my .02€, developing on linux and win32. Thanks, they are appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering

3 3

Re: Removing dots from toolset namesHo
by Aleksey Gurtovoy 08 Oct '04

08 Oct '04

Jürgen Hunold writes: > On Wednesday 06 October 2004 17:35, Aleksey Gurtovoy wrote: > > The changes are not that drastic, but it's a reasonable question to > > ask. Ignoring the fact that we already have nonconforming names > > fixing which requires some work, IMO all the current requirements > > except 31-character limit are not hindering us in any significant > > way, are easy to satisfy, and in general have a good cost/benefit > > ratio. > > > > I don't feel strongly about maximum length of 31, in particular since > > MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the > > limit. Being able to read a Boost CD on, let's say, Linux versions > > released before 1999 is definitely going to be appreciated by > > _somebody_, but there is a certain cost to that, and personally I'm > > starting to feel that may be it's not worth it. But then, as a > > release manager who has to take care of this issue, I'm biased. > > I've got this impression, too. > > My old PPC-6100-Mac is rotting in a corner ... ;-((( > > I don't want to spoil the release, but did you take a look at the > BoostBook generated docs ? > At least BBv2 generates files like > "bbv2.reference.buildprocess.alternatives.html" Yep, I'm aware of the issue. Or, rather, I was aware. It's taken care of now -- http://article.gmane.org/gmane.comp.lib.boost.documentation/661. > This will not work when someone tries to ship pre-built documentation on > pure ISO-9660 CD, either. > And I thought that a release tarball should contain a pre-built > documentation because no-one can be expected to install all the > necessary components to build it. Yep, it should and it will. > Do you/we want to change this, too ? > And have *lots* of cryptic, human-unreadable file names ? Well, the name length is still partly an issue, but certainly not to the extent it was before the subdirectories fix. And even the overly long names don't necessarily have to be turned into cryptic ids. For instance, something like "static_local_time_adjustor.html" doesn't have to become "id413791.html"; it can be "static_local_time_adjust00.html", or "static_local_time_00.html", or something else along these lines. Having said that, I'm going to repeat myself -- while I think all other requirements are worth sticking to, I don't feel strongly about keeping the 31-character limit. But now that we have not that many names to fix, it's tempting to go with it to the end at least for this release. > When we discuss this further, we should do it on Boost-Mailing-List Transferred; Cc'd to jamboost. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:Re: [boost] [serialization] test_level_class_info_load*...
by Robert Ramey 08 Oct '04

08 Oct '04

< .... Thank for a very clear and concise explanation to something that is just about impossible to understand. >The solution I suggested before does the dependency: ><directory>test_*_load_*.test --> <->test_*_save_*.test >Which make that last line of the DAG above: >test --> *.test -> *.run -> *.exe, *.obj, etc -> *_load_*.test directory >-> *_save_*.test >Make sense? More or less. If I understand this correctly, then on a second run if the directory is already created, the desired dependency won't be enforces. That is the following scenario won't work a) test_..._save builds but fails at runtime. This creates all directory structures for test...save. b) test...._load will build and run but will fail because test...save failed to create an temporary file that test...load needs. >PS. If you are sure you are only going to have run tests. You could do >things like: >local test-part-2 = [ test-bsl-run_files test_class_info_load ] ; >local >test-part-1 = [ test-bsl-run_files test_class_info_save ] ; >DEPENDS $(test->part-2:S=.run) : $(test-part-1:S=.run) ; Actually I think this latter is more a kin to what is required. The dependency is that test..save must be executed successfully to create the appropriate output file to test the run of the corresponding test...load. Even if the test..save fails to build or run, it is valuable to build (though not run) to check for compilation and linkage errors) Your explanation has motivated to spend a little time with this. Robert Ramey

1 0