- Boost - lists.boost.org

type_traits / MPL interoperability
by David Abrahams 22 Nov '05

22 Nov '05

I just ran into a problem caused by the TR1-ization of the type traits library. I had a function defined this way: template <class T> typename is_fundamental<T>::type f(T) { return mpl::bool_< is_fundamental<T>::value >(); } that wouldn't compile. Eventually I discovered that it was because type traits now yield instances of integral_constant<T,N> (is that documented somewhere now?) integral_constant<T,N> is derived from mpl::integral_c<T,N>, but mpl::bool_<N> is not derived from integral_constant<T,N>. I can understand not wanting to introduce that sort of two-way coupling between the libraries, but it also seems like the only way to make everything work smoothly. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

[Wave] Added dll support
by Hartmut Kaiser 22 Nov '05

22 Nov '05

Hi all, This is to notify you all that I've added '<runtime-link>dynamic' support to the Wave library (as recently requested by several of you). Please check it out (Boost::HEAD) and give it a test. This was added to the V1 Jamfiles only, for now. Regards Hartmut

1 0

Re: [boost] Boost.Logging: formal review
by Matt Doyle 22 Nov '05

22 Nov '05

> [mailto:boost-bounces@lists.boost.org]On Behalf Of John Torjo > Gennadiy Rozental wrote: > > > BTW before I start, I recalled couple more issues I forgot > to mention in > > original post: > > > > 1. Design: Lightweight interface > > Log library brings a lot of dependencies. In some case I do > not want this if > > Care to exemplify? What are the dependencies? > > > I need to use the library in header. IMO log needs to > support/implement some > > lightweight debug abstract interface Something like: > > > > struct DebugLog { > > virtual void log( string const& ) = 0; > > virtual void log( int ) = 0; > > }; > > > > struct Log : DebugLog { ... }; > > > > Now I could use DebugLog interface without need to know an > implementation. > > It comes with the price of virtual call. I primarily use > this for debug only > > logging. > > Anybody else wants this? Yes, for me that would be useful. > > 3. Design: hexdump > > I believe log library needs to provide support for dumping > memory in hex > > format on log file. It could be an addon to core functionality. > > > > I can add this, even though I'm not sure why you'd want this. Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/ > > > 4. Design: logged assert > > I believe log library needs to provide support for custom > assert. Such > > assert would log into log file and invoke system assert > depends in assert > > level. It could be an addon to core functionality. > > > > Well, I want to adapt SMART_ASSERT to allow for this functionality. Kind of falls in line with what I said in #3. I want to log the recoverable errors but if it was a non-recoverable error then "log & die" would fit nicely. Kind regards, Matt Scanned by Fortigate {X3BTB534}

10 16

Boost regression notification (2005-11-21 [RC_1_33_0])
by Douglas Gregor 22 Nov '05

22 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-21T14:38: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… 33 failures in 2 libraries: iostreams (32) serialization (1) |iostreams| array_test: intel-8.1-linux auto_close_test: intel-8.1-linux buffer_size_test: intel-8.1-linux bzip2_test: intel-8.1-linux code_converter_test: intel-8.1-linux component_access_test: intel-8.1-linux compose_test: intel-8.1-linux copy_test: intel-8.1-linux counter_test: intel-8.1-linux direct_adapter_test: intel-8.1-linux example_test: intel-8.1-linux file_descriptor_test: intel-8.1-linux file_test: intel-8.1-linux filtering_stream_test: intel-8.1-linux finite_state_filter_test: intel-8.1-linux flush_test: intel-8.1-linux gzip_test: intel-8.1-linux invert_test: intel-8.1-linux line_filter_test: intel-8.1-linux mapped_file_test: intel-8.1-linux newline_test: intel-8.1-linux null_test: intel-8.1-linux pipeline_test: intel-8.1-linux regex_filter_test: intel-8.1-linux restrict_test: intel-8.1-linux seekable_file_test: intel-8.1-linux seekable_filter_test: intel-8.1-linux stdio_filter_test: intel-8.1-linux symmetric_filter_test: intel-8.1-linux tee_test: intel-8.1-linux wide_stream_test: intel-8.1-linux zlib_test: intel-8.1-linux |serialization| test_nvp_text_archive: vc-8_0

3 3

Re: [boost] multi_index problem in VC 7.1
by JOAQUIN LOPEZ MU?Z 21 Nov '05

21 Nov '05

----- Mensaje original ----- De: Alexander Ivanov <amivanov(a)gmail.com> Fecha: Lunes, Noviembre 21, 2005 9:37 pm Asunto: Re: [boost] multi_index problem in VC 7.1 > I'm having trouple compiling multi_index_container<> with VC++7.1 > Wait, I think I found something... > I started from bidirectional_map example from the library > (http://www.boost.org/libs/multi_index/doc/examples.html#example4) > that compiles and works just fine. > > then i've added third tempate parameter CompareLessT to the > bidirectional map: > > template<typename FromT, typename ToT, typename CompareLessT> > struct bidir_map > { > typedef std::pair<std::string, std::string> value_type; > > typedef multi_index_container< > value_type > , indexed_by< > ordered_unique< > tag<from> > , member<value_type, FromT, &value_type::first> > , CompareLessT> > , ordered_unique< > tag<to> > , member<value_type, ToT, &value_type::second> > ^^^ Here, you are misplacing the second '>'. It should go after CompareLesstT below. > , CompareLessT > > > > type; > }; > HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] multi_index problem in VC 7.1
by JOAQUIN LOPEZ MU?Z 21 Nov '05

21 Nov '05

----- Mensaje original ----- De: Alexander Ivanov <amivanov(a)gmail.com> Fecha: Lunes, Noviembre 21, 2005 9:37 pm Asunto: Re: [boost] multi_index problem in VC 7.1 > I'm having trouple compiling multi_index_container<> with VC++7.1 > > I started from bidirectional_map example from the library > (http://www.boost.org/libs/multi_index/doc/examples.html#example4) > that compiles and works just fine. > > then i've added third tempate parameter CompareLessT to the > bidirectional map: > > template<typename FromT, typename ToT, typename CompareLessT> > struct bidir_map > { > typedef std::pair<std::string, std::string> value_type; > > typedef multi_index_container< > value_type > , indexed_by< > ordered_unique< > tag<from> > , member<value_type, FromT, &value_type::first> > , CompareLessT> > , ordered_unique< > tag<to> > , member<value_type, ToT, &value_type::second> > > , CompareLessT > > > > type; > }; > > and it stops compiling giving me infamous INTERNAL COMPILER ERROR: > e:\edatools\boost\1.32.0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48) > : fatal error C1001: INTERNAL COMPILER ERROR > (compiler file 'msc1.cpp', line 2712) > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for > more information > Hi Alexander. MSVC sometimes plays tricks on you, I cannot give specific advice, try shuffling things around. Sometimes, the ICE masks a real coding error, it'd help if you could post your entire snippet to see if you inadvertently missed something (some header, etc.) Joaquín M López Muñoz Telefónica, Investigación Desarrollo

2 1

Re: [boost] multi_index problem in VC 7.1
by JOAQUIN LOPEZ MU?Z 21 Nov '05

21 Nov '05

Hi Brock, ----- Mensaje original ----- De: Brock Peabody <brock.peabody(a)npcinternational.com> Fecha: Lunes, Noviembre 7, 2005 7:07 pm Asunto: [boost] multi_index problem in VC 7.1 > If I try to compile the very first example in multi index I get the > following error: > > c:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7\include\boost\multi_index\detail\node_type.hpp(56) : error > C2903: 'node_class' : symbol is neither a class template nor a > functiontemplate > > I get this with 1.33 and 1.32. I've tried many different compiler > options. Here is my latest command line: > > /Ox /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "NOMINMAX" /D "_AFXDLL" /D > "_MBCS" /FD /EHsc /MD /GS /Fo"Release/" /Fd"Release/vc70.pdb" /W3 > /nologo /c /Wp64 /Zi /TP > > I've dug around a bit and I can't make any sense of this problem. Has > anyone else seen this? > > The exact code I'm compiling is: > > #include <boost/multi_index/key_extractors.hpp> > #include <boost/multi_index_container.hpp> > [...] I think you forgot to #include <boost/multi_index/ordered_index.hpp> Does this solve your problem? Similar difficulties have been reported at times here in the list, maybe I should update the doc snippets so that the necessary #include's are explicitly shown. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Boost 1.34.0 ?
by Rene Rivera 21 Nov '05

21 Nov '05

Since 1.33.0 has been out for a while shouldn't we bump the version on HEAD to be 1.34.0? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 3

Boost regression notification (2005-11-21 [HEAD])
by Douglas Gregor 21 Nov '05

21 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-21T06:00:12Z 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. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 141 failures in 14 libraries: concept_check (13) graph (3) io (1) math (2) mpl (2) multi_array (1) parameter (12) serialization (30) spirit (2) tr1 (49) type_traits (1) typeof (18) wave (1) xpressive (6) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 vc-7_1 |graph| graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos log1p_expm1_test: gcc-3_4_3-sunos |mpl| size_t: gcc-4_0-darwin zip_view: mingw-3_4_2 |multi_array| concept_checks: mingw-3_4_2 |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tutorial: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-3_4_3-sunos std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_4_3-sunos std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_has_virtual_destructor_test: intel-win32-9_0 |type_traits| has_virtual_destructor_test: intel-win32-9_0 |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave: vc-7_1 |xpressive| test2u: vc-7_1 test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

Re: [boost] [asio] Are the _at_least_n functions useful?
by BRIDGES Dick 21 Nov '05

21 Nov '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of > Christopher Kohlhoff > Sent: Thursday, November 10, 2005 7:18 PM > To: boost(a)lists.boost.org > Subject: [boost] [asio] Are the _at_least_n functions useful? > > > Hello all, > > As part of cleaning up asio's interface I am pondering the utility of > the read_at_least_n/write_at_least_n free functions. I'd appreciate > hearing from anyone who actually uses these functions (or their async > counterparts), and anyone else who has an opinion on the matter :) [snip] > Cheers, > Chris <use_case truncated="yes"> I have done some message passing over TCP where the message headers can be fairly elaborate and there is considerable variation in message size (e.g., DIAMETER RFC 3588). Every time some traffic arrives, one of two questions get asked: "Did we get enough of the header to determine the message length?" or "Given we know the length, do we have the entire message yet?". It would be nice to move this code (and all of the associated anomaly handling) out of the application and *down* into the library. read_at_least_n would certainly be handy. </use_case> As a generalization, I'd say that those two questions get asked almost anytime discrete messages are passed over a stream protocol. <aside humorous="hopefully" sentiment="serious"> I am already using asio on [at least] two projects so I have no stake in hurrying the review process. License is Boost. Great support is available on boost(a)lists.boost.org. Packaging won't change substantially until 1.34. "Accepted" should be a *very* good bet. Take your time. ;) </aside> Regards, Dick Bridges

3 2