- Boost-users - lists.boost.org

RE: [Boost-users] Re: Conversions between shared_ptr<Base>andshared_ptr<Derived>
by Ben Hutchings 12 Feb '04

12 Feb '04

Konstantin Baumann <boost(a)ks-baumann.de> wrote: > For performance reasons I would like to see something like the > following conversion operators in shared_ptr<T>: > > template<class T> > class shared_ptr { > public: > ... > template<class S> > operator shared_ptr<S>&() throw() { > BOOST_STATIC_ASSERT(T* is convertible to S*); > return reinterpret_cast<shared_ptr<S>&>(*this); > } > > template<class S> > operator const shared_ptr<S>&() throw() const { > BOOST_STATIC_ASSERT(T* is convertible to S*); > return reinterpret_cast<const shared_ptr<S>&>(*this); > } > > }; // class shared_ptr<T> > > This would mimic the standard conversion from T* to S* without any > performance penalty for shared_ptr<T>. <snip> Don't sacrifice correctness for performance. First, the reinterpret_cast results in undefined behaviour. If you think you know that the actual behaviour is OK, you are wrong. If S is a base class of T then the conversion of T* to S* generally requires changing the bits of the pointer, unless S is the first non-virtual base. Second, if we can create a reference of type shared_ptr<S> to an object of type shared_ptr<T>, then we can also modify that object to contain a pointer of type S* which may not be convertible to T*.

1 0

RE: [Boost-users] Re: Thread creation state
by janardhan.guptha＠efi.com 12 Feb '04

12 Feb '04

The rest of the applicatin is just creating the object and preparing it for execution. I am using Win32 version of boost.Thread implementation. The creation code snipet is void main() { testCommand *tObj = new testCommand(11); tObj->createthread(); tObj->runthread(); } -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Michael Glassford Sent: Wednesday, February 11, 2004 12:17 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: Thread creation state It would be a lot easier to help if you could post a complete, compilable example that demonstrates the problem. Also, it would be useful to know whether you are using the Win32, pthread, or Mac implementation of Boost.Thread. Thanks, Mike <janardhan.guptha(a)efi.com> wrote in message news:433CFA26BCA852438922F929E3D07955AE53A7@blraddc02.efi.internal... > I am creating a boost thread, how to know in which state it is created. > I have a code snippet that is waiting always in the thread creatin functon > istelf. Where as i tried with some boost samples, they are working amazingly > perfect. This is how my code snippet looks like > > typedef boost::mutex::scoped_lock lock; > class testCommand { > static void threadfunc() { > testCommand *testObj = mMapCommand[mObjID]; > testObj->processthread(); > }; > > static map< int mObjID, testCommand*> mMapCommand; > private: > void createthread() { > mThread = new boost::thread(&testCommand::threadfunc); > } > void processthread() { > lock lk(mMutex); > mCondition.wait(lk); > //// Some Action > }; > > void runthread() { > lock lk(mMutex); > mCondition.notify_one(); > }; > > public: > static int mObjID; > boost::thread *mThread; > boost::condition mCondition; > boost::mutex mMutex; > }; > > > The newly created thread is waiting at the following location forever, by > the time > i get a chance to execute the new thread is greatly delayed. > > NTDLL! 77f8856e() > boost::detail::thread::lock_ops<boost::mutex>::unlock(boost::mutex & {...}) > line 49 > boost::detail::thread::scoped_lock<boost::mutex>::unlock() line 85 + 11 > bytes > boost::detail::thread::scoped_lock<boost::mutex>::~scoped_lock<boost:: mutex> > () line 74 > `anonymous namespace'::thread_param::started() line 47 + 15 bytes > thread_proxy(void * 0x0012fd74) line 71 > _threadstartex(void * 0x00961040) line 212 + 13 bytes > KERNEL32! 7c57b382() > > It sounds like i am missing something here. The queries here are > 1. why it is waiting at the above specified line forever ? > 2. Where can i get few worth thread samples done using boost::thread > > Regards > Janardhan _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

RE: [Boost-users] long compilation time of variant over long typelist with gcc
by Ben Hutchings 12 Feb '04

12 Feb '04

Graeme Lufkin <gwl(a)u.washington.edu> wrote: <snip> > When I compile code that declares a variable of this variant > type, the compilation takes unreasonably long (like, 1.5 hours on a > 2Ghz machine). For fewer types it goes much quicker, the transition > to unreasonably long happens around 14 types in the mpl::vector. <snip> > Something else I've noticed: the Intel compiler doesn't have the > compilation problem! I've attached sample case code that uses 16 > types, which takes less than 5 seconds to compile with Intel 8.0 and > almost 200 with GCC 3.2.2 (both on linux). > When I try the full 20 types I need, GCC chugs for several > hours, which is unacceptable for my project. Is there anything I can > do, or is this a GCC shortcoming that I need to wait for? I suggest you try newer versions of GCC (3.3 and 3.4 beta); if those still have the problem then report this as a bug at <http://gcc.gnu.org/bugs.html> with the keyword "compile-time-hog". Also check whether the poor performance is due to swapping, which indicates excessive use of memory and not necessarily excessive use of CPU time.

1 0

Spirit: pt_parse doesn't compile when using phrase_scanner_t for rules
by Steve Folly 11 Feb '04

11 Feb '04

Hi, I've read FAQ question number one about the free parse() function not compiling when and I've managed to get that to work by using rule<phrase_scanner_t> as suggested. However, I need to use the pt_parse method to create a parse tree. I'm obviously missing something really obvious because now pt_parse wont compile, even though I'm using a phrase_scanner_t because of the space_p skip parser. Any pointers most welcome. Thanks. Steve.

2 2

long compilation time of variant over long typelist with gcc
by Graeme Lufkin 11 Feb '04

11 Feb '04

I've recently become excited by the variant class and the apply_visitor technique. I've got a list of about 20 types that I want to handle in my variant (they're all related, so I won't need to supply 20 operator() to my visitors!). So I create a mpl::vector of the types, and then use make_variant_over to create my particular variant type. All this works fine (modulo a few days struggling to learn mpl stuff). When I compile code that declares a variable of this variant type, the compilation takes unreasonably long (like, 1.5 hours on a 2Ghz machine). For fewer types it goes much quicker, the transition to unreasonably long happens around 14 types in the mpl::vector. Side question: I finally found the macros BOOST_MPL_USE_PREPROCESSED_HEADERS and BOOST_MPL_LIMIT_VECTOR_SIZE that I had to suitably define to use such large mpl::vector-s. Are these documented anywhere, or am I missing the "suggested" way to do this? Something else I've noticed: the Intel compiler doesn't have the compilation problem! I've attached sample case code that uses 16 types, which takes less than 5 seconds to compile with Intel 8.0 and almost 200 with GCC 3.2.2 (both on linux). When I try the full 20 types I need, GCC chugs for several hours, which is unacceptable for my project. Is there anything I can do, or is this a GCC shortcoming that I need to wait for? -- - Graeme gwl(a)u.washington.edu "This sentence contains exactly threee erors."

1 0

Re: building boost with sunpro compilers
by King, William D 11 Feb '04

11 Feb '04

Thanks for your comments. The list sort problem is in the binary_search_test. binary_search_test.cpp in the utility library fails for sunpro 5.5 and 5.4, so sun needs to use the same workaround that begins in line 120 for DINKUMWARE and VC6. I will check my notes to find where the member template friends were an issue. It was something I found in 1.30.0, so, I am not sure if it will also be an issue in 1.31.0. So far, compiling 1.31.0 with sunpro is giving me much more trouble than either 1.30.0 or 1.30.2; sunpro doesn't like some of the iterator_facade code, which causes the filesystem library and several other tests to fail to compile. Davis King william.d.king(a)bankofamerica.com -----Original Message----- >From: boost-users-request(a)lists.boost.org >Message: 7 >Date: Tue, 10 Feb 2004 11:52:13 -0500 >From: Christopher Currie <christopher(a)currie.com> >Subject: [Boost-users] Re: building boost with sunpro compilers >To: boost-users(a)lists.boost.org >Message-ID: <c0b27u$luu$1(a)sea.gmane.org> >Content-Type: text/plain; charset=us-ascii; format=flowed >> The main fixes I have found so far is that for 5.5 and 5.4, >> BOOST_NO_LIST_SORT and BOOST_NO_MEMBER_TEMPLATE_FRIENDS need to be defined. >Can you point up which tests lead you to this conclusion? >Sun is supposed to be releasing an Early Access version of their next >compiler in the near future; I'll be focusing regressions and bugfixes >on that version once it's available. >Christopher ------------------------------

1 0

Thread creation state
by janardhan.guptha＠efi.com 11 Feb '04

11 Feb '04

I am creating a boost thread, how to know in which state it is created. I have a code snippet that is waiting always in the thread creatin functon istelf. Where as i tried with some boost samples, they are working amazingly perfect. This is how my code snippet looks like typedef boost::mutex::scoped_lock lock; class testCommand { static void threadfunc() { testCommand *testObj = mMapCommand[mObjID]; testObj->processthread(); }; static map< int mObjID, testCommand*> mMapCommand; private: void createthread() { mThread = new boost::thread(&testCommand::threadfunc); } void processthread() { lock lk(mMutex); mCondition.wait(lk); //// Some Action }; void runthread() { lock lk(mMutex); mCondition.notify_one(); }; public: static int mObjID; boost::thread *mThread; boost::condition mCondition; boost::mutex mMutex; }; The newly created thread is waiting at the following location forever, by the time i get a chance to execute the new thread is greatly delayed. NTDLL! 77f8856e() boost::detail::thread::lock_ops<boost::mutex>::unlock(boost::mutex & {...}) line 49 boost::detail::thread::scoped_lock<boost::mutex>::unlock() line 85 + 11 bytes boost::detail::thread::scoped_lock<boost::mutex>::~scoped_lock<boost::mutex> () line 74 `anonymous namespace'::thread_param::started() line 47 + 15 bytes thread_proxy(void * 0x0012fd74) line 71 _threadstartex(void * 0x00961040) line 212 + 13 bytes KERNEL32! 7c57b382() It sounds like i am missing something here. The queries here are 1. why it is waiting at the above specified line forever ? 2. Where can i get few worth thread samples done using boost::thread Regards Janardhan

2 1

How to export arrays from C(++) to python using boost
by Shukla, Nitin (Export) 11 Feb '04

11 Feb '04

I want to export an array of int and floats from C(++) to python using Boost but don't know how? Can anyone help me out? Is there any tutorials specifically on C(++)/Python interfacing using the Boost tool? I also want to export the BOOL type of C(++) to Python. How can I do that? --Nitin

2 1

building boost with sunpro compilers
by King, William D 11 Feb '04

11 Feb '04

Hello, I've been wondering if anyone else is trying to build boost on Solaris with recent sunpro compilers. In 1.31.0, the config files warn if you use any version later than 5.3, while the regression tests are running on 5.4, and Sun's latest release is 5.5. The main fixes I have found so far is that for 5.5 and 5.4, BOOST_NO_LIST_SORT and BOOST_NO_MEMBER_TEMPLATE_FRIENDS need to be defined. I would be interested in comparing notes and fixes with anyone else using Sunpro 5.5 (0x550). Thanks, Davis King william.d.king(a)bankofamerica.com

2 1

Re: [Boost-users] Problems with boost build setup
by Michael Buksas 10 Feb '04

10 Feb '04

On Sat, 31 Jan 2004 07:55:27 -0700, Jeff Garland wrote > First off, what version of bjam and boost are you using? I'm going to > assume version 1.30.2 of boost. It looks like boost-jam 3.1.7 from the rpm, and boost 1.30.2. > I think that bjam isn't that great at compiling outside of the boost > directory tree in the 1.30.2 version (I'm sure someone will correct me > if I'm offbase here :). This is a surprise. I had just assumed that the boost-jam would work the same way on user projects as in the library itself. Well, you know what they say about assuming... I'll ask about the install option at the jamboost list. Thanks for the pointer. In the meantime, is copying the libraries and using makefiles for application code typically what people do to link against boost libraries currently? Thanks again, Mike -- Michael Buksas <mb1(a)buksas.net>

1 0