December 2001 - Boost-users

Building nested FSM with BGL...
by Herman Bruyninckx 30 Dec '01

30 Dec '01

Has anyone already implemented a nested Finite State Machine with the Boost Graph Library? (Or a Petri net for that matter.) The thing that really puzzles me is how to implement the nesting, i.e., all nodes in a subset of the graph react to the same ``events'' from the ``outside world'', but I want to avoid making all the edges from the ``outside world'' nodes to the subset nodes... Herman

1 0

Re: new component, extent_set<>
by Nathan Myers 29 Dec '01

29 Dec '01

"David A. Greene" wrote: > Nathan Myers wrote: > > boost::extent_set<> implements a set of half-open ranges on a scalar > > type, with automatic splitting and merging, appropriate for managing > > ranges of disk blocks or video frames. In use it looks like: > > Cool! Why "extent_set" though? What about range_set or interval_set? "Extent" is the standard term of art when speaking of ranges of disk blocks, particularly as part of a file system. Also, since it's not really a set of ranges, range_set seemed inappropriate. > Any way this could be adapted to allow non-scalar ranges? What are > the requirements on the range element type? I would think anything > less-than-comparable should be useable but I didn't implement the > class. :) The current version uses closed ranges, BTW. The requirements are minimal: as listed in the header file, the Bound argument must be copyable, assignable, equality-comparable, comparable using the Compare argument, and incrementable and decrementable using the Succ and Pred arguments. It imposes no other requirements, so a non-scalar could work. Unfortunately I don't know how to define a useful decrement operator for a string, or a Compare operator for a complex number. Did you have some particular non-scalar in mind? The original version didn't need the increment and decrement operations, internally, but the client was still obliged to apply the equivalent of an increment operation. That made it slippery to use on strings. You could define increment to mean "append a space", so that a dictionary page might occupy the range "lost" to "love " (note the space). That assumes a lot about the character encoding, which the client (but not extent_set<>) is allowed to do. Unfortunately there is no simple equivalent for decrementing, so the trick doesn't work with closed ranges. It is conceivable that I might be able to continue storing half-open ranges internally, and thus avoid needing a decrement operation. It seems a bit fragile though. > Is there a way to control when ranges are combined (maybe sometimes > I want [10, 20) and [20, 30) to stay separate)? A policy for this > would be nice. It doesn't provide that in the current version. In fact, the presence of such a pair of extents would violate an invariant, breaking the insert and erase members as written. (They could probably be changed to accommodate it, at some cost in complexity.) How would you use such a feature? Nathan Myers ncm at cantrip dot org

1 0

Presentation Boost at Fosdem
by Toon Knapen 27 Dec '01

27 Dec '01

Dear Boost Developers, Currently, a presentation of Boost is scheduled at FOSDEM (www.fosdem.org) Fosdem is an anual free and open-source developer meeting in Brussels, Belgium that is gaining a lot of momentum, with an audience from all over europe and many international speakers of highly visible open-source projects. As has been discussed on the list before, Boost is well known to the standard commitee but need also be more visible to a wider public. That's also why I proposed to the Fosdem organiser (Raphael Bauduin) to schedule a Boost presentation. Boost developers and users that are planning to attend, contribute, ... please let me know. Toon

1 0

new component, extent_set<>
by Nathan Myers 26 Dec '01

26 Dec '01

I have uploaded to the Boost files section couple of archives containing an implementation of a class template extent_set; look in the folder "extent_set". The zip and tgz archives there are identical. Included in each is a header file and a test suite. boost::extent_set<> implements a set of half-open ranges on a scalar type, with automatic splitting and merging, appropriate for managing ranges of disk blocks or video frames. In use it looks like: boost::extent_set<int> set; set.insert(10, 20); // now contains [10,20) set.insert(30, 50); // now contains [10,20) [30,50) set.erase(40, 45); // now contains [10,20) [30,40) [45,50) set.insert(20, 30); // now contains [10,40) [45,50) std::cout << "(" << set.begin()->first << "," << set.begin()->second << ")" << std::endl; // writes "(10,40)" It is implemented using std::map. This is the initial submission. Please 'ave a look. (I am only subscribed to the -users list, so far.) Nathan Myers ncm at cantrip dot org

2 1

linker error with regex
by John Maddock 22 Dec '01

22 Dec '01

>By looking at the verbose progress messages from the linker, it >appears that the following libs (stl-port and regex only - others not >shown) are being linked against: > >Processed /DEFAULTLIB:vc6-stlport-re300m.lib >Processed /DEFAULTLIB:stlport_vc6_static.lib Those are the correct libs to link against for those options. >I am stumped as to why the linker fails from inside the IDE but works >when used from the command line! So am I, it works for me, but you are not alone in having problems with this. - John Maddock http://ourworld.compuserve.com/homepages/john_maddock/

1 0

lexiacal_cast and hex values
by rogeeff 21 Dec '01

21 Dec '01

Hi, can I you lexical_cast to convert string "0x16" to 22? Thanx, Gennadiy.

2 2

linker error with regex
by kchellap 20 Dec '01

20 Dec '01

Hi, Newbie question. I am using one of the latest versions of boost (not sure which version, but I downloaded it in Sept'00) and am using it with stlport ver 4.5. I've been successful in using the shared_ptr, shared_array, etc type of libraries with MSVC++ 6.0 (sp5) on a Win2K machine (sp2). However, recently I've been trying to get the regex library to work but seem to be getting linker errors. As indicated in the documentation, I set the env. using vcvars32, and used nmake to compile and install the regex libraries (both .lib and .dll files). As a sample I tried compiling snip1.cpp (in boost_libs\regex\demo\snippets) from the command line: D:\demo>cl /MT /D_MT -o snip1.exe -O2 -GX -GR snip1.cpp -link user 32.lib Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. snip1.cpp Microsoft (R) Incremental Linker Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /out:snip1.exe user32.lib snip1.obj and the compile succeeded. However, when I set up the same options in the MSVC++ IDE, I get the following linker errors: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. cl /MT /GR /GX /O2 /D "_MT" /Fo"Debug/" "D:\users\kumar\boost_libs\regex\demo\snippetsmsvc\snip1.cpp" snip1.cpp Microsoft (R) Incremental Linker Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /out:snip1.exe Debug/snip1.obj snip1.obj : error LNK2001: unresolved external symbol "public: static class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > __cdecl boost::re_detail::w32_traits_base::error_string(unsigned int)" (? error_string@w3 2_traits_base@re_detail@boost@@SA?AV?$basic_string@DV? $char_traits@D@_STL@@V?$allocator@D@2@@_STL@@I@Z) snip1.obj : error LNK2001: unresolved external symbol "public: static void __fastcall boost::w32_regex_traits<char>::transform_primary (class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &,class _STL::basic_stri ng<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &)" (?transform_primary@?$w32_regex_traits@D@boost@@SIXAAV? $basic_string@DV?$char_traits@D@_STL@@V? $allocator@D@2@@_STL@@ABV34@@Z) snip1.obj : error LNK2001: unresolved external symbol "protected: static bool __fastcall boost::re_detail::w32_traits_base::do_lookup_collate(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &,char const *)" (?do_lookup_collate@w32_traits_base@re_detail@boost@@KI_NAAV? $basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@PBD@Z) snip1.obj : error LNK2001: unresolved external symbol "public: static void __fastcall boost::w32_regex_traits<char>::transform(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &,class _STL::basic_string<char, class _STL::char_traits<char>,class _STL::allocator<char> > const &)" (?transform@?$w32_regex_traits@D@boost@@SIXAAV?$basic_string@DV? $char_traits@D@_STL@@V?$allocator@D@2@@_STL@@ABV34@@Z) vc6-stlport-re300m.lib(w32_regex_traits.obj) : error LNK2001: unresolved external symbol __imp__LoadStringA@16 vc6-stlport-re300m.lib(w32_regex_traits.obj) : error LNK2001: unresolved external symbol __imp__CharLowerW@4 snip1.exe : fatal error LNK1120: 6 unresolved externals Error executing cl.exe. By looking at the verbose progress messages from the linker, it appears that the following libs (stl-port and regex only - others not shown) are being linked against: Processed /DEFAULTLIB:vc6-stlport-re300m.lib Processed /DEFAULTLIB:stlport_vc6_static.lib I am stumped as to why the linker fails from inside the IDE but works when used from the command line! If anybody has an idea as to what is going on here or has a way to fix it, I'd really appreciate any help. Thanks, Kumar Chellapilla kumar(a)natural-selection.com

1 0

Using PREPROCESSOR to generate macros
by Gustavo Guerra 18 Dec '01

18 Dec '01

I use the following macros in my code: #define MAKE_FLAG_TYPE1(TYPE_NAME, F1) \ enum TYPE_NAME { F1 }; \ \ ::std::ostream& operator<<(::std::ostream& os, TYPE_NAME f) \ \ switch(f) \ { \ case F1: return os << #F1; \ } \ return os << "unknown"; \ } [2, 3 and 4 argument versions] #define MAKE_FLAG_TYPE5(TYPE_NAME, F1, F2, F3, F4, F5) \ enum TYPE_NAME { F1, F2, F3, F4, F5 }; \ \ ::std::ostream& operator<<(::std::ostream& os, TYPE_NAME f) \ { \ switch(f) \ { \ case F1: return os << #F1; \ case F2: return os << #F2; \ case F3: return os << #F3; \ case F4: return os << #F4; \ case F5: return os << #F5; \ } \ return os << "unknown"; \ } I wanted to try and do it with the Preprocessor library. It should be something like this: #include <boost/preprocessor/comma_if.hpp> #include <boost/preprocessor/repeat.hpp> #include <boost/preprocessor/repeat_2nd.hpp> #include <boost/preprocessor/inc.hpp> #include <boost/preprocessor/cat.hpp> #include <boost/preprocessor/enum_params.hpp> #ifndef MAX_MAKE_FLAG_TYPE_PARAMS #define MAX_MAKE_FLAG_TYPE_PARAMS 10 #endif BOOST_PREPROCESSOR_REPEAT(MAX_MAKE_FLAG_TYPE, MAKE_FLAG_TYPE_AUX, _) #define MAKE_FLAG_TYPE_AUX(N,_) \ #define MAKE_FLAG_TYPE##N(TYPE_NAME,BOOST_PREPROCESSOR_ENUM_PARAMS(N, F)) \ enum TYPE_NAME { BOOST_PREPROCESSOR_ENUM_PARAMS(N, F) }; \ ::std::ostream& operator<<(::std::ostream& os, TYPE_NAME f) \ { \ switch(f) \ { \ BOOST_PREPROCESSOR_REPEAT_2ND(N, MAKE_FLAG_TYPE_AUX2, _) \ } \ return os << "unknown"; \ } #define MAKE_FLAG_TYPE_AUX2(N,_) \ case F##N: return os << BOOST_PREPROCESSOR_CAT(#, F##N); #undef MAKE_FLAG_TYPE_AUX #undef MAKE_FLAG_TYPE_AUX2 But then I looked at my code and clearly saw this won't do it. One of the problems is that by preprocessing I'll get things like: #define MAKE_FLAG_TYPE2(TYPE_NAME, F1, F2) enum [...] That won't work because of the spaces between the commas. And also I doubt BOOST_PREPROCESSOR_CAT(#, F##N) will work So, does anyone has any suggestions on how to implement my MAKE_FLAG_TYPE<N> macros using the Preprocessor library? Or is it just not possible? Thanks Gustavo Guerra

3 3

Compile error with boost::tokenizer and Forte 6U2
by JULES D'ENTREMONT 18 Dec '01

18 Dec '01

Hi, I'm trying to use boost::tokenizer to tokenize colon-separated strings of the form "path1:path2:path3...". I wrote the following simple test program: #include <string> #include "boost/tokenizer.hpp" void func() { std::string s("abc:def:ghi"); boost::char_delimiters_separator<char> tokenizerFunc(false, "", ":"); boost::tokenizer<boost::char_delimiters_separator<char> > tokenizer(s, tokenizerFunc); } However, this fails to compile with the Sun Forte 6U2 compiler. It spews out the following error messages: "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/detail/ob_compressed_pair.hpp", line 416: Warning (Anachronism): Type names qualified by template parameters require "typename". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/detail/ob_compressed_pair.hpp", line 416: Warning (Anachronism): Type names qualified by template parameters require "typename". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/detail/iterator.hpp", line 382: Warning (Anachronism): Type names qualified by template parameters require "typename". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/detail/iterator.hpp", line 382: Warning (Anachronism): Type names qualified by template parameters require "typename". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 922: Error: Invalid template parameter default. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 925: Error: Invalid template parameter default. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 1116: Warning (Anachronism): Type names qualified by template parameters require "typename". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 1133: Error: value is not a member of boost::is_convertible<boost::detail::reduce_to_base_class<std::forward_iterator_tag, boost::detail::iterator_traits<boost::detail::Iterator>::iterator_category>::type*, std::bidirectional_iterator_tag*>. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: While specializing "boost::detail::non_bidirectional_category<const char*>". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: Specialized in boost::token_iterator_generator<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/tokenizer.hpp", line 37: Where: Specialized in boost::tokenizer<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "boostTest.cc", line 10: Where: Specialized in non-template code. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 1133: Error: An integer constant expression is required here. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: While specializing "boost::detail::non_bidirectional_category<const char*>". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: Specialized in boost::token_iterator_generator<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/tokenizer.hpp", line 37: Where: Specialized in boost::tokenizer<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "boostTest.cc", line 10: Where: Specialized in non-template code. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/iterator_adaptors.hpp", line 1134: Error: The type "boost::STATIC_ASSERTION_FAILURE<0>" is incomplete. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: While specializing "boost::detail::non_bidirectional_category<const char*>". "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/token_iterator.hpp", line 90: Where: Specialized in boost::token_iterator_generator<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "/nsm/rollsbuild/thirdparty/boost/boost_1_25_0/boost/tokenizer.hpp", line 37: Where: Specialized in boost::tokenizer<boost::char_delimiters_separator<char, std::char_traits<char>>, const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>. "boostTest.cc", line 10: Where: Specialized in non-template code. 5 Error(s) and 7 Warning(s) detected. *** Error code 5 Am I using the class incorrectly, or is this a genuine problem? Jules d'Entremont -- Jules d'Entremont jules.dentremont(a)alcatel.com Alcatel Canada http://batai.ca.newbridge.com/~julesd 600 March Road 613-784-6633 Kanata ON, K2K 2E6

3 4

Re: [Boost-Users] Re: Compile error with boost::tokenizer and Forte 6U2
by George Heintzelman 18 Dec '01

18 Dec '01

(moved to boost developers list) [snip most of the changes for SunPro CC] > Also ifdef BOOST_STATIC_ASSERTs on is_input_or_output_iter and > forward_iter_with_real_reference (~lines 616-630). Whoa Nelly. I also found most of the changes you suggested, but I looked into these assert failures compiling on SunPro 5.3 -- and I found that they really were indicating that the compiler was doing something wrong with the typedefs inside the constructed iterator. Ignoring the problem by #ifdefing these out I think may cause problems with the iterator adaptors in some contexts, though I think they will probably work correctly for simple dereferencing and incrementing. To fix (at least partly) these, I found I needed to turn on some of the hacks for BORLANDC in the detail/named_template_params header, specifically the ones to use type_traits::yes_type instead of a bool specialization. I also needed to turn on BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS for the static_assert header; I suspect the BORLANDC #ifdefs I had to turn on are related to this same problem, and they ought to be unified in the config header. Once that was done, the compiler still got itself quite confused by the line in detail/named_template_params.hpp: typedef typename choose_arg_or_default<typename is_default<Arg> ::type>::type Selector; Splitting this up into typedef typename is_default<Arg>::type is_default; typedef typename choose_arg_or_default<is_default>::type Selector; seemed to keep the compiler from getting itself all screwed up. This got me part of the way there, but one of those two Static_asserts was still firing, and it seemed to me correctly so (that is, correctly in that the compiler was behaving incorrectly elsewhere). I came to the conclusion that it was still the same buggy integral constant specialization problem -- if I were to rewrite some of the selector code to use yes_type instead of a bool specialization, I believe I could get it to work, but given that that would have meant some wholesale changes to type_traits, I stopped there. George Heintzelman georgeh(a)aya.yale.edu

1 0