March 2007 - Boost - lists.boost.org

[Report] 26 regressions on RC_1_34_0 (2007-03-29)
by Douglas Gregor 29 Mar '07

29 Mar '07

Boost Regression test failures Report time: 2007-03-29T01:01:27Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 26 failures in 3 libraries date_time (1) parameter (4) python (21) |date_time| testmicrosec_time_clock: borland-5.8.2 |parameter| python_test: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-cygwin-3.4.4 |python| bases: gcc-4.1.1_sunos_i86pc exec: gcc-4.1.1_sunos_i86pc exec-dynamic: gcc-4.1.1_sunos_i86pc extract: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux list: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle1: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle2: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle3: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pointee: gcc-4.1.1_sunos_i86pc pointer_type_id_test: gcc-4.1.1_sunos_i86pc upcast: gcc-4.1.1_sunos_i86pc

1 0

More filesystem::directory_iterator woes (AIX endless loop)
by Michael Klein 29 Mar '07

29 Mar '07

Hi, iterating over a directory on AIX results in an endless loop because of funny return codes from readdir_r(): http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.… Specifically, readdir_r() sets errno to EBADF upon end-of-directory. Currently, dir_itr_increment() detects an error condition and returns, but without ever calling dir_itr_close(), and the DIR handle never gets closed. Workaround: --- ../boost/libs/filesystem/src/operations.cpp.orig +++ ../boost/libs/filesystem/src/operations.cpp @@ -1250,10 +1250,9 @@ BOOST_ASSERT( buffer != 0 ); dirent * entry( static_cast<dirent *>(buffer) ); dirent * result; - int return_code; - if ( (return_code = readdir_r_simulator( static_cast<DIR*>(handle), - entry, &result )) != 0 ) return error_code( errno, errno_ecat ); + int return_code( readdir_r_simulator( static_cast<DIR*>(handle), entry, &result ) ); if ( result == 0 ) return dir_itr_close( handle, buffer ); + if ( return_code != 0 ) return error_code( errno, errno_ecat ); target = entry->d_name; # ifdef BOOST_FILESYSTEM_STATUS_CACHE if ( entry->d_type == DT_UNKNOWN ) // filesystem does not supply d_type value Kind regards, -- Michael #exclude <windows.h>

1 0

[XML] Searching for an XML parsing library in boost
by Shibu Bera 29 Mar '07

29 Mar '07

> I would like to know, > if any library for parsing XML file is available in boost or not. > I srearched in the boost.org site for the same but, >I cound't get any library as such. >If library is present, please let me know the details. >If not, please allow me to know, if any work is going in the concern topic. Thank you, -- Regards, Shibu

12 46

boost::filesystem::directory_iterator not working on NFS mounts
by Michael Klein 29 Mar '07

29 Mar '07

Hello list, the directory_iterator (current CVS) doesn't work if the iterated directory resides on an NFS mount and fails with an exception in boost::filesystem::basic_directory_iterator's constructor. The NFS server here runs Linux, and the iterator fails at least on clients running Solaris (Invalid argument) or HP-UX (Operation not supported). This reason is because of the call to pathconf(_PC_NAME_MAX) in directory_iterator::dir_itr_first() which fails for directories residing on NFS mounts, probably because the client doesn't know about the server's limits. Although arbitrary assumptions are usally not the best idea I think it's reasonable to use PATH_MAX as maximum length in this case. Not being able to use a directory_iterator on a NFS mount is a rather severe limitation, IMHO. As a workaround I'm using this patch right now: --- boost.orig/boost/libs/filesystem/src/operations.cpp +++ boots/boost/libs/filesystem/src/operations.cpp @@ -1187,7 +1187,21 @@ return error_code( errno, errno_ecat ); target = dummy_first_name; long pc_name_max( ::pathconf( dir.c_str(), _PC_NAME_MAX ) ); - if ( pc_name_max == -1L ) return error_code( errno, errno_ecat ); + if ( pc_name_max == -1L ) + { + switch ( errno ) + { + case EINVAL: +#ifdef EOPNOTSUPP + case EOPNOTSUPP: // HP-UX returns this +#endif + pc_name_max = PATH_MAX; + break; + + default: + return error_code( errno, errno_ecat ); + } + } dirent de; buffer = std::malloc( (sizeof(dirent) - sizeof(de.d_name)) + static_cast<std::size_t>( pc_name_max ) + 1 ); Any opinions? Kind regards, -- Michael #exclude <windows.h>

1 0

boost::iostream: Who's in charge ?
by Philippe Vaucher 29 Mar '07

29 Mar '07

Hello, Who's in charge of boost::iostream ? >From what I found on the mailing list, the lib author did quit boost development. The problem is, the doc isn't even complete, as http://boost.org/libs/iostreams/doc/guide/buffering.html shows. So right now it looks like nobody knows the lib entirely, like no one seems to know how to turn buffering off, despite me asking there and on irc. Actually I'm not even sure my problem is related to buffering, but no one can confirm / refute my guessing. I think this is somewhat dangerous to let a lib in a kind of "abandoned" state. My 0.02$. Philippe

1 0

Re: [boost] Boost.Threads, N2178, N2184, et al
by Emil Dotchevski 29 Mar '07

29 Mar '07

> Connection between pthreads and C++ threads: The critical connection > is cancellation. If you phthread_cancel a C++ thread, what happens? > If you thread::cancel() a pthreads thread, what happens? In the ideal > world everything would just work. I'm not convinced this is > practical. We can say "oh well, whatever" and not standardize what happens when thread cancellation crosses the C/C++ language barrier; however this approach doesn't work where the rubber meets the road: at some point, someone will have to define these semantics. Without a standard, the implementation-defined semantics (as of today) vary from platform to platform; I do not see how this is helpful. > Benefit of non-copyable (but movable) thread handle: It is all in how > you view: join, detach and cancel. If these are considered non-const > operations on the thread, then the sole-ownership model is much > simpler. I've got a thread, I own it, nobody else does, I can do non- > const things with it without fear of disturbing the universe. If > join, detach and cancel are const operations, (and if all other things > you can do through the handle are const) then under-the-cover > reference semantics are benign. On Windows, you can have two joins on the same thread. Copyable thread handles can support this behavior directly. How does one achieve the same thing with N2184::thread semantics? > This is quite analogous to reference counted strings: A reference > counted mutable string is complicated. If you modify one, you either > have to copy it so others sharing the data don't see the modification, > or you accept the fact that your string has reference semantics: > modify it here, and all other copies see what you've done. And OS > threads aren't copyable, so reference semantics for the handle are the > only option.> > A reference counted immutable string is quite simple. You never > modify it. The fact that it is shared is virtually undetectable (an > implementation detail). Not only strings, sharing mutable objects of any type is complicated. Sometimes we define const interfaces which turn sharing into an implementation detail, and sometimes we deal with the complexities of mutable operations. > Current thread handle: This feeds from the sole ownership view vs the > shared ownership view. Yes, this is why I mentioned it. You can't have non-copyable semantics and allow the current thread to be able to take a self handle. > In the sole-ownership view (value semantics), > there is only one owner of a thread. Only the owner can do non-const > things with it. Even the thread does not own itself unless it has > been passed its own sole-ownership handle. This simplifies (imho) > reasoning about non-const operations on the thread. It simplifies the implementation and/or the documentation, and yes, simpler is better -- but only if the functionality that's taken away is not needed in practice. I don't think the boost::thread documentation claim that "it isn't needed very often" is acceptable. If even one valid use case exists that requires shared handles, then we either need shared handles or we need to show that the use case is in fact invalid. > Otoh, if there is > a shared-ownership model (reference semantics), then one has copyable > thread handles and getting a copy of your own handle is very sensible. I see things the other way around: if there are valid reasons for getting a copy of your own handle, then a shared-ownership model is sensible. > thread::id is a practical exception to this model. It is common to be > able to identify threads, especially to see if the last thread that > executed *here* is *me* (recursive mutex prime example). So > thread::id is copyable, and you can get a copy of your own > thread::id. One can only do const-things with a thread::id, making it > harmless to share (can't tell the difference between reference > semantics and value semantics). If I have shared thread handles, I can associate arbitrary data with a thread by a map<handle,data>. Independently, somebody else may have their own map<handle,data>. If I use thread::id in a similar way, how do I know when to dispose of the associated data? (if I remember correctly, if I have a thread::id, I can't check whether the corresponding thread has ended.) > In general: thread manipulation of yourself is neither specifically > allowed nor disallowed in N2184. There's a single owner to every > thread. If you want to manipulate that thread, you have to be the > owner, even if that thread is yourself. No special case. Although > joining with yourself could be considered hazardous to your health and > frowned upon by your universe as a whole. :-) Understood. Emil Dotchevski _________________________________________________________________ i'm making a difference. Make every IM count for the cause of your choice. Join Now. http://clk.atdmt.com/MSN/go/msnnkwme0080000001msn/direct/01/?href=http://im…

11 85

Re: [boost] [ublas] [units] interfacing with boost::ublas
by Matthias Schabel 28 Mar '07

28 Mar '07

> The implementation of type deduction of uBLAS is really > complicated, so > we are still looking for a simpler version. The use of result_type of > operator+ was already a big advantage. However the current > implementation assumes that all operation (+,-,*,/) follow the same > rules. A modification of this assumption would mean a big redesign of > many classes. Any help is welcome. Why is type deduction complicated? Is there some reason to not obey the rules followed by the compiler itself? You might want to look at the header operators.hpp in the proposed Boost.Units library in the Vault (mcs_units_v0.7.2.zip) - this file contains all the type deduction needed for this library, and the type operations needed for compile-time dimensional analysis have to be much more complex than those in ublas. Even if you don't have typeof support, it is possible to simply define the following helper classes specialized for the supported built-in types (if a bit tedious) : template<typename X> struct unary_plus_typeof_helper; template<typename X> struct unary_minus_typeof_helper; template<typename X,typename Y> struct add_typeof_helper; template<typename X,typename Y> struct subtract_typeof_helper; template<typename X,typename Y> struct multiply_typeof_helper; template<typename X,typename Y> struct divide_typeof_helper; template<typename X,typename Y> struct power_typeof_helper; template<typename X,typename Y> struct root_typeof_helper; so template<> struct add_typeof_helper<int,double> { typedef double type; } etc... Then all operators return the appropriate type : template<class X,class Y> typename add_typeof_helper<X,Y>::type operator+(const ublas<X>&,const ublas<Y>&); Deduction in expression templates should just happen correctly if they are implemented correctly, since you should just get : (x+y)*z -> multiply_typeof_helper< add_typeof_helper<X,Y>::type,Z>::type I have implemented this in my own array library with relatively little difficulty. Matthias

1 0

[optional] New implementation of boost/none.hpp hits Borland 5.6.4 bug
by Nicola Musatti 28 Mar '07

28 Mar '07

Hallo, unfortunately the recently committed changes to Boost.Optional uncover a bug in BCB6, i.e. borland 5.6.4 . As 1.34 is going to be the last Boost release to officially support this compiler, it would be very important to fix this problem before the release. I see that currently no tester is running tests for borland 5.6.4; if none is available I could run the tests locally on my machine and report back or, with a little hand-holding, run a full regression run. The bug can be observed by compiling the following very simple source file: #include <boost/optional.hpp> #include <sstream> This result in a rather incomprehensible error message: [C++ Error] _ctype.h(124): E2034 Cannot convert 'int *' to 'const ctype_base::mask *' The problem appears to be triggered by the relational operator overloads that take a none_t as a first argument (don't ask me why!). By commenting out lines 838-866 in boost/optional/optional.hpp the problem disappears. The only workaround I was able to find is to revert to the previous implementation of boost/none.hpp, as in the following: #include <boost/detail/workaround.hpp> namespace boost { #if ! BOOST_WORKAROUND(__BORLANDC__, <= 0x564) namespace detail { struct none_helper{}; } typedef int detail::none_helper::*none_t ; none_t const none = ((none_t)0) ; #else enum none_t {none = 0}; #endif } // namespace boost Given this is such a simple header it may be reasonable not to include boost/detail/workaround.hpp here and explicitly state the condition. Note that this problem is not present in borland 5.8.2. Cheers, Nicola Musatti

2 6

Re: [boost] [Review] Quantitative Units library review begins today March 26
by Steven Watanabe 28 Mar '07

28 Mar '07

AMDG "Eric Lemings" wrote: > <snip> > > Undoubtedly, the scope of this library should include the dimensional > analysis framework which defines the fundamental types/metatypes (e.g. > dimension, unit, quantity), their semantics, and their operations. It > should also include only the most common dimensions such as the physical > dimensions (time, length, mass, etc.) and allow, at least, other > universal > dimensions (e.g. currency). Other, more specialized dimensions should > be defined elsewhere. > That was one of out goals. The units that we have are implemented solely in terms of the dimension/unit/quantity framework. > The scope should not include any facilities for input and output. It > should also not prevent such support however. (Input and output of > units and measures can be handled by extending C++ locales with new > facets. C++ locales already deal with I/O of time and money. More > about internalization and localization below.) > Input is definitely beyond the scope of the library. We have implemented primitive output.... On further thought, we should probably just have an output operator for quantity that prints the value_type then the unit and leave unit output alone. > The scope should not classify units of measurement into exclusionary > systems. True, many programs/programmers will have restrictions that > prevent/exclude use of any units of measurement outside a well-known > set of units but the other extreme is also quite possible. A program > may allow arithmetic/conversions between any and all units known to the > development/operating environment. In such cases, the programmer is not > concerned in the least with systems of units and classification of > units into systems becomes totally irrelevant (and impossible for many > older and rarer units of measure). Therefore, if constraining units > into discrete systems is a desired objective, it should be the > responsibility of the program rather than the library. > Allowing conversion between units having different dimensions and allowing fundamental units whose dimensions are not fundamental e.g. quarts for volume is very very difficult to implement. Off hand, I think that it requires defining some special system (probably SI) and converting through that system. > Whether the scope should include a particuar system of units (e.g. SI > units, Imperial units) is debatable. Personally, I believe each system > of units should be treated much the same way C++ currently treats > locales. The library may contain, even mandate, a "default" set of > units (e.g. SI) but including even the most common modern units is > beyond the scope of the library. (Which units are modern? Which units > are common?) Each system of units can therefore be defined separately > as an extension to the underlying framework. > Absolutely > I'll post more specific review comments about the proposal later. > > Thanks, > Eric. > Thanks! In Christ, Steven Watanabe

7 16

[Review] Quantitative units - compile time vs runtime
by John Phillips 28 Mar '07

28 Mar '07

I'll get the ball rolling on the question of whether building a compile time only library is a good choice. My current thinking is yes, it is. I have three basic reasons for this, so I'll list them all below. If the library is going to include a runtime component, it would be for unit conversions on the fly. Various implementation details for this have been discussed in the past, but they always boil down to choosing some annointed set of units that the program will really use, and converting anything that is not in those units to the preferred system (usually during I/O). If answers for users are desired in something other than the preferred system, this conversion is done after the calculations are finished. The goal of this approach is to provide automatic unit conversion, and thereby simplify code, while minimizing the impact on program performance. In some settings I think this is a very usable answer to the problem. However, for my work in specific I do not think it is a good choice. My first problem is with code simplification. In theoretic physics (which is my background), unit systems are chosen based on the problem at hand. The goal is always to simplify the notation and to make reasoning about the problem more natural. If this is done successfully, expressing the resulting equations in code is cleaner and more obvious. For example, the units chosen for many electro-dynamic calculations lead to equations that have no constant multipliers. Lack of these multipliers means no magic numbers hiding in the code, so no way to get confused by said magic numbers. In the part of the code that is the actual calculation, this leads to simplicity and easier debugging, as well as eliminating a few multiplications or divisions. My second problem is with numerical accuracy and stability. The distribution of floating point representable numbers inside the set of the reals is not uniform. Nor is the relative error due to round off uniformly distributed. In most cases, the relative error is minimized close to 1.0. (See references such as Accuracy and Stability of Numerical Algorithms by Nicholas Higham for details.) Thus, it is almost always advisable to use units where the quantities in the code are in the range around 1.0 in numerical calculations. There is no silver bullet for numerical stability any more than there is for any other coding issue, but this is sually good advice. In some cases, a wise choice of units can even make a problem cease to use floating point arithmetic and become a purely integer arithmetic problem (An example would be monte carlo simulation of spontaneous magnetization using the Ising model. More generally, it happens in situations where the discrete nature of quantum states is important.). Obviously, since integer arithmetic is exact, this eliminates all concerns with round off issues. The third problem I see is one of efficiency. In a well chosen unit system there are very few multiplicative constants in the equations that describe the evolution and state of the system. (Systems that manage to have few or no constants and where the measurements of interest are of order 1.0 are sometimes called natural units for the problem.) In the primary calculation of a tight loop, every multiplication or division I can avoid is important. If all calculations actually happen in some pre-determined, but not natural for my problem set of units these multiplications and divisions cannot be avoided, and in some cases become the dominant part of the calculation's use of resources. For simulation work where doubling the operation count on the main loop can be the difference between a project that can be done and one that can't, this is unacceptable. This is my opinion, and the reasons for it. In my work I would not be able to use a system that imposes conversions. Nor would I suggest such a system to my students. I think a system with conversions might be built on top of the library Matthias and Steven have provided (though I'm not sure, since I haven't tried), but one with conversions would be very hard to use as a platform for those of us who need to not have conversions. Thus I think the chosen design is a good one. John

2 1