March 2006 - Boost - lists.preview.boost.org

boost::scoped_array::release?
by Ralf W. Grosse-Kunstleve 30 Aug '06

30 Aug '06

Does this patch for boost/scoped_array.hpp look useful? < T * release() // never throws < { < T * result = ptr; < ptr = 0; < return result; < } < It allows me to use boost::scoped_array almost like an auto_ptr: int* foo(size) { boost::scoped_array<int> result(new int[size]); // do something to result // if an exception is thrown result will be cleaned up return result.release(); } void bar() { boost::scoped_array<int> foo_result(foo(1000)); // code is still exception safe } I wouldn't need this if - we had std::auto_array (don't think it exists) - std::vector<int>(size) wouldn't do the default construction of all elements and I didn't care about having two pointers instead of just one (sometimes I actually do care) - boost::scoped_array::ptr was protected instead of private so that I could inherit and add release() Are there arguments for not adding release()? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

11 21

Boost regression notification (2005-10-26 [RC_1_33_0])
by Douglas Gregor 23 Aug '06

23 Aug '06

Boost regression test failures ------------------------------ Report time: 2005-10-26T14:54:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 82 failures in 3 libraries: parameter (1) range (3) serialization (78) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1

7 11

Patch for smart pointers assignation of plain pointers
by Pierre THIERRY 15 Jun '06

15 Jun '06

It seems to me that smart pointers could have the same semantics that plain pointers have (it's also the orientation taken by other smart pointers, like those in Glibmm). Here is my proposed patch against CVS HEAD: Index: boost/scoped_ptr.hpp =================================================================== --- boost/scoped_ptr.hpp.orig +++ boost/scoped_ptr.hpp @@ -101,6 +101,12 @@ return *this; } + scoped_ptr & operator=(T * rhs) + { + this_type(rhs).swap(*this); + return *this; + } + T * get() const // never throws { return ptr; Index: boost/shared_ptr.hpp =================================================================== --- boost/shared_ptr.hpp.orig +++ boost/shared_ptr.hpp @@ -246,6 +246,12 @@ #endif // BOOST_NO_SFINAE, BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + shared_ptr & operator=(T * r) + { + this_type(r).swap(*this); + return *this; + } + #endif // BOOST_NO_AUTO_PTR #if !defined(BOOST_MSVC) || (BOOST_MSVC >= 1300) Regards, Nowhere man -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

2 5

[optional] boost/bind/apply.hpp bad interaction
by Daniel Wallin 20 May '06

20 May '06

#include <boost/bind/apply.hpp> #include <boost/optional.hpp> Results in: dev/boost/boost/optional/optional.hpp: In member function 'void boost::optional_detail::optional_bas e<T>::construct(const Expr&, const boost::in_place_factory_base*)': dev/boost/boost/optional/optional.hpp:309: error: invalid use of 'struct boost::apply<T>' On GCC4.0.2. The offending line is: factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; A simple fix is to move the apply() call out of the boost namespace. The attached patch fixes the problem. OK to commit? -- Daniel Wallin Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.9 diff -u -r1.9 optional.hpp --- optional.hpp 10 Feb 2006 20:52:25 -0000 1.9 +++ optional.hpp 18 Mar 2006 11:40:32 -0000 @@ -76,6 +76,16 @@ #define BOOST_OPTIONAL_WEAK_OVERLOAD_RESOLUTION #endif +namespace boost_optional_construct +{ + + template <class T, class Factory> + void construct(Factory const& factory, void* address) + { + factory.BOOST_NESTED_TEMPLATE apply<T>(address); + } + +} // namespace boost_optional_construct namespace boost { @@ -295,7 +305,9 @@ void construct ( Expr const& factory, in_place_factory_base const* ) { BOOST_STATIC_ASSERT ( ::boost::mpl::not_<is_reference_predicate>::value ) ; - factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; + boost_optional_construct::construct<value_type>( + factory, m_storage.address() + ); m_initialized = true ; }

2 1

[serialization] Serialisation/deserialisation of floating-point values
by Paul Giaccone 03 May '06

03 May '06

I'm having problems with deserialising floating-point (double) values that are written to an XML file. I'm reading the values back in and comparing them to what I saved to ensure that my file has been written correctly. However, some of the values differ in about the seventeenth significant figure (or thereabouts). I thought Boost serialization used some numerical limit to make sure that values are serialised exactly to full precision, so what is happening here? Example: Value in original object, written to file: 0.0019075645054089487 Value actually stored in file (by examination of XML file): 0.0019075645054089487 [identical to value written to file] Value after deserialisation: 0.0019075645054089489 It looks like there is a difference in the least-significant bit, as examining the memory for these two values gives: Original value: b4 83 9b ca e7 40 5f 3f Deserialised value: b5 83 9b ca e7 40 5f 3f (where the least-significant byte is on the left) Note the difference in the first bytes. I'm using Boost 1.33.1 with Visual Studio 7.1.3088 in debug mode. Paul

14 59

[filesystem] Some questions about string use
by Ion Gaztañaga 01 May '06

01 May '06

Hi to all, While revising a bit the boost::filesystem error/exception use for looking a model for interprocess library and after reading the N1934 "Filesystem Library Proposal for TR2 (Revision 2)" I'm a bit concerned about the heavy use of std::string/string_type in the library. The following functions return some kind of path as value type: // observers const string_type string() const; const string_type file_string() const; const string_type directory_string() const; const external_string_type external_file_string() const; const external_string_type external_directory_string() const; string_type root_name() const; string_type root_directory() const; basic_path root_path() const; basic_path relative_path() const; string_type leaf() const; basic_path branch_path() const; I know that syntactically this is nicer and we can have RVO: string_type str = path.string(); But when iterating through directories I find that that returning a temporary object that must allocate/copy/deallocate hurts my performance paranoia. Even with move semantics we have a an overhead: std::vector<std::path> paths; //fill with paths std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ std::path::string_type str = it->root_name();//temporary created str += "append some data"; std::cout << str; } Couldn't be better (although uglier) to take a reference to a string that will be filled? void fill_root_name(string_type &root_name) const; ... //////////////////////////////////////////////////////////////////// std::vector<std::path> paths; //fill with paths std::path::string_type root_name; root_name.reserve(PATH_LENGTH); std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ it->fill_root_name(root_name); str += "append some data"; std::cout << str; } This way we only allocate memory if we don't have enough place in our string. We can also reserve it beforehand to speed up code. Apart from this I see that path::iterator has a string member. dereference will return a reference to that member but an iterator is supposed to be a "lightweight" pointer-like abstraction, which is value-copied between functions. A string member, in my opinion, converts an iterator in a heavy class (that depends on the string length, but an small string optimization of 16 bytes is not going to help much). Now that filesystem is proposed for the standard I would like to ask boosters (and Beman, of course) if they find these performance concerns serious enough. Regards, Ion

10 29

[type_traits][regex] VC++ __fastcall /clr
by Edward Diener 28 Apr '06

28 Apr '06

Since no one responded to this in the boost user group, I will post it here in this group. When compiling managed code in VC++ .NET, which is any of the /clr compiler options, the programmer can mix both CLR classes and regular C++ classes. In the regular C++ classes, Boost should work fine. The VC++ macro which tells one that managed code of any kind is being compiled is _MANAGED, which is defined if managed code is being compiled else it is not defined. So when any of the /clr compiler options are being used _MANAGED is defined, else it is not defined. The VC++ compiler issues compiler warning C4561 whenever managed code is being compiled and __fastcall shows up as a calling convention in any way. Obviously the programmer can turn off this warning via a VC++ #pragma, but I am wondering if Boost could not change some of its headers to avoid this warning. In Boost bind and mem_fn, the programmer has to specifically ask for __fastcall support via special Boost macros to have any functions declared with the __fastcall calling convention, so nothing should be done there since it is clearly a programming error if he does so while compiling managed code. However there are two other places in Boost which I have discovered where functions with the __fastcall calling convention are declared without the programmer doing anything. The first, and most cumbersome reagrding warning messages, is in type_traits in the helper header files type_traits\detail\is_mem_fun_pointer_tester.hpp and type_traits\detail\is_function_pointer_tester.hpp. Since many other libraries, lambda in my case recently, uses type_traits, might not these headers be changed so that when VC++ is the compiler and _MANAGED is defined, the __fastcall versions of these helper functions are not declared ? The second, which I have not encountered but which I saw while searching through Boost header code, is in regex\config.h and I do not know, given some other macros there, whether BOOST_REGEX_CALL can ever be __fastcall when compiling with /clr, but if it can perhaps a change can be made there also. I know that it is not the purpose of Boost to try to accomodate C++ .NET programmers creating /clr compilations using Boost, especially when just warnings and not errors are issued. But in this case, using the predefined macro _MANAGED in VC++ and BOOST_MSVC, it would seem this acoomodation could be made. So I would like the Boost developers of type_traits, especially since it is used by so many other Boost libraries, and regex to consider it.

3 9

[Filesystem] Querying a card reader can throw on Windows
by Angus Leeming 14 Apr '06

14 Apr '06

Hi, Beman. If I understand correctly, the idiom to check whether a directory exists using Boost.Filesystem is if (fs::exists(path) && fs::is_directory(path)) Under normal conditions the code above shouldn't throw, right? One of our users reports that this code does, however, throw when it is used on Windows to query a card reader that has a drive letter J: assigned to it. Below is a diagnostic program that attempts to query a nonexistent "J:\foo". Executing it, our user finds: 1. If no drive is associated with J: then the program outputs nothing. 2. If an empty drive is associated with J: Exception caught: boost::filesystem::is_directory: "J:\foo": The device is not ready. Assertion failed: false file ekkehart.cpp, line 40 3. If the drive contains a disk the program outputs nothing. He goes on to say: The problem described disappears if I do one of the following: 1. Reassign another letter to the smart cars slot (such that J: is not assigned to any drive) 2. Reassign J: to a used slot (in my case the compact flash slot) and insert a card. 3. Remove the card reader. Conclusion: You should have either no drive assigned to J: or a drive with an inserted medium. This is with the current release of Boost, 1.33.1. Is this a known problem (is there a workaround) or have we stumbled upon a bug? Kind regards, Angus /* Compiled with g++ -fno-exceptions -Iboost -o ekkehart ekkehart.cpp \ -Lbuild/boost/libs/filesystem/src/.libs -lboost_filesystem */ #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> #include <cassert> #include <cstdlib> #include <exception> #include <iostream> namespace fs = boost::filesystem; int main() { fs::path const path("J:/foo", fs::no_check); if (fs::exists(path) && fs::is_directory(path)) std::cout << path.native_directory_string() << "is a directory" << std::endl; return 0; } namespace boost { void throw_exception(std::exception const & e) { std::cerr << "Exception caught:\n" << e.what() << std::endl; assert(false); } void assertion_failed(char const * expr, char const * function, char const * file, long line) { std::cerr << "Assertion triggered in " << function << " by failing check \"" << expr << "\"" << " in file " << file << ":" << line << std::endl; ::abort(); } } // namespace boost

2 1

Support for reading/writing binary 'streams' (asio?)
by Olaf van der Spek 13 Apr '06

13 Apr '06

Hi, When reading/writing binary streams, you often need to read/write an (unaligned) integer in big, little or native endian. Is there support for this in Boost? I think iostreams isn't usable as 'zero-copy' is required. What do other Boost developers/users use/recommend? Wouldn't this make a nice additional to the new asio library? Olaf

7 11

Using serialization for replication
by prez＠neuromancy.net 10 Apr '06

10 Apr '06

Hey, I want to use serialization for some kind of active replication, however the biggest barrier to this is the fact that serialization does not allow me to put the same object into the stream twice. To be more precise, I want to be able to serialize both to a network and to disk, and I very much like the elegance of the serialization approach (plus the fact it can re-create pointer references, arrays, and such). So my questions are: a) How difficult would it be to be able to allow an object to be serialized twice, where the second copy would more or less do an operator= (instead of creating a new object) on the first copy on deserialization. b) How difficult would it be to have more or less an 'appending' serialization stream - ie. I deserialize what I have previously stored on disk, and then continue to append to the serialization stream (which appends to the file from then on), making my serialization more or less unbounded. c) Is there currently an unbounded serialization stream? I mean, obviously the XML stream will not be 'complete' until you close the serialization stream and it can append any close tags it needs to, however if I wanted to continually write to a stream throughout the time my program is running, and if it crashes, be able to use that to get back to the state I was in, is it possible? I realize that in some respects this is kind of hammering a square peg into a round hole, since serialization seems to have been designed for 'one-short rights', but serialization and replication type functionality is very similar in nature. -- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis

3 8