- Boost - lists.boost.org

[1.43.0][preprocessor] BOOST_PP_SEQ_FOR_EACH doesn't work recursively
by Adam Badura 21 May '10

21 May '10

BOOST_PP_SEQ_FOR_EACH macro when used within another BOOST_PP_SEQ_FOR_EACH does not expand at all (and the same happens with _R versions). I use Visual Studio 2005. A simple test is: >>>>>>>>>>>>>>>>>>>> #include <boost/preprocessor.hpp> #define SEQ \ ( ( n1 )( n2 )( n3 ) ) \ ( ( n4 )( n5 )( n6 ) ) #define CAT( _r, _data, _elem ) \ BOOST_PP_CAT( _data, _elem ) #define JOIN( _r, _seq ) \ BOOST_PP_SEQ_FOR_EACH_R( _r, CAT, ::, _seq ) #define MAKE( _r, _data, _elem ) \ JOIN( _r, _elem ) BOOST_PP_SEQ_FOR_EACH( MAKE, nil, SEQ ) <<<<<<<<<<<<<<<<<<<< The expected result is something like: >>>>>>>>>>>>>>>>>>>> ::n1 ::n2 ::n3 ::n4 ::n5 ::n6 <<<<<<<<<<<<<<<<<<<< while it is not. Instead we get something like: >>>>>>>>>>>>>>>>>>>> BOOST_PP_SEQ_FOR_EACH_M(3, (CAT, ::, ( n1 )( n2 )( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(4, (CAT, ::, ( n2 )( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(5, (CAT, ::, ( n3 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(4, (CAT, ::, ( n4 )( n5 )( n6 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(5, (CAT, ::, ( n5 )( n6 ) (nil))) BOOST_PP_SEQ_FOR_EACH_M(6, (CAT, ::, ( n6 ) (nil))) <<<<<<<<<<<<<<<<<<<< It seems to me that something is wrong with BOOST_PP_SEQ_FOR_EACH(_R) because following JOIN macro works well in this test case: >>>>>>>>>>>>>>>>>>>> #define JOIN( _r, _seq ) \ BOOST_PP_LIST_FOR_EACH_R( \ _r, \ CAT, \ ::, \ BOOST_PP_TUPLE_TO_LIST( BOOST_PP_SEQ_SIZE( _seq ), BOOST_PP_SEQ_TO_TUPLE( _seq ) ) \ ) <<<<<<<<<<<<<<<<<<<< While all it does it to use BOOST_PP_LIST_FOR_EACH_R instead of BOOST_PP_SEQ_FOR_EACH_R and change the given sequence to a tuple and then that tuple to a list. Adam Badura

2 1

[Booster] Or boost is useless for library developers
by Artyom 21 May '10

21 May '10

Hello, I want to bring up an important issue that boost developers are not aware of: anybody who develops a library and wants to keep any kind of backward compatibility can-not use Boost. Issue, let's assume I want to develop a small library that keeps backward comparability well. Let's assume I want to use `boost::shared_ptr` as one of the most important parts of boost in my library interface... Impossible. why? Even, for such a small part of boost with stable (even tr1) definitions it is impossible to promise that it would not be broken between releases. Why boost::details::sp_counted_base may be changed because in next version atomic counter was implemented using assembly rather then pthread's mutex... which affects the layout of boost::details::sp_counted_base and thus breaks compatibility. That is not a first time I bring up this issue. But at this point I started to bring a some kind of solution. I do need boost for my FOSS project CppCMS <http://cppcms.sf.net>. I was trying for a long period use renamed version of Boost (with a small tool I written similar to BCP's renamer) inside the library not showing the interface outside but finally I realized that I need boost in interface. I need ASIO, I need shared_ptr, I need regex, I need thread and much more... So I created a small library I called "booster" as part of CppCMS project that has a goal - provide backward compatible and stable boost like library that can be used by other libraries. It has following libraries: - smart_ptr: intrusive_ptr, shared_ptr, - function - locale (full copy of Boost.Locale I develop) - regex (pcre-wrapper, no replace functionality, no wide api) - system (meanwhile without error_condition) - thread (partial) - aio - my own ASIO like library. - ptime - Posix time (very different from boost one) For this purposes I did: - Adopted some of boost code to booster (shared_ptr/intrusive_ptr) and made sure that it would not break ABI with internal changes. - Wrapped pthreads with boost.thread like interface (in any case boost.thread is more like pthreads with C++ interface). So under windows it requires pthreads-win32 library. - I wrapped pcre library with boost.regex like interface. - I had written my own Boost.Asio like library (Booster.AIO) that has very limited use of templates. It uses epoll/devpoll/kqueue where available and poll or select on other platforms (no IOCP as it adds many limitations). - It uses CMake instead of Boost.Build. - It supports **only** modern compilers: gcc>=3.4, MSVC-2008 (2005 should work as well, but not tested), intel 11 compiler. - It is little bit less Windows friendly then Boost - no auto-link, no wide api, no IOCP support. Believe me it wasn't simple decision to start writing this library. But I just had no other choice. ------------------------------------------------ The source code can be found there (svn): https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/branches/refact… - I do not encourage anybody use it over boost, but if you have similar problems with boost as I have, you are welcome to take a look on it, try it. - I do think that boost is great library. - I would really prefer to use boost if it was not breaking ABI every few month. - I would probably adopt more boost libraries into booster (where possible) ------------------------------------------------------------- I want boost community to think about it... Is it right that developers of many libraries can't use Boost. Think of GTKmm, think of Qt, think of kdelib - that no-one can use it just because they promise backward compatibility. Maybe there is something wrong with it? Artyom.

27 110

Re: [boost] [challenge!] find a common domain
by Krishna Achuthan 21 May '10

21 May '10

"Eric Niebler" <eric(a)boostpro.com> wrote in message news:< 4BF5CA3B.8090807(a)boostpro.com>... > On 5/20/2010 10:54 AM, John Bytheway wrote: > > On 19/05/10 07:02, Eric Niebler wrote: > > <snip> > >> Your job: implement the deduce_domain3 template that finds the > >> common domain of 3 domains. You're allowed to use decltype, but you > >> get bonus points for a solution that doesn't. Bonus also for > >> instantiating fewest templates. The challenge is for the ternary > >> case, but your solution should scale to N domains. If your solution > >> is better than mine, I'll use it in Proto and credit you! > > > > I attach my solution for completeness, though I think Daniel's is > > neater. I used a similar idea to him, but without the use of > > sizeof/decltype, and with the distance-to-not_a_domain implemented > > as a metafunction, rather than injected into the definition of domain. > > > > I think we use about the same number of instantiations, but Daniel's > > lends itself to unrolling much more than mine. I might argue that > > my implementation is a little easier to follow than his, but it > > would be a pretty feeble claim. > > Thanks, John. I'll need to investigate more closely. Everybody's code > is easy to follow when they wrote it! :-) Though I admit, Daniel's > solution is subtle and had me scratching my head for a while. > > And for completeness, here is my (decltype-based) solution. I tried to > make one giant expression that calculates the result in one shot. Like > Daniel, I use inheritance and overloading, but I build a parallel > hierarchy instead of reusing the domains. (For reasons that aren't > relevant, I don't want domains to actually inherit from other domains > in > Proto.) > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com > Here's another try. No inheritance or function overloading. I have no idea how many template instantiations are there in this code and if it is acceptable. There is some influence from Daniel's solution in getting the default_domain resolutions right. - Krishna Achuthan

1 0

Let's use stack exchange!
by Gennadiy Rozental 21 May '10

21 May '10

Hi, I've always envied a bit how stackoverflow site was operating. I like the interface much better than mailing lists. Search, filtering, thread tracking... Now that the engine behind it is free http://www.joelonsoftware.com/items/2010/04/13.html I think we can benefit a lot from using it for boost. In addition it should help us with review managers issues. We can use "reputation" based system to qualify potential managers. In practice: who should agree to this and who would do the work? Gennadiy

9 13

[thread] Compiler eoorrs while running the tests
by vicente.botet 21 May '10

21 May '10

Hi, I get some compile errors with boost 1.43 gcc.compile.c++ ..\..\..\bin.v2\libs\thread\test\test_thread_return_local_lib.test\gcc-mingw-4.4.0\debug\threading-multi\test_thread_return_local.o ..\..\../boost/thread/detail/thread.hpp: In function 'boost::thread make_thread_return_local(boost::thread::id*)': ..\..\../boost/thread/detail/thread.hpp:111: error: 'boost::thread::thread(boost::thread&)' is private test_thread_return_local.cpp:16: error: within this context How can the following compile? boost::thread make_thread_return_local(boost::thread::id* the_id) { boost::thread t(do_nothing,the_id); return t; } Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 8

Re: [boost] [challenge!] find a common domain
by Krishna Achuthan 21 May '10

21 May '10

----- Original Message ----- From: <daniel(a)boostpro.com> Newsgroups: gmane.comp.lib.boost.devel To: <boost(a)lists.boost.org> Sent: Thursday, May 20, 2010 6:05 AM Subject: Re: [challenge!] find a common domain > On Wed, May 19, 2010 at 03:54:29PM -0700, Eric Niebler wrote: >> On 5/19/2010 3:29 PM, Daniel Wallin wrote: >> > On Tue, May 18, 2010 at 11:02:56PM -0700, Eric Niebler wrote: >> >> Your job: implement the deduce_domain3 template that finds the common >> >> domain of 3 domains. You're allowed to use decltype, but you get bonus >> >> points for a solution that doesn't. Bonus also for instantiating fewest >> >> templates. The challenge is for the ternary case, but your solution >> >> should scale to N domains. >> > >> > Here's mine. It's decltype based, but I guess it could be sizeof based >> > in C++03. >> >> Wow! SO much simpler than my solution. I'll need to study this in depth. >> I also specialized domain<default_domain> to insert an extra level in >> the inheritance tree like you did. That's a great simplification, but it >> took me a week to see that. Kudos. > > Thanks. :) > >> BTW, you're creating a zero-sized array in sized_type<0>. I just >> bumped all the integers by one and it works fine on msvc-10. > > Duh, good catch. > >> This looks more efficient at compile-time, too. I'll be embarrassed to >> post my solution. :-O But not yet. Anybody care to eliminate decltype so >> I can use this in Proto? Anybody think they can instantiate fewer templates? > > Here's one without decltype. The changes needed were pretty minor. It > might still be possible to reduce the number of instantiations. For > instance, you could specialize nth_domain<> on some more indicies (I'm > guessing the number of super domains should be fairly low), but I don't > know what the cost of specialization compared to instantiation is. > > -- > Daniel Wallin > BoostPro Computing > http://www.boostpro.com When I tried to compile the code using VC 2005, it failed with the following error: error C2064: term does not evaluate to a function taking 1 arguments deduce_domain.cpp 53 After I broke the struct into two pieces like below, it works fine. template <class D0, class D1> struct domain_depth { static const int value = domain<D0>::index - sizeof(domain<D0>::deduce((D1*)0)); }; template <class D0, class D1, int DefaultCase = sizeof(default_case((D0*)0, (D1*)0))> struct deduce_common : nth_domain<domain_depth<D0, D1>::value, D0> {}; - Krishna Achuthan

2 1

[geometry][units] Vector Class
by Terry Golubiewski 21 May '10

21 May '10

I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class. However, it could be done, so that is very good! The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T. terry

5 7

[Test] WinCE patch for floating point changes
by David Deakins 20 May '10

20 May '10

Hi Gennadiy, I noticed the recent floating point feature broke testing on Windows CE since it does not have the _controlfp_s function like full-blown Windows. Do you mind if I apply the attached patch to make testing work again (at least until a suitable real implementation is found for WinCE if possible). Thanks, -Dave

1 0

boost thread slow with only one thread
by Natacha Fort 20 May '10

20 May '10

hi! here is my problem i am multithreading my program with boost but i don't get what i expect, and i can't understand why! i just run one thread and wait for it, and the fps are divide by 3. basically with no thread i have 30fps, and with 1 thread i have 10fps. here is the code: Code: boost::thread_group forces_threads; forces_threads.create_thread(boost::bind(&ElasticRods::computeBendingForces,this,edges,kb,edges_initial)); forces_threads.join_all(); i use thread_group because i want to run 7 thread but it is already too slow! do you have an idea of why this is so slow? thank you for your help!

3 2

[config] Is there a macro to check if we are compiling in C++0x mode?
by vicente.botet 20 May '10

20 May '10

Hi, In Boost.Config I see "Macros that describe C++0x features not supported", but there is a macro to check if the compiler is working on C++0x mode? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2