July 2008 - Boost - lists.boost.org

[1.36.0] Unmerged SVN Properties
by Beman Dawes 10 Jul '08

10 Jul '08

There are a whole bunch (see below) of messages from the unmerged changes analysis that look like this: Property changes on: tr1/tr1/valarray ___________________________________________________________________ Name: svn:eol-style + native Name: svn:mime-type + text/plain I guess these need to be merged from trunk to branches/release like any other change. --Beman Here is the full list: Property changes on: archive/detail/polymorphic_iarchive_route.hpp Property changes on: archive/detail/polymorphic_oarchive_route.hpp Property changes on: archive/xml_archive_exception.hpp Property changes on: compatibility/cpp_c_headers/cassert Property changes on: compatibility/cpp_c_headers/cctype Property changes on: compatibility/cpp_c_headers/cerrno Property changes on: compatibility/cpp_c_headers/cfloat Property changes on: compatibility/cpp_c_headers/climits Property changes on: compatibility/cpp_c_headers/clocale Property changes on: compatibility/cpp_c_headers/cmath Property changes on: compatibility/cpp_c_headers/csetjmp Property changes on: compatibility/cpp_c_headers/csignal Property changes on: compatibility/cpp_c_headers/cstdarg Property changes on: compatibility/cpp_c_headers/cstddef Property changes on: compatibility/cpp_c_headers/cstdio Property changes on: compatibility/cpp_c_headers/cstdlib Property changes on: compatibility/cpp_c_headers/cstring Property changes on: compatibility/cpp_c_headers/ctime Property changes on: compatibility/cpp_c_headers/cwchar Property changes on: compatibility/cpp_c_headers/cwctype Property changes on: config/warning_disable.hpp Property changes on: detail/lightweight_thread.hpp Property changes on: detail/sp_convertible.hpp Property changes on: detail/sp_counted_base_spin.hpp Property changes on: detail/spinlock.hpp Property changes on: detail/spinlock_gcc_arm.hpp Property changes on: detail/spinlock_nt.hpp Property changes on: detail/spinlock_pool.hpp Property changes on: detail/spinlock_pt.hpp Property changes on: detail/spinlock_sync.hpp Property changes on: detail/spinlock_w32.hpp Property changes on: detail/yield_k.hpp Property changes on: graph/edmonds_karp_max_flow.hpp Property changes on: graph/r_c_shortest_paths.hpp Property changes on: iostreams/detail/execute.hpp Property changes on: iostreams/detail/file_handle.hpp Property changes on: iostreams/detail/file_times.hpp Property changes on: iostreams/detail/functional.hpp Property changes on: iostreams/detail/path.hpp Property changes on: iostreams/filter/grep.hpp Property changes on: make_shared.hpp Property changes on: math/distributions/detail/generic_mode.hpp Property changes on: math/distributions/detail/generic_quantile.hpp Property changes on: math/distributions/non_central_beta.hpp Property changes on: math/distributions/non_central_chi_squared.hpp Property changes on: math/distributions/non_central_f.hpp Property changes on: math/distributions/non_central_t.hpp Property changes on: math/special_functions/detail/lanczos_sse2.hpp Property changes on: math/special_functions/detail/round_fwd.hpp Property changes on: math/special_functions/expint.hpp Property changes on: math/special_functions/modf.hpp Property changes on: math/special_functions/next.hpp Property changes on: math/special_functions/pow.hpp Property changes on: math/special_functions/round.hpp Property changes on: math/special_functions/trunc.hpp Property changes on: math/special_functions/zeta.hpp Property changes on: math/tr1.hpp Property changes on: memory_order.hpp Property changes on: pool/detail/for.m4 Property changes on: pool/detail/pool_construct.inc Property changes on: pool/detail/pool_construct.m4 Property changes on: pool/detail/pool_construct_simple.inc Property changes on: pool/detail/pool_construct_simple.m4 Property changes on: property_tree/detail/exceptions_implementation.hpp Property changes on: property_tree/detail/file_parser_error.hpp Property changes on: property_tree/detail/info_parser_error.hpp Property changes on: property_tree/detail/info_parser_read.hpp Property changes on: property_tree/detail/info_parser_utils.hpp Property changes on: property_tree/detail/info_parser_write.hpp Property changes on: property_tree/detail/info_parser_writer_settings.hpp Property changes on: property_tree/detail/json_parser_error.hpp Property changes on: property_tree/detail/json_parser_read.hpp Property changes on: property_tree/detail/json_parser_write.hpp Property changes on: property_tree/detail/path_implementation.hpp Property changes on: property_tree/detail/ptree_implementation.hpp Property changes on: property_tree/detail/ptree_utils.hpp Property changes on: property_tree/detail/pugxml.hpp Property changes on: property_tree/detail/rapidxml.hpp Property changes on: property_tree/detail/translator_implementation.hpp Property changes on: property_tree/detail/xml_parser_error.hpp Property changes on: property_tree/detail/xml_parser_flags.hpp Property changes on: property_tree/detail/xml_parser_read_pugixml.hpp Property changes on: property_tree/detail/xml_parser_read_pugxml.hpp Property changes on: property_tree/detail/xml_parser_read_rapidxml.hpp Property changes on: property_tree/detail/xml_parser_read_spirit.hpp Property changes on: property_tree/detail/xml_parser_read_tinyxml.hpp Property changes on: property_tree/detail/xml_parser_utils.hpp Property changes on: property_tree/detail/xml_parser_write.hpp Property changes on: property_tree/detail/xml_parser_writer_settings.hpp Property changes on: property_tree/info_parser.hpp Property changes on: property_tree/ini_parser.hpp Property changes on: property_tree/json_parser.hpp Property changes on: property_tree/ptree.hpp Property changes on: property_tree/ptree_fwd.hpp Property changes on: property_tree/ptree_serialization.hpp Property changes on: property_tree/xml_parser.hpp Property changes on: serialization/assume_abstract.hpp Property changes on: serialization/factory.hpp Property changes on: serialization/singleton.hpp Property changes on: serialization/vector_134.hpp Property changes on: statechart/detail/reaction_dispatcher.hpp Property changes on: swap.hpp Property changes on: test/utils/lazy_ostream.hpp Property changes on: tr1/tr1/algorithm Property changes on: tr1/tr1/array Property changes on: tr1/tr1/bitset Property changes on: tr1/tr1/complex Property changes on: tr1/tr1/deque Property changes on: tr1/tr1/exception Property changes on: tr1/tr1/fstream Property changes on: tr1/tr1/functional Property changes on: tr1/tr1/iomanip Property changes on: tr1/tr1/ios Property changes on: tr1/tr1/iostream Property changes on: tr1/tr1/istream Property changes on: tr1/tr1/iterator Property changes on: tr1/tr1/limits Property changes on: tr1/tr1/list Property changes on: tr1/tr1/locale Property changes on: tr1/tr1/map Property changes on: tr1/tr1/memory Property changes on: tr1/tr1/new Property changes on: tr1/tr1/numeric Property changes on: tr1/tr1/ostream Property changes on: tr1/tr1/queue Property changes on: tr1/tr1/random Property changes on: tr1/tr1/regex Property changes on: tr1/tr1/set Property changes on: tr1/tr1/sstream Property changes on: tr1/tr1/stack Property changes on: tr1/tr1/stdexcept Property changes on: tr1/tr1/streambuf Property changes on: tr1/tr1/string Property changes on: tr1/tr1/strstream Property changes on: tr1/tr1/tuple Property changes on: tr1/tr1/type_traits Property changes on: tr1/tr1/typeinfo Property changes on: tr1/tr1/utility Property changes on: tr1/tr1/valarray Property changes on: tr1/tr1/vector Property changes on: utility/swap.hpp

1 0

[extension] Problem with reference types
by Robert Dailey 10 Jul '08

10 Jul '08

I have the following exported factory function in a DLL I'm building on Windows: extern "C" void BOOST_EXTENSION_EXPORT_DECL export_aspects( boost::extensions::factory_map& fm ) { using namespace vfx::aspects; using namespace vfx::messenger; fm.get<Aspect, MessageReader&, unsigned int>()[0].set<Appearance>(); fm.get<Aspect, MessageReader&, unsigned int>()[1].set<Health>(); } As you can see, I am specifying that each class accepts a single construction parameter- a reference to a MessageReader object. However, this isn't compiling because I don't think that it likes reference types. How can I specify that the constructor takes a reference? boost::ref? I would post the compiler warnings & errors I'm getting, however they're exceedingly large. Most of the warnings and errors are coming from std::map, basically complaining that it's trying to create a map of reference types, which can't possibly work. Help is appreciated. As an unrelated note, I would really like to see the template parameters cleaned up. There's at least 5 places I've had to redundantly specify the same 3 template parameters (like in the example above). I already brought this up in another thread, but I can't tell you how important it is. If I ever change the number of construction parameters my Appearance or Health classes take (mapped above), I will have to shift through 5 or more files simply to adjust all of the template parameters to make everything compile.

1 1

[asio] std::ostream request_stream
by simonvifr＠voila.fr 10 Jul '08

10 Jul '08

Good morning, In the examples that illustrate the use of Boost.Asio in more complex applications, there is the "boost_asio/example/http/client/sync_client.cpp" example. In this example, the following code is written : boost::asio::streambuf request; std::ostream request_stream(&request); request_stream << "GET " << argv[2] << " HTTP/1.0\r\n"; request_stream << "Host: " << argv[1] << "\r\n"; request_stream << "Accept: */*\r\n"; request_stream << "Connection: close\r\n\r\n"; I would like to use the POST method with parameters instead of GET method, and to set the "Content-Type" property. But I do not how to do. Could you tell me more about using the POST method and setting the "Content-Type" property ? Could you also tell me where I can find documentation about it ? Thank you for your response, Regards. ____________________________________________________ Sur le mail Voila, vous pouvez personnaliser l’anti-spam ! http://mail.voila.fr

1 0

An elegant way to initialize an instance of boost::any with a C-style string constant
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to improve usage of boost::any with text (char*) constants. This would be the goal: boost::any foo("foo"); boost::any bar; bar = "bar"; Currently the compiler (MSVC 2008 in my case) complains about it: ...\boost\any.hpp(117) : error C2536: 'boost::any::holder< ValueType>::boost::any::holder<ValueType>::held' : cannot specify explicit initializer for arrays There are more ways to make it compiled, all of them either with an extra cast or object construction: boost::any foo(static_cast<const char *>("foo")); boost::any foo((const char *) "foo"); boost::any foo(std::string("foo")); Supposing there is no way to persuade the compiler to consider the constant not to be an array but just a pointer I would suggest adding support for arrays to boost::any. I am sorry if it has been discussed already. I found just one thread without a conclusion (http://lists.boost.org/Archives/boost/2003/01/43460.php) I asked about it in boost.users and got a nice proposal from Niels Dekker (http://thread.gmane.org/gmane.comp.lib.boost.user/37189/focus=37414) I replaced the member "held" in holder<> by a wrapper specialized for arrays: template<typename ValueType> struct wrapper { ValueType data; explicit wrapper(const ValueType & value) : data(value) {} }; template<typename ElementType, std::size_t NumberOfElements> struct wrapper<ElementType[NumberOfElements]> { typename remove_const<ElementType>::type data[NumberOfElements]; explicit wrapper(const ElementType (& value)[NumberOfElements]) { std::copy(value, value + NumberOfElements, data); } }; A new constructor in boost::any makes use of it: template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<ElementType[NumberOfElements]>(value)) {} This solution is more complicated but it makes the instance of boost::any own the copy of array just like its for scalar objects. Alternatively, instead of wrapping a copy of the array, I could store just a pointer to it without any other changes in bost::any (I want to use just constants in my example): template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<const ElementType*>(value)) {} I am attaching a patch to any.hpp from boost 1.35.0. I could provide a test for it too. What do you think about it? Shall I create a feature request for it? Thank you, Ferda

4 5

Re: [boost] How do you make MPL-compatible template meta-functions?
by joaquin＠tid.es 09 Jul '08

09 Jul '08

Hi Daryle Daryle Walker escribió: > Here's what I'm trying (to redo integer_test.cpp) [...] > BOOST_STATIC_ASSERT > ( (boost::is_same<distinct_integral_bit_counts, > boost::mpl::list_c<int, 8, 16, 32, 64> >) ); > } > I think there are two problems with this: 1. You're passing a *type* (boost::is_same<...>) to BOOST_STATIC_ASSERT when you should be passing a numeric contanst. Append ::value to the type. 2. Even with the correction above the thing won't work because is_same<T,Q> checks for strict equality of the types T and Q; in your case distinct_integral_bit_counts is *not* the same type as boost::mpl::list_c<...>, but only has the same components. You can use boost::mpl::equal to test this: BOOST_STATIC_ASSERT ( (boost::mpl::equal<distinct_integral_bit_counts, boost::mpl::list_c<int, 8, 16, 32> >::value) ); } Other than that, your type_to_digit_count is perfectly lambda-cabable AFAICS. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[Iostreams] Support std::codecvt<char> and std::codecvt_base::noconv in boost::iostreams::code_converter
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I found two problems when using boost::iostreams::code_converter with char as source (internal) type for the conversion. Firstly, I was not able to use facets parameterized with char extracted from std::locale and secondly, my test run in an endless loop if the facet returned std::codecvt_base::noconv from do_in() or do_out(). I would like to use the boost::iostreams::code_converter in a class parametrized either for char or wchar_t using the default std::codecvt. This code works for wchar_t: namespace io = boost::iostreams; class test { io::stream<io::code_converter<xxxodevice, io::default_codecvt> > output; ... }; However I cannot make in templated like this without inheriting from std::codecvt and pasing the inherited type to io::code_converter instead of std::codecvt: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; ... }; The compiler complains about the usage of std::codecvt: error C2248: 'std::codecvt<_Elem,_Byte,_Statype>::~codecvt' : cannot access protected member declared in class 'std::codecvt<_Elem,_Byte,_Statype>' io::detail::codecvt_holder<Codecvt> in codecvt_holder.hpp stores a copy of Codecvt but std::codecvt defines only protected destructor: template<typename Codecvt> struct codecvt_holder { ... Codecvt codecvt_; }; Standard std::codecvt specialized for wchar_t is solved by its explicit specialization storing the pointer: struct default_codecvt { typedef wchar_t intern_type, from_type; typedef char extern_type, to_type; typedef std::mbstate_t state_type; }; template<> struct codecvt_holder<default_codecvt> { ... const codecvt_type* codecvt_; }; Obviously it supports the most usual usage with an instance extracted from std::locale which owns it: typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type; ... = &std::use_facet<codecvt_type>(locale); What about facets not converting from sequence of wchat_ts but chars? If I imbue such facet to a locale I am not able to extract it and use it in io::code_converter: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; I helped it by converting io::detail::default_codecvt and the specialization of io::detail::codecvt_holder for it in codecvt_holder.hpp to this: template <class C> struct basic_default_codecvt { typedef C intern_type, from_type; ... }; template <class C> struct codecvt_holder<basic_default_codecvt<C> > { typedef std::codecvt<C, char, std::mbstate_t> codecvt_type; ... }; typedef basic_default_codecvt<wchar_t> default_codecvt; Now I was able to compile my slightly modified code: template <class C> class test { io::stream<io::code_converter<xxxodevice, io::detail::basic_default_codecvt<C> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; After being able to compile it a simple output code run endlessly. I found out that the facet in the default locale did not convert but it did not return true from always_noconv() from some reason. io::code_converter can cope with it - it copies the input buffer to the output one but it does not increase the pointer to the next character in the output buffer nor does it decrease the total bytes processed in io::code_converter::write. I am not sure about the behavior of the coverter if the facet returns std::codecvt_base::noconv. Currently it copies the buffer if internal type is the same as external one (both char) otherwise it does nothing (?). Should it not copy or assert if they are diferent? At least the writing should succeed if there was no conversion done and the characters were copied. I tried to modify the code accordingly and it succeeded then. I am attaching a patch to code_converter.hpp and codecvt_holder.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0

[Iostreams] What about making code_converter from boost::iostreams flushable?
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; stream << " and another raw"; Running the code writes "raw and another raw and converted" instead of "raw and converted and another raw" to the stream. I found that first in destructor of io::code_converter is the conversion buffer flushed causing the output. I could create a new instance of io::code_converter for every output and always close it: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; { io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; } stream << " and another raw"; But I would feel better being able to reuse the io::code_converter. (Actually, I have it as a private field in a class now.) I would like to make the io::code_converter flushable to be able to combine the output more conveniently: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted" << std::flush; stream << " and another raw"; I added the support to io::code_converter rather that inheriting from it. What do you think about it? Would you accept it to boost or is it better to make flushable my inherited class? I am attaching a patch to code_converter.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0

[Iostreams] code_converter from boost::iostreams fails with bidirection device
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an input/output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxiodevice> > wrapper(*stream.rdbuf()); wrapper << L"and converted"; I created a device wrapping std::streambuf. Pure input device (using io::source_tag) and pure output device (using io::sink_tag) were working. Combined device (using io::bidirectional_device_tag) failed with access violation in destructor (flushing and closing) of the io::code_converter in code_converter.hpp: template<typename Device, typename Codevt, typename Alloc> std::streamsize code_converter<Device, Codevt, Alloc>::write (const char_type* s, std::streamsize n) { buffer_type& buf = out(); ... std::codecvt_base::result result = // buf.eptr() was null here cvt().out( buf.state(), s + total, s + n, nint, buf.eptr(), buf.end(), next ); ... } I wondered how it is possible that the output buffer was not initialized. I learnt that the buffer was intentionally skipped in code_converter.hpp: template<typename Device, typename Codecvt, typename Alloc> struct code_converter_impl { ... void open(const Device& dev, int buffer_size) { ... // following condition is false for bidirectional if (can_write::value && !is_double::value) { buf_.second().resize(buffer_size); buf_.second().set(0, 0); } ... } ... }; The reason is the definition of a bidirectional device in categories.hpp: struct bidirectional : virtual input, virtual output, detail::two_sequence {}; It is detected in the io::code_converter turning off the initialization: typedef is_convertible<device_category, two_sequence> is_double; It means that I cannot use io::code_converter with io::bidirectional combining both io::input and io::output tags. Unfortunately I was not able to use these both explicitely: // original: typedef io::bidirectional_device_tag category; struct category : io::device_tag, io::input, io::output {}; The compiler complained about it with a message I was not able to fix: error C2784: 'std::basic_ostream<_Elem,_Traits> &boost::operator <<( std::basic_ostream<_Elem,_Traits> &,const boost::shared_ptr<Y> &)' : could not deduce template argument for 'std::basic_ostream< _Elem,_Traits> &' from 'boost::iostreams::stream<Device>' So far, I found just one working solution without changing boost sources - using two objects; one for reading, another one for writing: xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxidevice> > inwrapper(*stream.rdbuf()); io::stream<io::code_converter<xxxodevice> > outwrapper(*stream.rdbuf()); outwrapper << L"and converted"; However, I would like to use one object if it was possible. In my case, all writing is always finished before reading and vice versa. Encoding states in std::codecvt would not overlap. What would you suggest as a solution for input/output devices in io::code_converter? 1. Stick with the two objects - one for input, one for output. 2. Fix io::code_converter to accept devices with io::bidirectional tag. Either initialize both buffers or reuse the input one. 3. Use different tag than io::bidirectional. Which one? 4. Maybe I am wrapping std::streambuf in a wrong way. Is there another? I am attaching a simple example of a stripped source demonstrating the issue on std::stringstream. Thank you, Ferda

1 0

[Boost.Log1]: Bug in boost/log/detail/ts_posix.hpp
by Jens Seidel 09 Jul '08

09 Jul '08

Hi, I know that version 1 of John's logging library was never accepted and is probably not wildly used anymore nevertheless I found a nasty bug in it. It's strange but even after applying valgrind I found initially not the reason (probably I just assumed John's code is OK and it's something else) and it took some time until I resolved it. OK, for all users of this lib here is the patch: boost/log/detail/ts_posix.hpp: @@ -51,7 +51,7 @@ mutex & operator = ( const mutex & Not_Implemented); mutex( const mutex & From); public: - mutex() : m_mutex() { + mutex() : m_mutex(), m_count(0) { pthread_mutexattr_t attr; int res = pthread_mutexattr_init(&attr); assert(res == 0); I haven't checked whether this occurs in version 2 as well. Jens

3 3

Fusion Question
by Tom Brinkman 09 Jul '08

09 Jul '08

Heres a link to a simple unit test that demonstrates the layout library. http://www.reportbase.com/unit_test.hello.html

2 1