- Boost - lists.boost.org

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

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

05 May '05

In-Reply-To: <ufyx36ixl.fsf(a)boost-consulting.com> dave(a)boost-consulting.com (David Abrahams) wrote (abridged): > >> * This isn't an algorithm, so I don't want to evoke std::for_each. > > > > What is it that makes std::for_each an algorithm and BOOST_FOREACH > > not? > > You might consider just answering the first part of that question for > yourself: "what is it that makes std::for_each an algorithm?" It's a finite series of well-defined steps. As is BOOST_FOREACH. In any case, we use underlines in keywords and macros, too. For example, "dynamic_cast" or "BOOST_STATIC_ASSERT". -- Dave Harris, Nottingham, UK.

1 0

[Range] issues
by David Abrahams 05 May '05

05 May '05

I was just looking at using Boost.Range in my new Sequence library and noticed the following: 1. The documentation of requirements uses names like range_iterator without qualification. You need to add the boost:: prefix or make it very clear that all names are implicitly boost:: prefixed (as opposed to, say, boost::range:: prefixed). I prefer the former; people may land on the documentation for reference without reading all the introductory material. 2. Names like range_iterator in the requirements tables should be hyperlinked to some documentation for them. 3. The documentation you land on should clearly state in which header those names can be found. 4. Having a pile of names prefixed by "range_" (like boost::range_const_iterator) just seems wrong to me when we have namespaces. Is there a good reason we're not using boost::range::const_iterator or boost::ranges::const_iterator? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 13

range_result_iterator
by David Abrahams 05 May '05

05 May '05

What is the rationale behind this name? It seems unintuitive to me, and what's more, unneccessary. Shouldn't range_iterator<T const>::type just be range_const_iterator<T>::type? If not, why not? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 10

Logging Library over Iostreams? (was Logging Library -- Formal Review Request)
by Brian Braatz 05 May '05

05 May '05

> On Behalf Of Darryl Green > Hi John, > > John Torjo <john.lists <at> torjo.com> writes: > > > > > I've seen that some of you have requested "levels", and yes, I should > > add them. I hope I'll have time to implement them soon (less than a > month). > > However, > it probably isn't general or clean enough an interface, and this could > be addressed by providing a concept something like the following, to > replace the (not customisable at present) logger_impl. > > struct sink > { > void write(const log_types::stream &s); > bool enabled(log_types::level l); > }; > > The rest of the interface (actual type) is log_manager defined. > A sink with the current semantics + level support implemented by extending > the enabled flag to be a level (something you previously talked me out of, > but [Brian Braatz Writes:] This thread is making me contemplate, Why not make this logging library a well designed bolt on to IOSTREAMS? I LOVE IOSTREAMS, and it seems like if the logging library is (DESIGNED TO BE) an add on to that I get the best of both worlds.

2 1