May 2005 - Boost - lists.boost.org

BOOST_FOREACH and 1.33.0
by Russell Hind 06 May '05

06 May '05

This was posted under the 'BOOST_FOREACH review results' thread but was suggested to be posted as a separate thread so others can comment on it (including the review manager and author). What do people think? Could it be pushed in to 1.33.0 or do we wait for 1.34.0 before it is added to an official release? Cheers Russell -------- Original Message -------- Pavel Vozenilek wrote: > > Perhaps exception could be made - it is mature, used in apps > and the documentation can be updated quickly. > > It may serve as starting point for people exploring other libraries. > I would like to see it in there too. AFAICT, it doesn't require any changes to other libraries (the bcc32 addressof problem has already been patched in CVS) so its impact should be minimal to none on regression tests. I guess its would still then be up to Eric to decide if the current tests and docs are where he'd like them to be for general release after the review. Cheers Russell

5 6

[1.33] type traits VC8 fixes and the release schedule
by John Maddock 06 May '05

06 May '05

What's the timescale for 1.33 at present? I have some VC-8 specific fixes for type traits that hook up the compiler's intrinsic type traits support into our traits classes: these patches make VC8 the first compiler to "just do the right thing" with every single trait. That's a big milestone IMO! Assuming VC8 will be release before Boost-1.34 (which seems likely), I'd like to commit these to cvs, but won't do so if we're too close to release (as long as there's at least 10 days or so to go, then there's enough time to check for possible regressions - especially as only one compiler should be affected - and there are no regressions for me locally with gcc/vc++/borland/intel). Thoughts? Thanks, John.

3 3

[1.33.0] Need more help fixing bugs!
by Douglas Gregor 06 May '05

06 May '05

We're making progress fixing bugs for 1.33.0, but we still have over 2000 failures on our target set of compilers. We need your help! Doug

1 0

socketstreams for boost?
by Peter Sommerlad 06 May '05

06 May '05

Hello all I met some of you on the list at this years ACCU conference in Oxford. However, I forgot to ask something I might supply to boost. I have a long experience with writing and using iostream adapters for TCP-sockets (in 24x7 production servers written in C++). A quick look at boost seems to me that this part of IO is lacking. My current solution is not yet fit for inclusion into boost, because it is still using "legacy" C++ and requires some infrastructure from another foundation library (mine :-). However, I'd like to modernize that library and the surrounding MT-server-framework in the future. If such a work (sockt-iostream) could go into boost, I would be happy to use boost as a new foundation for my framework. I'd like to hear, a) if there is interest in iostream for sockets b) if there is already a solution pending for inclusion (to review it) c) if there are people working on it who I might join Thanks for giving me some answer encouring me to work on that topic...:-) Yours Peter. -- -- Peter Sommerlad Erlenstrasse 79 CH-8832 Wollerau tel +41 1 687 44 74 fax +41 1 687 44 71 mobile +41 79 432 23 32 mailto:psommerlad@hispeed.ch

4 3

boost serialization: unregistered_class exception
by Keith McNeill 05 May '05

05 May '05

Using boost serialization I'm getting a unregistered_class exception. I know how to solve the problem once I figure out what class is having the problem. Figuring out which class is the problem can be a real pain when you have lots of templates. Is there anyway to get more information from boost serialization as to exactly what class is unregistered? Or is there anyway to inspect the archive and print out what classes are in the archive? I'm using 1.31. Thanks, Keith

2 1

RE: [boost] Re: Re: Logging Library -- Formal Review Request
by Roman Yakovenko 05 May '05

05 May '05

> From: John Torjo [mailto:john.lists@torjo.com] > I really don't understand why you'd want this. And more to the point, > I'm really curious how you could implement this in C++: > > // show what you want above. > BOOST_LOG(app) << "result of f() " << f(); > > And finally, I don't know why you'd want the above. What if f() then > calls g(), and so on, all this functions doing some logging. > Would you actually prefer: > > a.cpp:14: result of f() > [100 lines of other logged messages] > a.cpp:14: 1234 > > To: > > [100 lines of other logged messages] > a.cpp:14: result of f(): 1234 > > Best, > John I'd like to add use case. I think that log messages should be written as soon as possible. Use case: program crash only on specific machine that you can't debug on. If logs messages will not be written immediately they will be lost. In this case this logger is pretty useless. I think that if someone prefer to see > a.cpp:14: result of f() > [100 lines of other logged messages] > a.cpp:14: 1234 he should wrote "log viewer" that will handle this. Roman

4 8

Singleton Review: GCC compiler errors
by Tom Brinkman 05 May '05

05 May '05

Was the "singleton" library tested on GCC. I'm getting many compiler errors on 3.34.

2 1

[std][ptr_container][multi_index] proposal about std algorithms based on iter_swap
by JOAQUIN LOPEZ MU?Z 05 May '05

05 May '05

Hello, although this is more of a std issue than a Boost one, I think it has some nice implications for some Boost libraries, so please allow me to post it here (also, my original proposal at comp.std.c++, http://tinyurl.com/7wjyl, got almost zero response.) The proposed resolution N1523 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1523.htm aims at settling down the issue of whether some std algorithms are required/allowed to call user-provided overloads of swap(): by requiring that internall calls to swap are unqualified, a whole range of algorithms (swap_ranges, reverse, rotate, etc.) are automatically extended to cover types modeling the "swappable" concept: this includes assignable types but also non-assignable types for which a suitable swap() overload is provided. Now, my proposal tries to extend the applicability of these algorithms by adding an extra level of indirection: instead of requiring that swap() is unqualifiedly called, let us mandate that swapping be performed by an unqualified call to iter_swap(). Also, make the definition of std::iter_swap() unqualifiyingly call swap(). What does this buy us? In the general case, the situation is exactly the same as proposed in N1523, but the extra level of indirection allows us to overload iter_swap() in cases where the pointed-to types are not even swappable. A paradigmatic case of use is Boost.PtrContainer: the types held in this kind of containers are in general not swappable, but an iter_swap() overload than simply exchanges the internal pointers makes a lot of sense: the overall result is that rotate, reverse, etc. will work as expected, save the minor detail that this "extended swap" concept does not work as usual with raw pointers to the ext-swapped elements --only iterators to the elements get their pointed-to elements interchanged. What do you think of this? IMHO this can solve the problem of making std swapping algorithms work with ptr_containers, a problem for which (if I'm not wrong) no satisfying solution has been designed. My selfish interest in this proposal stems from the fact that a vector-like type of indices I'm designing for Boost.MultiIndex would also benefit from this. If the idea is well accepted, maybe we can provide Boost implementations of these algorithms taking proper care of unqualifyingly call iter_swap(). Ideas, comments etc. are most welcome. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

RE: [boost] Critique of Boost.Threads
by Brian Braatz 05 May '05

05 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Aaron W. LaFramboise > > Of Aaron W. LaFramboise Wrote: > > > I've been thinking about Dave Abraham's suggestion > <http://lists.boost.org/boost/2005/03/21839.php> that theres no reason > to provide a special protection mechanism for these inner handles. The > feeling I get from many here is that you should be able to hit a red > button, such as including a special implementation header, and you're > back in shoot-yourself-in-the-foot land, with the confidence that "the > programmer knows what he's doing." > > I've decided that this is not compelling for me. We always know what > we're doing--we're superheroes, we're C++ programmers. Yet C++ is > partly about letting us define a set of rules for ourselves, to catch > our mistakes, and keep us honest. I think the ability to hit this red > button and suddenly have full license to blow away a class's invariants > without any of the traditional protection mechanisms is downright > barbaric. > > I think there *is* something special about inheritance. The "protected" > keyword gets wonderful milage in other application domains, and I have > no idea why system abstractions need to be any different, such that for > system dependence, its perfectly acceptable to revert to > pre-Dijkstraesque programming practices. Certainly noone would tolerate > this additude with other well-defined standard libraries: no matter how > much you beg, you just aren't going to get anyone to give you a pointer > to std::list's linked list head. [Brian Braatz Writes:] Weighing in. I am IN agreement with DaveA in the following "> David Abrahams wrote: > >> I have always thought that concrete implementations of portable >> libraries should supply users a way to get at the OS-specific data so >> they can use platform-specific facilities on them if neccessary. >" One of the problems of standardization of interface is that it HAS TO BE expandable and allow for future work to be piled on top of it. In this case the best analogy I can provide is Microsoft Foundation Classes. Yes, yes, YES. I know it is evil in it's design. But one thing they was make it EASY for you to use "their" abstractions, but at the same time, allow for the programmer to decide they need to use a special API call. MFC is evil in many ways, but it has lasted a VERY long time and there are many applications written with it. I personally believe this is largely due to the notion that they ALLOW me to get to the underlying handle. This way, when the OS gets the ability to allow me to BLT semi-transparent gradient images, I can USE this in MFC, even though they never designed this model into it. While It is easy to argue MFC is mentally deficient in its design, I believe this one trait has given it utility and longevity. With THREADING- I believe the following: Moore's law is dead. Multi-core is where the HW folks are headed. The OS vendors, will naturally begin to add more API functions giving me more bells and whistles to play with in the threading world. Without access to the underlying handle, a threading library will not be quite as useful in "the real world" where I MIGHT need to take the plunge and hook up to some OS specific (or HW specific) concept. We must think about threading (and many other types of standard interfaces) as the FOUNDATION of further thinking. NOT the "final" design in the domain. :)

1 0

Singleton Review: global variables
by Tom Brinkman 05 May '05

05 May '05

In the singleton documentation it states that "singletons" could/should replace all global variables in an application. Does this comment apply to global vectors as well. I have a vector of boost::any which I've declared static in a resource class. <code below> struct resource { static std::vector<boost::any> resources; ...<more>... }; std::vector<boost::any> resource::resouces; How would one incorporate this global vector into the singleton library to take advantage of its facilities.

2 1