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

[filesystem] Some comments
by Martin Adrian 17 Mar '06

17 Mar '06

1. The exception specifications are not clear - All predicates (exists, is_*) will throw on errors but you need to look into the status functions to see it. - What happens if an error occurs while iteratoring a directory or when the recursive iterator can't descend into a sub-folder. 2. Why not include the system_error code in the file_status object? If you want to avoid exceptions with the currenct code you need to write code like: system_error_code ec; file_status f(status(p, ec)); if (exists(f) && is_directory(f)) .. else if (status_known(f)) cout << "path is not a directory"; else cout << system_error_message(ec); // can't find this function in the TR2 and // I don't care what the problem is. system_error_code ec; if (is_regular(status(p, ec))) ... Which is kind of messy since the ec and f can't be scoped. It also seem strange that you need to define a system_error_code variable just to avoid exceptions. With a file_status object defined as struct file_status { explicit file_status(file_type v = status_unknown, system_error_code e = 0); file_type type() const; system_error_code error_code() const; std::string system_error_message() const; operator safe_bool() const { return ec == 0; } }; the code can be written as: if (file_status f(p, std::nothrow_t)) if (exists(f) && is_directory(f)) ... else cout << "Path is not a directory"; else cout << f.system_error_message(); and if (is_regular(status(p, std::nothrow_t))) ... 3. Why not differentiate storage type and interface type in the basic_path class?

2 2

[Boost-bugs] [ boost-Patches-1452698 ] iostreams // file_descriptor::seek BUG on files > 4 GB
by SourceForge.net 17 Mar '06

17 Mar '06

Patches item #1452698, was opened at 2006-03-17 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452698&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: iostreams // file_descriptor::seek BUG on files > 4 GB Initial Comment: Boost 1.33.1 iostreams library file_descriptor::seek() method file_descriptor.cpp, line 198 Win32, Visual C++ 2005 The method seek() can return a wrong value of a newly set offset when the offset is further than 4 GB. //--------------- return offset_to_position((lDistanceToMoveHigh << 32) + dwResultLow); //--------------- The code above has a bug. On 32-bit systems the expression (lDistanceToMoveHigh << 32) equals to lDistanceToMoveHigh. The correct code should first cast the lDistanceToMoveHigh variable to 64-bit and then shift it. //--------------- return (static_cast<boost::intmax_t> lDistanceToMoveHigh) << 32) + dwResultLow; //--------------- Sergey Kolodkin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452698&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

what do you get when you cross MPL metadata and boost::variant?
by Korcan Hussein 17 Mar '06

17 Mar '06

Enumerated Types (& simulated pattern matching): #include <iostream> #include <boost/mpl/size_t.hpp> #include <boost/variant.hpp> namespace mpl = boost::mpl; struct APPLES_ : mpl::size_t<0u> {} const APPLES; struct ORANGES_ : mpl::size_t<1u> {} const ORANGES; struct PEACHES_ : mpl::size_t<2u> {} const PEACHES; typedef boost::variant<APPLES_, ORANGES_, PEACHES_> fruit_type; struct fruit_printer : boost::static_visitor<void> { void operator()(APPLES_ a) const { std::cout << "apples: " << a << '\n'; } template < typename Tp > void operator()(Tp v) const { // catch all std::cout << typeid(Tp).name() << ": " << v << '\n'; } } const print_fruit; int main() { fruit_type my_fruit = APPLES; boost::apply_visitor(print_fruit, my_fruit); my_fruit = ORANGES; boost::apply_visitor(print_fruit, my_fruit); my_fruit = PEACHES; boost::apply_visitor(print_fruit, my_fruit); // my_fruit = mpl::size_t<4u>(); // compile-time error // my_fruit = 6u; // compile-time error } There might be some merit here such that generalization is applicable with some macro metaprogramming.

1 0

[numeric cast] Borland 2006 patch
by AlisdairM 17 Mar '06

17 Mar '06

Workarounds for old compiler are still necessary, simple update of version check should suffice: cvs diff -u -wb -- boost\numeric\conversion\cast.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/numeric/conversion/cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/conversion/cast.hpp,v retrieving revision 1.8 diff -u -w -b -r1.8 cast.hpp --- boost/numeric/conversion/cast.hpp 27 Jun 2005 15:05:12 -0000 1.8 +++ boost/numeric/conversion/cast.hpp 19 Feb 2006 12:19:22 -0000 @@ -22,7 +22,7 @@ #include <boost/detail/workaround.hpp> -#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564) +#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x581)) # include<boost/numeric/conversion/detail/old_numeric_cast.hpp> OK to commit? -- AlisdairM

2 2

[thread] monitor
by Vaclav Vesely 17 Mar '06

17 Mar '06

Hi, I all the time use mutexs and conditions in in following manner: // declaration Type m_value; mutex m_value_mutex; condition m_value_condition; // set new value { mutex::scoped_lock lock(m_mutex); m_value = new_value; } // wait for some condition { mutex::scoped_lock lock(m_mutex); while(<condition>) m_condition.wait(lock); } I'm wondering about something like this: // declaration monitor<Type> m_value; // set new value - locking in done in a monitor assignment m_value = new_value // wait for some condition m_value.wait(<lambda expression>) Do you think this concept is generally useful and should be added to the library? Regards, Vaclav

2 1

[tr1] cstdint
by Kevin Sopp 17 Mar '06

17 Mar '06

Hi, since boost already has a cstdint.hpp header it would be nice if we could have it in boost's tr1 adoption too. Kevin Sopp _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

[serialization] text archives, strings and embedded nulls
by Joaquín Mª López Muñoz 17 Mar '06

17 Mar '06

Hello, Currently, output text archives implement string saving like this: template<class Archive> BOOST_ARCHIVE_DECL(void) text_oarchive_impl<Archive>::save(const std::string &s) { const std::size_t size = s.size(); *this->This() << size; this->This()->newtoken(); os << s; } which looks fine, except that some stdlib implementations don't do the "os<<s" right when s contains embedded nulls --basically, output stops at the first embedded null. Such a defective stdlib implementation is for instance, that of MSVC 6.5, and I have had conversations with Linux users leading me to suspect some libstdc++ implementations as well. Besides, the std requirements on operator<<(ostream,string) mandate that this function does a lot more things than simply dump the characters of the string, as text_iarchive_impl<Archive>::load(std::string &) assumes implicitly (reading is done through istream::read.) The attached example shows the problem. It crashes in MSVC 6.5, my hunch is that it'll fail in some other environments as well, though not in every one. Using intermediate buffers of type vector<char> fixes the problem. My suggestion is that text_oarchive_impl<Archive>::save(const std::string &s) be changed so as to dump the string as follows: template<class Archive> BOOST_ARCHIVE_DECL(void) text_oarchive_impl<Archive>::save(const std::string &s) { const std::size_t size = s.size(); *this->This() << size; this->This()->newtoken(); os.write(s.data(),s.size()); } so as to avoid problems with embedded nulls. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[serialization] ambiguous concrete polymorphic archives
by Kim Barrett 16 Mar '06

16 Mar '06

The archive concepts include an is_saving and is_loading typedef. For concrete polymorphic archive types, such as polymorphic_binary_iarchive, attempting to access these values results in a compilation error due to ambiguity - there are two accessible definitions, from different base classes, specifically detail::interface_iarchive<binary_iarchive> detail::interface_iarchive<polymorphic_iarchive>

1 0

[test] gcc-warning patch
by Juergen Hunold 16 Mar '06

16 Mar '06

Hi ! I've been playing around with Boost.Test and I'm very impressed. We use gcc's -pedantic option in our build environment and this found an extra semicolon at uni_test_suite.hpp at line 51. Full patch against current anon cvs attached. This is a minor glitch, but some people are fond of -pedantic. (that's why my colleague activated it :-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

2 1

[in_place_factory] small typo
by David Grüner 16 Mar '06

16 Mar '06

http://www.boost.org/libs/utility/in_place_factories.html shceme -> scheme

2 1