- Boost - lists.boost.org

Who's Using Boost?
by David Abrahams 06 Aug '05

06 Aug '05

I have two concerns about these pages: 1. They violate the library naming/branding conventions (http://www.boost.org/more/discussion_policy.htm#lib_names) 2. How shall we get http://www.boost.org/libs/python/projects.html integrated into it? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

CSS expert advice needed
by David Abrahams 06 Aug '05

06 Aug '05

It has frustrated me that footnotes are rendered in such extremely small type in the Parameter library documentation (http://www.boost-consulting.com/libs/parameter) but I can't tell what needs to change in the CSS to fix it. Can anyone help? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 16

Name polution with boost::type_traits
by Ivan Godard 06 Aug '05

06 Aug '05

May I suggest that the type_traits identifiers all be placed in a boost::type_traits namespace, with one indirect #include file to grandfather existing usage? The added file, say hide_type_traits.hpp, would include all the detail .hpp files the way that type_traits.hpp does now. The individual detail files would wrap each API declaration in "namespace type_traits{...}". The present type_traits.hpp would simply: #include "hide_type_traits.hpp" namespace boost { using namespace type_traits; } The effect is that current usage will still work if you include type_traits.hpp as at present, but those of us who want the type_traits names (bit not the rest of boost) in the file namespace can do a "using boost::type_traits;" to achieve that. What prompts this note is a desire to prepare for TR1 while continuing to support old compilers. We attempted to say (in a file included when using an older compiler): namespace std { #include "boost/type_traits.hpp" } so that the boost type_traits identifiers would appear in the std namespace under an old compiler just as they would in a compiler that implements TR1. However, this blows up because the boost type_traits library transitively includes other boost stuff it uses, and that stuff does *not* like to be in std :-) Of course, we could leave all the identifiers in the boost space and pick them out one by one with using statements; that's in fact what we are doing. But that means we have to track your library with our using's, a maintenance nuisance. Lastly, may I suggest that future libraries with lots of identifiers should routinely use a per-module namespace, like the mpl library does now? That would obviate this nuisance should the library later be standardized. Ivan

2 1

Boost regression notification (2005-08-05)
by Douglas Gregor 05 Aug '05

05 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-05T15:10:44Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 34 failures in 3 libraries: iostreams (1) serialization (32) thread (1) |iostreams| mapped_file_test: intel-win32-9_0 |serialization| test_list_binary_archive: cw-9_4 cw-9_5-darwin test_list_binary_archive_dll: cw-9_4 cw-9_5-darwin test_list_ptrs_binary_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin test_list_ptrs_text_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_text_archive_dll: cw-9_4 test_list_ptrs_text_warchive: cw-9_4 cw-9_5-darwin test_list_ptrs_text_warchive_dll: cw-9_4 test_list_ptrs_xml_archive: cw-9_4 cw-9_5-darwin test_list_ptrs_xml_archive_dll: cw-9_4 test_list_ptrs_xml_warchive: cw-9_4 cw-9_5-darwin test_list_ptrs_xml_warchive_dll: cw-9_4 test_list_text_archive: cw-9_4 cw-9_5-darwin test_list_text_archive_dll: cw-9_4 test_list_text_warchive: cw-9_4 cw-9_5-darwin test_list_text_warchive_dll: cw-9_4 test_list_xml_archive: cw-9_4 cw-9_5-darwin test_list_xml_archive_dll: cw-9_4 test_list_xml_warchive: cw-9_4 cw-9_5-darwin test_list_xml_warchive_dll: cw-9_4 |thread| test_thread: vc-6_5

3 2

[1.33.0] [Serialization] Important: cw-9_4 failures
by Douglas Gregor 05 Aug '05

05 Aug '05

Lots of Serialization tests are failing: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html We need to resolve these before we can release RC2. Doug

3 2

[Type Traits, BoostBook] Lots of BoostBook parsing errors
by David Abrahams 05 Aug '05

05 Aug '05

xslt-xsltproc ../bin.v2/doc/gcc-3.4.4/debug/boost.docbook file:///boost/tools/boostbook/dtd//boostbook.dtd:412: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" %DocBook; ^ Entity: line 1: %DocBook; ^ src/boost.xml:345: parser error : Entity 'eacute' not defined <firstname>Hervé</firstname> ^ src/boost.xml:346: parser error : Entity 'ouml' not defined <surname>Brönnimann</surname> ^ src/boost.xml:701: parser error : Entity 'auml' not defined <surname>Järvi</surname> ^ ... ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:123: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_void">is_void</link><phr ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:123: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:126: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_void">is_void</link><phr ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:126: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:142: parser error : Entity 'nbsp' not defined struct</phrase> <link linkend="boost_typetraits.is_pointer">is_pointer</lin ^ ../bin.v2/libs/type_traits/doc/gcc-3.4.4/debug/type_traits.xml:142: parser error : Entity 'nbsp' not defined ><phrase role="special"> :</phrase><phrase role="keyword"> public</phrase>  ^ .... -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[parameter] some typos in tutorial...
by Pavel Chikulaev 05 Aug '05

05 Aug '05

Hi David, There is a strange symbols in /libs/parameter/doc/html/index.html in section 2.6.2 after second function code with modifier <span class="doublesize">. Absolutely the same in 2.7.2 and 2.7.3... In section 2.8.3 "Mnemonics" note can overlap code in that section when page less than 800 pixels wide. It's better to use tables IMO there. -- Pavel Chikulaev

7 14

[Range] No Reply?
by David Abrahams 05 Aug '05

05 Aug '05

Thorsten Ottosen <nesotto(a)cs.aau.dk> writes: > Citat David Abrahams <dave(a)boost-consulting.com>: > > Hi Dave, > >> >> Thorsten, >> >> there are important issues here that go to the suitability of this >> library for generic programming. I notice there was no answer on the >> list. It's crucial that you deal with these questions eventually, and >> IMO it should happen before the 1.33.0 release. >> > > I'll see what I can do. My laptop was stolen two weeks ago, so > its hard for me to do any real work. Ouch! I'm sorry to hear that! > When is 1.33.0 going to be? I think we're hoping to do a prerelease candidate this weekend or Monday. > Anyway, here's the issues: I'm not sure that you quite "got" most of the concerns I raised. > 1. change XXX to boost::XXX. ok, I don't see any problem with this. I > could fix it monday. -------------- If you already understood everything I'm writing in this section delimited by dashes, please just tell me so and I'll relax. I'm not asking for you to simply change XXX to boost::XXX everywhere. To quote from my original posting: > | 1. What does it take to get support for standard containers as ranges? > | According to what I can see in the documentation, the standard > | containers don't satisfy the range concepts. IOW, > | > | begin(v) > | > | isn't valid when v is a standard vector. > | > | From what I can tell from browsing the implementation, the > | requirement should be: > | > | boost::begin(v) The problem is that the Range concept requirements, as you specified them, are not satisfied by standard containers. Therefore the standard containers are not Ranges. Since it is a goal of the library that the standard containers be Ranges, you need to fix the way you've specified the concept requirements. And as I said later in the post: > One should be able to look at a concept definition and understand > which types will model that concept. That concept > definition may of course lead you to look at the implementation of > other functions, but it has to let you get ahold of one end of the > string, so you can follow it to its logical conclusion. That's why > the concept definition should say that boost::begin(s) is a > requirement... and of course it should link(**) to the documentation for > boost::begin so the reader can find out what it takes to make that > function work, and deduce that it works for standard containers. -------------- I also said: > | and the default behavior of boost::begin needs to be documented. > > it's documented in another document. I provided linke to in in the > CVS version some time ago after you requrested it. And then I asked that you post a link (both to the page with the boost::begin documentation and to the page in the main docs that links to it), but I have yet to see a reply. > 2. swappable range: > > The page says: "Since ranges are characterized by a specific underlying iterator > type, we get a type of range for each type of iterator." > > that's the definition. Sorry, but that's not a definition of anything. > Is it so hard to grasp? It is easy to infer what you mean, if you're very familiar with the new iterator concepts. It's also very easy to misinterpret if you're not, because swappable iterator is a counterintuitive name. More importantly, as I suggested, there is no need to name these concepts (because you can just say "Requires: iterator<R>::type is a model of RandomAccessTraversalIterator," or whatever), especially not before they have been shown to be useful in specifying algorithms. There's no need to build a parallel and redundant concept hierachy. In fact, it's probably harmful to do so. > 3. Implementation of concepts. > > A type conforms to a concept, so ok, you can't implement it. Maybe a renaming > to "Implementations of types that concorm to Range concepts". ? I don't know what the right title is first try to answer the question I asked: You need to rename this page. What is it really describing? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 4. links from concepts to implementation. I'm not sure what you're referring to. > I remember I put some links when you asked for it. It should be > in the cvs code. In the code? I remember asking you to post some links. Or maybe you mean you fulfilled the request in (**) to put links in the documentation? Can you tell me where, on the boost-consulting CVS mirror, I can find that? > Do you want more links? I can't know until I can see what you've already done. > 5. containers and iterators. It should be explained in the introduction > that pairs and containers "just works". That is insufficient. The concept requirements have to be correct. And by the way, if you mean "This library therefore provides the means to adapt standard-like containers, null terminated strings, std::pairs of iterators, and raw arrays (and more), such that the same generic code can work with them all." then no, it doesn't make it clear that they "just work." It claims that the library gives me the *means* to make them "just work." So I'm left asking, "how do I do that?" Also, IIUC, this and other mentions of null terminated strings need to be removed now. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[1.33.0 RC1] libs/type_traits/docs/html needs boostbook.css
by Larry Evans 05 Aug '05

05 Aug '05

The html tables created by the Jamfile.v2 and type_traits.qbk in parent directory have no delimiters between columns and rows without a boostbook.css in the html directory. A copy of the boostbook.css from: libs/python/doc/tutorial/doc/html seems to work.

2 5

Fw: shared_array EXC_BAD_ACCESS
by Peter Dimov 05 Aug '05

05 Aug '05

I'm forwarding the following post from boost-users http://lists.boost.org/boost-users/2005/08/12938.php since it describes a pretty severe configuration problem on Mac OS X that apparently leads to inconsistent definitions of BOOST_HAS_THREADS and all kinds of interesting ODR violations. Christopher Hunt wrote: > OK, this is now completely solved. :-) > > Interestingly, boost/detail/lightweight_mutex.hpp was being included > in one place and declaring lightweight_mutex from > boost/detail/lwm_nop.hpp. However the implementation from > boost/detail/lwm_pthreads.hpp was actually being used. > > To cut a long story short, declaring a prefix file that forced boost > to configure itself prior to importing Cocoa and Carbon dependencies > completely solved the problem. Here's what my Cocoa pch file looks > like: > > // > // Prefix header for all source files > // > > #ifdef __cplusplus > #include <boost/config.hpp> > // Gets brought in early so that any > Carbon presence doesn't influence > // its configuration. > #endif > > #ifdef __OBJC__ > #import <Cocoa/Cocoa.h> > #endif > > If you're doing just Carbon, then do your #include <Carbon/Carbon.h> > after boost/config.hpp is included (in place of the #ifdef __OBJC__ > block). > > The real gremlin here is this bit of code in > boost/config/platform/macos.hpp: > > # ifndef TARGET_CARBON > # include <boost/config/posix_features.hpp> > # endif > > There is a posting that discusses the rationale of the above: > http://lists.boost.org/boost-users/2004/10/8110.php and also makes the > observation that there's probably a better way to check for MSL. > > My recommendation is to check for the definition of __MSL__. Thus the > above code becomes: > > # ifndef __MSL__ > # include <boost/config/posix_features.hpp> > # endif > > IMHO the existing MSL check is a bug (checking TARGET_CARBON is too > broad) and will be a trap for all Cocoa/Carbon programmers wanting to > use boost. I would also think that the reality now is that most people > use xcode/gcc and not CodeWarrior/MSL (this is from someone who used > to use CW and MSL all the time). Thus, the motivation for addressing > the issue should now be high. > > What needs to be done to fix the problem? I'm willing to help to save > some other poor soul from spending a day or two stuffing around. > > Cheers, > -C

2 2