- Boost - lists.boost.org

[Ann]: Dox - a C++ documentation tool
by Narech Koumar 08 Jun '05

08 Jun '05

Dear all, A beta test of a C++ documentation tool, Dox, is transpiring at: http://dox.isfotek.se Constructive feedback and angry comments are greatly appreciated. Thanks, - Narech Koumar

1 0

Fwd: [serialization] test_demo_portable_archive failures
by Caleb Epstein 08 Jun '05

08 Jun '05

Sorry, these should have been CC'ed to this list earlier (two messages inline below): ---------- Forwarded message ---------- From: Caleb Epstein <caleb.epstein(a)gmail.com> Date: Jun 8, 2005 5:48 PM Subject: [serialization] test_demo_portable_archive failures To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Beman Dawes <bdawes(a)acm.org> The sole remaining failures for gcc-3_4_3-sunos appear to be the test_demo_portable_archive{,_dll} tests in the serialization library. These tests are failing because the numeric data that is written to the archive is two \x00 bytes for each value, which causes the restored object to contain all zeroes instead of the correct random data, and the comparison operation fails. My first thought was that this was an endian-ness problem, and in the end I was right. There is a block of code in portable_binary_[io]archive.hpp that checks #ifdef BOOST_BIG_ENDIAN. For some reason this macro is *not* being defined for me on SunOS. I can't find anywhere in Boost that it actually *is* defined, except <boost/detail/limits.hpp>, but this header is not included and trying to include it explicitly yields a slew of compiler errors. So I rebuilt the test program, adding -DBOOST_BIG_ENDIAN to the compiler command line. I still get the identical failure and the same \x00 bytes written to the archive. Looking more closely at the code that is doing the byte-swapping, there are three bugs: portable_binary_oarchive::save_impl: * last is initialized to first + size - 1. This should be first + sizeof (l) - 1; * the temporary variable x should be initialized with *last not *first portable_binary_iarchive::load_impl: * the temporary variable x should be initialized with *last not *first I've commited fixes for these to CVS just now, but I'm *not* sure how to best address the BOOST_BIG_ENDIAN issue. Any suggestions there? -- Caleb Epstein caleb dot epstein at gmail dot com ---------- Forwarded message ---------- On 6/8/05, Caleb Epstein <caleb.epstein(a)gmail.com> wrote: > I've commited fixes for these to CVS just now, but I'm *not* sure how > to best address the BOOST_BIG_ENDIAN issue. Any suggestions there? I think perhaps a new header file, <boost/endian.hpp> makes the most sense here. I don't think the definition of BOOST_BIG_ENDIAN / BOOST_LITTLE_ENDIAN belong in <boost/detail/limits.hpp> This header is not included unless BOOST_NO_LIMITS is defined, which I assume is only for non-standards-conforming implementations. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

RealNetworks has one more comment on boost.tokenizer
by Sebastien Martel 08 Jun '05

08 Jun '05

Hello boosters, Thank you for looking over the comments I posted. I completely forgot to mention one important thing boost.tokenizer 1.32 introduced that broke us when we moved from boost 1.31 : Here is my post on the matter on boost-users http://tinyurl.com/bc4av Essentially, the assign optimization (nice gains, thank you) adds requirements on the container type. We have a custom string classes that does not support it, but has a += member. So any use of tokenizer on these fails to compile. I sadly had to revert back to 1.31 behavior until this gets resolved. Thanks, -seb ( please cc me when replying, I do not follow boost@list ) -- Best regards, Sebastien mailto:smartel@real.com

2 2

[date_time] fractional_seconds: documentation suggestions
by Caleb Epstein 08 Jun '05

08 Jun '05

I think the specification of "fractional_seconds" in the time_duration class is unclear. Using the multi-argument constructor, and passing 1000 for the 4th argument, am I specifying milliseconds? Microseconds? Does it depend on the compile-time resolution of the class? If so (which is my suspicion), then using the 4-argument form of the ctor can lead to incorrect results if the resolution is changed. That seems like a bad thing. Looking at the implementation, I can see that I can divide the result of fractional_seconds() by the return value of ticks_per_second() to get a floating point value < 1.0, but I think that this should be more clearly spelled out in the section: doc/html/date_time/posix_time.html#date_time.posix_time.time_duration I'm not sure of the wording, but something like: *Construction* Mention that fractional_seconds depends on the compile-time resolution of the time_duration. I'd personally suggest it not be used and that the count-based construction be used instead. *Accessors Section* <tr> <td>static long ticks_per_second()</td> <td>The number of ticks per second. This is the resolution of the time_duration class</td> <td>long ticks_per_sec = time_duration::ticks_per_second();</td> <tr> <td>long fractional_seconds() const</td> <td>Get the number of fractional seconds. The return value will be in the range [0, ticks_per_second())</td> <td> time_duration td(1,2,3, 1000); td.fractional_seconds() --> 1000 <br/> double subsec = td.fractional_seconds() / time_duration::ticks_per_second () --> 0.001 (?) </td> Is this reasonable? -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Mailing list outage
by David Abrahams 08 Jun '05

08 Jun '05

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

RE: [boost] Re: Longer review period
by Brian Braatz 08 Jun '05

08 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Edward Diener > > I know I have never given a review but I feel that a 20 day period for > reviews rather than a 10 day period for reviews would give potential > reviewers, like me, a more comfortable zone in which to seriously look > at potential Boost software and give one. I think that would be a good > compromise between the present 10 day period, which seems to quick and a > full month period which seems too long. > > _______________________________________________ [Brian Braatz Writes:] Very much agree. The longer time will allow for some of us to FIND the time to participate. Additionally- I would like to suggest that if the period is extended, that the review manager periodically remind people of how much time is left. (if the discussion happens to die down) (i.e. every Monday morning or what not)

1 0

RealNetworks is using boost
by Sebastien Martel 08 Jun '05

08 Jun '05

Hello boosters, Name of the product: Rhapsody Name of the company: Real Networks Description of the Application and the Service: The Rhapsody Music Service allows its subscribers to legally download/transfer/burn over a million songs. The Rhapsody client software was built with many Boost libraries. URL of company and service: http://www.real.com/ Boost libraries used used with comments: boost.format Boost.Format is top notch. Using it is a bliss. boost.lexical_cast Quite useful. However pedantic use of streams to execute the conversions of basic types to/from strings is terrible. Had to be careful not to use in performance sensitive areas. I really wished there were a way to achieve performance comparable to c-runtime functions for ato* and *toa. boost.functional boost.function boost.bind These three libraries, along with smart pointer are the most used in our application. I could not imagine not having them handy. boost.smart_ptr Hands down, the most useful, and used library of the lot! boost.filesystem Not so happy here. This library looks promising, but there are a sum of little issues that makes me wonder if I should avoid using it in the future. 1- There is a bug on win98 when iterating a root drive. I sent a mail [http://lists.boost.org/MailArchives/boost-users/msg10391.php] about the problem on boost-users with a fix and never received a response. I might get better results by rephrasing the mail. 2- short-hand to build native paths using operator "/" is broken if you don't set the default name check to boost::filesystem::native. 3- What we really need is the reverse of the default library mode : have the library always work with native name-check and at the programmer's control, switch it to portable paths. There are WAY too many cases where we want to only work in native mode and portable path is the exception. 4- Lack of wstring/unicode support will become a problem very soon. 6- as noted in the do-list : "Windows: Some files seem to be poisoned to the point where you can't even do is_directory() on them without an access error. For example, pagefile.sys. Should directory_iterator ignore these files?" This is really a problem. A user must be very careful for exceptions when using iterators. They will throw. Overall this library, in it's current state, isn't a good fit for us. boost.date_time Simple to use, effective, does the job. I love the flexible input string parsing facilities, and the human readable ISO output. I created utilities to tie in with boost.filesystem so I can perform date_time calculations on files. Also had to create a layer to interface nicely with native locale date/time conversions api. I am sure every users of date_time that had to build UI apps ended up writing similar facilities. boost.tokenizer I glad to use tokenizer when we had to parse a whole bunch of weirdly formatted strings. It is a little bit tricky to get used to, especially the fact that tokenizer acquires references to its input in some cases instead of making a local copy. IMO, boost.Tokenizer would benefit from a policy design to fix this issue. I would prefer Tokenizer making a true copy of its input by default. boost.iterators Wow. Moving legacy iterating interfaces, or interfaces that should of been properly designed as iterators to STL compliant iterators was easy and painless. The gains in functionality to our code made by this library are invaluable. boost.array boost.optional Originally considered to implement an interface to value access of an embedded database but was discarded because of the _horrible_ compile times that appeared when introduced. Also considered for its visitation facility as a means to transport complex data to be rendered in UI controls. Again, dropped because of the compile times. boost.regex When you need it, it works magic. boost.thread Used to implement the monitor pattern in key areas. The 2 most desired features : static linking of boost.threads and ability to kill a thread. boost.preprocessor Used to implement repetitive unit-test code generation. The codebase benefited greatly from the clarity boost.preprocessor brought. -- Best regards, Sebastien mailto:smartel@real.com

3 3

Cache
by Maksym Motornyy 08 Jun '05

08 Jun '05

Hi all, I found that last discussion about cache classes in Boost was in year 2002. What happend at the end? Do we have cache in Boost or not? Sincerely, Maksym.

1 0

RE: [boost] Re: Re: Typeof: Review result
by Brian Braatz 08 Jun '05

08 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > I'm one of those people who feels I must put a lot of work into a review. > For > the FSM review I broke this policy and wrote a review even though I had > only > studied the documentation. My review was negative; it was basically a list > of > what I considered to be shortcomings of the library. > > I ended up getting into an unpleasant exchange with the library author, > who > repeatedly challenged me to suggest concrete changes to the design to fix > the > perceived problems. I had examined the library more thoroughly, my guess > is that > I would have been able to suggest improvements. I don't blame the library > author > in this case; it's only natural to ask for an alternate design when you > are told > that your design is flawed; however, I simply didn't have sufficient time > to > devote to the library. [Brian Braatz Writes:] What are the expectations here? I find myself in this spot frequently. I see something up for review, and it ALWAYS happens at the worst time for me. I look at it, but I tend to not say much unless I can REALLY devote the time needed to give the library the proper amount of review time. There might be "no answer" to the expectations questions. But I would be curious how others feel about this. I.e. If I only have an hour or two to look at something- is it still useful for me to submit a review? Part of the problem I have is an enormous respect for what a boost library is. It is not something one slaps together just to get their name in lights (to me at least). A boost library makes you go "Wow". if it doesn't make you go "Wow" it doesn't belong in boost. But if I cannot devote the time needed to review something DEEPLY, I feel it is somewhat disrespectful for me to participate. Do you guys think I am wrong to feel this way? Or do you find the opinions of a quick review valuable? Brian

5 6

Internationalization
by Maksym Motornyy 08 Jun '05

08 Jun '05

Hello all, Is there any i18n library available (pending) in Boost? Sincerely, Maksym.

3 4