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
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