- Boost-users - lists.boost.org

Boost.Thread problem with thread_specific_ptr<>::release ?
by Roland 22 Nov '03

22 Nov '03

Dear Boosters! As I am still trying to figure out how to use the thread local storage pointer I found another strange behaviour. Perhaps I am misunderstanding the docs, or this might be a bug. System: VC6.0 CVS Head Problem: When using release on a tss variable, the associated automatic cleanup routine seems not to be updated correctly as it tries to delete the original pointer, instead of the 0-pointer. Example (simple modification of tss.cpp example): boost::thread_specific_ptr<int> value; void increment() { int* p = value.get(); ++*p; } void thread_proc() { value.reset(new int(0)); // initialize the thread's storage for (int i=0; i<10; ++i) { increment(); int* p = value.get(); assert(*p == i+1); } //******** added the following two lines int* p = value.release(); delete p; // deleting the released pointer //******* } int main(int argc, char* argv[]) { boost::thread_group threads; for (int i=0; i<5; ++i) threads.create_thread(&thread_proc); threads.join_all(); } In the debug version the program faults at exit, as the pointers are beeing freed a second time. I suspect the problem lies in the following function, as it does not set the cleanup handler if the value is 0 bool tss::set(void* value) { if (value && m_cleanup) { cleanup_handlers* handlers = get_handlers(); assert(handlers); if (!handlers) return false; cleanup_info info(m_cleanup, value); (*handlers)[m_key] = info; } return !!TlsSetValue(m_key, value); } Regards, Roland Schwarz

2 2

When to use which functors?
by Bruce Johnston 22 Nov '03

22 Nov '03

I'm somewhat new to Boost, but pretty familiar with STL and Loki. I'm a bit puzzled by the wide array of similar-sounding libraries in Boost for dealing with function objects: Lambda, Function, Functional, and Bind/Mem_fn. Why are there so many of these libraries and under what circumstances would I want to choose one over the other? Thanks. - Bruce Johnston Simba Technologies

2 1

RE: [Boost-users] lexical_cast causes level 4 warnings w/ VC7.1
by Sam Partington 22 Nov '03

22 Nov '03

Peter Dimov <mailto:pdimov@mmltd.net> wrote: > Sam Partington wrote: >> >> 4511 and 4512 are useless warnings. They are telling you that the >> copy constructor and assignment operator are inaccessible. Even >> though you're not trying to call them. [...] > >> C4127 is also awkward. As it gives warnings for some common idioms. >> It refers to conditional expressions being constant. > > These warnings can be annoying, but they aren't useless. They do find > bugs. I agree that 4127 can help you find bugs. But I can't think of any situation where 4511 or 4512 will help you find a bug. If you actually try to call an inaccesible copy constructor or assignement operator, then the compiler (correctly) fails to compile it. Thats why I used the word "awkward" rather than "useless" for 4127. I'll happily be proved wrong though. Sam ****************** This e-mail has been sent from Imagination Technologies Limited. PowerVR, Metagence, Ensigma and PURE Digital are divisions of Imagination Technologies Limited. The information contained in this e-mail, including any attachment, is confidential and may be legally privileged. It is intended solely for the addressee(s) and access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying or distribution or use of the information contained in this e-mail, is prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender by return e-mail and then delete it from your system. Internet communications cannot be guaranteed to be secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result. Any views expressed in this message are those of the author, except where the author specifies and, with authority, states them to be the views of Imagination Technologies Ltd.

2 1

RE: [Boost-users] boost::shared_ptr performance
by Tom Matelich 21 Nov '03

21 Nov '03

> -----Original Message----- > From: Matthew Wilson [mailto:stlsoft@hotmail.com] > Sent: Friday, November 14, 2003 4:23 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] boost::shared_ptr performance > > > [I posted this in boost.devel, but got no response. > Presumably that was the > wrong group. :)] > I'm going to respond, but I don't have much to say. I would think that with all the work you put into making this comparison that you could probably determine why smart_ptr is slower than yours. To me this comparison is interesting but not without comparing your code with smart_ptr. Given the lack of code, I have to assume you're waiting for someone to say something like, "WOW!!! I gotta get me some of that!" boost::smart_ptr is already a well used class, so if you're looking to contribute, either post your code so we can maybe see how it is better, or see what it is that is missing from your code to make it faster. Benchmarks are useless without more information. Please make your code available so we can improve boost. If that is not your goal, come out and say so. Tom Matelich Boost Lover ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

3 3

RE: [Boost-users] lexical_cast causes level 4 warnings w/ VC7.1
by Sam Partington 21 Nov '03

21 Nov '03

Bruce Johnston <mailto:c_kernel@hotmail.com> wrote: > I'm working on a project with strict requirements for the > build settings, > including mandatory warning level 4 and "treat warnings as errors". I > discovered that lexical_cast causes warnings C4127, C4511, > and C4512 when > compiling with warning level 4 using VC7.1. Try the following > code for a > quick repro: 4511 and 4512 are useless warnings. They are telling you that the copy constructor and assignment operator are inaccessible. Even though you're not trying to call them. Take the following code class noncopyable { private: noncopyable(const noncopyable&); noncopyable& operator=(const noncopyable&); }; class a_resource : noncopyable { // ... }; // ... { a_resource res; } Clearly a_resource is not meant to be copied, the developer has gone to lengths to make that clear. Indeed it never is copied, or assigned, yet the warnings will still be issued. C4127 is also awkward. As it gives warnings for some common idioms. It refers to conditional expressions being constant. So : do { XXX } while(0); Gives the warning, which is a common implementation of an ASSERT() macro, and likewise // in an header : const bool debug = false; // in code : if (debug) { } does also. None of these technigues indicate a possible error in code. Ideally all three of these warnings would be disabled in config.hpp. > As an aside, what warning level is typically used by > developers working on > Boost? On VC6 we build on warning level 3, 4 is just too noisy with the built in headers. On VC7.1 we use level 4, but with C4127, C4511, C4512 switched off. HTH Sam ****************** This e-mail has been sent from Imagination Technologies Limited. PowerVR, Metagence, Ensigma and PURE Digital are divisions of Imagination Technologies Limited. The information contained in this e-mail, including any attachment, is confidential and may be legally privileged. It is intended solely for the addressee(s) and access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying or distribution or use of the information contained in this e-mail, is prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender by return e-mail and then delete it from your system. Internet communications cannot be guaranteed to be secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result. Any views expressed in this message are those of the author, except where the author specifies and, with authority, states them to be the views of Imagination Technologies Ltd.

2 1

Re: [Boost-users] Re: filesystem::directory_iterator::operator++() never returns <--never mind
by Beman Dawes 21 Nov '03

21 Nov '03

At 07:02 PM 11/19/2003, John.Wismar(a)alldata.com wrote: > >OK, I found it. > >Upon yet another search of the archive, I found it: I was using the >single-threaded version of the library in a multi-threaded app. > >Sorry for the bandwidth! Actually, it is helpful. It gives us more incentive to work on reliability enhancements. Thanks, --Beman

1 0

RE: [Boost-users] Re: boost::shared_ptr performance
by Tom Matelich 21 Nov '03

21 Nov '03

> -----Original Message----- > From: Matthew Wilson [mailto:stlsoft@hotmail.com] > Sent: Wednesday, November 19, 2003 11:27 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: boost::shared_ptr performance > > > > > > > > [I posted this in boost.devel, but got no response. > > > Presumably that was the > > > wrong group. :)] > > > > > > > I'm going to respond, but I don't have much to say. I > would think that > with all the work you put into making this comparison that you could > probably determine why smart_ptr is slower than yours. To me this > comparison is interesting but not without comparing your code with > smart_ptr. Given the lack of code, I have to assume you're > waiting for > someone to say something like, "WOW!!! I gotta get me some of that!" > > No, I was seeking information, as I said. > > "There are environment settings for which boost::shared_ptr will > perform much better. If that's so, can someone help me out > with suggestions > of what defines to make?" > > It turns out that there are. > > If I was wanting to make a splash, I'd got for a dip down at > the beach. :) Sorry for any appearance of hostility. I'll check out the devel thread. ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

lexical_cast causes level 4 warnings w/ VC7.1
by Bruce Johnston 21 Nov '03

21 Nov '03

I'm working on a project with strict requirements for the build settings, including mandatory warning level 4 and "treat warnings as errors". I discovered that lexical_cast causes warnings C4127, C4511, and C4512 when compiling with warning level 4 using VC7.1. Try the following code for a quick repro: #include <string> #include <iostream> #include "boost/lexical_cast.hpp" int main() { std::string helloFactor = boost::lexical_cast<std::string>( 7 ) ; std::cout << "Hello # " << helloFactor << std::endl ; return 0 ; } Builds fine at warning level 3, fails with /W4 and /WX. As an aside, what warning level is typically used by developers working on Boost? -Bruce Johnston Simba Technologies

1 0

Re: filesystem::directory_iterator::operator++() never returns <--never mind
by John.Wismar＠alldata.com 20 Nov '03

20 Nov '03

OK, I found it. Upon yet another search of the archive, I found it: I was using the single-threaded version of the library in a multi-threaded app. Sorry for the bandwidth! --------------------- John Wismar john.wismar(a)alldata.com In a previous state of enlightnment, I wrote: I'm using the fielsystem library's directory_iterator class to collect information about the files in a directory. I'm using VC7.0, and Boost 1.30.2. My logic looks something like this: ---------------------------------------------------------------------- class DirInfo { public: DirInfo(fs::path aPath) : myPath(aPath){} void scan(); void addFile(fs::path); private: fs::path myPath; } void DirInfo::scan () { fs::directory_iterator itEnd; for (fs::directory_iterator it(myPath); it != itEnd; ++it) { TRACE("File: %s\n", it->string().c_str()); if (!fs::is_directory(*it)) { addFile(*it); } } } DirInfo di(fs::path("C:\\temp\\", fs::native); di.scan(); ---------------------------------------------------------- This successfully goes through all of the files (and subdirectories) in the given directory, but after the last item, the next call to fs::directory_iterator::operator ++() never returns. If anyone has any suggestions or ideas, I would love to hear them!! Thanks! The call stack at the point where execution seems to lock up looks like this: ntdll.dll!NtDelayExecution() + 0xc kernel32.dll!_Sleep@4() + 0xb MyApp.exe.exe!boost::detail::lightweight_mutex::scoped_lock::scoped_lock(boost::detail::lightweight_mutex & m={...}) Line 96 + 0xa C++ MyApp.exe.exe!boost::detail::sp_counted_base::release() Line 132 + 0xf C++ MyApp.exe.exe!boost::detail::shared_count::~shared_count() Line 380 C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>:: ~shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>() + 0x2e C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>::reset () Line 217 C++ MyApp.exe.exe!boost::filesystem::directory_iterator::m_inc() Line 256 C++ > MyApp.exe.exe!boost::filesystem::directory_iterator::operator++() Line 88 + 0x2b C++ MyApp.exe.exe!DirInfo::scan() Line 63 + 0x1a C++ --------------------- John Wismar john.wismar(a)alldata.com

1 0

filesystem::directory_iterator::operator++() never returns
by John.Wismar＠alldata.com 20 Nov '03

20 Nov '03

I'm using the fielsystem library's directory_iterator class to collect information about the files in a directory. I'm using VC7.0, and Boost 1.30.2. My logic looks something like this: ---------------------------------------------------------------------- class DirInfo { public: DirInfo(fs::path aPath) : myPath(aPath){} void scan(); void addFile(fs::path); private: fs::path myPath; } void DirInfo::scan () { fs::directory_iterator itEnd; for (fs::directory_iterator it(myPath); it != itEnd; ++it) { TRACE("File: %s\n", it->string().c_str()); if (!fs::is_directory(*it)) { addFile(*it); } } } DirInfo di(fs::path("C:\\temp\\", fs::native); di.scan(); ---------------------------------------------------------- This successfully goes through all of the files (and subdirectories) in the given directory, but after the last item, the next call to fs::directory_iterator::operator ++() never returns. If anyone has any suggestions or ideas, I would love to hear them!! Thanks! The call stack at the point where execution seems to lock up looks like this: ntdll.dll!NtDelayExecution() + 0xc kernel32.dll!_Sleep@4() + 0xb MyApp.exe.exe!boost::detail::lightweight_mutex::scoped_lock::scoped_lock(boost::detail::lightweight_mutex & m={...}) Line 96 + 0xa C++ MyApp.exe.exe!boost::detail::sp_counted_base::release() Line 132 + 0xf C++ MyApp.exe.exe!boost::detail::shared_count::~shared_count() Line 380 C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>:: ~shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>() + 0x2e C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>::reset () Line 217 C++ MyApp.exe.exe!boost::filesystem::directory_iterator::m_inc() Line 256 C++ > MyApp.exe.exe!boost::filesystem::directory_iterator::operator++() Line 88 + 0x2b C++ MyApp.exe.exe!DirInfo::scan() Line 63 + 0x1a C++ --------------------- John Wismar john.wismar(a)alldata.com

1 0