May 2004 - Boost - lists.preview.boost.org

[boost] Finding operator==(directory_iterator&, directory_iterator&)
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

In trying to compile the filesystem library, I'm getting an error that the compiler cannot find the operator== for the following function: bool is_empty_directory( const fs::path & dir_path ) { return fs::directory_iterator(dir_path) == end_itr; } aCC-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/acc/debug /operations_posix_windows.o Error 226: "../../../libs/filesystem/build/../src/operations_posix_windows.cpp", line 176 # No appropriate function found for call of 'operator =='. class directory_iterator doesn't declare it, neither do ancestors iterator_facade and iterator_facade_types. Can't find free function for operator==(directory_iterator&, directory_iterator&), operator==(iterator_facade&, iterator_facade&), operator==(iterator_facade_types&, iterator_facade_types&) or any of its variants. Is it using the default compiler-generated operator== in directory_iterator? Can somebody who is familiar with the filesystem library code assist me so I can generate a test case for the HP aC++ team? Thanks! -Jerry

2 1

Re: [boost] Big integer library
by Richard Peters 12 May '04

12 May '04

I have once again uploaded a new version of my big integer library (available at http://groups.yahoo.com/group/boost/files/big_integer/, version 0.3). The divison algorithm is completely new, and this time it is fast (it now uses Knuth's algorithm). The code is also reorganised, which made it quite easy to build in support for GNU MP and CLN. When either of those two libraries is available, set BOOST_BIG_INTEGER_USE_GMP or BOOST_BIG_INTEGER_USE_CLN, and those libraries will be used to implement the basic arithmetic functions. Those libraries aren't completely supported yet, a few functions (mostly conversion functions from types larger than int) need to be implemented correctly (it's kindof hacked together right now), and most noticeable, cln hasn't got power_mod yet, because I was unable to find the matching function in the cln library. That aside, it shows that it is quite easy to make the library work with other libraries to provide speedy implementations with a uniform interface. Best regards, Richard Peters ----- Original Message ----- From: "Joel Young" <jdy(a)cs.brown.edu> > > I made a simple program with some big numbers that demonstrate the > speed difference: > > The summary is that big_integer is making millions of > iterator calls and lexicographical_compares, while even > boost::rational using long long is just making a few calls > to things like boost::gcd. > > Joel

3 2

[Boost-bugs] [ boost-Bugs-952713 ] incomplete connected components with disjoint_sets
by SourceForge.net 12 May '04

12 May '04

Bugs item #952713, was opened at 2004-05-12 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952713&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: incomplete connected components with disjoint_sets Initial Comment: I am trying to understand why the order in which I add edges to an adjacency_list graph has some effect on the connected components I get using incremental_components. Using the listing below, with Boost release 1.30.0 (also 1.31.0) with g++ 2.95 (cygwin) I get the following: > g++ -I./boost_1_31_0 -o ok -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./ok rank[0] = 0 rank[1] = 0 rank[2] = 0 rank[3] = 1 rank[4] = 0 parent[0] = 3 parent[1] = 3 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 1 0 This is what I expect. If I change the order in which I add edges to the graph, I get a different answer: > g++ -I./boost_1_31_0 -DSHOWBUG -o bug -ftemplate- depth-40 incremental-components-eg-bug.cpp > ./bug rank[0] = 0 rank[1] = 0 rank[2] = 1 rank[3] = 2 rank[4] = 0 parent[0] = 3 parent[1] = 2 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 0 This is not what I expect. The single connected component has lost a vertex. But it should be the same graph, the only difference being the order in which I called add_edge(). Is this a bug or a misunderstanding on my part? Any advice would be appreciated... Jeff #include <iostream> #include <vector> #include <algorithm> #include <utility> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> int main(int, char *[]) { using namespace boost; // Create a graph typedef adjacency_list < vecS, vecS, undirectedS > Graph; typedef graph_traits < Graph >::vertex_descriptor Vertex; const int N = 5; Graph G(N); add_edge(0, 3, G); add_edge(0, 4, G); #ifndef SHOWBUG add_edge(1, 4, G); add_edge(1, 2, G); #else add_edge(1, 2, G); add_edge(1, 4, G); #endif // create the disjoint-sets object, which requires rank and parent vertex properties std::vector < Vertex > rank(num_vertices(G)); std::vector < Vertex > parent(num_vertices(G)); typedef graph_traits<Graph>::vertices_size_type* Rank; typedef Vertex* Parent; disjoint_sets < Rank, Parent > ds(&rank[0], &parent [0]); // determine the connected components, storing the results in the disjoint-sets object initialize_incremental_components(G, ds); incremental_components(G, ds); for (unsigned int i = 0; i < rank.size(); ++i) { std::cout << "rank[" << i << "] = " << rank[i] << std::endl; } for (unsigned int i = 0; i < parent.size(); ++i) { std::cout << "parent[" << i << "] = " << parent[i] << std::endl; } typedef component_index < unsigned int >Components; Components components(parent.begin(), parent.end()); for (Components::size_type i = 0; i < components.size (); ++i) { std::cout << "component " << i << " contains: "; for (Components::value_type::iterator j = components [i].begin(); j != components[i].end(); ++j) std::cout << *j << " "; std::cout << std::endl; } return EXIT_SUCCESS; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952713&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 12 May '04

12 May '04

I'd appreciate if someone on the list could try the following in VC7.1 and report the results: template<typename T> struct A { template<typename Q> void operator()(const Q&){} }; template<typename T> struct B: private A<T> { using A<T>::operator(); }; int main() { B<char> b; b(3); return 0; } The regression tests for multi_index seem to indicate that VC7.1 is having trouble with this kind of construct and I'd like to make sure before applying any fix. Curiously enough, this problem also shows up in GCC for versions under 3.4, as confirmed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9810 Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

RE: [boost] Re: changing aCC-Link-action
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

I've attached changes with your suggestions. I tested it and it worked!! I'm starting to like bjam, now how does it compare to ant?? =) (we're still using gnu make here). I've also added the line: flags acc CFLAGS <inlining>off : +d The +d option prevents inlined functions from being inlined, useful for debugging -- assuming that's what the option is meant to do. -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Wednesday, May 12, 2004 7:54 AM To: boost(a)lists.boost.org Subject: [boost] Re: changing aCC-Link-action Rene Rivera wrote: > flags acc CFLAGS <target-types>$(SHARED_TYPES) : +z ; > flags acc LINKFLAGS <target-types>$(SHARED_TYPES) : -b ; Oops :-) That should be "target-type", singular not plural. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Regression tests: EXIT STATUS: 666
by Joaquín Mª López Muñoz 12 May '04

12 May '04

Regression status reports list the following run output for some tests of my lib in CWPro8: EXIT STATUS: 666 And nothing more (see for instance http://tinyurl.com/2e56z) Anyone has a clue what this is about? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost::date_time: ISO compliant IO for periods/durations?
by Daniel Krügler 12 May '04

12 May '04

Hello boosters, I would like to know whether there already exist ISO 8086 conforming extractors/inserters for the duration/period classes? Specifically I am looking for io/string functions which can handle "Periods of Time, no Specific Start or End", which begin with a 'P' following a list of periods, e.g. "P18Y9M4DT11H9M8S" (18 years, 9 months, 4 days, 11 hours, 9 minutes and 8 seconds) (I am using the term period in the sense ISO 8086 seems to do, i.e. including durations and periods - or did I overlook something?) Thanks for any help, Daniel

3 5

regex lib bug: \u and icase
by Benzinger, Ralph 12 May '04

12 May '04

Hello, Regular expressions "[\u]" and "\u", unlike "[[:upper:]]", will not match any letters when the icase flag is set. Similarly, "\U" will match anything. Expressions "\l" and "\L" seem to be fine due to the lower_case_map[] translation. My suggestion would be to replace classes.push(traits_type::char_class_upper); and the like by classes.push((_flags & regex_constants::icase) ? traits_type::char_class_alpha : traits_type::char_class_upper); in the 'syntax_u/U/l/L' cases in set_compile() and set_expression(). This approach is currently taken in the 'syntax_open_set' case in set_compile(). John may have a different fix in mind, though. :-) Regards, Ralph

2 1

[Boost-bugs] [ boost-Bugs-952335 ] Build Boost.Python from minwg gcc
by SourceForge.net 12 May '04

12 May '04

Bugs item #952335, was opened at 2004-05-12 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952335&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Build Boost.Python from minwg gcc Initial Comment: I try compile Boost.Python from minwg, and i recive compile error. Boost: CVS HEAD 2004-05-12 Os: WinXP Compiler: gcc (GCC) 3.2.3 (mingw special 20030504-1) (MinGW-3.1.0-1.exe) bjam: Boost.Jam Version 3.1.9. OS=NT. command line: c:>boost\libs\python\build>bjam -sTOOLS=mingw - sPYTHON_ROOT=C:/Lang/Python23 - sPYTHON_VERSION=2.3 Full output in attached file. Some output lines: gcc-C++- action ..\..\..\bin\boost\libs\python\build\boost_python.dl l\mingw\release\slice.obj In file included from C:/Lang/sf.net/boost/libs/python/src/slice.cpp:1: C:/Lang/sf.net/boost/boost/python/slice.hpp:29: warning: `dllexport' attribute ignored C:/Lang/sf.net/boost/boost/python/slice.hpp:29: declaration does not declare anything C:/Lang/sf.net/boost/boost/python/slice.hpp:29: parse error before `)' token C:/Lang/sf.net/boost/libs/python/src/slice.cpp:18: prototype for ` boost::python::slice::slice()' does not match any in class ` boost::python::slice' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952335&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

changing aCC-Link-action
by DY, JERRY U (SBCSI) 11 May '04

11 May '04

I would like to add options to the compile and link line used for building the threads library. I have added as follows but not sure if it's the proper place for it. With these changes, I'm able to cleanly compile and build the threads shared lib using aC++ 3.55 compiler. Credit to the HP aC++ team for their help on hpux.hpp changes. boost_1_31_0/tools/build/v1/acc-tools.jam:105 $(acc.bin-directory)$(CXX) -AA -mt +z -w -c +W823 -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDR S)" -I"$(STDHDRS)" -o "$(<)" "$(>)" boost_1_31_0/tools/build/v1/acc-tools.jam:82 $(acc.bin-directory)$(CXX) $(LINKFLAGS) -AA -mt -b -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) boost_1_31_0/boost/config/platform/hpux.hpp:63 #define BOOST_HAS_PTHREADS -Jerry

2 1