- Boost - lists.boost.org

[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 16 Feb '10

16 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

[BGL/PM] Composition of two property maps
by Matthias Walter 16 Feb '10

16 Feb '10

Hi, I currently have a function which gets a graph plus an index-map and want's to call a BFS. Therefore it needs to build a color-map which maps vertex_descriptors to colors. As the user already gives a way to map vertex_descriptor to index, I'd like to use this mapping. What I need is a way to define a property map as a composition: composed-map (vertex_descriptor) -> color via color-map (index-map (vertex_descriptor)) -> color whereas index-map (vertex_descriptor) -> index and color-map (index) -> color Of course this should not be too difficult to implement, so I'd just like to ask whether there already exists some kind of implementation, because I neither found a hint by looking in the docs, nor by digging through some of the code. The actual reason I ask is because there might be other ways to come around the problem, e.g. making the color-map itself use vertex_descriptors as keys, so maybe my suggested solution is not the best. best regards Matthias Walter

2 1

C++0x and MSVC 10
by Zachary Turner 16 Feb '10

16 Feb '10

Playing with the release candidate of MSVC 10, and I'm noticing boost 1.42.0 is not using any C++0x features. Has this been discussed before, or is there a reason for this? Taking a peek at boost/config/compiler/visualc.hpp, I see the following: #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #endif // _MSC_VER < 1600 // C++0x features not supported by any versions #define BOOST_NO_CHAR16_T #define BOOST_NO_CHAR32_T #define BOOST_NO_CONCEPTS #define BOOST_NO_CONSTEXPR #define BOOST_NO_DEFAULTED_FUNCTIONS #define BOOST_NO_DELETED_FUNCTIONS #define BOOST_NO_EXPLICIT_CONVERSION_OPERATORS #define BOOST_NO_EXTERN_TEMPLATE #define BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS #define BOOST_NO_INITIALIZER_LISTS #define BOOST_NO_RAW_LITERALS #define BOOST_NO_SCOPED_ENUMS #define BOOST_NO_SFINAE_EXPR #define BOOST_NO_TEMPLATE_ALIASES #define BOOST_NO_UNICODE_LITERALS #define BOOST_NO_VARIADIC_TEMPLATES It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following? #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #else #define BOOST_HAS_AUTO_DECLARATIONS #define BOOST_HAS_AUTO_MULTIDECLARATIONS #define BOOST_HAS_DECLTYPE #define BOOST_HAS_LAMBDAS #define BOOST_HAS_RVALUE_REFERENCES #define BOOST_HAS_STATIC_ASSERT #define BOOST_HAS_NULLPTR #endif // _MSC_VER < 1600 Zach

7 13