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

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

Preprocessor library question
by Tanton Gibbs 19 Dec '02

19 Dec '02

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: int main() { int i, j, k; cin >> i >> j >> k; if( i == 0 && j == 0 && k == 0 ) { T<0,0,0> t; } else if( i == 0 && j == 0 && k == 1 ) { T<0,0,1> t; } ... else if( i == 100 && j == 100 && k == 100 ) { T<100,100,100> t; } } 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. Thanks! Tanton [Non-text portions of this message have been removed]

2 1

Matrix-Matrix reference
by Wilken, Marc 18 Dec '02

18 Dec '02

Hello, does ublas support a matrix method like blitz++ .reference() method? (This method allows different matrices to share the same matrix datas.) Marc Wilken This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.

2 2

Problem with "this" and shared_ptr
by Michael Brinkmann 18 Dec '02

18 Dec '02

Hello, given the following code which uses shared_ptrs, I'm getting a double-free onto an object of type A: ------------------------------------------------------ #include <boost/shared_ptr.hpp> #include <list> #include <iostream> class A { public: A(void){} void makeSomething(void); void makeSomethingOther(void) { std::cout << "A" << std::endl; } }; typedef boost::shared_ptr<A> APtr; class B { public: B(const APtr& a) : mA(a) {} void makeSomething(void) { std::cout << "B" << std::endl; mA->makeSomethingOther(); } private: APtr mA; }; void A::makeSomething(void) { B b(this); // here I want to hand over the "A" shared pointer to "B", but I have only my "this" at hand. std::cout << "A" << std::endl; b.makeSomething(); } int main(void) { APtr a(new A); a->makeSomething(); } ------------------------------------------------------ (please don't ask me about why I'm doing it in that way, the code is stripped down from a much bigger program) I understand that the problem results from the accesss to "this" in the commented line. Is there an elegant way to get the shared_ptr pointing to "this" from "this", which would be the solution to the fault? Or do I have to store a shared_ptr member variable referencing "this" in the class A which is set by a A::method from outside of A to reference it? (not very beautiful) Sorry if this is a FAQ, but I didn't find a solution on news.gmane.org kind regards Michael

4 6