February 2010 - Boost - lists.boost.org

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 17 Feb '10

17 Feb '10

> > it is inevitable, etc., but.. read on. I know at least one library in > > Boost that also spoils function declarations in order to provide > > additional functionality: Concept Check library; they may be others > > too (MPL?). > > My suggestion is that if there are (or will be) libraries that require > > spoiling function declarations, they should all provide the same > > "spoiled" syntax. Otherwise I will be always asking "how do I declare > > a function in this library?". It would be very convenient if Boost > > provided one alternative function definition syntax that when used > > would enable all its libraries to work. > > I agree. However, in the past I did look into harmonizing my library > API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it > did not seem feasible... I will double check it. This is not only about clarity. As a super-correct programmer I may want to apply both concept checking and pre-/post-conditions checking to my functions. Perhaps, if the 'compromise' syntax is possible, it requires changing concept-checking library. Regards, &rzej

1 0

[variadic_templates][mpl]interest in compile time matrix multiplication?
by Larry Evans 17 Feb '10

17 Feb '10

For example, with: > ***domain_matrix: > ( 11 12 13 ) > ( 21 22 23 ) the following: > typedef > outer_product_pack > < plus_times_row_column<arg<1>,arg<2> > > >::apply > < domain_matrix > , domain_matrix > >::type > outer_plus_times_rows_rows; > > std::cout<<"***outer_plus_times_rows_rows:\n"; > for_each<outer_plus_times_rows_rows>(printer); produces: > ***outer_plus_times_rows_rows: > ( 434 794 ) > ( 794 1454 ) The plus and times operations can be replaced with any compile-time binary operation. Any interest? -regards, Larry

4 4

[Boost][gsoc]Intrest - big integer library
by Kamil Witecki 17 Feb '10

17 Feb '10

Hello all, I'd like to propose new library for boost - a Big Integer library. Boost has plenty of applications build upon it and some of them has to use integers greater that those ensured by C++ standard. What is more some of them needs even Pythonlike "unbounded" integers. What I am proposing is library implementing cross-platform library supporting such integers working as standard arithmetic type. Is it a good proposal for GSoC project and who would you recommend as a possible mentor for such project? Pozdrawiam, Kamil Witecki.

10 10

[Boost.Preprocessor] FOREACH( MACRO, ... )
by Daniel Larimer 17 Feb '10

17 Feb '10

Is there a reason why Boost.Preprocessor does not have many (any?) utilities for variadic macros? I have implemented a FOREACH( MACRO, ... ) that results in the following expansion MACRO(ARG1) MACRO(ARG2) ... Implemented as such: #define FOREACH_ARRAY( ... ) (PP_NARG(__VA_ARGS__) , ( __VA_ARGS__ ) ) #define FOREACH( A, ... ) BOOST_PP_REPEAT( PP_NARG(__VA_ARGS__), A, FOREACH_ARRAY(__VA_ARGS__) ) #define CASE(z,n,data) case BOOST_PP_ARRAY_ELEM( n, data ): FOREACH( CASE, a, b, c, d, e) case a: case b: case c: case d: case e: Depends upon this macro: #define PP_NARG(...) \ PP_NARG_(__VA_ARGS__,PP_RSEQ_N()) #define PP_NARG_(...) \ PP_ARG_N(__VA_ARGS__) #define PP_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63,N,...) N #define PP_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9,8,7,6,5,4,3,2,1,0

3 4

[thread] thread_specific_ptr, dangerous conflation of identity and address
by Edd Dawson 17 Feb '10

17 Feb '10

Hi folks, A thread_specific_ptr appears to use its own address as a key. For example, the two tss objects created below will likely share the same key: void f() { thread_specific_ptr<int> ptr; // ... } int main() { f(); f(); } When thread_specific_ptr's destructor is called, it does a reset() which clears the data for the thread doing the destruction. However, data for other threads still remain. I find this asymmetric behaviour a little strange. Why should all threads but one see their old data? The bigger problem though, is that it might not be *their* old data. It can just as easily be someone else's old data due to coincidental alignment of different thread_specific_ptrs on the stack at entirely unrelated points in the program, or even in different libraries that each happen to use boost::thread_specific_ptr! void g() { thread_specific_ptr<float> ptr; // ... } f(); g(); It's easy to see the problem here as the calls are very close to one another. In general, however, this strikes me as being really rather dangerous behaviour. Would it be fair to call it a bug? It seems it is only safe to allocate thread_specific_ptrs in static storage. A complete example is listed at the end. It exhibits the kind of behaviour I'm talking about on my x86 systems, at least. Kind regards, Edd //#define BOOST_ALL_NO_LIB 1 #include <queue> #include <iostream> #include <boost/thread/tss.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/barrier.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> using namespace boost; typedef function<void ()> task_type; // Simple multi-producer-single-consumer job queue. // Manages its own consumer thread. class jobq { public: jobq() : dying_(false), consumer_(bind(&jobq::work_loop, this)) { } ~jobq() { exit_work_loop(); consumer_.join(); } void add(const task_type &task) { unique_lock<mutex> lk(mtx_); tasks_.push(task); arrival_.notify_one(); } private: void exit_work_loop() { unique_lock<mutex> lk(mtx_); dying_ = true; arrival_.notify_one(); } bool wait_for_task(task_type &task) { unique_lock<mutex> lk(mtx_); while (!dying_ && tasks_.empty()) arrival_.wait(lk); if (dying_) return false; task = tasks_.front(); tasks_.pop(); return true; } void work_loop() { task_type task; while (wait_for_task(task)) task(); } private: bool dying_; std::queue<task_type> tasks_; mutex mtx_; condition arrival_; thread consumer_; }; template<typename T> void access_tsp(thread_specific_ptr<T> &tsp, barrier &b) { if (!tsp.get()) tsp.reset(new T(-1)); else std::cout << "Already initialized to " << *tsp << "!\n"; b.wait(); } template<typename T> void f(jobq &q) { barrier b(2); thread_specific_ptr<T> tsp; q.add(bind(&access_tsp<T>, ref(tsp), ref(b))); b.wait(); // wait until it's safe to destroy tsp } int main() { jobq q; f<int>(q); f<unsigned>(q); return 0; }

4 6

Re: [boost] [Boost][gsoc]Intrest - big integer library
by Kamil Witecki 16 Feb '10

16 Feb '10

I see that even a simple, but robust, implementaion covering each case (possibly some of them awaiting implementations of apropriate policy) would be hard, if not infeasible, to be done in such a short period of time as is given in GSoC. On the other hand I would take a deeper look in that topic and meanwhile look for another proposition. Many thanks for all your answers and clarifiyng all the infarmation and possible problems. Kamil Witecki.

1 0

Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

okay, I got it. Okay, I never cared about the project-config.jam file (maybe because the user_config file is mentioned after bootsrap.sh). I just put the using intel-linux stuff inside projetc-config: if ! intel-linux in [ feature.values <toolset> ] { using intel-linux : 10.1 : /lrz/sys/intel/icc_101/bin/icpc : <compileflags>"-fPIC" <linkflags>"-fPIC" ; } instead of the user_config. That's it. Don't know why it doesn't work for intel with user_config but for the gcc. However, I hope it'll work.. Thank @all, SirAnn -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

@ Normal 0 21 false false false DE X-NONE X-NONE Volodya > Well, just do that in project-config.jam? Or, alternatively, remove project-config.jam -- and have only user-config.jam be used. Okay, but which one is that? (location?) I can see your name in the jam files very often, thus you are to be the one who can help me out, dont' ya? @Dick Normal 0 21 false false false DE X-NONE X-NONE >If you build an executable that will dynamically load (with dlopen) shared libraries, then all of its code, including whatever it gets from static libraries, has to be compiled and linked with -fPIC. >This leads us to compile and link all of our code, including boost libraries, with -fPIC. bullseye! that's the problem that we have.. thus we have to turn on the fPIC option.. But I don't get it work for the intel compiler.... Do you have a solution? -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

3 2

boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

Hello I just try to compile boost 1.42 on the Altix-HPC in Munic. Problem is that I need to compile it with turned on -fPIC cxx-flag. Following steps I'd done: 1. run ./bootstrap.h --prefix=... --with-toolset=intel-linux 2. modify tools/build/v2/user_config.jam: ... using intel-linux : : : <cxxflags>-fPIC ; ... (according to http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r…) 3. run ./bjam --> error: error: at /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/project.jam:884 error: duplicate initialization of intel-linux with the following parameters: error: version = <unspecified> error: previous initialization at /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/project.jam:884 What's the matter? What point did I miss? Please help ;-) SirAnn -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

4 4

Re2: boost 1.42 - compile toolsset=intel-linux with fPIC
by "Sören Freudiger" 16 Feb '10

16 Feb '10

Normal 0 21 false false false DE X-NONE X-NONE > Take a look at project-config.jam -- it already has 'using intel....'. > I suggest you remove whatever setting you've made in tools/build/v2/user-config.jam. But that's especially what I wanna to: add the fPIC flag for the gcc version it works fine!) > Further, why are you even trying to use -fPIC. When building shared libraries, -fPIC is used already. Some of our guys have to link because of certain reasons against the static libs from boost and obtain the error boost should be compiled with turned on fPIC flag... -SirAnn -----Ursprüngliche Nachricht----- Von: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] Im Auftrag von Vladimir Prus Gesendet: Dienstag, 16. Februar 2010 17:18 An: boost(a)lists.boost.org Betreff: Re: [boost] boost 1.42 - compile toolsset=intel-linux with fPIC "Sören Freudiger" wrote: > Hello > I just try to compile boost 1.42 on the Altix-HPC in Munic. Problem is > that I need to compile it with turned on -fPIC cxx-flag. > > Following steps I'd done: > > 1. run ./bootstrap.h --prefix=... --with-toolset=intel-linux 2. modify > tools/build/v2/user_config.jam: > > ... > using intel-linux : : : <cxxflags>-fPIC ; ... > > (according to > http://www.boost.org/boost- build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.intel) > > 3. run ./bjam > > --> error: > error: at > /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/proj > ect.jam:884 > error: duplicate initialization of intel-linux with the following > parameters: > error: version = <unspecified> > error: previous initialization at > /home/hlrb2/pr95gi/lu78wol/libs/boost_1_42_0/tools/build/v2/build/proj > ect.jam:884 > > What's the matter? What point did I miss? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0