- Boost - lists.boost.org

Dispatcher Library Initial Implementation
by Dean Michael Berris 15 Jul '06

15 Jul '06

Hi Everyone, Uploaded to the vault [0] is the implementation of the dispatcher library. If there is enough interest, I would like to propose this library for inclusion into the Boost C++ Library. The documentation is yet unfinished, though I am not very sure about the contents of the documentation. However, I have put enough documentation with regards to how the library is designed, and used. A synopsis on how it can be used can be summed up in the following example code: [start code] #include <boost/dispatch.hpp> using boost::dispatch; //... dispatcher<int()> d; d[0] = int_function_1; d[1] = int_function_2; d[0]() // calls `int_function_1' d[1]() // calls `inf_function_2' d.unset(1); try { d[1]() // throws an unregistered_handler exception } catch (unregistered_handler & e) { // .. do nothing }; dispatcher<int()>::invoke_ d; d[1] = int_function_2; d << 0 << 1 ; // calls d[0] and d[1] in specified order. [end code] It also supports multiple argument callback registration (ala Signals): [start code] dispatcher<int (double, int, std::string)> d; d[0] = function_returns_int_and_takes_double_int_and_string; [end code] It also allows for parameterized index type definition: [start code] dispatcher<int(int), std::string> d; d["zero"] = function_returns_int_and_takes_int; [end code] The included documentation (doc/html) contains more information on the uses of the library, while the unit test (test/dispatch_test.cpp) can be referred to regarding the actual details on the usage. The project is currently hosted in sourceforge [1] and has been tested/built against RC_1_34_0 using MSVC 8.0 -- this is configured to be built only with BBv2. Have a great day everyone! Your comments and insights will be most appreciated. References: [0] Dispatcher Initial Implementation http://tinyurl.com/q9oux [1] Sourceforge.net project page http://tinyurl.com/mo2ds -- Dean Michael C. Berris C/C++ Software Architect Orange and Bronze Software Labs http://3w-agility.blogspot.com/ http://cplusplus-soup.blogspot.com/ Mobile: +639287291459 Email: dean [at] orangeandbronze [dot] com

4 8

[regex]Including regex.hpp causes error in an skeleton win32 project of VS.net2003 with MFC support
by Wang Weiwei 15 Jul '06

15 Jul '06

Hello, I have done a test, on WinXP + VS.net 2003, with regex lib as follows , A created a new 'Win32 Console Project', I selected MFC and pre-compiled header support. Leave other settings default. Then I created a skeleton project that can compile. Then I added #include <boost/regex.hpp> in the main cpp file. When I then compiled the program in debug mode, I got a "error C2665" at regex_raw_buffer.hpp(177) - “operator new. When I compiled it in release mode, it's Ok. Anybody know how about this phenomenom? Thanks Max

6 6

[regex]How to get Content-Type's parameter pairs using boost.regex?
by Mockey Chen 15 Jul '06

15 Jul '06

Hi, experts, I using boost.regex parse the content-type header's value in MIME. A typical content-type's BNF like following: Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string An example content-type as following: multipart/mixed; boundary="theboundary" ;id=33 There may be zero or one more parameters in content-type. My parse code as following: #include <boost/regex.hpp> #include <iostream> #include <string> #define COUT(x) std::cout << x << std::endl #define VAR(v) std::cout << #v << ": " << v << std::endl #define TOKEN "[a-zA-Z0-9]+" #define TYPE "(" TOKEN ")" #define SUBTYPE "(" TOKEN ")" #define PNAME "(" TOKEN ")" #define PVALUE "(" TOKEN ")" #define PARAM "(;" PNAME "=" PVALUE ")" #define CONTENT_TYPE_EXPRESS TYPE "/" SUBTYPE PARAM "*" int main() { std::string ct("multipart/mixed;boundary=theboundary;id=33"); COUT(CONTENT_TYPE_EXPRESS); boost::regex regex_content_type(CONTENT_TYPE_EXPRESS); boost::smatch result; if (boost::regex_match(ct, result, regex_content_type)) { VAR(result.size()); for (unsigned int i=0; i<result.size(); ++i) { if (result[i].matched) { COUT("result[" << i << "] = " << result[i]); } } } else { COUT("match failed."); } return 0; } /** output: ([a-zA-Z0-9]+)/([a-zA-Z0-9]+)(;([a-zA-Z0-9]+)=([a-zA-Z0-9]+))* result.size(): 6 result[0] = multipart/mixed;boundary=theboundary;id=33 result[1] = multipart result[2] = mixed result[3] = ;id=33 result[4] = id result[5] = 33 */ I want to get the parameter "boundary" and its value. Any way to do it? Thanks in advance. -- Regards. Mockey Chen

2 1

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

15 Jul '06

> I think I have a basic understanding of your logic, but let's think > about > practicality for a moment. I'm not saying logical and philosophical > reasons > are not appropriate for this discussion, but let's try and not > think about > them for a second. I haven't heard mathematics described as "philosophical reasons" but okay. > The ordering defined by the operator< overload for shared_ptr has the > following important property: it is independent of shared_ptr's > template > parameter. You can order shared_ptr<void> objects, if you like. Or, a > shared_ptr<void> and a shared_ptr<int>. I understand, total ordering is important and useful. The question is, what are the semantics of operator < ? If we fail to establish such principals then generic programming is a futile exercise. A generic algorithm is a theorem - it's correctness depends on a collection of semantic requirements (Concepts), these are the axioms for the theorem. Does it matter if share_ptr provides an operator <? No, but it isn't useful for generic code unless such an operation is tied to semantics which are generally accepted. T* does not provide such an operator < and I see no semantic difference between the two. The two should be consistent - I don't really much care which way we go but there are important semantics at play here for operator <. Specifically we're pinning down whether operator < should or should not guarantee a stable ordering across executions of the application. We can say that the C and C++ standard got the rules for T* wrong and lobby to change them, or that shared_ptr<> shouldn't have a less than operator. We might even still provide it under the claim that it shouldn't be defined but is so that std::less<> will work consistently with T* (assuming you don't want to just specialize std::less<> - which I think would be a better solution). Since we can't reasonably check semantic requirements, it is important for code correctness that we associate the requirements with the name of the operation. The signature is the only thing I can check. > Can you think of any problems that operator< could cause, in its > current > definition? In my mind, since you can't use T in your ordering > semantics, > you have no reasons to define your own ordering for shared_ptr. > Therefore, > you have no other use for operator<, and therefore if the one > defined by the > library causes no problems, we should keep it because it is practical. Not any realistic one - in general providing such an operator only breaks concept checks (when we are able to check if a function exists). But without consistent semantics it also doesn't allow me to develop any useful algorithms which rely on this. ----- > > 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. > > Disagree. That could potentially break other template programming > using std::less, to support std::unary_negate etc. Suddenly this would > "work" for std::complex, when it shouldn't. Allowing code which otherwise would not be allowed is hardly breaking anything. I can see the argument that std::less<> should also be consistent with other operators. I think it is then important to define a general total order operation for this case and develop the rules. Please propose a set of rules for when operator<() should and should not be defined. > > 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. > > No, that's just for pointers. 20.5.7/8 says: > > "For templates greater, less, greater_equal, and less_equal, the > specializations for any pointer type yield a total > order, even if the built-in operators <, >, <=, >= do not." > > It doesn't mention std::complex or any other composite types. That still doesn't answer the question of why have another relation for set/map then std::less? And as for the intent for STL I can assure you that the intent of the designer was std::less was intended to provide a total ordering on all types. That standard also does not prohibit us from specializing std::less for use defined types. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > The fact that it is a pointer? I don't care much if it doesn't have an > ordering. Then it shouldn't be different from T*. > > > > 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. > > Where does the standard say that? I have the advantage of having Alex Stepanov on my team. I asked him. > If you want to have an ordered collection of otherwise unordered data, > the relation must be an application specific attribute. So define an > appropriate functor, and use that with std::map, etc. If we want to introduce a third (or more) way to define a standard ordering other than operator <, std::less I'm fine with that. Just specify the semantics of them. ---- > That is also how I interpret his intent based on what is currently > in the > standard, and that is why I maintain that *under the current > standard*, the > appropriate way to make a type ordered (even if only for the > associatives) > is via defining operator<. If we do this for shared_ptr it should be with a clear statement that we expect the rules for T* should be changed (or consider T* to be a legacy exception which cannot be changed). > > Why would we have a separate default relation for set/map then > > std::less? > > and: > > > 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. > > If the standard was written with this in mind, greater<>, > less_equal<> and > greater_equal<> would have been defined in terms of less<>. It is not > reasonable to provide four customization points that the user is > supposed to > keep in sync. For me the fact that less_equal returns x <= y is strong > evidence that it is not supposed to be a customization point, but a > function > object alias of operator<=. You can make the same arguments that operator < is not intended to be a customization point because the compiler doesn't automatically provide a consistent >, >=, <= (and == and !=). The standard is a legacy that must be dealt with - this should be done by providing a consistent set of rules and then lobbying for how the standard should change to be compliant. Ideally the rules should be as consistent with the standard as possible, but the important thing is that we are always striving for a correct solution. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > Why should it be special? If a type K is ordered, pair<K, int> > should also > be. That isn't true for T*. I contend that either both should have operator < () defined or neither. I believe for shared_ptr is is probably best to try to be consistent with T* then to lobby to get T* changed. Note that this likely still means that you want to define std::less on pair<> to be less of each of the elements. Either way, the standard is flawed. Sean

3 2

Re: [boost] [BGL] Add edge with vertex' properties instead ofvertex descriptors
by Wang Weiwei 15 Jul '06

15 Jul '06

> >On Jul 14, 2006, at 10:54 AM, Wang Weiwei wrote: > >> Hello, >> >> I have a graph type as follows: >> >> namespace boost >> { >> enum vertex_flag_t { vertex_flag = 111 }; >> BOOST_INSTALL_PROPERTY(vertex, flag); >> } >> >> typedef boost::adjacency_list<boost::vecS, boost::vecS, >> boost::undirectedS, >> property<vertex_name_t, std::string, >> property<vertex_flag_t, bool, >> property<vertex_color_t, default_color_type> > >, >> no_property> graph_t; >> >> graph_t g; >> >> That means I want to associate a string as name, a flag, and a >> default color to each vertex of my graph, >> now I want to add edges to my graph directly using the vertex' >> properties instead of their descriptors, >> e.g. >> >> boost::add_edge("vertex1", "vertex2", g); >> >> How can I accomplish this? > >You'll need to create a separate mapping from vertex names to vertex >descriptors: > > std::map<std::string, graph_t::vertex_descriptor> name_to_vertex; > > Doug I've made the following template function to do the jod I want, as indicated by its name - add vertices using their properties. template<typename InputPropIterator, typename Graph, typename VertexPropMap> //// AddVerticesByProp(InputPropIterator first, InputPropIterator last, Graph& g, VertexPropMap& pmap, //// typename std::map< typename std::iterator_traits<InputPropIterator>::value_type, typename boost::graph_traits<Graph>::vertex_descriptor >& Prop2VertexMap) { typedef boost::graph_traits<Graph>::vertex_descriptor vertex_t; typedef std::iterator_traits<InputPropIterator>::value_type prop_t; typedef std::map<prop_t, vertex_t> prop_vertex_map_t; for(; first != last; ++last) { prop_vertex_map_t::iterator pos; bool inserted; vertex_t v; boost::tie(pos, inserted) = Prop2VertexMap.insert(std::make_pair(*first, vertex_t())); if(inserted) { v = add_vertex(g); pmap[v] = *first; pos->second = v; } else { v = pos->second; } } } I suppose it could more elegant if one can remove the template param 'VertexPropMap' and the corresponding function param 'VertexPropMap& pmap', because the type 'VertexPropMap' is determined and should be derived (I think) if the other 2 types are given. To be clearer, the VertexPropMap is a map from 'typename std::iterator_traits<InputIterator>::value_type' to 'typename boost::graph_traits<Graph>::vertex_descriptor'. Similarly, as far as internal property map is concerned, the function param 'pmap' is also determined and should be derived (I think) from 'g' and type info gien by the InputPropIterator. What I need now is any help that can eliminate these 2 param's to make the funtion interface not so tedious. Thanks. Max

1 0

Interest? Virtual preprocessor functions and more
by Matt Calabrese 15 Jul '06

15 Jul '06

This email actually introduces a few different concepts, so at least skim the following paragraphs if the first couple of topics don't capture your interest. As a summary, I am introducing manipulatable preprocessor function and function template descriptions, a macro which automatically generates a "result" template for use with result_of that does not rely of typeof (based off of such function descriptions), the possibilty of macros which use function descriptions to generate tempalte metafunctions which can yield if a function object call is ambiguous or if there is no match for provided parameter types, and finally an "object" concept for preprocessor metaprogramming which allows for simulation of "virtual" or "overloaded" macros which could potentially be used to join Boost.Preprocessor containers by "overloaded" macros, allowing for fewer named preprocessor macros exposed to the user and opens the possibilty up for more generic preprocessor algorithms. _____ Preprocessor function descriptions: While developing my current library, I had to come up with a way to describe functions, member functions, function templates, and member functions in such away that they could be examined and manipulated easily by the preprocessor, ideally all with the same generic code. Such descriptions contain named template parameters in the case of a template, a specifier, a return type, named function parameters, and a qualifier in the case of member functions. Using macros, programmers can then easily change the name of the function, change the return type, transform paramters in order to change their types and/or name, and automatically generate function headers. First, is there any interest for such macros outside of use from my library. For clarity, usage is as such: // where int isthe return type, test is the name, float left is the first parameter, and float right is the second parameter #define A_FUNCTION BOOST_FUN( (int), test, ((float),left)((double),right) ) BOOST_FUN_IMPL_HEADER( A_FUNCTION ) { return static_cast< int >( left + right ); } Uses for this primarily include things such as automatic creation of forwarding functions which may alter parameter types, but also allow for several more interesting applications. ___________ That brings me to perhaps a more common use. Using this little sublibrary of functions, I am making a result template generator for function objects which allows a user to very easily create a result metafunction which is automatically defined, without the need for typeof. For instance: struct fun_obj { BOOST_RESULT( ( BOOST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_CONST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_MEM_FUN_T( ((typename),L)((typename),R), (float), operator (), ((L),left)((R),right) ) ) ) // rest of object body }; // result is equal to float typedef result_of< fun_obj( float, float ) >::type result; ____________ Going further, a macro could easily be created which also produces a metafunction that tells you if a function object call is ambiguous, and a macro could be created which produces a metafunction which tells you if a function object call has no matches for the provided argument types. Such metafunctions could potentially improve error reporting, particularly for forwarding functions. ___________ Finally, if none of that is of immediate interest, the underlying mechanism for all of this may be. What I do in order to get polymorphic behavior for different kinds of functions (normal functions, member functions, and templates), is I use a form of object system. The concept is simple, but is applicable to a large amount of areas in preprocessor metaprogramming, and I offer it as a potential fundamental change to the way Boost.Preprocessor is interfaced with by simulating macro overloading, allowing for fewer named functions but with the same functionality and for more simple creation of generic preprocessor algorithms. The concept is simply this: An object is represented by the form ( OBJECT_ID, (object_data) ) Where OBJECT_ID is a unique "type" for the object and object_data is the internal implementation fo the container. The way it works is you "construct" an object by calling a macro which takes in the data and assembles it into the object representation just described, then, internally when calling overloaded" macros arguments are forwarded to a macro which internally concatenates the function name to the OBJECT_ID and forwards the arguments once more along with the internal representation of the object. The result is a seemingly "overloaded" or "virtual" macro. As an example of how this could be extremely useful for Boost.Preprocessor is it allows for an easy way to represent consistent container concepts. For instance, as Boost.Preprocessor stands, common container operations for arrays and sequences use different names, making it difficult to work with containers generically as you would in the STL or even in MPL. However, this could all be changed, and done so by merely building on top of code that is already there. As an example, here is a BOOST_PP_FRONT macro that works with either BOOST_PP_ARRAYs or BOOST_PP_SEQs (and could be easily be made to work with lists as well). // Seq constructor #define BOOST_PP_SEQ( seq ) ( BOOST_PP_SEQ_OBJ, (seq) ) // Seq FRONT implementation #define BOOST_PP_SEQ_OBJ_FRONT( seq ) BOOST_PP_SEQ_HEAD( seq ) // Array constructor #define BOOST_PP_ARRAY( size, tuple ) ( BOOST_PP_ARRAY_OBJ, ((size,tuple)) ) // Array FRONT implementation #define BOOST_PP_ARRAY_OBJ_FRONT( array ) BOOST_PP_ARRAY_ELEM( 0, array ) // FRONT implementation #define BOOST_PP_FRONT( obj ) BOOST_PP_NULLARY_VFUN( obj, FRONT ) // And here is how the code is used: #define SOME_ARRAY BOOST_PP_ARRAY( 5, (a,b,c,d,e) ) #define SOME_SEQ BOOST_PP_SEQ( (a)(b)(c)(d)(e) ) int main() { // int a; int BOOST_PP_FRONT( SOME_ARRAY ); // a = 5; BOOST_PP_FRONT( SOME_SEQ ) = 5; } __________ Of course, front is a simple operation, but the same technique can be used to join all common container operations. For instance, a generic BOOST_PP_FOR_ALL macro could be made as well as generic transformation algorithms, etc. No longer would you have to be concerned about which preprocessor container types you are dealing with and you don't have to explicitly append the container name to container macros. With this functionality, Boost.Preprocessor could be described in a much more familiar sense to generic C++ programmers, through concepts, models, and overloaded macros. -- -Matt Calabrese

3 2

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

15 Jul '06

>On Fri, 14 Jul 2006 11:33:22 -0300, Wang Weiwei <wwwang(a)ccsdl.org> wrote: > >> >>> 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 >> >> 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. > >I don't know what's wrong. I just downloaded the file and WinRAR opens it >correctly. > >Bruno > Hello Bruno, Mmmm, :-( Whould you mind email a copy to me directly? Thanks Max

1 0

Re: [boost] [BGL] Add edge with vertex' properties instead ofvertex descriptors
by Wang Weiwei 15 Jul '06

15 Jul '06

> >On Jul 14, 2006, at 10:54 AM, Wang Weiwei wrote: > >> Hello, >> >> I have a graph type as follows: >> >> namespace boost >> { >> enum vertex_flag_t { vertex_flag = 111 }; >> BOOST_INSTALL_PROPERTY(vertex, flag); >> } >> >> typedef boost::adjacency_list<boost::vecS, boost::vecS, >> boost::undirectedS, >> property<vertex_name_t, std::string, >> property<vertex_flag_t, bool, >> property<vertex_color_t, default_color_type> > >, >> no_property> graph_t; >> >> graph_t g; >> >> That means I want to associate a string as name, a flag, and a >> default color to each vertex of my graph, >> now I want to add edges to my graph directly using the vertex' >> properties instead of their descriptors, >> e.g. >> >> boost::add_edge("vertex1", "vertex2", g); >> >> How can I accomplish this? > >You'll need to create a separate mapping from vertex names to vertex >descriptors: > > std::map<std::string, graph_t::vertex_descriptor> name_to_vertex; > > Doug Hello, Doug, Yes, I also got the right way from the BGL book. The main reason I ask this question here is that I hope/guess there may be a more BGL-native way to do this, with it in mind that I'm not very familiar with the whole library. Thank you very much. Max

1 0

[date_time] posix_time::ptime assignability
by Gennaro Prota 15 Jul '06

15 Jul '06

Hi, the date_time library docs (posix_time.html) state: "The class boost::posix_time::ptime is the primary interface for time point manipulation. In general, the ptime class is immutable once constructed although it does allow assignment." Looking at the code it doesn't seem to me it allows assignment. Am I missing something? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

2 3

Re: [boost] Tuples and Bind problem
by Arash Partow 14 Jul '06

14 Jul '06

Hi Peter, thanks for your help, I'm one step closer to what I've been trying to accomplish and that is to be able use bind's within threads, the problem it seems is that bind doesn't like classes that implement the noncopyable interface. Would you have any idea on how to resolve such an issue? My code is as follows: template <typename T,int i> class select { public: typedef typename boost::tuples::element<i,T>::type result_type; template <typename U> result_type operator()(const U& u) const { return u.get(); } }; inline void do_something(const int i, const int j) { for(unsigned int x = 0; x < 1000; x++) { std::cout < param_set; std::vector<param_set> list; list.push_back(param_set(1,2)); list.push_back(param_set(2,3)); list.push_back(param_set(3,4)); boost::thread_group thrd_grp; std::for_each(list.begin(), list.end(), boost::bind(&boost::thread_group::create_thread,thrd_grp, boost::bind(&do_something, boost::bind(select<param_set,0>(),_1), boost::bind(select<param_set,1>(),_1)))); thrd_grp.join_all(); return true; } Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net Peter Dimov wrote: Arash Partow wrote: > > Hi all, > > > > I'm having some difficulties getting the following piece of code to > > compile: > > > > > > #include <iostream> > > #include <vector> > > > > #include <boost/utility.hpp> > > #include <boost/bind.hpp> > > #include <boost/tuple/tuple.hpp> > > > > > > class AClass > > { > > public: > > AClass(){} > > void b(int i, int j, int k) > > { > > std:: cout << "a::b() - " < > std::endl; } > > }; > > > > template <typename T,int i> class select > > { > > public: > > typedef typename boost::tuples::element<i,T>::type result_type; > > > > template <typename U> > > result_type operator()(const U& u) const The simpler result_type operator()(const T& u) const ought to work, too. > > { > > return u.get(); You might need u.template get(); here depending on the compiler. > > } > > > > }; > > > > int main(int argc, char* argv[]) > > { > > typedef boost::tuples::tuple<AClass,int,int,int> param_set; > > > > std::vector<param_set> list; > > list.push_back(param_set(AClass(),1,2,3)); > > list.push_back(param_set(AClass(),2,3,4)); > > list.push_back(param_set(AClass(),3,4,5)); > > list.push_back(param_set(AClass(),4,5,6)); > > list.push_back(param_set(AClass(),5,6,7)); > > > > std::for_each( > > list.begin(), > > list.end(), > > boost::bind(&AClass::b, > > boost::bind(select<param_set,0>(),_0), There is no placeholder named _0, they start at _1. > > boost::bind(select<param_set,0>(),_1), > > boost::bind(select<param_set,0>(),_2), > > boost::bind(select<param_set,0>(),_3))); You don't have enough arguments to use _2 or _3 as for_each only passes one. Instead of trying to get<0> the first element of the four tuples _0.._3, you need to get<0..3> the four elements of the one tuple _1. boost::bind(select<param_set,0>(),_1), boost::bind(select<param_set,1>(),_1), boost::bind(select<param_set,2>(),_1), boost::bind(select<param_set,3>(),_1)));

2 1