- Boost - lists.boost.org

[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

Re: [boost] BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 05 May '05

05 May '05

In-Reply-To: <d5c6jf$2bm$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > The only two negative reviews based their rejection on principle: > "Macros are evil and so should not be used". While this maybe > interesting point in itself, as I see things now, boost practice > supports using macros where necessary and macro nature of the tool > could not be a compelling enough reason to reject the submission. For the record, my review was negative and was not based on that principle. I agree with the boost policy of using macros where necessary. I rejected it because it is an overly complex solution to a simple non-problem. > While there were not so many specific issues discovered during > review, I would like to list couple: What about the name? Shouldn't it be "BOOST_FOR_EACH"? -- Dave Harris, Nottingham, UK.

5 4

RE: [boost] Re: [threads] Future directions (Was: TR2 and C++0x headsup)
by Cronje, Schalk 05 May '05

05 May '05

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrei Alexandrescu (See Website >I think I'd be representing the opinion of the entire group by saying >that a library-only approach is naive at best. See for example "Threads >Cannot Be Implemented As A Library" by Hans Boehm at >http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf, paper admitted >at the prestigious conference PLDI 2005 (sign that others believe Hans >actually makes sense). Actually I believe that any expert in threading >would cringe at the thought that Boost.Threads made it in the C++ standard. You definitely speak for me here. I would not like to see it go in as part of C++0x. >Speaking for myself about the quality of Boost.Threads' design itself, I >would add that it compares unfavorably (to use an euphemism) with many >other threading library interface for C++ or other languages - actually >all I know of, including unpublicized ad-hoc threading libraries >developed in-house at various companies I've worked with. I am much more in favour of a generic decoupled approach such as what Kevlin Henney has suggested (http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.p df). This approach lends itself to even more generic abstractions such as asynchronous functions as presented at Accu2005.

1 0

Review Schedule (5-May-2005)
by Tom Brinkman 05 May '05

05 May '05

The FOREACH macro has been accepted in to boost. The "singleton" library review starts today 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd and submit a review by 15-May-2005. Review Queue as of May 5, 2005 1) Singleton (5-May-2005; Ends: 15-May-2005) 2) Typeof (Starts: 20-May-2005; Ends: 30-May-2005) 3) Function Types (To be confirmed: 5-June-2005; Ends: 15-June-2005) 4) Logging 5) Policy Pointer Possible Future Reviews: 6) Fixed Strings 7) Intrusive (Review Manager Needed) 8) TR1 (Review Manager Needed) 9) Fusion 10) Factory 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it

1 0

Boost filesystem documentation
by James Gregory 05 May '05

05 May '05

http://www.boost.org/libs/filesystem/doc/exception.htm begins by saying: "The header provides class filesystem_error, publicly derived from std::runtime_error" I think this is wrong, isn't it publically derived from std::exception? Thanks, James

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 05 May '05

05 May '05

In-Reply-To: <4277C3E9.60407(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > Is do/while an algorithm? for (iterator i = c.begin(); i != c.end(); ++i) is an algorithm. Do/while would be if it included the code to step through a container. > You probably don't think of it that way. It's certainly not an > algorithm in the STL sense like std::for_each is. Again, a for-loop is. > The most effective way to think of BOOST_FOREACH (in my experience) > is as a new looping construct -- a foreach keyword. It's not a keyword. It's a macro which encapsulates an algorithm - roughly the same algorithm as std::for_each. > To encourage people to think of it as an algorithm in the STL sense > would be a mistake. It is range-based, not iterator-based. An algorithm does not need to be iterator-based to be an algorithm. > You can break and continue and return from the loop body. You can't > do any of those things from an STL algorithm. That's because the STL algorithms encapsulate differently, not because they are not algorithms. In any case, the question of whether FOREACH is an algorithm is a red herring, because the use of underlines as word separators does not just apply to algorithms. It also applies to macros (eg "BOOST_STATIC_ASSERT") and keywords (eg "static_cast"). Although there are some C++ keywords that don't have underlines, eg "sizeof", these are mostly inherited from C. The modern trend is for underlines unless there is a compelling reason otherwise. You've not offered a compelling reason. It sounds like you are mimicking the "foreach" of some other language. I think a C++ library should use C++ conventions, not the conventions of whatever it is you are copying. Consistency is important. Also, program text is easier to read if words don't all run together. -- Dave Harris, Nottingham, UK.

3 2

BOOST_FOREACH review results
by Gennadiy Rozental 05 May '05

05 May '05

Hi, everybody BOOST_FOREACH macro by Eric Niebler is accepted into boost. The library was received pretty good by boost community (I counted at least 13 positive reviews). The only two negative reviews based their rejection on principle: "Macros are evil and so should not be used". While this maybe interesting point in itself, as I see things now, boost practice supports using macros where necessary and macro nature of the tool could not be a compelling enough reason to reject the submission. Would this trend be ever changed in a future we could change a policy for future submissions. While there were not so many specific issues discovered during review, I would like to list couple: * documentation should contain more examples and special pitfalls section * testing should be split by compatibility sections * it would be good to make this facility work on more compilers Congratulation Eric for the excellent work and thanks to all the reviewers for participation. Gennadiy Rozental BOOST_FOREACH review manager

5 5

[bug] using boost::range and boost::array in MSVC 6.0
by Joe Gottman 05 May '05

05 May '05

MSVC 6.0 gives an internal compiler error when I include the following headers in the order below: #include <boost/array.hpp> #include <boost/range.hpp> The reason for this ICE (besides MSVC 6.0 being a non-conformant compiler) is the fact that several files in the boost/range/ subdirectory declare functions having a parameter called "array". It seems that MSVC has problems realizing that this is the name of a new variable, not an already existing class. When I renamed these parameters everything compiled fine. Would it be possible to change these parameters to a name that isn't the name of a boost class, something like c_array maybe? Thank you, Joe Gottman

2 1