- Boost - lists.boost.org

[test] regressions for vc 6.5/7.0
by Joaquín Mª López Muñoz 20 Feb '06

20 Feb '06

Hello, According to the maintenance plan of Boost.Test, the lib officially drops support for vc6.5/7.0 except that regressions showing up in the Boost libs regression tests page which are due to changes in Boost.Test will be taken care of. Well, the latter case has recently arisen, see for instance http://tinyurl.com/etpcg (there are a lot more, this is just an example.) These can be remedied (confirmed locally) by reverting to prior versions of the following files of Boost.Test which included explicit worakrounds for MSVC: class_properties.hpp --> v1.8 unit_test_suite.ipp --> v1.11 callback.hpp --> v1.5 Any chance of this being applied? I can do it myself if Gennadiy doesn't mind. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

gcc standard library experts out there?
by Robert Ramey 20 Feb '06

20 Feb '06

I'm addressing some test failures in the serialization library and need some help from someone who is knowledgable regarding the implementation of the standard library as it is delivered with the GCC compiler. http://tinyurl.com/s4ohn Shows the error message which is provoked by the following test code: // test array of objects BOOST_STD_EXTENSION_NAMESPACE::hash_set<A> ahash_set; ... std::vector<A> tvec, tvec1; std::copy(ahash_set.begin(), ahash_set.end(), std::back_inserter(tvec)); // error starts here std::sort(tvec.begin(), tvec.end()); a) I can't see anything wrong with this. b) No other compilers complain c) I can't follow the error message So if anyone has some insight here, I'd be glad to hear it. Robert Ramey

4 5

[MPL] libs/mpl/test/bool.cpp
by David Abrahams 20 Feb '06

20 Feb '06

This file contains a use of a runtime assert(), but none of the MPL tests are ever run. It would be better to use any construct that would at least cause the check to compile in release mode, e.g. (void)(condition), and best, I suppose, to actually run the test. Agreed? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: [boost] [configuring digital mars for boost]
by Jan Knepper 20 Feb '06

20 Feb '06

Thorsten Ottosen wrote: > Dear all, > > At boost (www.boost.org) we are trying to incorparate the digital > mars compiler into our regression testing. In not working very well, so > far. :-( > > We badly need people with intimate knowlegde of the strong/weak points > of the digital compiler to > > 1. Make sure the boost config system is correct for this compiler. If > these macros are not specicified correctly, its nearly impossible to get > any compiler to compile boost. > > 2. Help library authors with specific issues not covered by the config > system. > > If you would like to help us out, please write so > on the boost dev list: > > gmane.comp.lib.boost.devel > > (You have to sign up first, see > http://www.boost.org/more/mailing_lists.htm#main) > > best regards > > Thorsten As a matter in fact... just a couple of days ago I CVS'ed the latest boost down the pipe to take a peek at this... Jan -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org

1 0

STLPort 5.0 questions
by Robert Ramey 19 Feb '06

19 Feb '06

I've installed STLPort 5.0 in order to track down some test case errors. Right away I have a problem. It seems that by default STLPort 5.0 with VC 7.1 uses an unsigned short for wchar_t (I could be wrong, the information is kind of thin). I've looked at the config stuff and its not clear that config and STLPort address this issue. That is, its not clear whether the Boost Macro for this feature is guarenteed to be in sync with the way that STLPort 5.0 is built. The tests don't make it clear how the STLPort is built in this regard. Ideally, the config system would be able to set the appropriate BOOST macros in accordance with the particular build of STLPort library. I'm not sure whether or not such a thing is possible. I would be interested in hearing any information on this. Robert Ramey

1 0

[graph] minor patch for Borland testers
by AlisdairM 19 Feb '06

19 Feb '06

The following patch resolves some infinite loops that kill regression tests. Graph library is not supported on Borland compilers, so the following patch is mostly useful to: i/ people running regular regressions on this compiler ii/ someone trying to get a working port of graph library on Borland I am holding back other partial-fixes to boost-graph until I can show a reasonably large subset of the the library passing the tests. This one is a bit of a killer though: cvs diff -u -wb -- graph\random.hpp (in directory E:\sourceforge\devel\boost\boost\) Index: graph/random.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/graph/random.hpp,v retrieving revision 1.5 diff -u -w -b -r1.5 random.hpp --- graph/random.hpp 24 Mar 2005 15:06:44 -0000 1.5 +++ graph/random.hpp 19 Feb 2006 11:50:46 -0000 @@ -32,9 +32,13 @@ random_vertex(Graph& g, RandomNumGen& gen) { if (num_vertices(g) > 1) { + #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x581)) + std::size_t n = std::random( num_vertices(g) ); + #else uniform_int<> distrib(0, num_vertices(g)-1); variate_generator<RandomNumGen&, uniform_int<> > rand_gen(gen, distrib); std::size_t n = rand_gen(); + #endif typename graph_traits<Graph>::vertex_iterator i = vertices(g).first; while (n-- > 0) ++i; // std::advance not VC++ portable @@ -47,10 +51,15 @@ typename graph_traits<Graph>::edge_descriptor random_edge(Graph& g, RandomNumGen& gen) { if (num_edges(g) > 1) { + #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x581)) + typename graph_traits<Graph>::edges_size_type + n = std::random( num_edges(g) ); + #else uniform_int<> distrib(0, num_edges(g)-1); variate_generator<RandomNumGen&, uniform_int<> > rand_gen(gen, distrib); typename graph_traits<Graph>::edges_size_type n = rand_gen(); + #endif typename graph_traits<Graph>::edge_iterator i = edges(g).first; while (n-- > 0) ++i; // std::advance not VC++ portable I still need to investigate why boost::random is not working correctly, but in practice the random number generators used here produce an endless stream of zeros, which sends the 'find me another vertex' logic into an infinte loop. -- AlisdairM

3 3

[threads] Maintainers please contact me
by David Abrahams 19 Feb '06

19 Feb '06

Please send me an email if you're participating in maintaining the Boost.Threads library. Thank you, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Patches-1434821 ] rational::operator< fails for unsigned value types
by SourceForge.net 19 Feb '06

19 Feb '06

Patches item #1434821, was opened at 2006-02-19 16:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1434821&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: rational::operator< fails for unsigned value types Initial Comment: There's a minor bug in rational.hpp when using unsigned values. Consider the following simple program: int main(void) { boost::rational<unsigned int> x = 0; assert(x.operator<(1)); } The assertion fails. The reason is that in rational.hpp::rational<IntType>::operator< (param_type i) are the lines if (num > zero) return (num/den) < i; else return -i < (-num/den); The last line is bogus for unsigned types if num == 0 and i > 0. The problem can be fixed by changing (num > zero) to (num >= zero). Another issue with the same section of code is that it uses up to 5 comparisons of IntType values. Attached is a patch that fixes the bug described, and also makes the function only perform up to 3 comparisons. That can make a difference, of course, if IntType is a complicated type with a slow comparison operator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1434821&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [important] Preparing to Test Release Builds
by JOAQUIN LOPEZ MU?Z 19 Feb '06

19 Feb '06

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Febrero 19, 2006 8:44 pm Asunto: Re: [boost] [important] Preparing to Test Release Builds > Daniel James <daniel(a)calamity.org.uk> writes: > > > David Abrahams wrote: > >> functional > > > > The functional changes are all in my tests, and look good to me. > > Why is hashing located under functional? Because TR1 puts std::tr1::hash in <functional>, I think. > The functional library is > deprecated, IIRC. Do you mean Boost.Functional? I can't seem to find any notice about deprecation of this library. In any case, my understanding is that this lib is in no way connected to Boost.Hash, except that both extend <functional>, hence the name clashing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[shared_ptr] utility for shared-only classes
by Jordan DeLong 19 Feb '06

19 Feb '06

I find myself often writing some boilerplate stuff to make a class usable and creatable only with shared_ptr's. For example, stuff of the form: struct A : private boost::noncopyable { static boost::shared_ptr<A> create(int); // ... private: explicit A(int); }; Anyway, I made a little utility to simplify this, which looks like: struct A : private boost::noncopyable { // ... private: friend class shared_new_access; explicit A(int); ~A(); // only shared_new_access can delete us, also }; And then later: boost::shared_ptr<A> pa = shared_new<A>(some_int); The shared_new function template also works generally as a way to create new shared_ptr's, since shared_new_access will still have access to public constructors and destructors also. It also has the same forwarding problem thing that people have run into when making auto_ptr_new() or other such utilities. So anyway: is there any interest in this for boost? It is pretty small and straight-forward, but I can post an implementation of it to the vault (or to this list, if that is preferred for something this small), if there is some interest. -- Jordan DeLong fracture(a)allusion.net

2 2