- Boost - lists.preview.boost.org

Off topic:making replies threaded
by Tonko Juricic 28 Jul '04

28 Jul '04

I use http://news.gmane.org/gmane.comp.lib.boost.devel to read group archives and I send my replies from Yahoo mail. After trying several variations on mail Subject prefixes I still can not make my replies appear as the part of the thread, when viewed from Gmane. I am sure some will find those 'detached' replies as annoying as I do so any suggestion on how to fix it would be much appreciated. Tony __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

3 2

filesystem thoughts/issues
by Jeff Flinn 28 Jul '04

28 Jul '04

I'm now getting into using the filesystem library. Of course the first thing I've run into is the need to generate lexically relative paths. Having the luxury of being able to discount links, I have a working solution, atleast for windows. Some issues that arose are related to a path as a sequence container. While not show stoppers, the lack of some sequence container member functions - such as size(), assign(itr,itr) - required that existing templated classes be refactored to allow use of path as a template argument. Additionally lacking is a const_iterator type. size() is used to determine the 'shorter' of two paths whose path::iterator are passed to std::mismatch as the controlling (beg,end] arguments. The pair of iterators returned by std::mismatch are used to populate the common, first_remainder and second_remainder paths. If there is interest in this code I can post it. Any thoughts on providing additional sequence container member functions and typedefs in a post 1.32 release? Also any plans on incorporating Richard Johnson's globiter facilities? It would be nice to have a filtered_directory_iterator in any case. Something like: filtered_directory_iterator ( const fs::path& , boost::function1<bool,const std::string&> ) as a convenience class based on the boost::filter_iterator. Then I could: std::for_each ( filtered_directory_iterator( aPath, bind( extension, _1 ) == ".hpp" ) , filtered_directory_iterator() , SomeFnc ); Then perhaps 'globbing' would be better supported as an additional regex syntax_option_type? This would keep filesystem from depending on regex. Jeff F

1 0

Range/compat2 is not correct
by Stefan Slapeta 28 Jul '04

28 Jul '04

compat2.cpp is failing on VC 7.1 and the compiler seems to be right: there is a 'typename' missing! Stefan ..\libs\range\test\compat2.cpp(45) : warning C4346: 'range_iterator<Container>::pts<C>::type' : dependent name is not a type prefix with 'typename' to indicate a type

2 2

difference_type for int in numeric_traits
by DY, JERRY U (SBCSI) 28 Jul '04

28 Jul '04

In boost/detail/numeric_traits.hpp, integer_traits can be used to find the difference_type for an int type, in aC++, I get a long long -- I don't think that's the correct result, but can somebody please tell me why not? Thanks! integer_traits<int>::difference_type // long long?? I expect this to be an int Here's why: template <class Integer, bool = true> struct integer_traits { ... typedef typename if_true<(int(x::is_signed) // true && (!int(x::is_bounded) // true || (int(x::digits) + 1 >= digit_traits<boost::intmax_t>::digits))) // false >::template then< Integer, typename if_true<(int(x::digits) + 1 < digit_traits<signed int>::digits)>::template then< // false signed int, typename if_true<(int(x::digits) + 1 < digit_traits<signed long>::digits)>::template then< // false signed long, // else intmax_t // this is long long >::type>::type>::type difference_type; ... } -Jerry

1 0

Missing '\' in boost/serialization/export.hpp ?
by Jonathan Wakely 28 Jul '04

28 Jul '04

Should there be a backslash at the end of line 235 in boost/serialization/export.hpp ? jon

1 0

Intel: uBLAS and range go DR, random still unresolved
by Stefan Slapeta 28 Jul '04

28 Jul '04

I've submitted a Intel 8 DR for two obvious compiler defects: test2 in uBLAS and the iterator_range in iterator (ICE). Is there nobody feeling competent/responsible to give any hint for the random failure? I don't know if I can find it on my own. Stefan

1 2

VC 7.1 warning in linear_congruential.hpp
by Stefan Slapeta 28 Jul '04

28 Jul '04

in rand48::operator () [...]\linear_congruential.hpp(218) : warning C4244: 'return' : conversion from 'boost::uint64_t' to 'boost::int32_t', possible loss of data Patch attached. Stefan RCS file: /cvsroot/boost/boost/boost/random/linear_congruential.hpp,v retrieving revision 1.18 diff -u -r1.18 linear_congruential.hpp --- linear_congruential.hpp 27 Jul 2004 03:43:32 -0000 1.18 +++ linear_congruential.hpp 28 Jul 2004 15:09:10 -0000 @@ -215,7 +215,7 @@ void seed(uint64_t x0) { lcf.seed(x0); } template<class It> void seed(It& first, It last) { lcf.seed(first,last); } - int32_t operator()() { return lcf() >> 17; } + int32_t operator()() { return static_cast<int32_t>(lcf() >> 17); } // by experiment from lrand48() static bool validation(int32_t x) { return x == 1993516219; }

1 0

RE: [boost] Boost Test Library: Bug in floating-point comparison?
by Rozental, Gennadiy 28 Jul '04

28 Jul '04

> Hi, > > I want to use the boost::test floating-point comparison > algorithms (Boost > 1.31.0) and wrote the following simple lines of code: > > double d1 = 0.2; > double d2 = 0.8; > double d3 = d2-d1-d1-d1-d1; // d3 should be zero > > bool b = boost::test_toolbox::check_is_closed( d3, 0., 1e-3 ); > > To my surprise, the return value b is FALSE, although d3 > should be _very_ > close to zero (and is 5.55112e-17 on my machine). > > Am I missing something or is this a bug in the test library? > > Thanks, > Michael > > -- > Michael Kettner > kettner(a)ive.uni-hannover.de Read algorithm description. The algorithm compare "relative errors". In your case it's 1 and infinity. Definitely more then 1e-03. It you want to compare absolute values (which is not recommended in real life applications) you either could write you own predicate or wait a bit, while I am considering adding BOOST_IS_SMALL tool that will be responsible namely for this kind of test. Gennadiy.

2 1

RE: [boost] Re: RE: Re: DLL library (Was: Re: additional boostlibraries?)
by Reece Dunn 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >Bronek Kozicki wrote:mechanism Garland wrote: > >> This isn't really a re-invention of either -- just a very small library >that > >> does someskeletonsilar to what both do -- without all the baggage. COM > >> is a > >> Windows only option, for example. Both are big frameworks with gobs of > >> stuff not needed to load a dll and call a function. > > > > I think that similar motivation drove YAMI project, see > > http://www.msobczak.com/prog/yami/ > >Do you mean "without all the baggage" by "similar motivation"? What I see >on >the page is still very complex -- some network communication and the like. > >I want just portable mechanism to access objects from shared libraries. >This >is much more lightweight than CORBA, which requires IDL, stubs, skeletons, >supports talking to objects on other machines, a lots of other stuff. Frameworks like COM and CORBA are designed to be language independent: this is why they use IDL for describing interfaces. Since what you require is C++-specific, you can skip the IDL language and use abstract base classes and/or virtual functions, which is what Volodya is doing. The frameworks also provide some means of generic exception handling. COM skips this by returning an error code (HRESULT) value because of the issues of dealing with exceptions across language borders (e.g. C++ to C). The C++ exception mechanism is fine for what Volodya wants because there will be no cross-language problems. The frameworks may provide some means of automation. COM uses a discriminant union type (VARIANT) and a dispatch interface to achieve this, as well as providing direct access via the interfaces. I don't think scripting is an important issue in this case, but it should be possible to implement using Boost.Spirit :). The frameworks provide a mechanism for managing object lifetimes. COM does this by the base interface supporting AddRef/Release with the DLL responsible for construction (via exposed object types) and the object responsible for deconstruction (deleting itself once the reference count is 0). As I see it, this is intended to be implemented using shared_ptr's, the issue being *how* to load the objects and DLL's. In COM the object is responsible for keeping the DLL alive (via a reference count on the DLL as has been mentioned in other posts). If there are two objects from the DLL alive, then the DLL's reference count is two (unless it is explicitly locked to keep it alive). The MS documentation on DllMain says: During initial process startup or after a call to LoadLibrary, the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point function. Thus, if the DLL is already loaded by a process, it will not reload it on successive calls to LoadLibrary. The documentation on FreeLibrary says: The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL). When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. Thus, there is no easy way to reload a DLL. The best solution would be to release the instance of the plugin you have loaded and let the system unload the DLL. It is best to only be concerned about the DLL when loading the plugin. If you want to alter plugins at run-time (e.g. removing or adding a plugin), just remove all references to the plugin to delete it or load the plugin into the plugin map from the DLL. The frameworks provide other facilities, but I think these are the main (core) facilities. I am not sure how this will map to Linux or MacOS systems. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Building Libraries in Boost
by Jody Hagins 28 Jul '04

28 Jul '04

Most of boost is implemented in header files (as most is based on templates). However, what are the guidelines for splitting code into compilable units? For example, if a library is not a template library, should the author strive to implement it entirely in headers as inline functions, or should it be implemented as part inline functions and part a compiled library? A fair amount of code uses the PIMPL pattern to reduce header complexity, reduce interface and implementation exposure, and to reduce compile times. However, this requires, in large part, separate compiled libraries. What is the Boost position in this regard? Thanks!

2 1