March 2005 - Boost - lists.boost.org

tuple patch (constructing from a pair)
by John Maddock 29 Apr '05

29 Apr '05

The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity). RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636 > template <class T, class U> > tuple(const std::pair<T, U>& p) > : inherited(p.first, p.second, detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull()) > { > BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 > } > Is it acceptable to add this? Many thanks, John Maddock.

10 49

[rational] Announcing new maintainer -- call for feature requests
by Jonathan Turkanis 28 Apr '05

28 Apr '05

Dear All, Several months ago I became the official maintainer of Boost.Rational, and am just now getting around to considering proposed modifications to the library. I would like to know: 1. Do people use Boost.Rational, and if so, what is it used for, and with what template parameters? 2. What changes or additions would people like to see? Here are the changes that have been proposed: A. [me and others] Make int_type (and possibly param_type) public. This will be done. B. [Andras Erdei] Make rational more usable with limited precision integral types by providing automatic rounding when the result of a computation can not be represented exactly, or by asserting or throwing an exception in such cases. C. [Andras Erdei] Provide automatic selection of the underlying int_type which would be fastest for representing rational arithmetic with a specified precision. ---- Proposal B Andras's original proposal, if I understood it correctly, was to use a form of rounding which could be computed as the natural side-effect of the existing algorithm to compute a rational arithmetic operation, in the case that the actual result could not be represented exactly using the underlying int_type. At the time, I questioned whether it would be acceptable to change the current behavior of rational, since some current users may be relying on it. This is partly why I am asking question 1) above. A more general solution would be to add an optional template parameter representing a rounding policy, which could - implement no rounding, silently resulting garbage in some cases (this is the current implementation) - implement Andras's rounding method - throw an exception if rounding would be required - assert if rounding would be required, or - (possibly) implement some other rounding algorithm The reason I qualified the last option with "possibly" is that implementing alternate rounding policies may require completely different algorithms for the basic operations, meaning that the implementations of the basic operations would have to be moved into the rounding policy, which I'm reluctant to do. Andras, please let me know if I have misrepresented your ideas. For background, see these threads: http://lists.boost.org/MailArchives/boost/msg76375.php http://lists.boost.org/MailArchives/boost/msg80121.php ---- Jonathan

15 55

What I Hate About How We Abstract System Dependence
by Aaron W. LaFramboise 19 Apr '05

19 Apr '05

Over the past few years, the style of our abstract interfaces for system-dependent features has bothered me more and more. Here’s my challenge to those happy with the status quo: Find me an interface in Boost or the C++ standard that represents an observable inter-program interface, such that, for any popular operating system, I can’t find a feature of the operating system that is impossible to express using that interface without relying on undefined behavior, undocumented behavior, or circumventing access specifiers. First, a realistic example is in order. We all know and love C++ standard iostreams (“iostreams library,” <http://www.cplusplus.com/ref/iostream>), which is almost certainly the most widespread operating system abstraction in the C++ world. So we create a std::ifstream, and use it to open some file. Now we want to map this file to a region of memory. Do what?! Suddenly, everyone breaks out in laughter, with tears rolling down their cheeks, little globules of spittle escaping from the corners of their mouths, ridiculing the very notion of any standard library being involved in such a reasonable and common operation. But why? The operating system can do this, and it’s not incompatible in the slightest with the concept or interface of std::ifstream. In fact, if we had some way of stealing the secret file descriptor stashed away inside the filebuf, we could do it—but programmers, deep down, feel that this sort of access just isn’t right. Grab some popcorn and watch programmers sweat and squirm in their own cognitive dissonance as they try to find an elegant solution to this insolvable problem (“Legalize access to file descriptors now!” <http://gcc.gnu.org/ml/libstdc++/2005-02/msg00090.html>). Let me get straight to the heart of the problem: we love our concrete interfaces. Every programmer loves the ability to be able to manipulate a class, knowing its complete interface, exactly what sort of animal it is, and exactly what its going to do—and know all of this before the program ever runs for the first time. I hope I’m not bursting anyone’s bubble here, but if when we’re talking about components that abstract system interfaces, then this just isn’t the way the world works. It’s time we grow up, get out of the playpen, and realize that there really is a big scary world of polymorphism out there. My core belief is this. We don’t fully know the capabilities of the system components we manipulate, not at compile time, not at load time, and perhaps not even by the time the program halts. Any interface that pretends to is a lie, and most of the time, a pretty bad liar at that. Here’s another one of my favorite examples, in Boost.Threads (“Boost.Threads,” <http://www.boost.org/doc/html/threads.html>). boost::thread lacks a method to forcefully terminate a thread, despite the fact that many threading systems have one. However, we can’t add one, because there exists at least one threading system that doesn’t have this feature. Well, we *could*, but then we’d be playing a game of chicken with the user daring them to call a function that has completely undecidable behavior. Now let’s say the user was really determined get this feature, and so she decided to write her own thread class. Nope, she loses again! Because her class is not named boost::thread, the class is incompatible with all of the rest of the thread manipulation functions, and so is entirely unusable with Boost.Threads. Do you like scary movies? I have an idea for one. It’s about a future C++ standard that includes a threading library that I can’t use if I want forced termination semantics, or any other feature that any operating system has that the library lacks. Besides the inability of our concrete interfaces to support a capability set that varies, and the lack of ability to reimplement these interfaces compatibly, concrete schemes also can’t represent what I call /multi-interface systems/. Some environments, such as Cygwin (“Cygwin Information and Installation,” <http://www.cygwin.com>), have two (or more) entirely distinct sets of system interfaces that may be used as underlying primitives for a particular concept. In the case of Cygwin and threads, the environment supports both the POSIX and Windows thread interfaces. Both may be used simultaneously, and as each system has its own unique characteristics, it may be entirely reasonable to do so. But, Boost.Threads can’t do this, and really couldn’t possibly be expected to, in its current form. Note that the total set of capabilities is not decidable at compile time, or even load time. For instance, let’s say we’re using a process class on a System V-style system. We’re implementing a debugger, and so we’d like to get access to the process’ core memory through the /proc interface. However, up until we actually try to do so, we really have no way of knowing whether this is supported, as the /proc filesystem may well not be mounted. I’m calling for polymorphism. These interfaces really are conceptually polymorphic; let’s reflect that in our language. Let’s give the user the tools she needs to be able to write her own compatible classes when the ones we write prove insufficient. For the sake of exposition, let me propose a sketch of a possible design for a process class. A generic process is represented by an abstract base class. Derived from it are classes for the major types of processes: POSIX, Windows, DCE, and whatever else. Derived from each of those are specific variants of these types, with additional or extended capabilities. For example, a child of the POSIX class might be a class implementing the ptrace() process debugging interface. Naturally, we’d instantiate objects of these classes with some factory. Since we might not know at creation time exactly what capabilities the system has, or what capabilities are needed, we need a copying mechanism to construct a new process from an old one. This copy might, for example, copy the POSIX base, so as to get the process identifier, and slice the rest off, as unneeded. Clearly there would need to be significant design effort put into this area. This and other implementation issues are mostly tangential from my primary concerns. Finally, pointers are a pain, so we can wrap pointers to a process in your favorite smart pointer. This smart pointer might have additional associated mechanics to enable it to automatically select the best kind of process creation machinery as it is able. I could see this basic process class (which is practically concrete) as having a very pleasant and desirable syntax. Lastly, performance needs to be addressed. I’m not at all worried about making operations that would be normal function calls into virtual function calls, and you shouldn’t be, either. An indirect call will often have a cost an order of magnitude less than the cost of the actual underlying system operation, which might involve many more indirect calls, context switches, and synchronization. A more significant concern is the additional machinery needed to support virtual inheritance. RTTI may also be necessary to fully exercise the class hierarchy’s capabilities. However, when using the subset of features that would be available to an equivalent concrete implementation, RTTI and similar should not be needed, so a user shouldn’t have to pay (too much) for what she’s not using. So here’s my question to the Boost community. How many people have similar concerns and experiences? How often, in real code, do concrete classes prove insufficient? Who here has to entirely reimplement libraries like Boost.Threads for relatively silly reasons? Are there any alternate solutions for the problem I describe? What unforeseen problems might there be with this polymorphic style? Would you use a library such as Boost.Thread if it had been rewritten in this manner? Submitted with Love, Aaron W. LaFramboise

14 24

logo contest status query
by christopher diggins 11 Apr '05

11 Apr '05

So what's the status on the logo contest, any word on when the results will be tallied? Christopher Diggins

9 24

[filesystem] large file support detection broken on Solaris (possibly others)
by Caleb Epstein 07 Apr '05

07 Apr '05

The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy) The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on. Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably. -- Caleb Epstein caleb dot epstein at gmail dot com

2 6

[Unicode strings] We're off
by Erik Wien 06 Apr '05

06 Apr '05

Hi. I hope you guys still remember this, despite my lack of activity on this list, but I was here about developing a Unicode library for Boost a while back, and well.. We're off! :) We are now at a point in the development where we would really appreciate feedback from you Boosters. We have developed a *very* early prototype based on some of the ideas put forward in the earlier discussion here, and we would like you guys to comment on it. The design is by no means locked, and only represent one possible way to implement a Unicode string class. If you have an alternate solution, please let us know. We are using an evolutionary development model (prototyping), so we are open for design changes should there be a need for that. You can download the source code (VC++/DevCpp projects only for now, sorry) from our site here: http://hovedprosjekter.hig.no/v2005/data/Gr5_unicode (the files section). On the same site we have also set up a forum where you can discuss different aspects of the project if you want to keep it off list. No registration is required, so it should be hassle (password) free. Current design: The current design is based around the concept of «encoding_traits». These are templated on the different encodings used in Unicode (UTF-8, 16 and 32, both endians), and provide functions and typedefs for working on code units (8, 16 and 32 bit integers respectively) in any encoding. These traits are then used for implementing different interfaces that externally use 32bit code points, thereby abstracting away the underlying encoding. The string class itself is created with encoding transparency in mind. Also at the class level. This means that the encoding used in the string is not a template parameter of the string class itself (making each instantiation of the string it's own type), but rather a parameter of an implementation class that is used internally to hold the string. Something like this (highly simplified): class impl_base { // A lot of pure virtual functions for manipulating a string. }; template<typename encoding> class impl { // Implement the functions...obviously. }; class encoded_string { impl_base* m_impl; template<typename encoding> void set_encoding(encoding enc_tag) { m_impl = new impl<encoding>(); } }; The reason for doing this is that it allows functions that take encoded_string parameters to be blissfully unaware of what encoding they are working on, without having to templatize (it that a word?) the function itself. (Something I understood was a bit of a worry for some in the last discussion.) An alternate way of doing this (something we also tested when developing the current version), is to simply template the string class itself on encoding, but then you loose the above advantage of being able to have non-template functions working on multipe encodings. You do however gain speed (I would assume), since you wouldn't have the overhead of virtual function-calls, as well as a less complex implementation. There's also an implementation of the Unicode Character Database in the prototype, along with an implementation of the normalization algorithms, but I won't go into the details of them here (to keep this from becoming a novel). Should be easy enough to understand if you want to. Anyway.. Comments are as always welcome. Either here, or in the forum at the site. Regards - Erik To Eric Niebler: Did you recieve the mail I sendt you a while back about the whole contact-person debackle? (on the Boost Consulting address) Never got a reply, so I'm not sure if it went through.

10 58

[test] CodeWarrior+IsDebuggerPresent()
by Stefan Slapeta 04 Apr '05

04 Apr '05

Many tests on CW fail due to a missing IsDebuggerPresent() in execution_monitor.ipp. I assume this code should be disabled for CW, no? http://tinyurl.com/59vnj ### mwcc Compiler: # In: ..\boost\test\impl\execution_monitor.ipp # From: ..\libs\logic\test\tribool_io_test.cpp # ----------------------------------------------- # 199: if( IsDebuggerPresent() ) # Error: ^ # undefined identifier 'IsDebuggerPresent' Stefan

4 10

[signals] Performance
by Jody Hagins 04 Apr '05

04 Apr '05

Are there any docs which describe the performance of the signal/slot library? I was about to embark on a performance study because I want to use it in a very high performance critical code path, but I thought I'd ask if anyone else may have already done some work in this area. Thanks!

12 35

Re: Asynchronicity (long)
by Don G 04 Apr '05

04 Apr '05

Hi Boris, No problem on the delay. I sometimes have long spells of silence due to work/family/church/life-in-general. :) My answers / opinions are below... --- Boris <boris(a)gtemail.net> wrote: > Hi Don, > > sorry for my late answer but work caught me again. At least > it's good to see others jumping in and keeping the > discussion alive. :) > > > [...] > > ------ Sketch -------- > > [...] > > It reminds me of I/O completion ports - several ports each > of them handling several events? Is your idea similar to this? It is similar, but the channel concept has no analogy. Then again, most async mechanisms are similar, it's just in the details that they diverge<g>. QueueUserAPC + SleepEx(ALERTABLE) is also similar, but again lacking the channel notion. The closest analogy in Windows is the USER thread message queue, an HWND and Get/DispatchMessage + PostMessage. I believe one can find nearly a one-to-one correspondence with that model. > > ------ Pseudo-code -------- > > > > class nexus > > The concept of the class really reminds me of a I/O > completion port. The only difference is that there is no > invisible background thread being responsible for a > nexus object - the application has to make sure that > there is one thread controlling a nexus object? Essentially, yes. Nothing is hidden with the possible exception of how does some body of code know the proper nexus object to which a channel should be connected. This can be explicit, but a thread-specific data item is also compelling. > > [...] > > class channel > > AFAICS you use this class to communicate with a nexus object. > The owner thread does the multiplexing (waiting for different > events in a nexus object) and other threads communicate with > this nexus object through channels which are responsible for > synchronizing? Is this correct? If I understand you correctly, Yes. The channel objects are the means by which the user enqueues events to a nexus object and a different piece of user code calls the nexus object to dispatch/dequeue the messages. > So the difference between your approach and I/O completion > ports in Windows is ... hm, I think in Windows a completion > port is a combination of your nexus and channel, isn't it? It is basically that, yes. The channel class, however, I believe to be a very important concept. Merging it with the nexus class would create dangerous situations where one would have to ask at the point a message is enqueued: "will it be OK to deliver this message regardless of what might happen between now and the time of delivery?" The key impulse that can make this answer always NO is "delete foo". The delete operation is synchronous. Without a channel to serve as a way to cancel pending messages to that object, we would have dangling pointers in the queue (a bad thing). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 13

[1.33.0] Let's start preparations...
by Douglas Gregor 02 Apr '05

02 Apr '05

Let's start revving up to release Boost 1.33.0. Personally, I'd like to get it out the door by mid-April at the latest, and I'm offering to manage this release. To get things rolling, I'd like library maintainers to add their goals for the 1.33.0 release to the checklist on the Wiki. This will give us all an indication of our progress toward the feature set we want for this release. A few weeks before the release, we'll freeze the feature set, bump the remaing list to 1.34.0, and work on portability and stability until we get it right. The checklist is here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?1.33.0_Check… Depending on the size of the list, we'll decide when to feature freeze. I'll be travelling for the next week, but will try to answer e-mail as I find time. Doug

18 63