October 2004 - Boost - lists.preview.boost.org

RE: [boost] Re: recursive mutex and condition
by Ben Hutchings 04 Nov '04

04 Nov '04

James Ahlborn <james.ahlborn(a)med.ge.com> wrote: > > Ben Hutchings <ben.hutchings <at> businesswebsoftware.com> writes: > > > I don't believe so. If waiting for a condition releases the mutex > > only once, this can result in deadlock, and if it releases the mutex > > completely the protected data can be seen while its invariant is > > broken. There seems to be no right way to use recursive mutexes > > with condition variables. > > umm, using a condition fundamentally implies releasing a mutex and > then reacquiring it. regardless of the mutex type, one needs to make > sure that the invariants are valid when the mutex is released. Yes, I understand all this. <snip> > > I think you should avoid using recursive mutexes. Read > > <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>. > > well, i've programmed significantly in both java and c++ and i think > the poster of that comment is mistaken on many fronts. besides the > obvious bias against java and the seemingly minimal knowledge of how > "synchronized" works in java, "Minimal knowledge"? Does that mean you think he's wrong in fact, or that his opinion about its usefulness is mistaken? > i think the fundamental argument of a recursive mutex being the "lazy > man's mutex" is wrong. In any moderately complex system, trying to > avoid using recursive mutexes adds complexity to the overall design > and eventually breaks the modularity of the system. As I understand it, your reason for using a recursive mutex would be that there are functions that require a weaker invariant and may safely be called from a function that holds the mutex and has broken the normal invariant, but may also be called without the mutex being held. (If a function requires the normal invariant then you need to re-establish that before calling it, and having done so you could safely unlock the mutex, removing the need for it to be recursive.) This means that responsibility for re-establishing the normal invariant for a recursive mutex is divided up between several functions. So how can the single function that waits on the condition re-establish the invariant? Wouldn't that require a gross breach of the modularity you want? <snip> > to return to boost specifically, the implementation of > recursive_mutex and condition seem to imply their combined use. I > see no documentation which says "hey, you should only use condition > with a normal mutex", nor any compiler error when i try to do so. > i see no "fundamental" reason why a recursive mutex and a condition > should not work together (they are quite happy in java). I do. > yet, they don't work, and I'm wondering if that is intended or a > bug in boost. It looks like a documentation bug to me.

6 5

IO Collection Framework (Output Formatters REDESIGN)
by Reece Dunn 03 Nov '04

03 Nov '04

Hi All, I have been working on the library and have got a local reimplementation of my Output Formatters library based on the review comments. There are still a few issues that need to be resolved and I would like to expand stream state support. I have created a preliminary evolution document available at: http://uk.geocities.com/msclrhd/iocoll/evolution.html that outlines what the new functionality looks like. This redesign addresses several of the issues brought up during the review. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

FORMAL review of "Output Formatters" - results
by John Torjo 03 Nov '04

03 Nov '04

Dear all, We got a lot of feedback relating the "Output Formatters" library [1]. "Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2 Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign. Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place. Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days. I will talk to Tom and Reece and schedule a next review date. Best, John [1] Just in case you still want a peek at the old code: http://www.torjo.com/code/outfmt.zip (153Kb) -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

20 54

Request for data-member smart pointer
by Oleg Fedtchenko 02 Nov '04

02 Nov '04

To Peter Dimov Hi, Peter Could you, please, tell if is there a smart pointer template to a class data-member. I failed to find an appropriate pointer among five ones existing in the boost. I need it for the two tasks appended. By this time, I have written an extension to intrusive_ptr to meet these needs. If you or anyone else are interested I could post it or send in person. Oleg boostoleg(a)yandex.ru Task 1) class A { public: A(){ m_wData = 0;} WORD* GetData(){ return &m_wData} A* CreateA( int nOffset){ return new A;} protected: WORD m_wData; }; main() { A aInstance; WORD* pData = aInstance.CreateA( 15)->GetData(); *pData = 57; // access violation } Task 2) class DocActiveX { protected: Tree* m_pTree; public: ~DocActiveX(){ if(m_pTree) delete m_pTree;} bool Load( const char* lpszPath); Tree* Parse(){ return m_pTree;} }; class DocDirect { protected: Tree* m_pTree; public: ~DocDirect(){ if(m_pTree) delete m_pTree;} bool Load( const char* lpszPath); Tree* Parse(){ return m_pTree;} }; class ShowExternal { public: bool Show( const Tree* pTree); }; class SomeClass { protected: Tree* m_pTree; }; void SomeClass::OnLoad() { DocActiveX* pInstance = new DocActiveX; aInstance.Load( lpszSomePath); m_pTree = aInstance.Parse(); } void SomeClass::OnShow() { ShowExternal ashow; ashow.Show( m_pTree); }

5 19

[tuple] which version to take ?
by Patrick Kowalzick 02 Nov '04

02 Nov '04

Dear all, I am not sure which version of tuples is actual and should be used: -The version in boost/tuple is working and seems consitent to the manual on the boost homepage. -The version in boost/spirit/fusion/sequence is working too and seems to be consistent to "C++ Standard Library Technical Report". tuple_size and tuple_element exist, which do not exist in the first version. Why are there two versions? Which one shall I use? Any recommendations? Thank you, Patrick P.S.: I have another short question, and need a small hint (what to search ;) ) for kind of a "compile time for-loop". Something like this: index[0] = fw_index::template get_index< tuples::tuple_element< 0, TTuple>::type >(); index[1] = fw_index::template get_index< tuples::tuple_element< 1, TTuple>::type >(); ...

6 7

Problems building PDF documentation
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

While building PDFs for standalone libraries (BB2 is one example) works without a glitch, we were unable to build the master "boost.pdf", due to what appears to be a problem in FOP: ... fop-nt ..\bin.v2\doc\debug\boost.pdf [INFO] FOP 0.20.4 [INFO] building formatting object tree [ERROR] property - "font-selection-strategy" is not implemented yet. [ERROR] property - "line-height-shift-adjustment" is not implemented yet. [ERROR] property - "last-line-end-indent" is not implemented yet. [INFO] [4] [INFO] [5] [INFO] [6] [INFO] [7] [INFO] [8] [INFO] [9] [INFO] [10] [INFO] [11] [INFO] [12] [ERROR] region-name 'xsl-footnote-separator' doesn't exist in the layout-master-set. [ERROR] property - "last-line-end-indent" is not implemented yet. ... [ERROR] property - "last-line-end-indent" is not implemented yet. [INFO] [17] [INFO] [18] [INFO] [19] [INFO] [20] [INFO] [21] [INFO] [22] [ERROR] java.lang.NullPointerException set JAVA_HOME=C:/WINDOWS/system32/java.exe C:/PROGRA~1/FOP-02~1.4/fop.bat ..\bin.v2\doc\debug\boost.fo ..\bin.v2\doc\debug\boost.pdf ...failed fop-nt ..\bin.v2\doc\debug\boost.pdf... ...failed updating 1 target... ...updated 32 targets... This is using: xsltproc --version xsltproc was compiled against libxml 20614, libxslt 10111 and libexslt 809 libxslt 10111 was compiled against libxml 20614 libexslt 809 was compiled against libxml 20614 DocBook XSL 1.66.1 stylesheets FOP 0.20.4/0.20.5 (identical results) on Windows. It's probably possible to get to the root of the issue by commenting out different parts of "doc/src/boost.xml" until it's buildable, but in what little time we could devote to investigating this, we didn't have much success going this route. It would be greatly appreciated if somebody could take a look at this. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

[1.32 Release] Draft tarballs are available
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

Draft zip/tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation), or, if there are none, to confirm that pending a few issues below, we are finally ready to release. For your convenience, the unpacked contents is also available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website. KNOWN ISSUES ------------ The following is a list of known issues present in the tarballs which grant them their draft status: 1) A small number of unmarked test failures (but no regressions). 2) A small number of broken links as follows: doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png doc/html/libraries.html: broken link: ../boost.pdf libs/libraries.htm: broken link: ../boost.docbook, broken link: ../boost.fo, broken link: ../boost.pdf libs/numeric/conversion/doc/converter.html: broken link: udt_support.html libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html 3) No documentation in PDF format ("boost.pdf"), due to some build issues (I'll post separate email on this). 4) Placeholder pages in place of the revoked pre-1.32 MPL documentation. If you encounter any issues that are not in the above list, please report them here! TESTING ------- To run regression tests on the archives, you need to: 1) Grab the archive for your platform from one of the above locations. 2) Grab the latest "regression.py" from http://www.meta-comm.com/engineering/boost/regression.py 3) Put the archive and "regression.py" in the same directory and invoke the latter with the following command line: python regression.py --local=<archive name> --runner=<your runner id> --toolsets=<your toolsets> [<more options as needed>] For example, python regression.py --local=boost_1_32_0.zip --runner=metacomm --toolsets=msvc,vc7,vc-7_1,cw-8_3 --pjl-toolset=vc-7_1 The results will be automatically uploaded to ftp://fx.meta-comm.com/boost-regression/boost_1_32_0/. Finally, thanks in advance to everybody who will be looking at this! -- Aleksey Gurtovoy MetaCommunications Engineering

14 37

too much typing
by Neal D. Becker 01 Nov '04

01 Nov '04

I'm always writing (e.g.) std::vector<double> out (size); std::transform (in.begin(), in.end(), out.begin(), func); Wouldn't it be nice to have versions of the std algorithms that worked like: template<typename out_cont_t, typename in_cont_t, typename UnaryOperation> inline out_cont_t transform_r (const in_cont_t& in, UnaryOperation u) { out_cont_t out (boost::size (in)); std::transform (boost::begin (in), boost::end (in), boost::begin (out), u); return out; } Then you can say: std::vector<double> out = transform_r<std::vector<double> > (in, func); That is, the first template parameter is the desired return container type, and the algorithm constructs the return value into it. Since constructors can be elided, I think this may be just as efficient as the original, or maybe better. OK, perhaps it looks like I didn't save much typing, but when you chain function calls you save a lot.

5 4

[filesystem] regressions for operations_test
by JOAQUIN LOPEZ MU?Z 31 Oct '04

31 Oct '04

Hi, msvc, msvc-stlport, iw-7_1-vc6 and iw-7_1-vc6-stlp-4_5_3 currently fail this test (see for instance http://tinyurl.com/4xo4a) I don't know for sure, but I've got the hunch this might be related with the fact that 2004 is a leap year and today we've had a 1-hour adjustment in some countries due to the daylight saving policy. These two facts combined might yield an offset outside the expected range. Just wanted to note this in case it might ring a bell for somebody. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization] The problems with CW...
by Rene Rivera 31 Oct '04

31 Oct '04

I took some time to take a closer look at what the current test failures could be about on the cw-8.3 compiler... before I go on vacation. Specifically I looked at the test_exported errors as those seemed to be common to both the 9 and 8 versions of CW. My findings... I managed to get the export tests to *pass* by modifying the test itself (see attached). The problems boils down to the behavior of CW to only instantiate templates when they are used. This not just applies to class templates, but to template methods. In the case of the exported tests it does not instantiate two important things: a) The serialize template method of non-directly referenced derived classes. Specifically for test_exported: polymorphic_derived1::serialize<test_oarchive>, polymorphic_derived1::serialize<test_iarchive>, polymorphic_derived2::serialize<test_oarchive>, and polymorphic_derived2::serialize<test_iarchive>. Forcing those to be instantiated generates all the rest of the self registration code for the derived classes. This still leaves: b) The archive serialization instance for the needed specializations is also not generated as they are not directly reference. Only the ones for the base class, polymorphic_base, are generated as that's the class used in the actual de/serialize calls. I'm not sure anything can be done about fixing this for the release as the only solutions I can come up with would involve changing the serialization interfaces. HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq =================================================================== RCS file: /cvsroot/boost/boost/libs/serialization/test/test_exported.cpp,v retrieving revision 1.4 diff -u -r1.4 test_exported.cpp --- test_exported.cpp 22 Jul 2004 06:39:17 -0000 1.4 +++ test_exported.cpp 29 Oct 2004 19:36:07 -0000 @@ -40,6 +40,7 @@ class polymorphic_derived1 : public polymorphic_base { friend class boost::serialization::access; +public: template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); @@ -49,10 +50,19 @@ }; BOOST_CLASS_EXPORT(polymorphic_derived1) +namespace { + void (polymorphic_derived1::* pd1so_p)(test_oarchive &,const unsigned int) = &polymorphic_derived1::serialize<test_oarchive>; + void (polymorphic_derived1::* pd1si_p)(test_iarchive &,const unsigned int) = &polymorphic_derived1::serialize<test_iarchive>; +} +template<> +const boost::archive::detail::pointer_iserializer<polymorphic_derived1, test_iarchive> boost::archive::detail::pointer_iserializer<polymorphic_derived1, test_iarchive>::instance; +template<> +const boost::archive::detail::pointer_oserializer<polymorphic_derived1, test_oarchive> boost::archive::detail::pointer_oserializer<polymorphic_derived1, test_oarchive>::instance; class polymorphic_derived2 : public polymorphic_base { friend class boost::serialization::access; +public: template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); @@ -62,6 +72,14 @@ }; BOOST_CLASS_EXPORT(polymorphic_derived2) +namespace { + void (polymorphic_derived2::* pd2so_p)(test_oarchive &,const unsigned int) = &polymorphic_derived2::serialize<test_oarchive>; + void (polymorphic_derived2::* pd2si_p)(test_iarchive &,const unsigned int) = &polymorphic_derived2::serialize<test_iarchive>; +} +template<> +const boost::archive::detail::pointer_iserializer<polymorphic_derived2, test_iarchive> boost::archive::detail::pointer_iserializer<polymorphic_derived2, test_iarchive>::instance; +template<> +const boost::archive::detail::pointer_oserializer<polymorphic_derived2, test_oarchive> boost::archive::detail::pointer_oserializer<polymorphic_derived2, test_oarchive>::instance; // save exported polymorphic class void save_exported(const char *testfile)

4 4