- Boost - lists.preview.boost.org

[filesystem] possible bug in exists(path const &)
by Angus Leeming 30 Sep '04

30 Sep '04

Beman, I notice that the Windows implementation of exists() contains the line: if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) This contrasts with DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); in is_directory(). I wonder if there are any implications in using string() as opposed to native_file_string() here? It does appear that in most places you prefer to use the "native_" flavour when invoking system functions. Regards, Angus

2 1

[review] Formal review of the Smart Container library - one week left reminder
by Pavol Droba 29 Sep '04

29 Sep '04

Hi All, This the the reminder, that there is only one week left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

Re: [uBLAS] Linux regressions
by Michael Stevens 29 Sep '04

29 Sep '04

Martin, Thanks for your work on the Linux tests. Looks like all the staleness problems are fixed. The uBLAS tests now show the expected 100% passes. Michael

2 1

Formal review of "Output Formatters" library begins today
by John Torjo 29 Sep '04

29 Sep '04

Dear boosters, The FORMAL Review of "Output Formatter" library begins today, Sept 12, 2004. Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

15 42

[tokenizer] Any expert in bjam?
by Joaquín Mª López Muñoz 29 Sep '04

29 Sep '04

tokenizer is regressing for msvc-stlport as shown in http://tinyurl.com/3mkvx The same kind of problem happens at the following cells wich are marked as expected failures: http://tinyurl.com/44pbx http://tinyurl.com/5xd8z I've built these tests locally for msvc-stlport locally (from my IDE) and they work just fine. No fundamental problem with this platform. So I guess the problem lies in the corresponding Jamfile entries (located directly in boost/status/Jamfile): test-suite tokenizer : [ run libs/tokenizer/examples.cpp <lib>../libs/test/build/boost_test_exec_monitor ] [ run libs/tokenizer/simple_example_1.cpp ] [ run libs/tokenizer/simple_example_2.cpp ] [ run libs/tokenizer/simple_example_3.cpp ] [ run libs/tokenizer/simple_example_4.cpp ] [ run libs/tokenizer/simple_example_5.cpp ] ; I'm pretty sure this is related to some messing up of stdlibs binaries (I vaguely recall that STLPort does not work with single-thread static runtime lib), but my skills of Jamfile are lousy. Could somebody please have a look at it? Another thing that left me wondering is that examples 1, 2 and 4 have the same structure as 3 and 5, and yet they do not fail. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

failures with intel-win32-7.1-vc6-stlport-4.5.3 Toolset?
by John Maddock 29 Sep '04

29 Sep '04

I've been trying to track down a couple of regex test failures that appear for this toolset, but can't build even build STLPort never mind the tests with Intel 7.1, I consistently get errors like: c:\download\open\stlport\STLport-4.5.3\stlport\cstdlib(42): error: namespace "st d" has no member "div_t" using _STLP_VENDOR_CSTD::div_t; ^ c:\download\open\stlport\STLport-4.5.3\stlport\cstdlib(43): error: namespace "st d" has no member "ldiv_t" using _STLP_VENDOR_CSTD::ldiv_t; ^ So is this test being run with a modified STLport version or something? Thanks, John.

2 1

Re:Re: [boost] serialization: buffers
by Robert Ramey 29 Sep '04

29 Sep '04

Darren Cook wrote: >> Or you might try the following (non-portable) idea >> >> ar & BOOST_SERIALIZATION_NVP( >> make_binary_object(str, (p - str)* sizeof(int)) >> ); >Thanks, that is closest to what I was after; I don't need a portable >version here. >> But really, I think you might be best off replacing the class above >> with >> >> class Example { >> std::slist<int> str; // or maybe std::vector<int> str } >It was done using a fixed size buffer to avoid dynamic memory allocation >(mainly for speed reasons). >However as I worked through the class some more I found it can output a >string representation, which uses fewer bytes. So in future I might add a >parser for input and then switch to using that (though I'll be back to >needing separate load/save functions then won't I, oh well :-). A couple final observations: a) the make_binary .. implementation is maximal speed on a binary archive. It just streams the bytes to the i/o buffer. b) If you're concerned about binary portability and file size, take a look at the demo binary portable. It implements saving/loading of integers as variable length binary bytes so that a lot of the zeros are eliminated. c) if you're concerned about file size. You might consider using the streams library - currently pending review - to compress/de-compress the i/o on the fly as the data is saved/loaded. Robert Ramey

1 0

date_time formatting
by Martin 29 Sep '04

29 Sep '04

I'm trying to understand the date_time formatting via iostreams but got problems with a few things. I tried to search the archive but didn't find answers to these questions. 1. Why doesn't date_time use the standard time facet (time_put.do_put etc) if the special greg_date_facet isn't available? 2. Why do I need to specify the names of all months and weekdays in the greg_date_facet just to use a different separator than '-' or another ordering? 3. How do I specify the format of a ptime (date-separator, time-separator and decimal separator)? -------------------------------------------- I also got some compile warnings on VC70 (latest CVS) 1: in the function "from_time_t" on this line return start + seconds(t); boost\date_time\posix_time\conversion.hpp(27) warning C4244: 'argument' : conversion from 'time_t' to 'long', possible loss of data 2: in the function "from_stream_type" ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown boost\date_time\date_parsing.hpp(211): warning C4244: 'argument' : conversion from 'wchar_t' to 'char', possible loss of data

2 3

New numeric cast
by Fernando Cacciola 29 Sep '04

29 Sep '04

Hi, According to the regression summary, the new numeric conversion library is in pretty good shape(thanks to Joaquín Muñoz for his latest fixes!) I want to test how far can the new "numeric_cast<>" replace the old one. For that, I want to put the exact same test that's currently used for the old numeric_cast in the new library. Right now, cast_test.cpp contains numeric_cast<> test with other conversions. I will factor it out, but I have a doubt: it is not using the Test framework at all, it's just printing the test result to std out. Does the regression scripts parse the output, or these test are just wrongly integrated? Should I update those test to use the Unit Test Framework? Fernando Cacciola SciSoft

3 6

[type_traits] fixes for GCC 2.95
by Joaquín Mª López Muñoz 29 Sep '04

29 Sep '04

The following regressions in gcc-2.95.3-linux http://tinyurl.com/638l6 http://tinyurl.com/3k6hu are IMHO due to the fact that bad_alloc is defined in <new>, and this header is not included by the corresponding test programs. I'd say it's only out of sheer luck (dependant inclusions) that these tests works for the rest of compilers, but I might be wrong. In any case, #including <new> solves the problem. If noone sees a problem with these patches, I'll commit them. Joaquín M Lópz Muñoz Telefónica, Investigación y Desarrollo 16d15 < #include <new> 22d21 < #include <new>

2 1