September 2005 - Boost - lists.preview.boost.org

temp file
by Tomek 10 Sep '05

10 Sep '05

Hi, Can you add to boost::filesystem namespace class for temporary files which will remove file on object destruction ? I prepared same sample code : http://psycho.pl/pub/src/tmpfile.cc If you say that this is ok, I will write it using boost library and also working on win32. Thanks Tom

10 15

[binary-int] pre-release available
by Scott Schurr 10 Sep '05

10 Sep '05

Greetings, At the moment I'm anticipating a formal review of the binary_int implementation sometime in October. This seems like a good time to suggest that anyone who's curious take a look at the pre-release version of binary_int. Anything caught now improves the likelihood that the October review will be the final review. The binary_int template allows the compile time expression of integer binary literals. Usage looks like this: unsigned int regValue = binary_int<1000,1001,0011,0000>::value There is no run-time code overhead for using this template; all overhead is at compile time. I expect these binary literals to work any place that an integer literal would work at compile (not preprocessing) time. The template is designed to allow binary values up to 64-bits to be expressed, although it has only been tested up to 32-bits to date. You'll find the template, its documentation, and a small unit test at: http://boost-consulting.com/vault/ under binary_int.zip In addition to the issue of whether the template works for you, there are four points I'm curious about: o Some compilers used to complain when the most significant bit of a binary_int was set. I've fixed that problem as well as I know how. Do any compilers still see this problem, and does it produce warnings or full fledged errors? o Does the template properly produce 64-bit values on a 64-bit compiler? The unit test only goes up to 32-bits since neither of my compilers support 64-bit compilation. o Are the names 'binary_int' and 'binary_nibble' good names? Pavel Vozenilek, who has very kindly been my Boost mentor, suggests 'bits' and 'nibble' may be better names. o There's a BOOST_WORKAROUND in the template so I can do something vaguely BOOST_STATIC_ASSERT like. Pavel suggests that the workaround would be better solved in a general form that all compilers can accept. What would be a better solution to the BOOST_WORKAROUND? Thanks for your consideration. Scott Schurr

3 10

out of date comment in boost/config/compiler/visualc.hpp
by Marcin Kalicinski 10 Sep '05

10 Sep '05

boost/config/compiler/visualc.hpp has out of date comment at the end: // last known and checked version is 1310: #if (_MSC_VER > 1400) should probably be: // last known and checked version is 1400: #if (_MSC_VER > 1400) cheers, Marcin

2 1

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> I didn't know about that, because on win32 there is a problem with > deleting open files. Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data is written after the handle is closed. You still can't delete an open file but you can possibly avoid ever creating the file in the first place.. Matt > On unix systems (probably most or all of them) > you can delete file and when last handle is closed kernel > automatically > removes file - it's great solution. > > Anyway, same people on unix (in same cases) first open temp file, > then remove it and then use it - no one could do anything > with your file. > > Tom <<snip>> Scanned by Fortigate {X3BTB534}

4 5

read_write_mutex fundamentally broken in 1.33?
by John Maddock 09 Sep '05

09 Sep '05

I've been trying to solve the deadlock problem reported here: http://lists.boost.org/Archives/boost/2005/08/92307.php but I've simply run into more and more problems, and just about every operation I've tried will deadlock if you try hard enough. THIS IS NOT GOOD. Applying Roland Swartz's suggested fix everywhere that looked appropriate initially seemed to fix the issue, but once you move to more complex situations (both readers and writers) then the deadlocks simply come back again. At this point I've exhausted my understanding of the problem and the design of the lock. As an aside: it is *very* hard to implement something like this correctly: no amount of debugging will ever get you a reliable system, only a clearly understood design backed up by a solid theoretical understanding of the implementation method (formal methods anyone?). To be honest I have to question whether it's even a good idea for this to be in Boost (no slur intended towards the implementers of that class, it's the difficulty of the problem that's the issue). In case anyone wants to pursue this further I'm attaching my current test case, and the current patches I have to the implementation, however, please note that neither this test case, nor the current regression tests are anything like comprehensive, THEY WILL NOT CATCH ALL POSSIBLE PROBLEMS. Sorry about the capital letters folks, but I suspect we have a "Huston, we have a problem" moment here :-( Regards, John.

8 15

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> Matt Doyle wrote: > >>I didn't know about that, because on win32 there is a problem with > >>deleting open files. > > > > > > Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. > > > > from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being > used for temporary storage. File systems avoid writing data > back to mass storage if sufficient cache memory is available, > because an application deletes a temporary file after a > handle is closed. In that case, the system can entirely avoid > writing the data. Otherwise, the data is written after the > handle is closed. > > > > You still can't delete an open file but you can possibly > avoid ever creating the file in the first place.. > > But then you have to carefully craft the spec, as users may > expect to be able to > share the file (by name) among processes. There are clearly > different use > cases for temporary files, so it is important to capture the > most important ones. Ah, that's true. There is a different flag that could be used FILE_FLAG_DELETE_ON_CLOSE which won't delete it until "all" handles to the file are closed but I really can't vouch for it because I haven't used that one. I've no idea what kind of nasty undocumented luggage it brings along with it. Given the source, I like to try it before I believe it ;) Matt > > Regards, > Stefan > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by Fortigate {X3BTB534}

1 0

Re: [boost] temp file
by Greer, Joe 09 Sep '05

09 Sep '05

While you are thinking about this stuff, keep in mind that some OSes such as win32 have the ability to open a file as temporary and will automatically delete it when the last handle is closed. It would be nice if that could be exploited by whatever interface is decided upon. joe

3 2

Boost regression notification (2005-09-09 [HEAD])
by Douglas Gregor 09 Sep '05

09 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (copying new results), please wait...</p> </body> </html>

2 1

Boost regression notification (2005-09-09 [RC_1_33_0])
by Douglas Gregor 09 Sep '05

09 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-09T15:57:06Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 143 failures in 9 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0

[concept_check] New failures on RC
by Markus Schöpflin 09 Sep '05

09 Sep '05

A new test called stl_concept_covering has appeared in the concept_check lib on the RC branch. It currently fails for all platforms. Maybe it should have gone to the trunk? Markus

1 0