- Boost - lists.boost.org

Patches status
by Marshall Clow 15 Apr '06

15 Apr '06

These are the submitted patches that are waiting to be integrated/rejected/whatever. Thanks to everyone who has helped! As always, if you see one that is mis-assigned, or you think that one marked "nobody" is right for you, please don't hesitate to jump in. ;-) Thank you for your cooperation! Patches per assignee: Jonathan Turkanis 4 David Abrahams 1 Ronald Garcia 1 Robert Ramey 1 Roland Schwartz 1 Here are the currently submitted patches, sorted by assignee. Assignee: david_abrahams <http://sourceforge.net/users/david_abrahams/> Summary: Explicitly delete registered converter chains Bug #: 1464421 <http://sourceforge.net/tracker/index.php?func=detail&aid=1464421&group_id=7…> Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: Boost.Serialization for std::bitset Bug #: 1029258 <http://sourceforge.net/tracker/index.php?func=detail&aid=1029258&group_id=7…> Assignee: rgarcia <http://sourceforge.net/users/rgarcia/> Summary: [concept_check.hpp] remove unused variable warning in msvc Bug #: 1388901 <http://sourceforge.net/tracker/index.php?func=detail&aid=1388901&group_id=7…> Assignee: speedsnail <http://sourceforge.net/users/speedsnail/> Summary: [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report Bug #: 1430820 <http://sourceforge.net/tracker/index.php?func=detail&aid=1430820&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational::operator< fails for unsigned value types Bug #: 1434821 <http://sourceforge.net/tracker/index.php?func=detail&aid=1434821&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational.hpp::gcd returns a negative value sometimes Bug #: 1438626 <http://sourceforge.net/tracker/index.php?func=detail&aid=1438626&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational::operator<(rational) fails due to overflow Bug #: 1438991 <http://sourceforge.net/tracker/index.php?func=detail&aid=1438991&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: iostreams // file_descriptor::seek BUG on files > 4 GB Bug #: 1452698 <http://sourceforge.net/tracker/index.php?func=detail&aid=1452698&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

status of fibonnaci_heap and mutable_queue
by Fernando Cacciola 15 Apr '06

15 Apr '06

Does anyone know the satus of these pending libraries? I'm in need of a mutable priority queue. TIA Fernando Cacciola

4 11

[Filesystem] Querying a card reader can throw on Windows
by Angus Leeming 14 Apr '06

14 Apr '06

Hi, Beman. If I understand correctly, the idiom to check whether a directory exists using Boost.Filesystem is if (fs::exists(path) && fs::is_directory(path)) Under normal conditions the code above shouldn't throw, right? One of our users reports that this code does, however, throw when it is used on Windows to query a card reader that has a drive letter J: assigned to it. Below is a diagnostic program that attempts to query a nonexistent "J:\foo". Executing it, our user finds: 1. If no drive is associated with J: then the program outputs nothing. 2. If an empty drive is associated with J: Exception caught: boost::filesystem::is_directory: "J:\foo": The device is not ready. Assertion failed: false file ekkehart.cpp, line 40 3. If the drive contains a disk the program outputs nothing. He goes on to say: The problem described disappears if I do one of the following: 1. Reassign another letter to the smart cars slot (such that J: is not assigned to any drive) 2. Reassign J: to a used slot (in my case the compact flash slot) and insert a card. 3. Remove the card reader. Conclusion: You should have either no drive assigned to J: or a drive with an inserted medium. This is with the current release of Boost, 1.33.1. Is this a known problem (is there a workaround) or have we stumbled upon a bug? Kind regards, Angus /* Compiled with g++ -fno-exceptions -Iboost -o ekkehart ekkehart.cpp \ -Lbuild/boost/libs/filesystem/src/.libs -lboost_filesystem */ #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> #include <cassert> #include <cstdlib> #include <exception> #include <iostream> namespace fs = boost::filesystem; int main() { fs::path const path("J:/foo", fs::no_check); if (fs::exists(path) && fs::is_directory(path)) std::cout << path.native_directory_string() << "is a directory" << std::endl; return 0; } namespace boost { void throw_exception(std::exception const & e) { std::cerr << "Exception caught:\n" << e.what() << std::endl; assert(false); } void assertion_failed(char const * expr, char const * function, char const * file, long line) { std::cerr << "Assertion triggered in " << function << " by failing check \"" << expr << "\"" << " in file " << file << ":" << line << std::endl; ::abort(); } } // namespace boost

2 1

[parameter] Lack of safety?
by Fred Bertsch 14 Apr '06

14 Apr '06

There are cases where boost::parameter can translate its arguments to the wrong arguments at the function implementation side. I'm hoping that I'm doing something wrong, but it seems like a problem with the parameter library. The parameter library suggests creating global variables named with the names of the arguments to your function. If you have an inner scope at the calling site with a variable with the same name, things don't work. I'm okay if this simply results in a compiler error, but in some fairly simple cases, it can correctly compile to the wrong call to the implemented function. Here's an example: void FooImpl( int x, int y ) { // Gets x = 8, y = 14. We wanted x = 12, y = 8. } BOOST_PARAMETER_KEYWORD( tags, x ) BOOST_PARAMETER_KEYWORD( tags, y ) typedef boost::parameter::parameters< tags::x, tags::y > FooParams; template< typename ArgumentPack > void FooImpl( ArgumentPack const& args ) { typename boost::parameter::binding< ArgumentPack, tags::x, int >::type xx = args[ x | 12 ]; typename boost::parameter::binding< ArgumentPack, tags::y, int >::type yy = args[ y | 14 ]; FooImpl( xx, yy ); } // Some overloads are left out. This shouldn't matter. template< typename T0 > void Foo( T0 const& a0 ) { FooImpl( FooParams()( a0 ) ); } void Bar( int y ) { ... Foo( y = 8 ); ... } Notice that Bar has an argument with the same name as one of the global variables declared with BOOST_PARAMETER_KEYWORD. I can't think of a general solution to this problem. It might be better to use the call syntax "Foo( y( 8 ) );" instead because overloaded function call operators are less common than assignment operators. This does not remove the danger, however; it only disguises it better. Another solution might be to put all of the global variables in their own named namespace so that one has to qualify their use. E.g.: "Foo( arg::y = 8 );". Some other naming convention might also mitigate the problem. Note that my example looks fairly artificial because I've simplified it so much, but it's not as unlikely as it looks. The global variable is called something that meaningfully describes the argument. It is not so unlikely for a caller to have a variable with the same purpose in the context of the call, and it is not unlikely for that to have the same name. Hopefully I'm missing something important here. Please correct my misunderstanding if that's true. -Fred Bertsch

3 4

[review] Review Manager Needed
by Ronald Garcia 14 Apr '06

14 Apr '06

Hi all, Of the current set of libraries in the review queue, only one lacks a review manager. It would be great if some boost veteran stepped up and took on this role for the following library: Pimpl Pointer ------------- :Author: Asger Mangaard :Review Manager: Need Volunteer :Download: Boost Sandbox (http://boost-consulting.com/vault/) under pimpl_ptr. :Description: The pimpl idiom is widely used to reduce compile times and disable code coupling. It does so by moving private parts of a class from the .hpp file to the .cpp file. However, it's implementation can be tricky, and with many pitfalls (especially regarding memory management). The pimpl_ptr library is a single header file, implementing a special policy based smart pointer to greately ease the implementation of the pimpl idiom. Thank you, Ron Garcia Boost Review Co-Wizard

1 0

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 14 Apr '06

14 Apr '06

David Abrahams wrote: > Valentin Samko <boost(a)digiways.com> writes: > > > DA> auto(x){ x->first < 0 } > > > > This is quite similar to what we are considering for polymorphic > > lambdas, > > <>(x) { return x->first < 0; } > > Except 1/3 longer, and, I guess for some people, there's a huge > difference in aesthetics Yes. Looking at the current paper by Doug Gregor and others, I don't like the syntax: <>( int x ) -> bool { return x == 10; } It is too different from "normal" function declerations. Dave's auto(x) is closer and given a choice I would prefer that one. Lambda functions and expressions should scale well, for example, in a GUI application: copy( range( 0, listbox.get_length()) | transform( auto( item ) { QtString str; listbox.get_item_text( item, str ); return std::wstring( str ); } ), v.begin()); where you need to do a conversion inside the lambda function before returning it. Here, it might be easier to define that transformation function externally, but this doesn't work all of the time. It also makes the code harder to follow if you have a lot of similar functions/ function objects that vary very slightly. Another example would be manipulating pair/tuple objects and doing a transform on them before returning from the lambda function. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[type_traits] is_convertible<noncopyable,To> crashes
by JOAQUIN LOPEZ MU?Z 14 Apr '06

14 Apr '06

Hello, In a post from yesterday (see http://tinyurl.com/hzk5w) Alexei Alexandrov found a rather serious problem with is_convertible in at least MSVC 7.1 and Intel 9.0, namely that is_convertible<From,To> fails to compile when >From is non-copyable, emitting an error message like this: boost/boost/type_traits/is_convertible.hpp(254): error: class "XXX" has no suitable copy constructor BOOST_STATIC_CONSTANT(bool, value = ... where XXX is the From argument. Needless to say, some fix for this issue would be most welcome. I'm sorry I cannot provide any more help than a mere report of the problem. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 14 Apr '06

14 Apr '06

Gennadiy, my computer time is too limited these days to allow me to write an elaborate answer. Let me return to you by the end of this week or the beginning of the next one. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Jueves, Abril 13, 2006 5:35 pm Asunto: Re: [boost] [multi_index]terminology/design concern > > > Essencially. The same way as book index allows to jump to proper > > > page based > > > on keyword. Could you show some code example? What I want is to > > > iterate > > > through all persons with last name "Smith". All operations should > > > have > > > contant complexity. > > > > So, if your multi-index container is defined like this: > > > > typedef multi_index_container< > > address, > > indexed_by< > > ordered_non_unique< // (last_name,first_name) index > > composite_key< > > address, > > member<address,std::string,&address::last_name>, > > member<address,std::string,&address::first_name> > > > > > > > > ... // other indices > > > > > > address_book_t; > > > > address_book_t b; > > > > then you can write the following: > > > > void list(const std::string& last_name) > > { > > std::pair<address_book_t::iterator,address_book_t::iterator> p= > > b.equal_range(last_name); > > std::copy( > > p.first,p.second, > > std::ostream_iterator<address>(std::cout)); > > } > > > > You require that all ops are constant complexity, which is > > not entirely fulfilled by my example, since equal_range is > > O(log n). On the other hand, I cannot see why your indexing > > concept must guarantee constant complexity and not only fast > > lookup. > > That's the primary reason I would need an Index. Aa Order may have > have > different complexity guarantees. But in some cases I need > partucular search > to be performed much faster then it is guaranted by order search > complexity. > Essentially I am looking for an ability to do something like this: > > address_book_t ab; > typedef address_book_t::order<2>::type full_name_order; > > // this operation is compile time > full_name_order fno = ab.get_order<FullName>(); > > // this operation has constant complexity, since Last name Index > provide > direct access > std::pair<full_name_order::iterator,full_name_order::iterator> > p = fno.get_index<LastName>::equal_range( "Smith" ); > > ... > > In some cases Index could have non-constant complexity, but still > could be > used to significantly speedup orderred collection search. Lets say > I have > Input messages log ordered sequencially (meaning that the order is > just > natuaral order messages where comming in). And I have int64 number > of theses > comming in every day. Now for this order I want to define Time > index to > speedup lookup for messages in partucilar time interval. This > operation most > probably wont be constant (due to continues nature of time) but > still could > be implemented much faster then global serach through messages > collection. > In addition for the same collection I may want to define Symbol > (some > attribute in a messages) order. And for that order I need first > letter > index. > My primary point in above examples is that both Order and Index > are first > class citizents and current desing doesn't account for the latter. > > > > IMO we need another level of indirection that would support Index > > > within an > > > Order concept. I do not see how existing design could handle this. > > > If the need for the kind of bookmarking (allow me to use this term > > so as to not mix the different meanings we're giving to the > > word "index") you describe is sufficiently general, such a facility > > can be built separately from B.MI itself (like a standalone > > view-like library) or integrated into B.MI as an index decorator: > > > > typedef multi_index_container< > > element, > > indexed_by< > > bookmarked< > > ordered_unique<...> > > > > > ... > > > > > > > > > > So, the bookmarked<...> construct can embed any preexistent index > > ("order" in your terminology) type and supplement it with > > bookmarking facilities, provided we had a precise definition of > > what bookmarking boils down to. This kind of stuff can be done > within> the current design, but then again I yet fail to see how > what you > > describe is a general need not sufficiently covered by current > > facilities, like for instance compatible keys in ordered > > indices --clarification here most welcome. > > I am not really crazy about the term Bookmark. IMO Order/Index is > much > better reflect the nature of the concepts we are trying to model. > But above > is step in right direction IMO. > > Gennadiy > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

darwin missing clock_gettime (causing problems in shmem)
by Ian Fasel 14 Apr '06

14 Apr '06

I was trying to use the shmem library on darwin and ran into errors because darwin does not have a clock_gettime function. I believe there needs to be something like a BOOST_HAS_CLOCK_GETTIME in config.hpp -- either there, or in shmem. Then the following patch for shmem would probably be appropriate: --- shmemlib-0-orig/boost/shmem/sync/xtime.hpp 2005-12-30 19:32:02.000000000 +0000 +++ shmemlib-0/boost/shmem/sync/xtime.hpp 2006-04-11 22:24:09.000000000 +0000 @@ -102,12 +102,19 @@ #else - + + #if defined BOOST_HAS_CLOCK_GETTIME timespec ts; clock_gettime(CLOCK_REALTIME, &ts); xtp->sec = ts.tv_sec; xtp->nsec = ts.tv_nsec; - return clock_type; + #else + struct timeval tv; + if (gettimeofday (&tv, 0) == 0) { + xtp->sec = tv.tv_sec; + xtp->nsec = tv.tv_usec*1000; + } + #endif #endif return clock_type; With this patch, I am able to get the examples in shmem to build. Unfortunately, it then fails in boost::shmem::detail::mutexattr_wrapper::mutexattr_wrapper because pthread_mutexattr_init fails. I can go into more info about the problems with shmem on darwin if this is useful to anyone. I realize this may be the wrong list for this post since shmem is still in 0.9 development, so please point me in the right direction if so. -Ian Fasel

3 4

[thread] Poll for users of MPtasks
by Roland Schwarz 14 Apr '06

14 Apr '06

I am intending to drop support for MPTasks on the Mac platform in the thread rewrite. Since there currently are also no regression test builders available for the Mac platform I am polling the list if there are any objections against this plan. Background: I contacted the original contributor of the mac code in boost and got the below information: >> These days, Mac OS 9 is obsolete, and anyone building on Mac OS X can just use the pthreads implementation. Therefore, I think that it's safe to move these old files. << and >> The lowest-level threads on Mac OS X are Mach Threads (Mac OS X is based on BSD with a Mach kernel). pthreads sit directly above Mach Threads. The old Boost Threads implementation was based on MP tasks. MP tasks still exist on Mac OS X, but on top of TS Threads, which are on top of pthreads. << and >> As I noted above, I don't believe the the Mac needs much special attention anymore, given the move to POSIX-based OS X. << This makes me believe, that it is safe to drop support for MPTasks entirely. However in the thread rewrite it will be possible to get both, a default build that relies on pthread being available and native support if possible. So if anyone thinks boost thread on Mach Threads is meaningful, please contact me at the thread devel list. BTW.: Possibly the 1-34 release should write out a message that informs users of MPTasks that support will be dropped? Roland

2 1