- Boost - lists.boost.org

[graph] Bundled properties, listS, listS, write_graphml
by remi.chateauneu＠gmx.de 02 Dec '08

02 Dec '08

Hi, I try to use boost::graph with two bundled properties, listS for vertices and edges, and serialize with write_graphml, and it does not compile: Boost 1.35 and 1.36, Windows Visual C++ 8.0 Here are the most important details of the code: class Host { int idx ; }; class SocketPair { int xxx ; }; typedef boost::adjacency_list< boost::listS, /// Needs stability of iterators. boost::listS, /// Needs stability of iterators. boost::directedS, Host, SocketPair > Graph; Graph gblGrf ; boost::dynamic_properties tmpDP ; boost::write_graphml( std::ofstream("xxx.xml"), boost::vertex_index_map( boost::get( &Host::idx,_gblGrf ) ), gblGrf, tmpDP ); Here is the beginning of the compile errors. Any idea, please ?? Thanks in advance 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2039: 'vertex_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graphml.hpp(225) : see reference to class template instantiation 'boost::graph_traits<G>' being compiled 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> i:\remi\graph\graph\graph.cpp(435) : see reference to function template instantiation 'void boost::write_graphml<boost::bgl_named_params<T,Tag,Base>,Netstat::Graph> (std::ostream &,const Graph &,VertexIndexMap,const boost::dynamic_properties &,bool)' being compiled 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property, 1> Graph=boost::bgl_named_params<boost::bundle_property_map<boost::adjacenc y_list<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property>, 1> VertexIndexMap=Netstat::Graph 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2146: syntax error : missing ';' before identifier 'vertex_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2602: 'boost::graph_traits<G>::vertex_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : see declaration of 'boost::graph_traits<G>::vertex_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2868: 'boost::graph_traits<G>::vertex_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2039: 'edge_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2146: syntax error : missing ';' before identifier 'edge_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2602: 'boost::graph_traits<G>::edge_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : see declaration of 'boost::graph_traits<G>::edge_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2868: 'boost::graph_traits<G>::edge_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(28) : error C2039: 'adjacency_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(29) : error C2039: 'out_edge_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ]

2 1

Reflexion in boost.
by Alejandro J. 02 Dec '08

02 Dec '08

I think push reflexion into the boost library, i need the new branch.this process i try doing in the next mount., sorry for my english. Alejandro jaime. _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…

1 0

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir Batov 02 Dec '08

02 Dec '08

Andy, Thank you for taking the criticism the right way and my apologies if some of my comments sound(ed) somewhat harsh. It is never my intention. I won't be addressing the points below directly as some issues I raised are petty (and I somewhat wish I did not raise them). I admit I felt uneasy with the proposal but could not pin-point what it was. I'll try again. Background: We are in our project currently using uuid facility heavily and very dependent on it. The version we use (from memory) is something like (it's not necessarily exactly what we use and I'll omit some scaffolding and stick with the basics): struct uuid : public std::string { typedef std::string base; uuid() : base(generate()) {} explicit uuid(string const& s) : base(s) {} static uuid null() { return uuid(std::string()); } private: std::string generate(); }; On Linux the generate() function calls uuid_generate(). No one (in our project anyway) can be bothered choosing between uuid_generate_random() or uuid_generate_time() -- uuid_generate() takes care of the guess work and picks the best available. The same on Windows -- it'll probably be UuidCreate()&UuidToString(). Given that uuid above is merely a wrapper over OS facilities, we get known behavior, we are guaranteed "support" and an automatic "upgrade" if/when the standard changes or a new better algorithm becomes available. For me (a collective nebulous "me") to switch to your boost::uuid it has to provide something to win me over. Let's see what that might be. Does boost::uuid provide superior implementation? Maybe. If it is, that was not spelt out sufficiently visibly for me to pick up in the documentation. Therefore, as it is now the answer regretfully has to be 'no'. Does boost::uuid provide superior interface? That issue might get very subjective and personal. Therefore, I'll re-focus on if boost::uuid is user-friendlier. Maybe but I doubt it as an ordinary user does not want to be bothered choosing between algorithms. If uuid_generate() and UuidCreate() can make that choice for me, it is good enough for the overwhelming majority of uuid applications. Therefore, the answer seems again 'no'. Does boost::uuid provide superior support and a upgrade path? With all due respect I have to say 'no' again as your support (no matter how enthusiastic it is) cannot compete (on industrial/commercial scale) with vendor-backed support. uuid_generate(), UuidCreate() as printf() come with the system. One has to have really serious reasons to use something else instead. Does boost::uuid provide superior documentation? Well, my impression is that it is 'no' again. What boost::uuid does immediately entice an ordinary user with then it is Boost reputation. However, in all honesty it's not boost::uuid property per se but the reputation for quality of the Boost libraries built over those many years. In this thread I hear some people say "it's OK to ship". I disagree. Every new library has Boost reputation to uphold. It takes time to build such a reputation. It does not take long to lose it -- a couple of just "OK to ship" libraries will probably do. I'd probably be more comfortable if boost::uuid took the approach of boost::thread of providing consistent interface across many platforms via re-use of the functionality provided by the OS (when available) rather than duplicating it. Then though I'd expect the interface to be given considerably more thought. As for the interface I'll express my view to one of your comments below. > I would not want the default constructor to generate a uuid. I don't > want users to pay for that if they don't want it. Some use cases will > not require generating uuids, only using them. I have to disagree. I believe that the overwhelming majority of cases falls into the following category -- "I introduce something when/because I need that something". That is, by Foo foo; std::string str1; std::string str2(params); uuid id1; uuid id2(param); I create valid instances. Say, 'str1' is empty but it is still a valid string. I create 'id1' because I need an uuid. You on the other hand use uuid id2(param); // valid instance uuid id1; // invalid instance where #1 creates a valid instance but #2 creates an invalid instance (it lacks its identifying property -- it's NOT unique). Therefore, you use the same (visually and behaviorally) creation mechanism to achieve *different* results. From the user perspective it is inconsistent and likely unexpected. The case you are catering for with uuid() is not mainstream but quite the opposite -- the user introduces something that he does *not* want. Such case should be handled explicitly with the user actually spelling out what he means like Foo::Foo() : uuid_(boost::uuid::null()) // initially invalid {} Best, Vladimir.

4 3

Boost namespace abreviations
by edam 01 Dec '08

01 Dec '08

Hi there, I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy. I try to avoid going "using namespace" (for a few reasons, nicely summarised here: http://dev.lsstcorp.org/trac/wiki/DiscussCodeStandards) and I can't bring myself to go down the route of announcing to the compiler that I will be "using ..." specific symbols from whichever namespace either. So I am left with having to explicitly specify the namespace of each symbol, like this: std::cout << std::setw( 2 ) << std::setfill( '0' ) << hours; While this requires more typing, I prefer it to the alternatives. As a boost user though, I find this becomes a bit more of a pain. Boost's namespaces, whilst well named, are a lot to keep typing out! Here's a quick example: boost::posix_time::time_duration foo = boost::posix_time::hours(2); Multiply this by a thousand lines of boost-using code and you've got a lot of typing! I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp: // this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } This would allow the developer to shorten the above example code to bst::pt::time_duration foo = bst::pt::hours(2); in this case saving a full 18 characters! Multiply this by 1000 lines of code and you may save some finger-ache. What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o) Regards, Tim. -- edam - www.waxworlds.org/edam

5 4

boost::regex problem with escaped parenthesis
by Kumar, Anurag 01 Dec '08

01 Dec '08

Hello, While trying to match the escaped "(" I am facing problem. Following is the code snippet : std::string stdString = "abc(def)ghi"; std::string bExpression = "c\\(def\\)g"; // Creating the expression boost::regex boostRegEx ( bExpression, boost::regex::extended ); // my match function boost::smatch boostMatch; std::string::const_iterator itr_begin ( stdString.std().begin()); std::string::const_iterator itr_end ( stdString.std().end() ); bool b_match = false; // Match flags used boost::match_flag_type matchFlags = boost::regex_constants::match_default | boost::regex_constants::match_not_dot_newline | boost::regex_constants::match_single_line; // Trying to match b_match = boost::regex_search( itr_begin, itr_end, boostMatch, boostRegEx, matchFlags ); My expected result is: b_match should be "true" boostMatch should contain "c(def)g" Please help me to fix this problem. Regards, Anurag

2 1

[date_time] Internal header testfrmwk.hpp
by Andrey Semashev 01 Dec '08

01 Dec '08

Hi, There is a testfrmwk.hpp header in the boost/date_time directory. This header contains some utility to aid testing of the library and I believe is not a part of the library interface (that is, it's not in boost namespace and I don't see it documented). I don't know why the header resided in the boost/date_time directory in the first place, so I intend to move it into the test directory. Does anyone have objections? (Jeff, I hope, you're reading this)

2 2

[Boost.Thread] ids obtained from the same thread not equal
by Karp Dantax 01 Dec '08

01 Dec '08

Using boost::thread::get_id() in an executable and one of its DLLs generate different ids although the calls are made from the same thread. Until Boost 1.34.1, which used GetCurrentThreadId() to compare two boost::thread objects, it worked perfectly. I have not delved into the code, but now that the library is using thread local storage to store the current thread id, it is not working in the context mentioned above. Well, thats it. Maybe i am missing something here? []s

2 1

[Review] UUID library (mini-)review ends today, November 30rd
by Hartmut Kaiser 01 Dec '08

01 Dec '08

Hi all, the review of Andy Tompkins' UUID library ends today, November 30th. Nevertheless, it's still possible to submit a review for at least a week, as I'm not going to have time for the analysis of the review before Christmas. Thanks to all of you who submitted a review. Regards Hartmut Review Manager

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 01 Dec '08

01 Dec '08

> Too bad, and just when I thought we were getting down to brass tacks. > Well, maybe Tom would care to weigh in on these issues; I'm still making > an effort to figure out how best to resolve them. I have been absolutely swamped in the last two days and will not have the time to write up any responses until much later today. Having said that, do you think it's worth my time? It doesn't seem really like we're getting anywhere.

3 6

RFC: Automatic indexing of quickbook/boostbook/docbook docs.
by John Maddock 30 Nov '08

30 Nov '08

I've just committed a new tool to the sandbox under tools/auto_index which helps automate the indexing of quickbook/boostbook/docbook documentation. Obviously the tool is biased toward C/C++ code documentation, as among other things it can scan C/C++ headers looks for definitions of classes/typedefs/macros/functions which should be indexed. The actual index can be produced either by the final XSL transform, or by auto_index itself (ie using regular docbook markup for the index), the former is better for PDF/print docs as it allows page numbers to be inserted, the latter works better for html docs, and is also faster (thankfully - the XSLT index generation code is glacially slow). There are some examples taken from type_traits and Boost.Math here: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/example/readme.html Some rather basic documentation for the tool itself is here: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html note that currently there is no Boost.Build integration - I really need some help with that - so the tool is much harder to use than it should be. Any comments, especially on the usability of the indexes generated would be much appreciated! Cheers, John.

5 12