- Boost - lists.boost.org

[rtl] - errors compiling example
by Oliver.Kowalke＠qimonda.com 28 Nov '06

28 Nov '06

Hi, I tried the RTL library from the Vault. If I try to compile the example (EarthCoord) I get following errors: compiling test_rtl.cpp (g++) /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp: In member function 'void boost::rel::expression_registry_traverse_functor::operator()(R&, boost::rel::cover_tag) const': /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp:122: error: '<anonymous>' has incomplete type /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp:99: error: forward declaration of 'struct boost::rel::cover_tag' /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp: In member function 'void boost::rel::expression_registry_traverse_functor::operator()(R&, boost::rel::cache_tag) const': /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp:196: error: 'tag' has incomplete type /opt/boost/include/boost-1_33_1/boost/rtl/expression_registry.hpp:98: error: forward declaration of 'struct boost::rel::cache_tag' make[2]: *** [test_rtl.o] Error 1 regards, Oliver

1 0

[config] auto-link tests
by Vladimir Prus 28 Nov '06

28 Nov '06

John, are your V2-based auto-link tests in CVS yet? I'm not sure it would be good to add them to regression tests at this moment, but I'd rather have them in CVS just in case. Thanks, Volodya

2 4

[iostreams] fix cw link errors
by Vladimir Prus 28 Nov '06

28 Nov '06

I've committed the attached patch to fix a couple of link failures of iostreams tests on cw. Two tests, instead of linking to the library, just compile in some source files. At the same time, the tests managed to set BOOST_IOSTREAMS_DYN_LINK -- therefore adding dllimport to all declarations. The compiled-in source had no dllexport. MSVC seems to be forgiving in this situation, but cw is not. I'm 95% this change will fix those two errors, but if somebody thinks the change is wrong -- shout. - Volodya

1 0

[iostreams] [cw-9.4] finite_state_filter
by Vladimir Prus 28 Nov '06

28 Nov '06

This failure: http://tinyurl.com/wlwh2 reads like this: illegal access from 'boost::iostreams::detail::finite_state_filter_impl<identity_fsm>' to protected/private member 'boost::iostreams::detail::finite_state_filter_impl<identity_fsm>::on_any<identity_fsm>(identity_fsm &, char)' It might be a compiler bug, but I'd suppose that enough "friend" declarations should help, and if all fails, the member can be made public just for one compiler. Anybody can look into this? Thanks, Volodya

1 0

[iostreams] compression tests
by Vladimir Prus 28 Nov '06

28 Nov '06

The iostreams compression tests fail on VC7.1 (RudbekAssociates-V2): http://tinyurl.com/y4vngt the error message suggest that the iostreams library is either not built, or built with a wrong name, or something. I would appreciate if somebody look at those. Also, Victor, can you provide the values of iostream-related environment variables? Thanks, Volodya

1 0

Request for review: scope_exit
by Tom Brinkman 28 Nov '06

28 Nov '06

Alexander, Your library has been added to the review queue. Either Ronald or myself will be in touch to make further arrangements about the review schedule. Thank You.

1 0

[test] prg_exec_fail2.cpp
by Vladimir Prus 28 Nov '06

28 Nov '06

The prg_exec_fail2 test fails for OSL-V2: http://tinyurl.com/y3gj8p It looks like the test assumes that division by zero is detected, and it's not. Gennadiy, Doug, do you have any ideas what's going on? Thanks, Volodya

1 1

Function Types Accepted - November 28, 2006
by Tom Brinkman 28 Nov '06

28 Nov '06

Function Types Review Managers Summary Tom Brinkman Accepted The library has matured much between reviews. It is my conclusion that the documentation, the examples, the test suite, and the library's interface all meet the requirements to be accepted as Boost library. My own experience with the library was good. I compiled all the examples, read the documentation and have become familiar with the design. However, I did have some compiling issues with two out of three of my linux machines. I fear that this library may face some compatiblity issues with some of the lessor supported platforms The reason for the relatively low review count is that this library is for library "authors" and not for "end users". The low review count is not a concern and does not reflect on the quality of this library, While these are not issues required for acceptance, I do think that this library should eventually be merged with the "type traits" library. I'll leave that up to Tobias and others to make the final determination of how to make that happen, or if it is even practical. Clearly, there does appear to be some redundancy between the "type traits" library and the "function types" library ("tags"). I would encourage Tobias to get in contact with maintainers of those libraries and flush that issue out. It is my opinion that the "Function Types" library has met or exceeded all of the conditions set by the "Full-Review" conducted by John Maddock last year and should be accepted into boost. Congratulations and thanks to Tobias for his "Function Types" library; I'm looking forward to seeing it in a future version of boost. ----Download---- http://tinyurl.com/qaf5f ----Author---- Tobias Schwinger ----Review Dates---- June 2005 - Full Review November 2006 - Mini Review ----Review Manager(s)---- John Maddock (Full Review) Tom Brinkman (Mini Review) ----Full Review ---- 2005-Jun-6 to 2005-June-16 Accepted int Boost, subject to a mini-review. ----Mini-Review---- 2006 November 6 - 2006 November 17 Accepted into Boost

1 0

[math] [cw-9.4] common_factor_test
by Vladimir Prus 28 Nov '06

28 Nov '06

The failure at: http://tinyurl.com/y27tlc looks like problem with the test itself. Anybody's in position to fix it? I think the same operator<< was causing problems for other compilers and John has a patch, but I have no idea if this patch will apply to cw-9.4. If we exclude stale (Nov 22) test failures that are fixed since, those borland, 6.5, 7.0 and cw-9.4 are four remaining failures of the math library, it would be great to see them go away. Thanks, Volodya

2 1

BOOST_ALL_NO_LIB
by Vladimir Prus 28 Nov '06

28 Nov '06

Pardon my nit-picking, but I fail to see the relation between BOOST_ALL_NO_LIB spelling and autolinking -- which is exactly what this macro controls. Perhaps this macro has some extra semantics, but I can't find any, except for auto-linking, in separate_compilation.html, nor in library's config.hpp files. Wouldn't it be better if the macro was named BOOST_ALL_NO_AUTOLINK? Thanks, Volodya

2 1