- Boost - lists.boost.org

[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

[Boost-bugs] [ boost-Support Requests-1252231 ] pointer refresh?? ?!?!??!?!?!
by SourceForge.net 04 Aug '05

04 Aug '05

Support Requests item #1252231, was opened at 2005-08-04 14:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1252231&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: pointer refresh?? ?!?!??!?!?! Initial Comment: i used boost-shared_ptr in a system tray app, and i think i'm loosing some data because of it. If the app stays minimized in sys tray for let's say an hour, things don't go very well. i'm not having any errors, but i ask u if that is possible ? it;s like they need some refresh or something..don't know what ... this is critical..help-help.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1252231&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.33.0] Release candidate #1 is available
by Doug Gregor 04 Aug '05

04 Aug '05

Boost 1.33.0 release candidate #1 is now available here: http://www.osl.iu.edu/~dgregor/boost-1.33.0/ There are two sets of files important for this release: - boost_1_33_0_rc1.*: The actual release candidate - boost_1_33_0_(docbook|fo|man).*: The documentation in other formats Please download and unpack the archives, browse the documentation, try the release with your favorite compiler, etc. Thanks! Doug Gregor 1.33.0 Release Manager

12 18

[network] Boost.Network proposal v0.3
by Pedro Lamarão 04 Aug '05

04 Aug '05

Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: *) IOStreams classes, fully buffered *) A listener class *) A wrapper for the name resolution service *) A type to store addresses The missing pieces being: *) Complete the copy constructores and assignment operators of the generic_address class. *) Implement optimized xsputn() and xsgetn() in the stream buffer. *) Implement setbuf() in the stream buffer. *) Documentation (never enough) The above list is what I intend to polish up for a formal proposal. This is the TODO list for a next version: *) Address types specific for IPv4 and IPv6, with input operators. *) A formatter output operator for generic address types based on the name resolution service. *) Resolver options and manipulators for the above output operator. *) Code conversion in the stream buffer. *) A poller class. *) Wrapper for sendfile/TransmitFile. *) Implement showmanyc() and perhaps putbackfail() in the stream buffer. With a proper poller class I believe most people's desires for non-blocking operation would be satisfied. I'm going out of town on vacations for some days, so things are going to stall for a while. I hope to complete all tasks soon after Boost 1.33 is released and a new review cycle starts. -- Pedro Lamarão

6 8

[1.33.0 RC1] Possible regression in serialization
by Eelis van der Weegen 04 Aug '05

04 Aug '05

Here's another one-liner that fails to compile (with gcc 3.3.5): #include <boost/serialization/nvp.hpp> I get the following error: In file included from .../boost_1_33_0/boost/serialization/nvp.hpp:33, from t.cpp:1: .../boost_1_33_0/boost/serialization/tracking.hpp:50: error: syntax error before `>' token Again, this worked with Boost 1.32 :) Regards, Eelis

3 2