- Boost - lists.boost.org

Printing documents from boost?
by Neal D. Becker 05 Feb '04

05 Feb '04

I know this is a little OT, but I'm viewing the lovely new boost iterator docs (using konq), and I'm wondering how I can get a printed version which would include all the pages that make up the whole iterator documentation? I seem to recall long ago a tool called html2ps or something like that would do it, but I can't seem to find anything.

3 2

1.31.0 date_time and VC7.1
by Victor A. Wagner, Jr. 05 Feb '04

05 Feb '04

I'm still getting undefined symbols attempting to use date_time library with Visual Studio.NET 2003 Since the program is so short to demonstrate the problem, I include it here: ================================================================== #include <iostream > #include <string> #include "boost/date_time/posix_time/posix_time.hpp" int main() { boost::posix_time::ptime now = boost::posix_time::second_clock::universal_time(); boost::posix_time::ptime cnow(boost::posix_time::second_clock::universal_time()); std::string xx = to_iso_string(now); std::cout << to_iso_string(boost::posix_time::second_clock::universal_time()) << std::endl; std::cout << now << std::endl; std::cout << xx << std::endl; std::cout << to_iso_string(cnow) << std::endl; return 0; } ================================================================== produces the following output: ------ Build started: Project: OneLineDateTime, Configuration: Debug Win32 ------ Linking... OneLineDateTime.obj : error LNK2019: unresolved external symbol "public: char const * __thiscall boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in function "public: static class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_format>::format_month(class boost::gregorian::greg_month const &,class std::basic_ostream<char,struct std::char_traits<char> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@Viso_format@date_time@3@@date_time@boost@@SAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABVgreg_month@gregorian@3@AAV45@@Z) OneLineDateTime.obj : error LNK2019: unresolved external symbol "public: char const * __thiscall boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in function "public: static class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_format>::format_month(class boost::gregorian::greg_month const &,class std::basic_ostream<char,struct std::char_traits<char> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@Viso_format@date_time@3@@date_time@boost@@SAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABVgreg_month@gregorian@3@AAV45@@Z) Debug/OneLineDateTime.exe : fatal error LNK1120: 2 unresolved externals Build log was saved at "file://c:\Projects\Programming\SeriousTesting\OneLineDateTime\Debug\BuildLog.htm" OneLineDateTime - 3 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

8 19

Missing include for boost::format
by Guillaume Melquiond 04 Feb '04

04 Feb '04

Hi, The Format headers in the main CVS are missing some #include for I/O streams. For example, if you try to compile this snippet: #include <boost/format.hpp> #include <string> int main() { std::string a = (boost::format("%1%") % 0).str(); } GCC will complain that error: base class `std::basic_ostream<char, std::char_traits<char> >' has incomplete type Regards, Guillaume

3 2

[serialization] void_cast patch
by Robert Ramey 04 Feb '04

04 Feb '04

This has been corrected in the next version. Robert Ramey > I believe that the attached patch should be applied to void_cast.cpp. > According to std::3.2/3 > > "An inline function shall be defined in every translation unit in > which it > is used" > > which means putting inline function is .cpp file is not okay. The problem > I > had is then with optimization on, those function were stipped, leading to > link errors. > > - Volodya

1 0

Relational Template Library: transactions, etc.
by Arkadiy Vertleyb 04 Feb '04

04 Feb '04

Dear Boosters, A while ago we introduced RTL the Relational Template Library a lightweight facility to create relational tables and perform relational operations on them. The main concept RTL operates with is a relation, which has two types of models: tables and operators. Tables can store, in a type safe manner, fields of any types that satisfy requirements imposed by a typical STL container. Operators store references to their arguments, and produce data on the fly. Both provide iterators that can be used in STL algorithms. Any relation (operator or table) can serve as an argument to yet another operator, thus forming an arbitrary complicated expression tree. A relation has a sort order, which is calculated at compile time based on the sort order of its arguments. Range queries are available, based on this sort order. RTL allows to index any relation, which again can be either a table or a relational operator. In this sense our indexing models the ORDERED BY feature, provided by SQL. Therefore a relational expression can contain any number of indexes, used to re-sort tuples to better suite a particular query or queries. The March issue of C/C++ users journal will contain our article about RTL, where we described the library in more depth. This article reflects the state of the library as of about a year ago. NEW FEATURES ============ This time we are offering a significantly enhanced version of the library. The main addition is the TRANSACTION facility, that allows for synchronized updates to one or more tables. The additional very powerful (in our opinion) benefit is the possibility of incremental index update. When a table is changed, all the indexes that depend on this table get invalidated, and need to be updated. RTL takes care of this by calculating deltas on each index, and applying only necessary changes incrementally. We also modified the library interface to use MPL sequences instead of our proprietary type list implementation, and replaced all our meta-programming code to also make use of MPL. RTL allows the user to choose between available table implementations, as well as define new ones. The current in-stock implementation is based on std::vector, and therefore is most appropriate when the updates dont happen too often. We also experimented with indexed_set library to define a set-based implementation. Since the indexed_set is not a part of boost yet, we do not currently supply this implementation. However we do have it, and if anybody has immediate interest, please let us know well make it available (you will have to download the indexed_set library). We struggled to support VC6 up to the last moment, when some of our tests failed to build with Boost release candidate 2. The problems are with quantitative limitations we are getting ISO, and have to brake down our tests in smaller units. Since Microsoft no longer supports this compiler, we also decided to stop supporting it (we may re-consider if there are significant objections). The library has been tested with VC7.1 and GCC 3.3. Here is the link: http://f2.grp.yahoofs.com/v1/ABchQJF130FfDvd2GnsXCEIYu6UWzEecAPEgRIXr6rS50A… As always, we are looking forward to any feedback. Arkadiy vertleyb(a)hotmail.com Dmitriy dmitriy_arapov(a)hotmail.com _________________________________________________________________ Scope out the new MSN Plus Internet Software optimizes dial-up to the max! http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1

1 0

BUG: dynamic_bitset - shift assignment operator
by Lester Gong 04 Feb '04

04 Feb '04

There is a bug in dynamic_bitset operator<<=(). Calling operator<<=() followed by operator>>=() may shift in non-zero bits from the left. For example, this sequence of statements ... dynamic_bitset<> b(std::string("0110"); b <<= 1; // gives "1100" b <<= 1; // gives "1000" b <<= 1; // gives "0000" b >>= 1; // gives "1000" !! b >>= 1; // gives "1100" !! b >>= 1; // gives "0110" Seems that some stray bits are not cleared when shifted beyond the lhs of the bitfield. Attached files: test_dynamic_bitset.cc Simple program that illustrates bug test_dynamic_bitset.out Output from simple test program dynamic_bitset.hpp.patch Patch that seems to fix the bug bitset_test.hpp.patch dyn_bitset_unit_tests2.cpp.patch Proposed changes to test programs that would catch this problem. -Lester #include <boost/dynamic_bitset.hpp> #include <iostream> #include <string> using boost::dynamic_bitset; using std::cout; using std::endl; int main(int argv, char** argc) { dynamic_bitset<> b(std::string("0110")); cout << "Original dynamic_bitset object:" << endl; cout << b << endl << endl; cout << "Shift left assignment (3 times):" << endl; b <<= 1; cout << b << endl; b <<= 1; cout << b << endl; b <<= 1; cout << b << endl << endl; cout << "Shift right assignment (3 times):" << endl; b >>= 1; cout << b << endl; b >>= 1; cout << b << endl; b >>= 1; cout << b << endl; return 0; } Original dynamic_bitset object: 0110 Shift left assignment (3 times): 1100 1000 0000 Shift right assignment (3 times): 1000 1100 0110 *** dynamic_bitset.hpp.orig Mon Feb 2 12:48:52 2004 --- dynamic_bitset.hpp Mon Feb 2 15:25:52 2004 *************** *** 670,676 **** // div blocks are zero filled at the less significant end std::fill(this->m_bits, this->m_bits+div, static_cast<block_type>(0)); ! } --- 670,676 ---- // div blocks are zero filled at the less significant end std::fill(this->m_bits, this->m_bits+div, static_cast<block_type>(0)); ! m_zero_unused_bits(); } *** bitset_test.hpp.orig Mon Feb 2 13:10:26 2004 --- bitset_test.hpp Mon Feb 2 15:21:34 2004 *************** *** 365,370 **** --- 365,400 ---- BOOST_CHECK(lhs[I] == prev[I + pos]); } + static void shift_left_assignment_followed_by_shift_right_assignment(const Bitset& b, std::size_t pos) + { + Bitset lhs(b); + Bitset prev(lhs); + lhs <<= pos; + lhs >>= pos; + // Check that zeros replace bits shifted off the end of the bitset. + std::size_t N = lhs.size(); + for (std::size_t I = 0; I < N; ++I) + if (I < (N - pos)) + BOOST_CHECK(lhs[I] == prev[I]); + else + BOOST_CHECK(lhs[I] == 0); + } + + static void shift_right_assignment_followed_by_shift_left_assignment(const Bitset& b, std::size_t pos) + { + Bitset lhs(b); + Bitset prev(lhs); + lhs >>= pos; + lhs <<= pos; + // Check that zeros replace bits shifted off the end of the bitset. + std::size_t N = lhs.size(); + for (std::size_t I = 0; I < N; ++I) + if (I >= pos) + BOOST_CHECK(lhs[I] == prev[I]); + else + BOOST_CHECK(lhs[I] == 0); + } + static void set_all(const Bitset& b) { *** dyn_bitset_unit_tests2.cpp.orig Mon Feb 2 13:10:44 2004 --- dyn_bitset_unit_tests2.cpp Mon Feb 2 15:28:26 2004 *************** *** 130,135 **** --- 130,199 ---- Tests::shift_right_assignment(b, pos); } //===================================================================== + // Test operator<<= followed by operator>>= + { // case pos == 0 + std::size_t pos = 0; + boost::dynamic_bitset<Block> b(std::string("1010")); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == 1 + std::size_t pos = 1; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == <half of Block> + std::size_t pos = (sizeof(Block) * CHAR_BIT) / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == <full Block> + std::size_t pos = sizeof(Block) * CHAR_BIT; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos == size()/2 + std::size_t pos = long_string.size() / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + { // case pos >= n + std::size_t pos = long_string.size(); + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_left_assignment_followed_by_shift_right_assignment(b, pos); + } + //===================================================================== + // Test operator>>= followed by operator<<= + { // case pos == 0 + std::size_t pos = 0; + boost::dynamic_bitset<Block> b(std::string("1010")); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == 1 + std::size_t pos = 1; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == <half of Block> + std::size_t pos = (sizeof(Block) * CHAR_BIT) / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == <full Block> + std::size_t pos = sizeof(Block) * CHAR_BIT; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos == size()/2 + std::size_t pos = long_string.size() / 2; + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + { // case pos >= n + std::size_t pos = long_string.size(); + boost::dynamic_bitset<Block> b(long_string); + Tests::shift_right_assignment_followed_by_shift_left_assignment(b, pos); + } + //===================================================================== // test b.set() { boost::dynamic_bitset<Block> b;

2 1

Re: 1.31.0 release candidate 3
by Stephan T. Lavavej 04 Feb '04

04 Feb '04

I have tested 1.31.0 RC3 by using it to compile the test suite for my personal library libnuwen. The compile was clean without errors or warnings, including shadow warnings. So everything looks fine from my perspective, although I don't come close to using all of Boost. Stephan T. Lavavej http://nuwen.net

4 3

OK to correct typo's in RC.1.31.0 branch docs?
by John Maddock 04 Feb '04

04 Feb '04

Beman and all, Neal Becker has spotted a couple of nasty errors in the regex docs (wrong namespace in one place, wrong type in another), is it OK to commit the corrected docs (4 files) at this late stage to the release, I would rather commit than not, otherwise the end user could possibly be mislead. Thanks, John.

2 2

Re: 4 more associative containers.
by Rich Sposato 04 Feb '04

04 Feb '04

Joaquín M López Muñoz wrote: > De: "David B. Held" > > "Jeremy Maitin-Shepard" <jbms(a)attbi.com> wrote in message > > news:87u128yr3g.fsf@jbms.ath.cx... > > > I believe that a library named ``indexed_set,'' which has been > > > proposed and is pending formal review, provides this functionality > > > in addition to supporting multiple indices. > > Are you sure it does the same thing? I was under the impression > > that Joaquin's library lets you define *additional* indexes, but what > > if you just want to use an existing index, but it is comparable to > > something other than the key_type? > indexed_set does provide this functionality > (multiple indices aside.) See > http://tinyurl.com/2vu5g, section "Special lookup operations". > See also > http://tinyurl.com/3dyzh, section "Index set operations" > for a formal definition of the kind of special lookup > operations provided. And so indexed_set does provide the ability to lookup by a type other than the key_type. Which means that if we compared the various set containers in terms of abilities, flex_set is a special case of indexed_set where the number of indexes == 1. >From what I just read about indexed_set, it seems that the best benefit to using flex_set instead of indexed_set is that flex_set is simpler and smaller. We can sort set container classes by abilities to get this: std::set < flex_set < indexed_set. We can also sort multiset containers by ability and get this: std::multiset < flex_multiset < indexed_set. Rich Sposato

2 1

Re: [boost] Getting rid of some warnings on gcc?
by Reece Dunn 04 Feb '04

04 Feb '04

Beman Dawes wrote: >At 10:50 AM 2/3/2004, Marshall Clow wrote: > > >I've noticed that a bunch of the gcc tests (Mac OS, Linux, Windows) > >have many, many warnings, and they're all the same: > >... > >So I tried adding "typename" in two spots. In the MacOS testing, it > >changed 30+ tests from "Warn" to "Pass". Here's the change: > > > >diff -r1.23 token_functions.hpp > >304c304 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >396c396 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >VC++ 6.0 fails with the added "typename", so it has to be placed in #if ... >#endif. But, yes, the change does clear a lot of gcc warnings. The change >seems so innocuous I went ahead and committed it to the CVS HEAD. Doesn't BOOST_DEDUCED_TYPENAME fix the compatibility with VC++ 6? Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1