- Boost - lists.boost.org

typeof internals document updated
by Arkadiy Vertleyb 25 Apr '05

25 Apr '05

Hi all, A new section, that describes details of template template parameters support, has been added to this document. I thought this information might be usefull during the upcomming review (still have no idea when it's supposed to happen nor whether we go before or after Eric). Regards, Arkadiy

1 1

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Mats, It's good to have someone with experience in non-TCP environments! Glad you're here. > The X.25 API doesn't provide the equivalent to the tcp > listen(2) backlog parameter. To drive an X.25 acceptor > to be capable of accepting incoming calls at a high > rate, one has to implement the backlog oneself. Perhaps this is something that should be part of the impl of the acceptor for X.25. That would make X.25 and TCP the same in this sense (there are no doubt other differences of which this is just one). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 24 Apr '05

24 Apr '05

On Fri, 2005-04-22 at 14:23 +0300, Peter Dimov wrote: > Iain Hanson wrote: > > On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote: > > [ snip ] > > This would give a significant performance hit as there will now be two > > copies of the data. The 1st from kennel space to the library and the > > second in the callback from the library to the user. > > Sometimes, yes, but not always. You don't have to make a copy in the > callback, and for small packets and low bandwidth, the extra copy may not be > significant. Also note the "by default" in the above. I am not against > manual buffer management, just against the absence of automatic buffer > management. > I really don't see this as workable in the general case. The library has to guess the size of the read buffer. It would also prevent reading a complete record on a stream by reading a header up to the length field and then making a 2nd read call for that length with the correct size buffer. It would also add dynamic memory allocation to the library and be a source of runtime errors as a result a user not copying the buffer and trying to use it after its lifetime expired. I know we can't always protect users from themselves but we do try to not make it easy for them to make mistakes. /ikh

4 5

TR2 and Boost fixed_string
by Tanton Gibbs 24 Apr '05

24 Apr '05

With regards to TR2 and Boost, I would like to see a string class that allows a user specified length. For instance boost::fixed_string<100> fs; // synonymn for boost::fixed_basic_string<char, 100> Whether the rest of the class was monolithic like std::string or broken out as proposed by Herb Sutter, I wouldn't care. I often come across uses for this where I don't want to dynamically allocate memory, but I also want the functionality of the string class. Tanton

1 0

Re: [testing] Buildbot setup status.
by Rene Rivera 24 Apr '05

24 Apr '05

Robert Ramey wrote: > It looks like it runs even before I finish getting a whole group of changed > checked in. It's on a 10 minute trigger. So it waits for 10 minutes where it hasn't gotten CVS notifications before proceeding. Looks like you had the commits spaced out in 20, or so, minutes. This is one of those, tweak until we get what's appropriate for Boost development. Should I make that longer? 20, 30, 60 minutes? I don't want to make it feel unresponsive though. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Regression testing and BuildBot discussions
by Beman Dawes 24 Apr '05

24 Apr '05

Dave Abrahams, Doug Gregor, Thomas Witt, and I had a discussion last week at the C++ committee meeting about how to improve Boost regression testing, and the whole process of getting ready for releases. Much of what we talked about has already been discussed on this list, so our conclusions shouldn't be much of a surprise: * Making Boost regression testing as robust, automatic, distributed, and timely as possible is the best way to help developers, release managers, testers, and eventually, users. * BuildBot (http://buildbot.sourceforge.net/) looks like best way to achieve those goals, based on experiments to date. * It would be very helpful if a team coalesces around Rene Rivera to develop BuildBot regression testing for Boost. They will need to stay coordinated with the MetaCommunications folks, of course. The rationale behind the "robust, automatic, and distributed" goals is that many people are willing to volunteer machine resources for Boost regression testing, but they say that other than downloading (and perhaps answering a very few startup wizard questions) they don't have any of their own time available. Thus the vision is of something like the SETI@home project which lets people contribute spare machine cycles without burdening them further. The rationale behind the "timely" goal is that developers will benefit tremendously from faster feedback, both for HEAD and active branches. Automating the feedback will free developers from having to track what is happening on many different platforms. The rationale behind encouraging a team to work on BuildBot regression testing is that this is important to Boost, so it will benefit from a team forming. That should improve and speed development, and ensure that several people understand the system and can maintain the internals. Rene is the logical leader since he has already stepped into that role for BuildBot. --Beman

4 6

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > FD_SETSIZE only applies to select, and nobody > uses select except in "quick and dirty" servers > (as I did recently). Sadly, select is by far the most portable solution. On Windows, it is the only solution for 9x/Me. We can and should write more efficient impls for platforms that support poll() or epoll() or kqueue, etc.. > The idea of an explicit poll() call is to allow > the implementation to use a single-threaded > dispatch mechanism (select/epoll/kqueue), if one > is available. Without poll() you are forced to > use worker thread(s) and a callback queue to > support a single-threaded application, and this > can be considerably less efficient than > epoll/kqueue (or select in the < FD_SETSIZE > case) (in theory). Yes, indeed. Though I may be missing something in your idea about net::poll(). How would it avoid a queue? > Of course, if the threaded model can be > demonstrated to achieve comparable performance, > there would be no need to complicate the > interface with poll(). The "need" is performance and familiarity (IMO). If performance were taken out of the picture, it would be hard to argue for it. I don't know how the comparison would go which is why I was writing some stuff to try it out and get some measurements. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > I see that you are slowly moving away from your network-centric > scheme after you've already convinced me of its merits. ;-) Not exactly. Just trying to explore it completely :-) In other posts I state that my thinking is still as I originally proposed. I just see some use cases where your approach has merit; perhaps it is best left to the app but could be provided as a library of its own. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: TR2 and C++0x heads up
by JOAQUIN LOPEZ MU?Z 24 Apr '05

24 Apr '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Sábado, Abril 23, 2005 11:32 pm Asunto: [boost] Re: TR2 and C++0x heads up > "Beman Dawes" <bdawes(a)acm.org> wrote in message > news:6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net... > > | So far there are plans to propose Boost.Threads, > Boost.Filesystem, and > | Boost.Signals. As well as proposals for some of the more major > libraries, I > | personally hope someone will do a sweep through Boost looking at > some of > | the smaller utilities and helpers for a possible "Small Additions" > | proposal. > > I believe Alisdair was considering to work on boost.format. > > Besides, boost.date_time I think these other libs are good > candidates (maybe > with slight modifications): > > 1. conversion > 2. optional > 3. string algorithms > 4. utility > 5. variant > 6. iostreams > I'd add a tokenizer to the bunch. Not specially sexy but massively helpful --the typical impulse of a beginner is to do the tokenizing stuff by hand, many a time resulting in off-by-one errors, mishandling of unexpected separators etc. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Patch for bug in boost/boost/iterator/zip_iterator.hpp
by mstone＠cs.swarthmore.edu 24 Apr '05

24 Apr '05

boost/iterator/zip_iterator.hpp has an incomplete #include guard. This patch adds the necessary define to avoid redefinition errors when zip_iterator.hpp is included more than once. Michael

2 1