When using shared_mutex class with shared_lock. I see the following behavior     boost::shared_lockboost::shared_mutex lock(m_mutex) ; When running valgrind ==32255== LEAK SUMMARY: ==32255==    definitely lost: 0 bytes in 0 blocks. ==32255==      possibly lost: 0 bytes in 0 blocks. ==32255==    still reachable: 8 bytes in 1 blocks. ==32255==         suppressed: 0 bytes in 0 blocks. However, if I change the code to     boost::shared_lockboost::shared_mutex lock(m_mutex,boost::adopt_lock) ; then the valgrind report goes away. I understand that there are valid cases to expect reachable memory at exit Should this be expected in this case ? Rajeev     --- On Thu, 9/3/09, Jens Weller wrote: From: Jens Weller Subject: Re: [Boost-users] Formal Review of Boost.Polygon extended one more week: until September 9, 2009 To: boost-users@lists.boost.org Date: Thursday, September 3, 2009, 5:37 AM

Dear boost users,

The review of Boost.Polygon was initially scheduled to end today. However, the discussions are in their best moment only now so the review period was extended by one week, until September 9, 2009 (that is next Wednesday).

thanks for the reminder. I don't have the time of a full review. But one of my first thoughts when seeing the examplecode and docs of the library I'd like to share. First, I like the idea, and I think there is use for such a library. But also, seeing the first few lines of example code, makes me think. I know the boost coding guides barley, but a class named CPolygon I'd expect in a dinosaur like MFC, not in a library trying to become part of boost. So my question to you is, will you change those things to the patterns which the users of boost are used to? just my 2 cents. regards, Jens Weller -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I found similar problems when getting an exclusive lock via unique_lock as well. I wrote this test code to reproduce.  I get the still-reachable problem if I use either the read() or the write() call (shared_lock or unique_lock).  Multiple calls to these functions  did not increase the number of reachable bytes in the valgrind report.  I understand my previous use of adopt_lock was undefined (hence i've not used it here). Is my use as described by the code correct now ? If so, is this a bug ? <code>// boost-1.39.0#include <iostream>#include "boost/thread/locks.hpp"#include "boost/thread/shared_mutex.hpp" using namespace std ; boost::shared_mutex & get_mutex() {    static boost::shared_mutex global_lock;    return global_lock;} void write() {    boost::unique_lockboost::shared_mutex write_lock(get_mutex()) ;    std::cout << "write" << std::endl ;} void read() {    boost::shared_lockboost::shared_mutex read_lock(get_mutex()) ;    std::cout << "read" << std::endl ;} int main(int argc,char **argv) {    write() ; // LINE A    read() ;  // LINE B    std::cout << "done" << std::endl ;    return 0 ;}</code> --- On Thu, 9/3/09, Steven Watanabe wrote: From: Steven Watanabe Subject: Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex To: boost-users@lists.boost.org Date: Thursday, September 3, 2009, 7:01 AM AMDG Rajeev Rao wrote:

  When using shared_mutex class with shared_lock. I see the following behavior

     boost::shared_lockboost::shared_mutex lock(m_mutex) ;

When running valgrind

==32255== LEAK SUMMARY: ==32255==    definitely lost: 0 bytes in 0 blocks. ==32255==      possibly lost: 0 bytes in 0 blocks. ==32255==    still reachable: 8 bytes in 1 blocks. ==32255==         suppressed: 0 bytes in 0 blocks.

However, if I change the code to     boost::shared_lockboost::shared_mutex lock(m_mutex,boost::adopt_lock) ; then the valgrind report goes away.

This is undefined behavior.  From the documentation shared_lock(Lockable &  m,boost::adopt_lock_t) Precondition:     The current thread owns an exclusive lock on m.

I understand that there are valid cases to expect reachable memory at exit Should this be expected in this case ?    

Yes.  This is not expected, and there is no obvious way to change it. In Christ, Steven Watanabe P.S. Please start a new thread instead of replying to an unrelated existing thread. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

looks like boost::mutex doesn't have the problem (when used with unique_lock). So I guess the problem is in shared_mutex. Rajeev --- On Thu, 9/3/09, Steven Watanabe wrote: From: Steven Watanabe Subject: Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex To: boost-users@lists.boost.org Date: Thursday, September 3, 2009, 9:40 AM AMDG Rajeev Rao wrote:

I found similar problems when getting an exclusive lock via unique_lock as well. I wrote this test code to reproduce. I get the still-reachable problem if I use either the read() or the write() call (shared_lock or unique_lock). Multiple calls to these functions  did not increase the number of reachable bytes in the valgrind report. I understand my previous use of adopt_lock was undefined (hence i've not used it here). Is my use as described by the code correct now ? If so, is this a bug ?    

It is almost certainly exactly the same as with shared_lock.  The code that allocates the object is in a lower level component. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi All, I m wondering about the status of the polygon library, on the review process page it still syas pending. I am in no position to judge the quality of the library (better leave that to the professionals), but I can say I am looking forward to using it! What is the best way of using sandbox libraries that might be accepted into the boost libraries soon? Should I just download it from the sandbox and put it in between the other boost libraries, or will that give me issues when I later run svn update when the library is accepted? Lastly, I have some questions regarding the documentation. In Polygon set concept, a sentence reading "A Polygon Set Concept may be defined with floating point coordinates, but a snap rounding distance of one integer unit will still be applied, furthermore, geometry outside the domain where one integer unit is sufficient to provide robustness may lead to undefined behavior in algorithms" appears. This seems to be talking about the polygons themselves, not specifically the polygon set, and i find it worrying. I would need to use polygons defined by floating point vertices and I do not want them to be rounded or truncated to integers. For now, I only need to test if a point is inside the given polygon. Is this robust for points and polygon-vertices that do not lay on an integer grid? Best and thanks! Diederick On Thu, Sep 3, 2009 at 2:38 PM, Thomas Klimpel wrote:

Jens Weller wrote:

...

I know the boost coding guides barley, but a class named CPolygon I'd expect in a dinosaur like MFC, not in a library trying to become part of boost. So my question to you is, will you change those things to the patterns which the users of boost are used to?

The examples just show that even dinosaur classes can be adapted to the concepts, so no need to change anything here.

Regards, Thomas _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi Diederick, Diederick C. Niehorster wrote:

This seems to be talking about the polygons themselves, not specifically the polygon set, and i find it worrying. I would need to use polygons defined by floating point vertices and I do not want them to be rounded or truncated to integers. For now, I only need to test if a point is inside the given polygon. Is this robust for points and polygon-vertices that do not lay on an integer grid?

I've done a benchmark including point-in-polygon test and I think you can use the proposed Boost.Polygon library for this. It supports also floating point polygons and the point-in-polygon operation, and as far as I know (but Luke knows the details) there is no truncation to integer for this purpose. Alternatively, you might have a look to the Generic Geometry Library which will be soon proposed to Boost (it has been in preview 4 times). See http://trac.osgeo.org/ggl/ where also references to documentation and SVN access are mentioned. Regards, Barend Gehrels