Fall Review Schedule - version 1.0
Boost Fall Review Schedule - version 1.0 Contact Tom Brinkman at reportbase@gmail.com to request a review, to make updates to this document or to volunteer to be a review manager. Review Queue as of August 14, 2005. Not in any particular: 1. xpressive - Eric Niebler 2. logging - John Torjo 3. singleton - Jason Hise (new review needed) 4. function types - Tobias Schwinger (mini post-review needed) 5. output formatters - Reece Dunn (new review needed) 6. policy pointer - David B. Held 7. fixed strings - Reece Dunn 8. intrusive - Olaf Krzikalla 9. interfaces - Jonathan Turkanis Other Libraries: 10. factory - Federico Stella f.stella@flashnet.it 11. TR1 1. xpressive - Author: Eric Niebler eric@boost-consulting.com> Review Manager: needed Download: http://boost-sandbox.sf.net/vault/index.php?directory=eric_niebler Docs: http://boost-sandbox.sf.net/libs/xpressive Review Date: to be confirmed xpressive is a TR1 regex work-alike that also accepts regexes as expression templates and lets regexes nest and call each other recursively. Significant changes since 0.9.3 - c_regex_traits to wrap the global C locale - null_regex_traits for searching non-char data - doc and test improvements - bugs in static regexes and Unicode support squashed You can consider this the xpressive 1.0 release candidate. All that remains is to add more tests and documentation, and perhaps a tweak to the traits interface. 2. logging Author - John Torjo john@torjo.com Review Manager - Hartmut.Kaiser Hartmut.Kaiser@gmail.com Download: http://torjo.com/code/logging.zip Docs: http://torjo.com/ 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...."; Recent Additions: - 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 3) Singleton Author - Jason Hise chaos@ezequal.com Review Manager - Needed Download: http://tinyurl.com/6qvrd (old version from previous review) Docs: 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. 4) Function Types Author - Tobias Schwinger tschwinger@neoscientists.org Review Manager - John Maddock john@johnmaddock.co.uk Download: http://tinyurl.com/4oe7q (old version - from previous review) Docs: 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. This library was reviewed June 2005 and was accepted pending a mini post-review. 5. Output formatters Author - Reece Dunn msclrhd@hotmail.com Review Manager - Needed Download: Docs: This library was reviewed september 11, 2005. It requires a second full review. 6. Policy Pointer Author - David B. Held dheld@codelogicconsulting.com Review Manager - Gennadiy gennadiy.rozental@thomson.com Download: Boost Sandbox under policy_ptr Docs: 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. 7. Fixed Strings Author - Reece Dunn msclrhd@hotmail.com Review Manager - Beman Dawes bdawes@acm.org Download: boosts-sandbox/boost/fixed_string Docs: 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. 8. Intrusive Author - Olaf Krzikalla krzikalla@gmx.de Review Manager - needed Download: http://people.freenet.de/turtle++/intrusive.zip Docs: http://people.freenet.de/turtle++/intrusive.zip 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. 9. Interfaces Author - Jonathan Turkanis technews@kangaroologic.com Review Manager - needed Download: http://www.kangaroologic.com/interfaces Docs: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."
Tom Brinkman wrote:
Boost Fall Review Schedule - version 1.0
5. Output formatters Author - Reece Dunn msclrhd@hotmail.com Review Manager - Needed Download: Docs:
This library was reviewed september 11, 2005. It requires a second full review.
A minor nit, but I do not think this could be true unless I have fallen asleep last night for over a month.
Any Boost plans to put any more focus towards threading and multi-processing in the near future perhaps to provide more user experiences with libraries that solve programmer's problems. It would help advise any C++ threading standardisation effort. Has the effort moved towards say http://jupiter.robustserver.com/mailman/listinfo/cpp-threads_decadentplace.o... 1) Boost Thread library work seems to have slowed considerably and yet now more than ever this is one area where C++ is sadly lacking. Recent commentaries such as Kevlin's on this list have not necessarily flattered the Boost thread design, but do we have a champion(s) who are/could help to address this, or are alternative efforts happening instead behind the scenes in C++ working groups? I've seen lots of excellent advise from Peter Dimov, Dave Abrahams and many others but is it the case that its just seen as too thorny a problem for individual's to commit to, or is Boost thread considered sufficient? 2) Is Shmem being considered for the full-scale Boost library treatment as it appears to have a great deal of useful functionality to support existing OS threading and shared memory techniques. I realise reaching a full consensus may be impossible, but I would argue that multi-processing through threading, process control and shared data structures is an area of critical importance to C++ in the next few years. A well-understand pragmatic but not perfect fit to C++ is better than none at all. Regards Paul Baxter
"Paul Baxter" <pauljbaxter@hotmail.com> wrote in message news:BAY101-DAV113579AA6AA3847FF4AF43B5BE0@phx.gbl...
Any Boost plans to put any more focus towards threading and multi-processing in the near future perhaps to provide more user experiences with libraries that solve programmer's problems. It would help advise any C++ threading standardisation effort.
Has the effort moved towards say http://jupiter.robustserver.com/mailman/listinfo/cpp-threads_decadentplace.o...
1) Boost Thread library work seems to have slowed considerably and yet now more than ever this is one area where C++ is sadly lacking. Recent commentaries such as Kevlin's on this list have not necessarily flattered the Boost thread design, but do we have a champion(s) who are/could help to address this, or are alternative efforts happening instead behind the scenes in C++ working groups?
I've seen lots of excellent advise from Peter Dimov, Dave Abrahams and many others but is it the case that its just seen as too thorny a problem for individual's to commit to, or is Boost thread considered sufficient?
2) Is Shmem being considered for the full-scale Boost library treatment as it appears to have a great deal of useful functionality to support existing OS threading and shared memory techniques.
I realise reaching a full consensus may be impossible, but I would argue that multi-processing through threading, process control and shared data structures is an area of critical importance to C++ in the next few years. A well-understand pragmatic but not perfect fit to C++ is better than none at all.
Agreed. One of the things the committee's library working group members have to learn to endure is criticism for standardizing library component x when y is obviously so much better. Library x could be about every library we ever standardized, and y is short for an improved version that is so good it also cures disease and promotes world peace, but is, unfortunately, vaporware. Out of respect for Kevlin Henney, the proposal to standardize Boost.Threads has been tabled. But if Kevlin's promised improved design fails to materialized, I for one will press the LWG to take up the Boost.Threads proposal again. --Beman
"Paul Baxter" wrote:
2) Is Shmem being considered for the full-scale Boost library treatment as it appears to have a great deal of useful functionality to support existing OS threading and shared memory techniques.
Shmem is being developed but it covers a lot of functionality so its needs some time to get polished. /Pavel
1) Boost Thread library work seems to have slowed considerably and yet now more than ever this is one area where C++ is sadly lacking. Recent
It's a shame since there were some comments about reworking some components like rw_locks. There was also a discussion about the interface.
commentaries such as Kevlin's on this list have not necessarily flattered the Boost thread design, but do we have a champion(s) who are/could help to address this, or are alternative efforts happening instead behind the scenes in C++ working groups?
I find Kevlin's "More C++ Threading" paper is really good. Maybe we should adapt Boost.Thread's implementation to this interface and check if this is better than current one. But it's a quite big task.
I've seen lots of excellent advise from Peter Dimov, Dave Abrahams and many others but is it the case that its just seen as too thorny a problem for individual's to commit to, or is Boost thread considered sufficient?
I'm not sure but some people have said they don't see boost-thread interface as the best interface. But I don't know how many think that. I personally prefer the "futures" approach described in Kevlin's paper.
2) Is Shmem being considered for the full-scale Boost library treatment as it appears to have a great deal of useful functionality to support existing OS threading and shared memory techniques.
Well, I'm developing Shmem and I'm a biased, but I do think that C++ world needs some serious inter-process library apart from threads. The fact is that Shmem tries to offer a framework to put object in shared memory, including STL container, but for this, I needed to develop basic operating system wrappers. Not being a OS expert myself, I've took as much as I could from Boost.Thread interface (locks, conditions...). I have no idea about memory models so the current discussion for C++0x is somewhat far from my knowledge, but in boost, we could try to define some things about the interface: -> Is boost threads interface sufficient or do we prefer kevlin's approach? We can try to develop the second interface based on existing Boost Thread's code. -> We must define the synchronization objects. If we like boost thread's approach, that's fine, but I would suggest that the use of lockers (like scoped_lock) should be optional and not mandatory. -> The same for thread local storage. Apart from this, I would define more concepts: -> A semaphore: Some say it's dangerous, but sometimes, a semaphore is tha only way to notify events from drivers and interruptions. For me, a semaphore is a must. -> Define read-write locks interface definitively. Some have expressed boost thread's approach is inefficient. Same with barriers. -> Define a message queue. A message queue should be a must for a serious C++ standard thread library. Should it use posix-like priorities? System V approach? -> We can even define a pipe, that can be used in a iostream-like interface to pass data between threads/processes. I would then adapt all Shmem stuff to the defined thread interface, so we can use the same lockers with thread and process-wide mutexes. The same with the inter-process message-queue. I would also separate Shmem's low-level wrappers to a ipc library, so that Shmem just uses them to offer STL-like shared memory containers, allocators and some framework to create named objects. This way, we could split Shmem and make reviews shorter. Obviously, I would love to have also a unix socket-like ipc, but it would be a serious development to emulate it in windows without using TCP sockets. I appreciate a lot boost libraries, but sometimes I think the libraries are "expert level ideas", and that C++ is lacking basic blocks like network, threads, processes, data-bases, and a GUI. Not that I have much time, but I'm ready to help a bit in thread/process ideas. Regards, Ion
Ion Gaztañaga <ion_g_m@terra.es> writes:
1) Boost Thread library work seems to have slowed considerably and yet now more than ever this is one area where C++ is sadly lacking. Recent
Yes.
It's a shame since there were some comments about reworking some components like rw_locks. There was also a discussion about the interface.
Yes.
commentaries such as Kevlin's on this list have not necessarily flattered the Boost thread design, but do we have a champion(s) who are/could help to address this, or are alternative efforts happening instead behind the scenes in C++ working groups?
I'm not an expert, but I think such experts as Alexander Terekhov will be pretty quick to stand up and tell you that something at about the same level of abstraction as Boost's design needs to be available.
I find Kevlin's "More C++ Threading" paper is really good. Maybe we should adapt Boost.Thread's implementation to this interface and check if this is better than current one. But it's a quite big task.
I've seen lots of excellent advise from Peter Dimov, Dave Abrahams and many others but is it the case that its just seen as too thorny a problem for individual's to commit to, or is Boost thread considered sufficient?
I'm not sure but some people have said they don't see boost-thread interface as the best interface. But I don't know how many think that. I personally prefer the "futures" approach described in Kevlin's paper.
I haven't seen Kevlin's paper. All I can find is http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf. IIUC, futures are a very useful high-level abstraction but you can't solve all the same problems with them as you can with the facilities of Boost.Threads. 'Course, I could be wrong, but that paper doesn't mention condition variables anywhere so I can't tell. That is to say, IIUC, futures are a good idea *in addition to* having some lower-level primitives.
2) Is Shmem being considered for the full-scale Boost library treatment as it appears to have a great deal of useful functionality to support existing OS threading and shared memory techniques.
Well, I'm developing Shmem and I'm a biased, but I do think that C++ world needs some serious inter-process library apart from threads.
Yes. Especially considering that threads and processes are, um, different ;) However, it would be very useful to have some common abstractions that allow one to move between the two with little or no pain.
The fact is that Shmem tries to offer a framework to put object in shared memory, including STL container, but for this, I needed to develop basic operating system wrappers. Not being a OS expert myself, I've took as much as I could from Boost.Thread interface (locks, conditions...).
I have no idea about memory models so the current discussion for C++0x is somewhat far from my knowledge,
It sounds more complicated than it actually is. It's simply that when you take the language used in the standard to describe what a program sees when it reads and writes memory, and you toss in the idea of concurrency on top of it, it's impossible to describe the behavior of synchronization primitives so that they give us the results we expect from them. The formal description of how a program sees its memory is very loose -- just tight enough to work for single threaded programs, but not forced to be enough like the memory model of any particular real system supporting multithreading to make it possible to specify synchronization. The challenge is to tighten it up just enough without overspecifying it so that we rule out existing MT systems or force avoidable inefficiencies.
but in boost, we could try to define some things about the interface:
-> Is boost threads interface sufficient or do we prefer kevlin's approach? We can try to develop the second interface based on existing Boost Thread's code.
-> We must define the synchronization objects. If we like boost thread's approach, that's fine, but I would suggest that the use of lockers (like scoped_lock) should be optional and not mandatory.
?? How would you like to lock a mutex, then?
-> The same for thread local storage.
I'm pretty sure nothing in Boost.Threads mandates the *use* of TLS.
Apart from this, I would define more concepts:
-> A semaphore: Some say it's dangerous, but sometimes, a semaphore is tha only way to notify events from drivers and interruptions. For me, a semaphore is a must.
Is it possible to abstract away any of the "unsafety" without losing applicability to the crucial use cases?
-> Define read-write locks interface definitively. Some have expressed boost thread's approach is inefficient. Same with barriers.
Good plan.
-> Define a message queue. A message queue should be a must for a serious C++ standard thread library. Should it use posix-like priorities? System V approach?
-> We can even define a pipe, that can be used in a iostream-like interface to pass data between threads/processes.
Nifty.
I would then adapt all Shmem stuff to the defined thread interface, so we can use the same lockers with thread and process-wide mutexes. The same with the inter-process message-queue. I would also separate Shmem's low-level wrappers to a ipc library, so that Shmem just uses them to offer STL-like shared memory containers, allocators and some framework to create named objects. This way, we could split Shmem and make reviews shorter.
Obviously, I would love to have also a unix socket-like ipc, but it would be a serious development to emulate it in windows without using TCP sockets.
I appreciate a lot boost libraries, but sometimes I think the libraries are "expert level ideas", and that C++ is lacking basic blocks like network, threads, processes, data-bases, and a GUI.
We're all aware of the issue; the question is, who's going to do something about it? ;-)
Not that I have much time, but I'm ready to help a bit in thread/process ideas.
What we really need is someone/people to step up to the plate and take responsibility for development, maintenance, and documentation of relevant libraries. We need more than ideas; we need leadership. That isn't to say it has to be done by one person alone, but at least someone needs to rally the energy of Boosters with the interest and expertise to tackle the problems. Maybe you and Paul can do something together? -- Dave Abrahams Boost Consulting www.boost-consulting.com
I find Kevlin's "More C++ Threading" paper is really good. Maybe we should adapt Boost.Thread's implementation to this interface and check if this is better than current one. But it's a quite big task.
I haven't seen Kevlin's paper. All I can find is http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf. IIUC, futures are a very useful high-level abstraction but you can't solve all the same problems with them as you can with the facilities of Boost.Threads. 'Course, I could be wrong, but that paper doesn't mention condition variables anywhere so I can't tell.
Sorry, for the word "paper". I was talking about that pdf. Maybe is not enough, but we could offer both interfaces, and kevin's approach like a wrapper over Boost.Thread. Conditions variables are not mentioned but they could be the same as Boost.Thread, I find them very useful.
Yes. Especially considering that threads and processes are, um, different ;) However, it would be very useful to have some common abstractions that allow one to move between the two with little or no pain.
That's why I would like to share some utilities like scoped_locks and make the interface very similar (mutexes, locks, etc...)
Apart from this, I would define more concepts:
-> A semaphore: Some say it's dangerous, but sometimes, a semaphore is tha only way to notify events from drivers and interruptions. For me, a semaphore is a must.
Is it possible to abstract away any of the "unsafety" without losing applicability to the crucial use cases?
Umm, we have a lot to think here.
-> Define a message queue. A message queue should be a must for a serious C++ standard thread library. Should it use posix-like priorities? System V approach?
-> We can even define a pipe, that can be used in a iostream-like interface to pass data between threads/processes.
Nifty.
I will try to define the interface of both classes. I would not reinvent the wheel, we have posix message queues and unix pipes, that work great and semantics are known. Maybe atomic write issues with pipes could be simplified, since we have a message queue, for the messages, and use the pipe like a stream oriented, unstructured flow.
What we really need is someone/people to step up to the plate and take responsibility for development, maintenance, and documentation of relevant libraries. We need more than ideas; we need leadership. That isn't to say it has to be done by one person alone, but at least someone needs to rally the energy of Boosters with the interest and expertise to tackle the problems. Maybe you and Paul can do something together?
I'm ready to make a new Shmem snapshot, stop the development of Shmem (well trivial bug-fixes only) and work on Boost Thread's interface. Not that I am an expert in threads, I'm talking just about the interface, but at least I will start making noise about this. If we have a definitive boost thread interface, I would then adapt Shmem to this interface. Last time I looked, Michael Glassford was mantaining Boost.Thread, and he had good ideas, so he could help a lot here. Regards, Ion
Ion Gaztañaga <igaztanaga@gmail.com> writes:
What we really need is someone/people to step up to the plate and take responsibility for development, maintenance, and documentation of relevant libraries. We need more than ideas; we need leadership. That isn't to say it has to be done by one person alone, but at least someone needs to rally the energy of Boosters with the interest and expertise to tackle the problems. Maybe you and Paul can do something together?
I'm ready to make a new Shmem snapshot, stop the development of Shmem (well trivial bug-fixes only) and work on Boost Thread's interface. Not that I am an expert in threads, I'm talking just about the interface,
Getting the interface right is the hard part. Become enough of an expert to make informed decisions (with input from the community) about what should be done.
but at least I will start making noise about this. If we have a definitive boost thread interface, I would then adapt Shmem to this interface. Last time I looked, Michael Glassford was mantaining Boost.Thread, and he had good ideas, so he could help a lot here.
Yes. I haven't heard from Michael in a while; you should get in touch with him and see how you can work together. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 8/15/05, Ion Gaztañaga <ion_g_m@terra.es> wrote:
I appreciate a lot boost libraries, but sometimes I think the libraries are "expert level ideas", and that C++ is lacking basic blocks like network, threads, processes, data-bases, and a GUI. Not that I have much time, but I'm ready to help a bit in thread/process ideas.
Hi Ion, I am new to boost but I think the expert level ideas are the foundation on which to build real blocks and this probably will accelerate soon network ----------- the future boost::aio will be a big advancement for the app developer threads/processes --------------------------- You should ping Kevlin and see if he can help. You're alreadly pushing this with your library. databases --------------- This probably needs a reflection library first. What I would find useful is using the sql db definition as a file to parse and then generate automatically all the db interfaces GUI ------ First you need a solid c++ graphics library like vector-agg. I will ping the author Web ------ I'd like to see a web applications library on top of boost::aio . I am trying to work on this !
On Mon, 15 Aug 2005 10:52:03 +0100 "John Maddock" <john@johnmaddock.co.uk> wrote:
Other Libraries: 10. factory - Federico Stella f.stella@flashnet.it 11. TR1
Tom,
Is there any particular reason why TR1 is down under "Other Libraries", whatever that means? I wrote to you asking to be scheduled for a formal review back in May.
The following lines were at the top of the list... Review Queue as of August 14, 2005. Not in any particular: so I would not consider the numbering as an ordering in the queue. Tom, could we get an ordering as well? Thanks!
participants (11)
-
Beman Dawes -
David Abrahams -
Edward Diener -
Ion Gaztañaga -
Ion Gaztañaga -
Jody Hagins -
John Maddock -
Jose -
Paul Baxter -
Pavel Vozenilek -
Tom Brinkman