March 2004 - Boost - lists.boost.org

patch for STLport debug libs without stldebug-mode
by Ulrich Eckhardt 22 Mar '04

22 Mar '04

Hi! I discovered to my dismay that the boost_thread lib that uses STLport uses STLport's special debug mode. I therefore prepared a patch (against 1.31.0) that renames the current 'debug' target to 'stldebug' and adds a new 'debug' target that only uses the normal debug version of STLport. There are a few issues to discuss though: - I'm no expert of the build-system, not even an adept. I just tried to understand what's going on and tried until it seemed to work. It is a little tested on MSVC6. - I have no idea why the special debug-mode was introduced as default in the first place, I haven't found anything that tells why. - I found a note in one of the bbuild v2 files (which I did neither use nor patch) saying that 'normal debug' is not supported. Again, why and why isn't that stated in the notes for the *-stlport toolsets? - regex(IIRC) uses a 'd' in the resulting lib to mark debug libs and 'dd' to mark libs with special debug modes like STLport's. I adapted this naming convention when making the patch. In case anyone wonders, I work in an environment where I just don't have the extra time for STLport's debug mode. any comments welcome Ulrich Eckhardt

2 2

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 22 Mar '04

22 Mar '04

Hello Brian, thank you for reviewing indexed_set! ----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Marzo 21, 2004 1:00 am Asunto: Re: [boost] Formal Review: Indexed Set > > I read the "tutorial" and only glanced at the other sections. The > documentation is quite good. A few quick comments: > > Some of the code examples in the tutorial have lines longer than 80 > chars and they don't render well in my browser. Breaking the long > lines into multiple lines will easily fix this. > > At one point in the tutorial it says "nth_indexed_type" instead of > "nth_index_type". The same (extra "ed") bug is repeated again > shortly after the first one. Thank you, I'll fix these. > > I had to manually > #include "boost/indexed_set/sequenced_index.hpp" > in addition to > #include "boost/indexed_set.hpp" > in order to get "sequenced" to work. Not sure if this is a bug in > the docs or a bug in the library itself; either it should be included > automatically, or else the docs should mention including it manually. Well, this is not actually a bug, buy an issue I would like people to give their opinion about, along with other naming and organizatinal issues. If you feel in the mood, please take a look at the review notes at http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html Pavel has started an independent thread to treat these points. > > The docs mention > #define BOOST_INDEXED_SET_ENABLE_INVARIANT_CHECKING > for both "safe mode" and "invariant checking mode". I did not look > into this enough to decide if there is (or is supposed to be) a > different separate flag to set for "safe mode". > It's a bug in the docs. There exists a separate BOOST_INDEXED_SET_ENABLE_SAFE_MODE macro. Thank you for spotting this out. [...] > At one point, when using tags, I did something like > > struct by_seq {}; > ... sequenced<by_seq> ... // oops, should be > sequenced<tag<by_seq> > > > and got a compiler error. (BTW, the docs are not totally clear here; > they should say that you need tag<...>.) [...] Well, the requirement is stated at the referece, though it won't hurt to say it more explicitly in the tutorial. I'll try to improve this. > I noted with some dismay that duplicate tags are not detected. That > is, you are allowed to say > > struct by_id {}; > struct by_name {}; > struct by_foo {}; > typedef indexed_set< > employee, > index_list< > unique<tag<by_id,by_foo>,identity<employee> >, > > non_unique<tag<by_name,by_foo>, > member<employee,std::string,&employee::name> > > > > > employee_set; > > where I have named both indices "by_foo". I would prefer it if the > library detected this as a BOOST_STATIC_ASSERT-able error. > Currently, the approach is that the first index with a given tag is picked (the reference states this explicitly). I'm not convinced the approach you suggest is more convenient: maybe eliminating such duplicate tags in a metaprogramming environmnt (imagine the indexed_set is instantiated by an automatic framework) is not that simple. A static *warning* would be ideal here :) > > > Do you think the library should be accepted as a Boost library? > Be > sure to say this explicitly so that your other comments don't > obscure your overall opinion. > > Yes. great ;) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[config] Patch for Intel 8.0 + Dinkum lib
by Gennaro Prota 22 Mar '04

22 Mar '04

Intel C++ for Windows never stops surprising me with its Microsoft bugtibility conundrums. When you use /Qms0 (version 8.0) it defines _MSC_VER to be 1200, as if it emulated VC++6! This tricks up the code in config/stdlib/dinkumware.hpp to define # define BOOST_NO_STD_USE_FACET # define BOOST_HAS_TWO_ARG_USE_FACET However the two-arg version of use_facet is deprecated and marked as such with __declspec(deprecated). Attached is an obvious patch to fix the problem. -- Genny. begin 644 dinkumpatch.txt M*BHJ(&1I;FMU;7=A<F4N:'!P+F]R:6<)5'5E($9E8B`@,R`Q,SHT,3HT-2`R M,#`T"BTM+2!D:6YK=6UW87)E+FAP<`E&<FD(a)36%R(#$R(#$X.C(W.C,T(#(P M,#0**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`R.2PS-B`J*BHJ"B`@(R`@("`@9&5F M:6YE($)/3U-47TY/7U-41%]!3$Q/0T%43U(-"B`@(R`@96YD:68-"B`@(R`@ M9&5F:6YE($)/3U-47TA!4U]005)424%,7U-41%]!3$Q/0T%43U(-"B$@(R`@ M:68@*&1E9FEN960H7TU30U]615(I("8F("A?35-#7U9%4B`\(#$S,#`I*2`F M)B`A9&5F:6YE9"A?7T)/4DQ!3D1#7U\I#0H@("`@("`@("\O(&EF('1H:7,@ M;&EB('9E<G-I;VX@:7,@<V5T('5P(&9O<B!V8S8@=&AE;B!T:&5R92!I<R!N M;R!S=&0Z.G5S95]F86-E=#H-"B`@(R`@("`@9&5F:6YE($)/3U-47TY/7U-4 M1%]54T5?1D%#150-"B`@(R`@("`@9&5F:6YE($)/3U-47TA!4U]45T]?05)' M7U5315]&04-%5`T*("`@("`@("`O+R!#(&QI8B!F=6YC=&EO;G,@87)E;B=T M(&EN(&YA;65S<&%C92!S=&0@96ET:&5R.@T*+2TM(#(Y+#,W("TM+2T*("`C M("`@("!D969I;F4@0D]/4U1?3D]?4U1$7T%,3$]#051/4@T*("`C("!E;F1I M9@T*("`C("!D969I;F4@0D]/4U1?2$%37U!!4E1)04Q?4U1$7T%,3$]#051/ M4@T*(2`C("!I9B`H9&5F:6YE9"A?35-#7U9%4BD@)B8@*%]-4T-?5D52(#P@ M,3,P,"D@)B8@0D]/4U1?24Y414Q?0UA87U9%4E-)3TX@/"`X,#`I("8F("%D M969I;F5D*%]?0D]23$%.1$-?7RD-"B`@("`@("`@+R\@:68@=&AI<R!L:6(@ M=F5R<VEO;B!I<R!S970@=7`@9F]R('9C-B!T:&5N('1H97)E(&ES(&YO('-T M9#HZ=7-E7V9A8V5T.@T**R`@("`@("`O+R`H8V%U=&EO;CH@26YT96P@."XP M(&9O<B!7:6X@=VET:"`O46US,"!D969I;F5S(%]-4T-?5D52('1O(&)E(#$R M,#`@8G5T(&ET(&ES(&YO="!60S8A*0T*("`C("`@("!D969I;F4@0D]/4U1? M3D]?4U1$7U5315]&04-%5`T*("`C("`@("!D969I;F4@0D]/4U1?2$%37U17 M3U]!4D=?55-%7T9!0T54#0H@("`@("`@("\O($,@;&EB(&9U;F-T:6]N<R!A @<F5N)W0@:6X@;F%M97-P86-E('-T9"!E:71H97(Z#0IB ` end

4 26

recommend logging library?
by Neal D. Becker 22 Mar '04

22 Mar '04

I notice boost doesn't have a logging library. I have seen several floating around. Are there any recommendations?

13 24

[fsm] Finally ...
by Andreas Huber 22 Mar '04

22 Mar '04

... has boost::fsm reached a reasonably stable state. Code, examples and documentation can be found here: http://boost-sandbox.sf.net/fsm.zip The documentation can also be browsed online: http://boost-sandbox.sf.net/libs/fsm Comments, questions, etc. are most welcome. Andreas Huber

1 0

[filesystem] relative_to
by John Torjo 22 Mar '04

22 Mar '04

Dear boosters, I noticed that currently there's no way to get the relative path of path A related to path B. What I mean is, given two **complete** paths, to get the relative path of one related to the other. To give a real example, I have an application that starts in directory initial_path(). I have several dialogs that allow the user to browse for files. My requirement is, after the user browses for a file, to internally ALWAYS store the path relative to initial_path(). Since there's no way to do this currently, I created my own function. Do you think it could be a useful addition to filesystem library? // converts the given path, making it relative to the src path // // precondition: dest & src are both complete path relative_to( const path & dest, const path & src) { // both paths should be complete assert( dest.is_complete() && src.is_complete() ); path::iterator dest_begin = dest.begin(), dest_end = dest.end(); path::iterator src_begin = src.begin(), src_end = src.end(); path result; #if defined(BOOST_WINDOWS) //#if defined(WIN32) if ( dest.root_name() != src.root_name() ) { // paths are on different drives (like, "c:/test/t.txt" and "d:/home") return dest; } if ( src_begin != src_end) ++src_begin; if ( dest_begin != dest_end) ++dest_begin; #endif // ignore directories that are same while ( (src_begin != src_end) && (dest_begin != dest_end)) { if ( *src_begin != *dest_begin) break; ++src_begin, ++dest_begin; } // now, we begin to relativize while ( src_begin != src_end) { result /= ".."; ++src_begin; } while ( dest_begin != dest_end) { result /= *dest_begin; ++dest_begin; } return result; } void test_relative_to( const std::string & dest, const std::string & src) { std::string result = relative_to( dest, src).string(); std::cout << "Testing path '" << dest << "',\n" " relative to '" << src << "'\n" " result : '" << result << "'\n" << std::endl; } int main(int argc, char* argv[]) { path::default_name_check( &native); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test/other"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/temp/test", "c:/temp/test"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "d:/temp/test"); test_relative_to( "c:/temp/test", "d:/temp/test"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/oth/test/other"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/temp"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/other/test"); return 0; } Best, John

2 2

Using Serialization for binary marshalling
by Matthew Vogt 22 Mar '04

22 Mar '04

Is anyone else interested in using Robert Ramey's serialization library for the purpose of marshalling data into pre-determined binary formats? This is not related to serialization in a general sense, but employing the syntax and underlying fundamentals of the library, to a somewhat related purpose. This is a test program demonstrating what I'm doing - I'm interested to know if anyone else is doing anything similar... Matt test.cpp: ------------------------------------------------------------------ #include <sstream> #include <cassert> #include "marshall.hpp" #include "network_oarchive.hpp" #include "network_iarchive.hpp" class test { struct subobject; // Basic fixed-size primitives uint8_t a; uint16_t b; uint32_t c; uint64_t d; // String data that must be serialized to a pre-determined length marshall::fixed_length<std::string, 20> e; marshall::fixed_length<std::wstring, 10> f; // String data that must be serialized with a prepended length // (whose size is itself predetermined) marshall::variable_length<std::string, uint8_t> g; marshall::variable_length<std::wstring, uint8_t> h; // Arbitrary data that must be serialized to a pre-determined length marshall::fixed_length<std::vector<uint16_t>, 5> i; marshall::fixed_length<std::vector<subobject>, 2> j; // Arbitrary data that must be serialized with a prepended length // (whose size is itself predetermined) marshall::variable_length<std::vector<uint16_t>, uint32_t> k; marshall::variable_length<std::vector<char>, uint32_t> l; // A sub-object of arbitrary complexity struct subobject { subobject(void) : a(0), b(0) {} subobject(uint32_t x, uint32_t y) : a(x), b(y) {} bool operator== (const subobject& other) const { return (a == other.a && b == other.b); } private: uint32_t a; uint32_t b; friend class boost::serialization::access; template <class Archive> void serialize(Archive& archive, const unsigned version) { archive & a & b; } }; friend class boost::serialization::access; template <class Archive> void serialize(Archive& archive, const unsigned version) { archive & a & b & c & d & e & f & g & h & i & j & k & l; } public: test(void) : a(0x01), b(0x0203), c(0x04050607), d(0x08090a0b0c0d0e0f), e("abcdefg"), g("xyz") { f[0] = 'A'; f[1] = 'B'; f[2] = 'C'; h.push_back('w'); i[0] = 255; i[1] = 254; i[2] = 253; j[0] = subobject(99, 100); k.push_back(1); k.push_back(2); k.push_back(3); l.push_back('l'); } test(bool) {} // Don't initialize everything bool operator== (const test& other) const { return (a == other.a && b == other.b && c == other.c && d == other.d && e == other.e && f == other.f && g == other.g && h == other.h && i == other.i && j == other.j && k == other.k && l == other.l); } }; int main(int, char**) { test t1; // Serialize object to binary format, in network byte order std::ostringstream oss; boost::archive::network_oarchive oa(oss); oa << t1; // Create uninitialized object test t2(false); // De-serialize object from binary format, in network byte order std::istringstream iss(oss.str()); boost::archive::network_iarchive ia(iss); ia >> t2; assert(t1 == t2); return 0; } This produces the following binary output: ------------------------------- 0000000 |01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 61 |a |b |c |d |e 0000020 |62 63 64 65 66 67 00 00 00 00 00 00 00 00 00 00 | 0000040 |00 00 00 00 00 00 41 00 00 00 42 00 00 00 43 00 | | f 0000060 |00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | 0000100 |00 00 00 00 00 00 00 00 00 00 00 03 78 79 7a 01 | |g |h 0000120 |00 00 00 77 00 ff 00 fe 00 fd 00 00 00 00 00 00 | |i |j 0000140 |00 63 00 00 00 64 00 00 00 00 00 00 00 00 00 00 | |k 0000160 |00 03 00 01 00 02 00 03 00 00 00 01 6c | |l

3 4

BOOST_PP_COMMA, LPAREN,RPAREN delay eval?
by Larry Evans 22 Mar '04

22 Mar '04

I've looked at some of the uses of these, but can't figure out how to do the following. Using boost/preprocessor macros, I want to generate code something like: #include <boost/mpl/vector.hpp> #include <boost/mpl/at.hpp> using namespace boost::mpl; struct source { target my_target ; template<typename VecOfTypes> source ( VecOfTypes const& , at_c<VecOfTypes,0>::type a0 ) : my_target ( a0 ) {} template<typename VecOfTypes> source ( VecOfTypes const& , at_c<VecOfTypes,0>::type a0 , at_c<VecOfTypes,1>::type a1 ) : my_target ( a0 , a1 ) {} }; and use it as follows: typedef vector<int,float> int_float_typelist; source s0(int_float_typelist(),0); source s1(int_float_typelist(),0,2.5); I was planning on defining a macro, PP_CTOR_FORWARDER_OVERLOAD, to be used as: struct source { BOOST_PP_REPEAT(2,PP_CTOR_FORWARDER_OVERLOAD,(source, my_target)) }; However, I also would like to use it where instead of my_target(a0,a1), there might be super_type(new target(a0,a1)), in which case the tuple that was the last arg to BOOST_PP_REPEAT would contain left and right parens. However, when I tried: BOOST_PP_REPEAT( 2, PP_CTOR_FORWARDER_OVERLOAD, (source,auto_ptr<target> BOOST_PP_LPAREN() new target, BOOST_PP_RPAREN() )) I get: /usr/local/gcc-3.4-20040225/bin/g++ -ggdb -c -Wall -MMD -O0 -ggdb -E -I/home/evansl/prog_dev/boost-root.ln/boost_dev -I/home/evansl/prog_dev/boost-root.ln pp_ctor_forwarder.cpp |indent -st pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_0" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_1" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_2" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_0" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_1" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_2" requires 4 arguments, but only 2 given # 1 "pp_ctor_forwarder.cpp" How can I cause the delay in evaluation of BOOST_PP_RPAREN and LPAREN to avoid these errors? Here is my current macro def: #include "boost/preprocessor/enum_params.hpp" #include "boost/preprocessor/inc.hpp" #include "boost/preprocessor/punctuation/comma_if.hpp" #include "boost/preprocessor/tuple/elem.hpp" #define PP_CTOR_FORWARDER_PARAM(z,n,_) \ BOOST_PP_COMMA_IF(n) at_c<VecOfTypes,n>::type BOOST_PP_CAT(a,n) #define PP_CTOR_FORWARDER_OVERLOAD(z,n,data) \ template< typename VecOfTypes > \ BOOST_PP_TUPLE_ELEM(4,0,data) \ ( VecOfTypes const& \ , BOOST_PP_REPEAT(BOOST_PP_INC(n), PP_CTOR_FORWARDER_PARAM, BOOST_PP_EMPTY) \ ) \ : BOOST_PP_TUPLE_ELEM(4,1,data) \ BOOST_PP_ENUM_PARAMS(BOOST_PP_INC(n), a ) \ BOOST_PP_TUPLE_ELEM(4,2,data) \ {} TIA.

2 3

[BGL] transpose_graph documentation.
by Cromwell Enage 21 Mar '04

21 Mar '04

Accodring to <http://www.boost.org/libs/graph/doc/transpose_graph.html> the graph that will hold the transposition is supposed to have no edges in it and to have the same number of vertices as the input graph. However, looking through the source code in <boost/graph/copy.hpp>, which the algorithm uses, I see as many vertices being added to the output graph as there are in the input graph. Does this mean that the output graph is actually supposed to have no vertices to begin with? In the attached program, if the #if condition is set to 1, the program does as the documentation currently suggests, but the output is wrong. With the #if condition left at 0, the program gives the correct output. What's the verdict? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

2 1

[Filesystem] Relational operators
by Martin 21 Mar '04

21 Mar '04

I have used the filesystem library for some time now and I am really happy with it. In the CVS I noticed that it recently added relational operators and an "equivalent" function. To my surprice the relational operators are implemented in a non-portable way. It only does a lexicographical compare! In the rationale it says: "Programmers wishing to determine if two paths are "the same" must decide if that means "the same representation" or "resolve to the same actual file or directory", and choose the appropriate function accordingly." In windows the path "file.cpp" is the same as "FILE.CPP" but not in posix. So if I write portable code I need to do add a function like bool eq_path(const path& path1, const path& path2) { #if BOOST_POSIX return path1.string() == path2.string(); #else return boost::algorithm::iequals(path1.string(), path2.string()); #endif } In most of my cases the equivalent function is not an alternative since it requires that both paths can be evaluted by the filesystem, i.e. paths must exist and the parent of relative paths must be known. --------------------------------------- Another minor question: Why does the "leaf()" member function return a string and not a path?

2 1