- Boost - lists.boost.org

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

Link boost DLL (BOOST_ALL_DYN_LINK) ? Beginner..
by Renato Tegon Forti 21 Nov '05

21 Nov '05

Hi all, I did try use: BOOST_ALL_DYN_LINK, but I did't have success. The boost returns this to me: c:\Boost\include\boost-1_33_1\boost\config\auto_link.hpp(281): fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." How I fix this? My code: // BoostDefines.hpp : Defines the entry point for the console application. // //-------------------------------------------------------------------------- -- // //-------------------------------------------------------------------------- -- // Filename: BoostDefines.hpp // Type: Declaration // Language: Microsoft Visual C++ V7.1 // Module: //-------------------------------------------------------------------------- -- // Description: class BoostDefines //-------------------------------------------------------------------------- -- #ifndef BOOSTDEFINES_HPP #define BOOSTDEFINES_HPP #pragma once #define BOOST_ALL_DYN_LINK #define BOOST_THREAD_USE_DLL //thread header not compliant with 'BOOST_ALL_DYN_LINK' #define BOOST_LIB_DIAGNOSTIC #ifdef BOOST_ALL_DYN_LINK #pragma message("Include: dynamic linking with boost libraries") #endif #endif //BOOSTDEFINES_HPP // test.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "BoostDefines.hpp" #include <boost/lexical_cast.hpp> #include <boost/regex.hpp> int _tmain(int argc, _TCHAR* argv[]) { //... //use boost //... return 0; }

2 1

c++/cli boost subproject?
by relative＠gmx.net 21 Nov '05

21 Nov '05

is there, or are there plans for, a boost c++/cli subproject? i've played around with boost and the cli compiler, a lot of libraries work with unmanaged data types (with a lot of warnings, but work), others don't. none work with managed data types of course although that wouldn't be a big problem I suppose. (e.g. boost::tuple) the spec is there, at least one compiler exists(mono?) and there is a STL called STL.NET by dinkumware(distributed by microsoft) for c++/cli. I haven't found anything on the website or the mailing list archives, is this beyond the scope of the boost project? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner

7 10

boost::thread - mistake in documentation
by Oliver.Kowalke＠infineon.com 21 Nov '05

21 Nov '05

Hello, the documentation (http://www.boost.org/doc/html/condition.html) of class condition contains a mistake: instead of template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, Pred); it should be template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, const boost::xtime <http://www.boost.org/doc/html/xtime.html> & , Pred); so long, Oliver

1 0

contribution - sync. queue between producer/consumer threads
by Oliver.Kowalke＠infineon.com 21 Nov '05

21 Nov '05

Hello, I would contribute this code. The queue synchronizes the access between producer threads (putting items into the queue) and consumer threads (removing items from queue). I would be glad if you add this code to boost::thread library. With regards, Oliver <<queue.hpp>> <<test.cpp>>

1 0

Re: [boost] [multi_index] ordered_index should be noncopyable?
by JOAQUIN LOPEZ MU?Z 21 Nov '05

21 Nov '05

----- Mensaje original ----- De: Dylan Trotter <trotterdylan(a)yahoo.ca> Fecha: Domingo, Noviembre 20, 2005 8:17 pm Asunto: [boost] [multi_index] ordered_index should be noncopyable? > I just had a really irritating time tracking down bad memory access > in > ordered_index because I foolishly wrote something like this: > > typedef client_set::nth_index<0>::type address_index_type; > address_index_type addressIndex = clients_.get<0>(); > address_index_type::iterator iter = addressIndex.find(addr); > > The problem here is that I got my addressIndex by value in the > second > line. I may be overlooking something here, but I think it might be > useful to make ordered_index noncopyable so that this would be > detected > at compile time instead of runtime. I nearly threw my monitor out > the > window over this one. > Hi Dylan, I'm sorry you had a hard time with that. The truth is, indices are not copyable; moreover, I comment on this very mistake you have stumbled upon at the end of the following section: http://boost.org/libs/multi_index/doc/tutorial.html#multipe_sort So, how come you can compile even when the docs state you shouldn't? The problem is that some compilers have problems with template friends (signaled by Boost.Config macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS) that force me to make (on these compilers only) some internal index ctors public, hence your problem. What compiler are you using? MSVC 6.5/7.x/8.0 all have this problem. Most others don't, and on those a nice compiler error would have popped up when compiling your snippet. Again, I'm sorry for the time you might have wasted. At least, you have refrained from throwing the monitor out of the window :) Thanx for using Boost.MultiIndex. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization] fast array serialization (10x speedup)
by bwood 21 Nov '05

21 Nov '05

Matthias Troyer wrote: >> >> i) somehow I doubt that this archive type has been tested with all >> the serialization test suite. Instructions for doing so are in the >> documenation and the serialization/test directory includes batch files >> for doing this with one's own archives. Was this done? What where >> the >> results? With which compiler? It costs nothing to do this. > > >Just ask if you had a doubt. The short answer is "I have done this". >After adding the fast array serialization to the binary and >polymorphic archives, I ran all your regression tests, without any >problem (using gcc 4 under MacOS X). Have you done this with vector also? I would be surprised if you have. It seems to me there is a standards issue to be addressed in this area. It is no problem to send the data in a vector of int as a unit, but I don't know of a way to add/receive the data into a vector correctly. It is possible to stuff the data into the correct place, but the vector's internal state/size does not get set properly since you didn't call push_back or some other method to get the data into place. Adding something like push_n_back to vector might help when it comes this. Brian www.webEbenezer.net

2 1