July 2006 - Boost - lists.preview.boost.org

Re: [boost] [BGL] Graphviz
by Wang Weiwei 14 Jul '06

14 Jul '06

>On Fri, 14 Jul 2006 10:58:00 -0300, Wang Weiwei <wwwang(a)ccsdl.org> wrote: > >> I know BGL is compatible with Graphviz file format. >> and Graphviz is also an open source library. >> >> Is Graphviz ported to windows platform? > >Yes. > >http://www.graphviz.org/Download_windows.php > >Bruno > Thanks! I have downloaded the .src.tgz file and unzipped it. But can only get a .src file instead of an organised folder containing the C++ source files, which is what I expected. ??? More help needed. :-( Thanks again. Max

2 1

[BGL] Graphviz
by Wang Weiwei 14 Jul '06

14 Jul '06

hello, I know BGL is compatible with Graphviz file format. and Graphviz is also an open source library. Is Graphviz ported to windows platform? Thanks Max

2 1

Re: [boost] [asio] has anybody enabled SSL in a large project?
by Scott 14 Jul '06

14 Jul '06

Hey Chris, >Is your program single or multithreaded? Any chance you can boil >it down to a test program? What version of OpenSSL are you >using? It's multithreaded. On the client side, we have one thread that basically starts in the io_service::run() method. Before starting the thread, we attach a async_read() callback handler then start the thread. When the thread receives data, it stores all messages in a global map (locked from a mutex), that all threads have access to. Messages can be received by an application defined message id. After each message is received, it reattaches the async_read() callback handler so the io_service never runs out of work to do. Other threads in the client such as the UI thread share the same socket and can send requests thru the socket. However all replies are handled by the receiver thread. There are other threads as well, but they don't really interact with ASIO. Server The server creates multiple threads to listen for incoming connections. At the end of each ThreadEntry() func is a call to a shared global asio::io_service::run(). These threads do typical server things such as handle incoming requests and send back responses. We also have other threads that are constantly running. As an example, there's a thread that monitors CPU performance. Clients can request a monitor be placed on the CPU activity level and when it changes this thread will immediately send data to client on the change. This is not a typical request/response scenario as the data will be sent to the client at random intervals (as far as the client is concerned) without a corresponding request (other than the initial monitor request). Given some of the scenarios I've described above, do you seen any implementation issues? OpenSSL version is 0.9.8a. I'll attempt to modify the included ASIO SSL example program to better mimic some of the processes we have running. :) Thanks, Scott

2 1

Re: [boost] [asio] has anybody enabled SSL in a large project?
by EMalenfant＠interstarinc.com 14 Jul '06

14 Jul '06

From: viktor kougitko [mailto:klug@apriorit.com] > > From: "Scott" <cheesy4poofs(a)cox.net> > [snip] > > It all seemed great at first, because it seemed to > > seemlessly work. > > But eventually the communications break down. I either get > >asserts in > > my code from unexpected data in the stream, or the client hangs > > waiting for data that never appears or any of several > >different stream > > problems. It's rarely the exact same thing. But it > >eventually always > > fails. Especially on long sustained transfers. > > > > it seems that problem with buffer sizes try to change > asio/ssl/detail/openssl_stream_service.hpp > openssl_stream_service::create > ::BIO_new_bio_pair(&int_bio, 3*8192, &impl->ext_bio, 3*8192); > it helps in my case > I know next to nothing about asio's SSL implementation, but this reference to buffer sizes reminds me of a problem that we saw in a previous version of TAO: http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1429 The fix in that case was to enable partial writes in open ssl, using SSL_set_mode to enable SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER. HTH, Éric

2 1

Interest in a small array count facility?
by Gennaro Prota 14 Jul '06

14 Jul '06

Hi guys, a while ago there was some discussion about incorporating a compile-time array count facility in boost. I also provided an implementation for multidimensional arrays. Is there still interest for this? The benefits over the classical sizeof(array)/sizeof(array[0]) idiom are not overwhelming but at least there's a fair syntactical convenience and, of course, the advantage of unit test integration. If there's interest I can add it, to the utility subdirectory I guess (better suggestions are welcome; I really don't like using utility/ as a sort of repository for anything we have no better place for). --Gennaro.

8 32

Interest in super string class?
by Jeff Garland 14 Jul '06

14 Jul '06

I've been working on a little project where I've had to doing lots of string processing, so I decided to put together a string type that wraps up boost.regex and boost.string_algo into a string type. I also remember a discussion in the LWG about whether the various string algorithms should be built in or not -- well consider this a test -- personally I find it easier built into the string than as standalone functions. You can download from the string/text processing part of the vault: http://tinyurl.com/dbcye Below is the summary and motivating code example. Enjoy, Jeff -------------------------------------------------------------------------- Souped up string class that includes fancy query, replacement, and conversion functions. This type has the following main goals: * Is a drop-in replacement convertable to std::string and std::wstring * Provide case conversions and case insensitive comparison * Provide white space triming functions * Provide a split functions to parse a string into pieces base on string or regex * Provide sophisticated text replacement functions based on strings or regex * Provide append and insert functions for types Overall, this class is mostly a convience wrapper around functions available in boost.string_algo and boost.regex. This is best illustrated with some code: super_string s(" (456789) [123] 2006-10-01 abcdef "); s.to_upper(); cout << s << endl; s.trim(); //lop of the whitespace on both sides cout << s << endl; double dbl = 1.23456; s.append(dbl); //append any streamable type s+= " "; cout << s << endl; date d(2006, Jul, 1); s.insert_at(28, d); //insert any streamable type cout << s << endl; //find the yyyy-mm-dd date format if (s.contains_regex("\\d{4}-\\d{2}-\\d{2}")) { //replace parens around digits with square brackets [the digits] s.replace_all_regex("\$([0-9]+)\$", "__[$1]__"); cout << s << endl; //split the string on white space to process parts super_string::string_vector out_vec; unsigned int count = s.split_regex("\\s+", out_vec); if (count) { for(int i=0; i < out_vec.size(); ++i) { out_vec[i].replace_first("__",""); //get rid of first __ in string cout << i << " " << out_vec[i] << endl; } } } //wide strings too... wsuper_string ws(L" hello world "); ws.trim_left(); wcout << ws << endl; Expected output is: (456789) [123] 2006-10-01 ABCDEF (456789) [123] 2006-10-01 ABCDEF (456789) [123] 2006-10-01 ABCDEF1.23456 (456789) [123] 2006-10-01 2006-Jul-01 ABCDEF1.23456 __[456789]__ [123] 2006-10-01 2006-Jul-01 ABCDEF1.23456 0 [456789]__ 1 [123] 2 2006-10-01 3 2006-Jul-01 4 ABCDEF1.23456 hello world

22 95

Re: [boost] [Boost-users] bug in documentation
by Daryle Walker 14 Jul '06

14 Jul '06

On 7/11/06 4:40 PM, "Ovanes Markarian" <om_boost(a)keywallet.com> wrote: > there is currently a bug in boost::lambda documentation > (<http://www.boost.org/doc/html/lambda/s03.html>). > > Current version: > > template <class T> : public binary_function<T, T, T> > struct plus { > T operator()(const T& i, const T& j) const { > return i + j; > } > }; > > should be: > > template <class T> > struct plus : public binary_function<T, T, T> > { > T operator()(const T& i, const T& j) const { > return i + j; > } > }; Fixed. (Hopefully; this HTML page is generated. There are two possible files it could come from. The first one, $ROOT/libs/lambda/doc/lambda.xml, was already OK. I fixed the second file at $ROOT/libs/lambda/doc/detail/lambda_doc.xml in the trunk as revision 1.15. Please undo this if changing this file was inappropriate. I don't know which of the two Lambda XML doc files is important.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

STLPort 5.0 configuration
by Robert Ramey 14 Jul '06

14 Jul '06

I'm trying to tweak a couple of tests so that they pass with STLPort 5.0. A part of the test has to be run differently for this platform and I want to detect which version of STLPort I'm running on. Here is the part of the test. This works for STL 4.5.3 but for STLPort 5.0 it doesn't. When I look in config it looks like I should be using // at least one library - MSL notes: it doesn't make much sense // to implement the == operator for hash collections - but goes ahead // does it anyway even though it doesn't seem to work. So sort into // vectors and then compare. Currently, it seems that STLPort versions // greater than 5.0 don't support the == operator on hashed sets #if !defined(_STLPORT_VERSION) || (_STLPORT_VERSION < 0x500) BOOST_CHECK(ahash_map == ahash_map1); #else std::vector< std::pair<random_key, A> > tvec, tvec1; std::copy(ahash_map.begin(), ahash_map.end(), std::back_inserter(tvec)); std::sort(tvec.begin(), tvec.end()); std::copy(ahash_map1.begin(), ahash_map1.end(), std::back_inserter(tvec1)); std::sort(tvec1.begin(), tvec1.end()); BOOST_CHECK(tvec == tvec1); #endif When I look at config infoSTLPort standard library version 0x510 I see __SGI_STL_PORT =0x510 __STL_DEBUG =1 _STLP_DEBUG =1 _STLP_DEFAULT_TYPE_PARAM =1 _STLP_IMPORT_VENDOR_CSTD =1 _STLP_LONG_LONG =long long _STLP_OWN_IOSTREAMS [no value] _STLP_USE_NEW_C_HEADERS [no value] _STLP_USE_OWN_NAMESPACE =1 __GLIBCXX__ =20051201 _GLIBCXX_USE_LONG_LONG =1 _GLIBCXX_USE_C99_MATH =1 _GLIBCXX_USE_C99 =1 _GLIBCXX_USE_LFS =1 _GLIBCXX_HOSTED =1 _GLIBCXX_SJLJ_EXCEPTIONS =1 So it looks like I should have something like: #if !defined__SGI_STL_PORT) || (__SGI_STL_PORT < 0x500) But I'm not sure how this would work with STLPort 4.5.3 What should I be doing. Robert Ramey

1 0

Re: [boost] [BGL] Help Needed
by Wang Weiwei 14 Jul '06

14 Jul '06

Hello Enage, Thank you so much for your help and sample code. One more question is: :-) If MyVPropType and MyEPropType are 2 user-defined typenames already exist that I want the vertex/edge descriptors to map into. e.g. class MyVPropType { std::vector<int> v; std::map<int, std::string> m; } class MyEPropType { double weight; std::string path_name; } And I also need two user types as the vertex/edge descriptors, e.g. -vertex descriptor type class MyVDescriptor { std::pair<int, std::string>; // sth else } -edge descriptor type class MyEDescriptor { std::string name; boost::array<int, 10> array; } (all of the above user types are somewhat complex intentionally but I think this does not matter, is it?) Additionally, while using these user maps, I want also retain the default color map for the vertices. How to write the code (using an adjacency_list graph class)? Thanks again. Max >--- Wang Weiwei wrote: >> > Thanks for your help. Would you pls give me an >> > example showing the usage of internal property >> > map for the vertices and edges? >> >> or, to make the question simpler, how to declare >> an adjacency_list type graph object with internal >> vertex/edge property maps as follows: >> >> vertex descriptor -> MyVpmType >> edge descriptor -> MyEpmType > >struct elem_id_t >{ > typedef boost::vertex_property_tag kind; >}; > >struct edge_id_t >{ > typedef boost::edge_property_tag kind; >}; > >typedef boost::property<elem_id_t, char> > MyVpmType; >typedef boost::property<edge_id_t, std::string> > MyEpmType; >typedef boost::adjacency_list< > boost::listS > , boost::vecS > , boost::directedS > , MyVpmType > , MyEpmType > > > Graph; > >Graph g; > >> And how to access the internal maps to do sum >> get/put operation? > >boost::property_map<Graph, elem_id_t>::type > vertex_map = boost::get(elem_id_t(), g); >boost::property_map<Graph, edge_id_t>::type > edge_map = boost::get(edge_id_t(), g); > > Cromwell D. Enage > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > = = = = = = = = = = = = = = = = = = = = 　　　　　　　　致礼！　　　　　　　　Wang Weiwei 　　　　　　　　wwwang(a)ccsdl.org 　　　　　　　　　　2006-07-14

1 0

Re: [boost] Please don't define a fake"operator<"just for ordered containers
by Sean Parent 13 Jul '06

13 Jul '06

Christoph Ludwig posted the correct reason why std::complex should not have an operator < () defined - sorry, my follow up using addition was poorly constructed. What I am proposing is that std::less should be defined for std::complex. > >> std::less is ambiguous. It could be that you wanted merely the > >> function object representation of operator<, or it could be that > you > >> wanted the default map/set ordering relation. It is not clear which > >> of the two std::less is supposed to be. > > > > If shared_ptr doesn't support operator< it's not a problem, is it? > > The context is: > > - If we had a separate relation for set/map we would use that for > settable/mappable objects. > - Why is a separate relation better than just using less<>? > - Because it is evident from the design of the standard library > that less<> > isn't meant for that, not consciously, at least. > > "What should shared_ptr do" is a separate question. Under the > current status > quo, it defines operator< to order pair< shared_ptr<>, int > as > well. Under > a revised standard, it may well need to do something else, > depending on how > the standard is changed. Why would we have a separate default relation for set/map then std::less? std::less is intended to map to operator <() on the type _or_ to a total ordering for the type if operator <() is not defined. That's what the standard says - it is intentional (Alex would have had operator <() defined even for types such as complex - but couldn't get that through the standard - he was especially concerned with pointer comparisons to separate containers because this is very useful. Not being able to change the language he at least got the change for std::less (not being there this is probably a misrepresentation of history - but the Alex's intent was that a total ordering should be present nearly everywhere) - he was using operator <() even in the cases he new it was "wrong", because there is no operator [glyph for < with a loop at the small end]. I convinced him that std::less<> is a reasonable way to spell [glyph for < with a loop at the small end.] For pair<shared_ptr<>, int> - what makes shared_ptr special? This doesn't work pair<T*, int> today - I don't see why we should special case shared_ptr - especially in a way which should likely change in the future. Rather I'd recommend specializing std::less - note that you could also specialize std::less<> for std::pair<shared_ptr<>, T> (and the two other variants) if this is _really_ a big concern. I haven't run across a need to order pairs with shared_ptr (nor a pair with pointers for that matter). As for what I expect std::greater<> et al. to do - I had that in my earlier 6 point note - they _better_ be defined consistently with std::less. std::less is supposed to be operator <, unless operator < is not defined in which case std::less provides a total ordering. It isn't ambiguous. Sean

4 3