- Boost-users - lists.preview.boost.org

[BGL] Possible bug in minimum_degree_ordering
by Jeppe N. Madsen 22 Dec '02

22 Dec '02

Hi, I'm fairly new to BGL so this may not be a bug after all......but I get a fair number of warnings about possible loss of data due to conversions (mainly between signed/unsigned types) with MSVC7 trying to compile the example below. Some may be ignored but at least line 188 of minimum_degree_ordering.hpp seems wrong: data[id[i]] = - (id[j] + offset); id[j] is unsigned, making (id[j] + offset) unsigned thus making the unary minus rather spurious. Also, compile time checks for correctly using signed types for the permutations would be nice :-) rgds Jeppe #include <iostream> #include <boost/graph/adjacency_list.hpp> #include "boost/graph/minimum_degree_ordering.hpp" #include <iostream> #include <boost/graph/adjacency_list.hpp> #include "boost/graph/minimum_degree_ordering.hpp" using namespace std; using namespace boost; int main(int, char **) { typedef adjacency_list <vecS, vecS, directedS> Graph; Graph G; add_edge(0, 1, G); add_edge(1, 0, G); add_edge(0, 2, G); add_edge(2, 0, G); add_edge(0, 5, G); add_edge(5, 0, G); add_edge(1, 2, G); add_edge(2, 1, G); add_edge(1, 3, G); add_edge(3, 1, G); add_edge(1, 6, G); add_edge(6, 1, G); add_edge(2, 4, G); add_edge(4, 2, G); add_edge(3, 4, G); add_edge(4, 3, G); add_edge(4, 5, G); add_edge(5, 4, G); std::vector<size_t> degree(num_vertices(G), 0); std::vector<int> inverse_perm(num_vertices(G), 0), perm(num_vertices(G), 0); std::vector<size_t> supernode_sizes(num_vertices(G), 1); property_map<Graph, vertex_index_t>::type id = get(vertex_index, G); minimum_degree_ordering (G, make_iterator_property_map(&degree[0], id, degree[0]), &inverse_perm[0], &perm[0], make_iterator_property_map(&supernode_sizes[0], id, supernode_sizes[0]), 0, id); for(size_t i = 0; i < num_vertices(G); ++i) std::cout << inverse_perm[i] << "\n"; return 0; }

1 0

boost::python abstract base class
by John Hunter 20 Dec '02

20 Dec '02

I am trying to get raw pointers and abstract base classes working properly with boost::python v2. I am working on an example inspired by the tutorial http://www.boost.org/libs/python/doc/tutorial/doc/inheritance.html. In my case, the base class has a pure virtual function, but I don't need to override it in python and call it from c++, so I don't think I need to do a BaseWrap. The problem is that if I try and expose Base to python, I get the compiler (gcc 3.2) error: g++ -isystem/usr/local/include -I/usr/local/include/python2.2 -fPIC -ftemplate-depth-100 -c rawpointer.cpp /usr/local/include/boost/python/object/value_holder.hpp: In instantiation of `boost::python::objects::value_holder<Base>': /usr/local/include/boost/type_traits/alignment_of.hpp:52: instantiated from `boost::detail::alignment_of_impl<boost::python::objects::value_holder<Base> >' /usr/local/include/boost/python/object/instance.hpp:29: instantiated from `boost::alignment_of<boost::python::objects::value_holder<Base> >' ...snip... rawpointer.cpp:47: instantiated from here /usr/local/include/boost/python/object/value_holder.hpp:36: cannot declare field `boost::python::objects::value_holder<Base>::m_held' to be of type ` Base' /usr/local/include/boost/python/object/value_holder.hpp:36: because the following virtual functions are abstract: rawpointer.cpp:15: virtual const std::string& Base::get_name() rawpointer.cpp:14: virtual void Base::sayit() const make: *** [rawpointer.o] Error 1 and if I only expose the derived classes, the code compiles but then I get a runtime error when I try and import the class in python >>> import rawpointer Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: extension class wrapper for base class 4Base has not been created yet >>> Below is my example code. Suggestions welcomed! John Hunter // work with raw pointers #include <iostream> #include <string> #include <boost/python.hpp> #include <boost/python/manage_new_object.hpp> using namespace boost::python; class Base { public: virtual ~Base() {}; virtual void sayit() const=0; virtual const std::string& get_name()=0; private: }; class Foo : public Base { public: Foo() : _name("Foo") {} void sayit() const { std::cout << "Foo" << std::endl; } const std::string& get_name() {return _name;} private: const std::string _name; }; class Bar : public Base { public: Bar() : _name("Bar") {} void sayit() const { std::cout << "Bar" << std::endl; } const std::string& get_name() {return _name;} private: const std::string _name; }; Base* barfactory(){ return new Bar(); } Base* foofactory(){ return new Foo(); } std::string simonsays(Base* p) {return p->get_name();} BOOST_PYTHON_MODULE_INIT(rawpointer) { class_<Base>("Base", no_init) .def("sayit", &Base::sayit); class_<Foo, bases<Base> >("Foo") .def("sayit", &Foo::sayit); class_<Bar, bases<Base> >("Bar") .def("sayit", &Bar::sayit); def("foofactory", foofactory, return_value_policy<manage_new_object>()); def("barfactory", barfactory, return_value_policy<manage_new_object>()); def("simonsays", simonsays); }

2 2

Why file_system build on msvc 6.5 is only dynamic?
by Daniel Yerushalmi 20 Dec '02

20 Dec '02

Hi All I got filesyetm from the CVS and build it using bjam (no args with VCVARS32.BAT of msvc 6.5) Only the folder: runtime-link-dynamic was created under bin/lisbfs.lib/msvc. Other libraies (i.e. thread) build by default also runtime-link-static. What should I do to do the build with static run time library? Thanks Daniel

3 5

Re: [Boost-Users] Re: Re: Preprocessor library question
by Tanton Gibbs 20 Dec '02

20 Dec '02

> Are all the record lengths constant at any given time? > > Paul Mensonides Yes, for any given invocation of the program the record lengths and the record field lengths are constant. It is only with different invocations of the program that the record lengths or field lengths can change.

1 0

Re: [Boost-Users] Re: Preprocessor library question
by Tanton Gibbs 20 Dec '02

20 Dec '02

Thanks for your response, I'll look through it and try to get a full grasp on everything you said. Basically, my problem is this I have to read in a file of fixed length records, manipulate them (e.g., sort, dedup, group, some custom processing ) and then write them out. There are about 40M records, so I want it to be as fast as possible. If I know the length of the record fields ahead of time, it is MUCH more efficient. However, I would like the field lengths to be customizable at runtime...I thought if I could precompute the program for various values of the 3 fields, then I could have the best of both worlds. However, I forgot about all the template instantiations...perhaps they'll just have to recompile when they want a new field length. Tanton ----- Original Message ----- From: "Paul Mensonides" <yg-boost-users(a)m.gmane.org> To: <boost-users(a)yahoogroups.com> Sent: Thursday, December 19, 2002 1:56 AM Subject: [Boost-Users] Re: Preprocessor library question > > "Tanton Gibbs" <thgibbs(a)deltafarms.com> wrote in message > news:024e01c2a725$6814d720$b048cc18@Corp.Acxiom.net... > > I'm trying to create a template class based on user input. For example: > > > > template< int i, int j, int k > class T {}; > > > > int main() { > > int i, j, k; > > cin >> i >> j >> k; > > T<i, j, k> t; > > } > > > > Naturally, this is not possible, as i, j, and k must be constants. > Therefore, I would like to limit the maximum value of i, j, and k to 100 and > create all permutations for T<i,,j,k> at compile time. Basically, something > like this: > > Hi Tanton, > > You realize that this will give you a 101*101*101 permutation right? While > the pp-lib can generate it, that is a pretty big block of code to be inside > a single function. I would try to separate it into separate functions if > possible: > > template<int i, int j, int k> struct bound { > static void target() { > T<i, j, k> t; > // ... > } > }; > > typedef void (* pf)(); > > template<int i, int j> pf bind(int k) { > switch (k) { > case 0: > return &bound<i, j, 0>::target; > break; > case 1: > return &bound<i, j, 1>::target; > break; > > // ... > > default: > return 0; > } > } > > template<int i> pf bind(int j, int k) { > switch (j) { > case 0: > return bind<i, 0>(k); > case 1: > return bind<i, 1>(k); > > // ... > > default: > return 0; > } > } > > pf bind(int i, int j, int k) { > switch (i) { > case 0: > return bind<0>(j, k); > case 1: > return bind<1>(j, k); > > // ... > > default: > return 0; > } > } > > int main() { > int i, j, k; > std::cin >> i >> j >> k; > bind(i, j, k)(); > // ... > } > > Will something like that work for you? Something similar to this is *way* > better than having an if structure with 101*101*101 conditional tests. If > so, here is an implementation: > > #include <iostream> > #include <boost/preprocessor/iteration/local.hpp> > > #define LIMIT 100 > > template<int i, int j, int k> struct bound { > static void target() { > std::cout << i << ' ' << j << ' ' << k << &std::endl; > return; > } > }; > > void overflow() { > std::cout << "overflow" << &std::endl; > return; > } > > typedef void (* pbound_f)(); > > template<int i, int j> pbound_f bind(int k) { > switch (k) { > #define BOOST_PP_LOCAL_MACRO(k) \ > case k: \ > return &bound<i, j, k>::target; \ > /**/ > #define BOOST_PP_LOCAL_LIMITS (0, LIMIT) > #include BOOST_PP_LOCAL_ITERATE() > default: > return &overflow; > } > } > > template<int i> pbound_f bind(int j, int k) { > switch (j) { > #define BOOST_PP_LOCAL_MACRO(j) \ > case j: \ > return bind<i, j>(k); \ > /**/ > #define BOOST_PP_LOCAL_LIMITS (0, LIMIT) > #include BOOST_PP_LOCAL_ITERATE() > default: > return &overflow; > } > } > > pbound_f bind(int i, int j, int k) { > switch (i) { > #define BOOST_PP_LOCAL_MACRO(i) \ > case i: \ > return bind<i>(j, k); \ > /**/ > #define BOOST_PP_LOCAL_LIMITS (0, LIMIT) > #include BOOST_PP_LOCAL_ITERATE() > default: > return &overflow; > } > } > > int main() { > int i, j, k; > std::cin >> i >> j >> k; > bind(i, j, k)(); > return 0; > } > > This works, but takes forever to compile--at least on Comeau C++. The > reason is not the use of the pp-lib though (that is fast), it is because of > the sheer amount of template instantiations. E.g. you get 101 > instantiations of the one-template-argument "bind," 10,201 instantiations of > the two-template-argument "bind," and 1,030,301 instantiations of the > "target" function (+ 1,030,301 instantiations of "T"). Even if you use the > "if/else if" statements (or nested switches), you still going to get > instantiations of "T" in the millions. That means that you have to 1) bite > the bullet and give up trying to do whatever you're doing with compile-time > values or 2) seriously reduce the maximum value (to about 10, for example). > In any case, the pp-lib can generate this, direct nested switches, or even > the permutations along the lines of "if/else if." The problem is massive > instantiation and massive code bloat no matter how you do it. IMHO, it just > isn't worth it. > > Another idea is to have an array of function pointers: > > pbound_f array[101][101][101] = { ... }; > > ...and initialize the elements with instantiations of some fully bound > function template (the pp-lib can, of course, do this as well). And use it > like this: > > array[i][j][k](); > > This will only avoid the first 10,302 instantiations though. You are still > going to get template instantiation in the millions. What are you trying to > do exactly? Maybe there is a better way. > > > Naturally, I don't want to type all that in myself, so I was hoping the > boost preprocessor library could do it for me. If someone knows of a way to > do it, please let me know. > > Regards, > Paul Mensonides > > > > > > > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > >

2 1

Using Boost.Build for non Boost projects?
by Felix E. Klee 19 Dec '02

19 Dec '02

Hi, from the Boost.Build documentation it is not clear to me whether Boost.Build is a system specifically designed for building Boost libraries or whether it is a general purpose build system. For example in the "Getting Started" section there are examples for setting up an independent project whereas in the "Design Criteria" section it is shown that Boost.Build was specifically designed for building Boost libraries. Now I wonder whether it is wise to use Boost.Build for non Boost projects or whether I should set up my own build system based on the original Perforce Jam (eg. because Boost.Build might become tightly integrated with Boost in the future). Felix

2 1

Build boost with vc7 toolset failed.
by Black Ice 19 Dec '02

19 Dec '02

vc 7 boost 1.29.0 set BOOST_ROOT=D:\boost\boost_1_29_0 set VISUALC="C:\Program Files\Microsoft Visual Studio .NET\Vc7" bjam "-sTOOLS=vc7" Command line error D2016 : '/Za' and '/Ze' command-line options are incompatible Any suggestion are appreciated.

2 1

Another threads question...
by Martin Johnson 19 Dec '02

19 Dec '02

Hi, Just to get it through my thick skull. >The threadmon.dll is a seperate library that's always dynamically linked. Then why not make threads a dynamic lib. As an exercise I attempted this though as I found that the template methods of condition a little troublesome. Could this not be reworked by reworking or typing the condition class. I am able to build the lib as a dll with threadmon.cpp included. It involves exporting all classes and crude hack to condition *just* to get it to work. It would appear to function correctly as far as I can see. With the cleanup handlers being called without requiring a seperate dll, though I guess this puts a static link a little out of the picture. But why would I static link anyway, for distribution purposes, but I have to distribute threadmon.dll What do you think? I am just trying to think of a way around it, I know you have been there done that but i just need to appreciate this a little better. Regards Martin Johnson

2 1

MacOS X MSL Mach-O Problem with Threads
by Bobby Thomale 19 Dec '02

19 Dec '02

It's me again with weird problems compiling Boost on the Mac! :-) I just converted my MacOS X code from CFM to Mach-O and I ran into another small compilation problem. This time, it is the thread code. Now that I am moved over to Mach-O, the _POSIX_THREADS flag is true, causing posix_features.hpp to set BOOST_HAS_PTHREADS to true. This seems to be causing all sorts of compiler errors. Probably due to the fact that, even though some of the posix headers are being included, I am using the MSL headers rather than the BSD headers, and my understanding is that none of that posix stuff will actually work until I eject the MSL in favor of the Unix C headers, which I am not prepared to do right now. That and the fact that since I am using Carbon, TARGET_CARBON is also true, therefore BOOST_HAS_MPTASKS is getting set to true. So anyway ... BOOST_HAS_PTHREADS and BOOST_HAS_MPTASKS are both getting defined. I would like to be able to control whether BOOST_HAS_PTHREADS gets defined, because I am actually wanting to use the MP libraries instead, despite _POSIX_THREADS being defined. It looks like how you handled this same problem with Windows was by adding a !defined(BOOST_HAS_WINTHREADS) to the condition as follows: # if defined(_POSIX_THREADS) && (_POSIX_THREADS+0 >= 0) && !defined(BOOST_HAS_WINTHREADS) # define BOOST_HAS_PTHREADS # endif One solution would be to add an additional check for MP Tasks as follows: # if defined(_POSIX_THREADS) && (_POSIX_THREADS+0 >= 0) && !defined(BOOST_HAS_WINTHREADS) && !defined(BOOST_HAS_MPTASKS) # define BOOST_HAS_PTHREADS # endif I did this in my local working copy and it seems to have fixed the problem. I had to add an additional "#define BOOST_HAS_MPTASKS" to my user.hpp to make sure that BOOST_HAS_MPTASKS got defined before the above check. I am not sure if this is the best way or if there is a better way to solve this problem. I suppose another approach would be to check for !defined(TARGET_CARBON) in the above check - if carbon is on, MP Tasks will get turned on. Or you could in the place where BOOST_HAS_MPTASKS gets defined, undef the BOOST_HAS_PTHREADS. But the way I solved it in my local copy (shown above) using !defined(BOOST_HAS_MPTASKS) seemed the cleanest to me, especially since it looks like it is how you solved the same problem for Windows. Anyway - I tried hard to find a way to make this compile without changing anything but my user.hpp but I failed. (If someone has any ideas I'd love to hear them.) -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------

2 2

compilation error with boost_1.29.0
by Volker Boerchers 19 Dec '02

19 Dec '02

Hi, I'm getting the following error on Linux 2.2.16 / Suse 7.0 / g++ 2.95.2 / glibc 2.1.3: ../../../../../include/boost/pool/detail/ct_gcd_lcm.hpp:43: sorry, not implemented: `static_cast_expr' not supported by dump_expr ../../../../../include/boost/pool/detail/ct_gcd_lcm.hpp:43: sorry, not implemented: `static_cast_expr' not supported by dump_expr The following patch fixes it: --- include/boost/pool/detail/ct_gcd_lcm.hpp.orig Thu Dec 19 15:10:54 2002 +++ include/boost/pool/detail/ct_gcd_lcm.hpp Thu Dec 19 14:58:41 2002 @@ -38,7 +38,7 @@ BOOST_STATIC_CONSTANT(unsigned, A_mod_B_ = A % B); BOOST_STATIC_CONSTANT(unsigned, value = (::boost::details::pool::details::ct_gcd_helper< - B, static_cast<unsigned>(A_mod_B_), + B, A_mod_B_, ::boost::type_traits::ice_eq<A_mod_B_, 0>::value >::value) ); }; What is the cast good for anyway? It seems redundant. Regards, Volker -- Volker Boerchers <vboerchers(a)tecon.de> System Engineer TECON Systems AG, Perlengraben 2, 50676 Köln, http://www.tecon.de Tel: +49-221-92007-55, Fax: +49-221-92007-77

1 0