November 2004 - Boost - lists.boost.org

RE: [boost] preprocessor fix
by Arias Brent-P96059 24 Nov '04

24 Nov '04

I can't allow the boost mailing to pour into my work account over the holidays, so I'm unsubscribing. However, I'd like to continue our conversation - I guess offline if thats ok. I'll want to ask about updates to Besser's printable enum for starters. My e-mail is panoply(a)att.net By the way, what other portions of Boost have you contributed to besides preprocessor programming? Remember, I will have already unsubscribed before you can respond to this letter - so if you respond, please respond to the e-mail I provided. Thanks, -Brent -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Paul Mensonides Sent: Tuesday, November 23, 2004 6:53 PM To: boost(a)lists.boost.org Subject: RE: [boost] preprocessor fix > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Arias Brent-P96059 > > Have you seen > http://www.cuj.com/documents/s=8470/cujboost0306besser/? > > > Yes, I have seen that before. I did not use it for several > reasons: (1) I think the source for Besser's ENUM was not > easily available, (2) my employer gets nervous when code > "looks" too C++ oriented and gets nervous when macros become > too "involved" - which means "lengthy" (3) Besser's ENUMX > macro requires that you specify the number of parameters > (e.g. ENUM3 or ENUM23). I believe that he got rid of that (really annoying) issue. At first, that code was written more like the pp-lib itself is written--repetition of macros. That almost defeats the purpose of using the pp-lib at all. The pp-lib's strength is that it provides basic interfaces that enable you to build more complex interfaces or solutions. That basic interface provides, among other things, an abstraction layer over manual repetition of macros--so clients don't have to do it. Later on, I think that the code changed to using sequences. > Reason #3 was a real hurdle for me - because I'm trying to > provide this macro to other developers who might "rebel" if > using the macro requires from them non-intuitive new concepts > or exercises. That is, if they didn't have to count the > number of parameters in the enumeration before - they may > well reject the ENUM macro if it starts to require them to > count the entries. I definitely understand that. > So, I set out to make an ENUM macro that (1) didn't need its > entries counted by the developer and (2) had a short > definition (which makes it less daunting for "managment" buy-in). I understand that as well. :( > You said: > > >there are still basic notions of computation, etc., such as control > >flow--which is nothing but a conditional "invocation" > >of its accompanying code. Those kinds of things still apply at the > >preprocessor level. What you really needed was a way to > conditionally > >enumerate some sequence elements, not enumerate a > conditional sequence. > > My implementation was "backwards" because I was unable to > make the code compile otherwise. That is, depending on the > value of ENUMS, the following code did not compile: Sorry, I'm getting way too used to variadics. If SEQ_ENUM generates more than one comma-separated element, then the comma will interfere with the internals of EXPR_IIF. E.g. #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define EXPR_IIF(bit, expr) PRIMITIVE_CAT(EXPR_IIF_, bit)(expr) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr #define COMMA() , EXPR_IIF(0, a COMMA() b) EXPR_IIF(1, a COMMA() b) Both of these invocations will (i.e. "should") fail. For 'expr', EXPR_IIF gets the argument "a COMMA() b". That is fine because it is a single argument. However, macro arguments (by default) are expanded _before_ they replace the formal parameter instances in the replacement list. The argument "a COMMA() b" expands to "a , b". With that, the expansion procedes as follows: EXPR_IIF(0, a COMMA() b) 0 -> 0 a COMMA() b -> a , b -> PRIMITIVE_CAT(EXPR_IIF_, 0)(a , b) -> EXPR_IIF_0(a , b) // error: too many arguments The same thing occurs if 'bit' is 1, and that is what is occuring with EXPR_IIF and SEQ_ENUM. BTW, an argument that expands to include open commas (i.e. it becomes more than one argument when passed again) is called (by me) an "intermediate". Dealing with intermediates is one of the major reasons why the pp-lib source is as hacked up as it is because many preprocessors don't do the expansion order correctly. Using intermediates requires that a single argument become some known number of arguments at a fairly particular time. BTW2, for anyone that may be interested, placemarkers (which is, in essence, C99 uses to deal with empty arguments) can be used to prevent argument expansion pretty much indefinitely. E.g. #define A(x) B(x) #define B(x) C(x) #define C(x) D(x) #define D(x) x A(x) Here 'x' gets scanned for macro expansion once on entry to A, once on entry to B, once on entry to C, once on entry to D, and once again during the rescan of D's replacement list. It gets scanned for macro expansion a total of five times. However, #define A(p, x) B(, p ## x) #define B(p, x) C(, p ## x) #define C(p, x) D(, p ## x) #define D(p, x) p ## x A(, x) Here 'x' gets scanned once--during the rescan of D's replacement list. (You can't get rid of that one.) The point of this is optimization. Scanning preprocessing tokens for expansion can become expensive (especially when the scan is a no-op--which the preprocessor cannot assume). For example, the following code... #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) x ...has more computational power than the pp-lib. The 'x' argument gets scanned 260 times. If there was nine macros (instead of four), the scan count is in the millions. With thirteen, the scan count is in the billions. It is a sum of powers plus one scan on entry to A. If 'n' is the number of macros, and 'b' is the parametric base (i.e. the number or "M(M(M(M(M(M(..." in the replacement lists), then the scan count is 1 + the summation from k=0 to n-1 of b^k -- which can be rewritten as 1+(1-b^n)/(1 - b). [If anyone actually wants to see this in action, try this on a compliant preprocessor (such as gcc)... // file.c #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define SPLIT(i, im) PRIMITIVE_CAT(SPLIT_, i)(im) #define SPLIT_0(a, b) a #define SPLIT_1(a, b) b #define IS_NULLARY(x) \ SPLIT(0, CAT(IS_NULLARY_R_, IS_NULLARY_C x)) \ /**/ #define IS_NULLARY_C() 1 #define IS_NULLARY_R_1 1, ~ #define IS_NULLARY_R_IS_NULLARY_C 0, ~ #define EMPTY() #define EAT(x) #define IIF(bit) PRIMITIVE_CAT(IIF_, bit) #define IIF_0(t, f) f #define IIF_1(t, f) t #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) E(E(E(E(E(E(x)))))) #define E(x) x #define KILL(x) x #define IS_ALIVE() IS_NULLARY(KILL(())) #define TEXT(t) \ IIF(IS_ALIVE())(TEXT_A, EAT)(t) \ /**/ #define TEXT_A(t) t TEXT_B EMPTY()()(t) #define TEXT_B() TEXT KILL( A( TEXT( Boost ) ) ) gcc --pedantic -x c++ -std=c++98 -E -P file.c ...this generates 'Boost' more than 1500 times. A word of warning: don't actually do this in real code, especially with something that generates lots and lots of scans because even though 't' (called, by me, an "active argument") eventually stops expanding (referred to, by me, as "reaching a terminal state") the preprocessor still performs the scans (etc.)--even though the scans might be no-ops. Scanning, for example, the single preprocessing token + billions of times (and the invocations required to generate those scans) is no small operation--in fact, it takes a *really* *really* *really* long time to generate a single + if you don't run out of memory first (which you probably will).] Obviously, scanning itself can become expensive. It is interesting that the most important benefit of placemarkers may well be that it provides a means to prevent argument expansion rather than providing the means to pass empty arguments (which is also very useful). > > #define ENUM(name, start, entries) \ > > BOOST_PP_EXPR_IIF(ENUMS)( \ > > BOOST_PP_SEQ_ENUM( \ > > (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ > > BOOST_PP_SEQ_TAIL(entries) \ > > (LAST_ ## name } name;) \ > > ) \ > > ) \ > You said: > > >You can do it, but EXPR_IIF does not lazily evaluate its > argument (the > >syntax above is what EXPR_IIF would look like if it *did* lazily > >evaluate it argument). > >In other words, when ENUMS is 0, SEQ_ENUM will still be invoked, but > >its results will be discarded. > > I'm not sure what you are suggesting. Depending on the value > of ENUMS, the code snippet I showed above would not compile - > lazy evaluation or not. If it won't compile, then there's > nothing for me to ponder (except to use a different approach > - which happily you taught me with the TUPLE_EAT macro). :) Apologies. I was thinking about EXPR_IIF with variadics. With variadics, you can, ala: #define EXPR_IIF(bit, ...) PRIMITIVE_CAT(EXPR_IIF_, bit)(__VA_ARGS__) #define EXPR_IIF_0(...) #define EXPR_IIF_1(...) __VA_ARGS__ E.g. here the number of arguments doesn't matter. If, on the other hand, EXPR_IIF did lazy evaluation, then you can still do it without variadics: #define EXPR_IIF(bit) PRIMITIVE_CAT(EXPR_IIF_, bit) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr syntax: EXPR_IIF(bit)(expr) Here, 'expr' doesn't get expanded at all if 'bit' is 0. The side-effect of lazy evaluation is that the argument is not passed on (internally) to another macro, which means that the situation that occurs in the pp-lib-style EXPR_IIF (the first one above) cannot occur. I could redesign EXPR_IIF (etc.) using the "EXPR_IIF(bit)(expr)" form. That would allow the code to work. I still couldn't guarantee lazy evaluation, of course, because preprocessors are terrible in general. However, if I do so, I open an encapsulation hole in the workarounds for various preprocessors. Granted, there are many of those already--the pp-lib cannot actually "fix" broken preprocessors after all--but client exposure is minimized. Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Merge of RC_1_32_0 with trunk?
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Miércoles, Noviembre 24, 2004 6:00 pm Asunto: Re: [boost] Re: Merge of RC_1_32_0 with trunk? > Joaquín Mª López Muñoz writes: > > OK. A note of warning, though: during the last days before the > release,> Aleksey commited some changes to the docs directly in > the branch. These > > changes affect: > > > > 1. The main page (portions of the release notes) > > 2. The MPL docs > > 3. Boost.MultiIndex (some docs pages) > > 4. Other libraries? > > > > I'm sure Aleksey'll take care of 1 and 2, > > I'm going to take care of everything. > Oh, I'm afraid I've already done the job for multi_index :( So, you can safely skip that library. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 24 Nov '04

24 Nov '04

1.32 didn't make a difference. Thanks for the suggestion though. -----Original Message----- From: Tim Laplaca Sent: Wednesday, November 24, 2004 12:39 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and > after > spawning 283 or so threads, it stops running and 'Aborted' is > printed. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 24 Nov '04

24 Nov '04

I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and > after > spawning 283 or so threads, it stops running and 'Aborted' is > printed. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[serialization] Enhanced Documentaiton for Argument Dependent Lookup?
by Jeff Flinn 24 Nov '04

24 Nov '04

Robert, The release notes page makes reference to: Differences from Draft #20 - Support for Argument Dependent Looup for serialization override invocations. - Enhanced documentation to help explain usage of the above. Where might this be found? A link here would be useful. Note: the misspelling of Lookup above is in the page. Thanks, Jeff

2 3

[graph] non-recursive version of undirected_dfs
by Synge Todo 24 Nov '04

24 Nov '04

Dear Boosters, I'm posting a non-recursive version of undirected_dfs, which should have advantages in space and time over the current implementation based on recursion, especially for huge graphs. It's a direct counterpart of the non-recursive version of depth_first_search for digraphs. I have confirmed that libs/graph/example/undirected_dfs.cpp as well as my own programs using undirected_dfs reproduce the identical outputs as those with the original recursive version. Best regards, Synge *** boost/graph/undirected_dfs.hpp 6 Aug 2004 05:02:41 -0000 1.1.1.1 --- boost/graph/undirected_dfs.hpp 19 Aug 2004 05:11:32 -0000 1.2 *************** *** 28,38 **** --- 28,106 ---- #define BOOST_GRAPH_UNDIRECTED_DFS_HPP #include <boost/graph/depth_first_search.hpp> + #include <vector> namespace boost { namespace detail { + // Define BOOST_RECURSIVE_DFS to use older, recursive version. + // It is retained for a while in order to perform performance + // comparison. + #ifndef BOOST_RECURSIVE_DFS + + template <typename IncidenceGraph, typename DFSVisitor, + typename VertexColorMap, typename EdgeColorMap> + void undir_dfv_impl + (const IncidenceGraph& g, + typename graph_traits<IncidenceGraph>::vertex_descriptor u, + DFSVisitor& vis, + VertexColorMap vertex_color, + EdgeColorMap edge_color) + { + function_requires<IncidenceGraphConcept<IncidenceGraph> >(); + function_requires<DFSVisitorConcept<DFSVisitor, IncidenceGraph> >(); + typedef typename graph_traits<IncidenceGraph>::vertex_descriptor Vertex; + typedef typename graph_traits<IncidenceGraph>::edge_descriptor Edge; + function_requires<ReadWritePropertyMapConcept<VertexColorMap,Vertex> >(); + function_requires<ReadWritePropertyMapConcept<EdgeColorMap,Edge> >(); + typedef typename property_traits<VertexColorMap>::value_type ColorValue; + typedef typename property_traits<EdgeColorMap>::value_type EColorValue; + function_requires< ColorValueConcept<ColorValue> >(); + function_requires< ColorValueConcept<EColorValue> >(); + typedef color_traits<ColorValue> Color; + typedef color_traits<EColorValue> EColor; + typedef typename graph_traits<IncidenceGraph>::out_edge_iterator Iter; + typedef std::pair<Vertex, std::pair<Iter, Iter> > VertexInfo; + + std::vector<VertexInfo> stack; + + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + stack.push_back(std::make_pair(u, out_edges(u, g))); + while (!stack.empty()) { + VertexInfo& back = stack.back(); + u = back.first; + Iter ei, ei_end; + tie(ei, ei_end) = back.second; + stack.pop_back(); + while (ei != ei_end) { + Vertex v = target(*ei, g); + vis.examine_edge(*ei, g); + ColorValue v_color = get(vertex_color, v); + EColorValue uv_color = get(edge_color, *ei); + put(edge_color, *ei, EColor::black()); + if (v_color == Color::white()) { + vis.tree_edge(*ei, g); + stack.push_back(std::make_pair(u, std::make_pair(++ei, ei_end))); + u = v; + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + tie(ei, ei_end) = out_edges(u, g); + } else if (v_color == Color::gray()) { + if (uv_color == EColor::white()) vis.back_edge(*ei, g); + ++ei; + } else { // if (v_color == Color::black()) + ++ei; + } + } + put(vertex_color, u, Color::black()); + vis.finish_vertex(u, g); + } + } + + #else // BOOST_RECURSIVE_DFS + template <typename IncidenceGraph, typename DFSVisitor, typename VertexColorMap, typename EdgeColorMap> void undir_dfv_impl *************** *** 69,74 **** --- 137,145 ---- } put(vertex_color, u, Color::black()); vis.finish_vertex(u, g); } + + #endif // ! BOOST_RECURSIVE_DFS + } // namespace detail template <typename Graph, typename DFSVisitor,

2 2

[Boost-bugs] [ boost-Bugs-1072605 ] condition variables and recursive_mutex
by SourceForge.net 24 Nov '04

24 Nov '04

Bugs item #1072605, was opened at 2004-11-24 09:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: condition variables and recursive_mutex Initial Comment: Hello - I've been working through the Boost.Threads example code, I'm new to the library, but i think i found a bug in the monitor.cpp example (boost_1_31_0/libs/thread/example/monitor.cpp) . When run using a recursive_mutex, the program hangs more often than not. It appears that the cuplrits are the calls to cond.wait(lk). For the recursive_mutex case, it appears that in some circumstances, these fall through without actually waiting for a change in the state of the lock lk. Attached is an example which is somewhat simpler that the one in monitor.cpp, but yields the same problem. Note that I'm compiling on a redhat ws3 system, with: Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) and linking against libboost_thread-gcc-mt.so Typical output as given is: sent 100, received 100 sender waits 99, receiver waits 49944 I.e. close to 50k calls to cond.wait() in the receiver thread) When recompiling with "recursive_mutex" replaced by "mutex", the number of waits is on the order of the number of receives (i.e. in the range 0-100) Any help/insight is appreciated. Regards, Bill Moser billm(a)ll.mit.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Named params lib review
by Gennadiy Rozental 24 Nov '04

24 Nov '04

Hi, Recently I became quite fond of interfaces with named parameters. I developed variety of different solutions with different trade-off and set of features. At first here is couple notes from my experience: 1. In most cases multiargument interface are not in high performance critical areas. 2. In many cases it's constructors. Now lets delve in more detailed discussion on: Design =============== I. Active vs. passive I found that there are two major branched in designs for named parameters: "active" parameters collection and "passive" one. Submitted library is a variation of "passive" solution: one need to call "get" method to retrieve any parameter from collection: template<typename Params> void foo( Params const& p ) { std::string name = p[name]; std::string description = p[descr]; ... } An "active" solutions automatically place parameters in appropriate slots by single 'apply' call: class A { public: template<typename Params> A( Params const& p ) { p.apply( *this ); } }; Even though "active" solutions in some cases provide an interface look more natural. I found that "passive" solution in most cases more flexible and easier to implement. While in both cases one may employ runtime polymorphism, with "passive interfaces it's more natural. Note that parameter may not necessary is just a simple value, it maybe some kind of optional feature and 'apply' method maybe not so trivial and even invoke some functions. All in all both design seems to have heir advantages and I believe we need to provide support for both flavors. II Interfaces a) Call interface and parameters combining IMO with some very rare exclusions (1/2 optional parameter) the named parameter framework shouldn't require/expect multiple overloading of target function with different number of parameters. As well as any "impl" functions. The only acceptable interface is the one with single Params template parameters (in some cases one may provide positional interface as well, though it's rather exclusion case). This is applicable both to active and passive solutions: class A { A() : ... {} template<typename Params> A( Params const& p ) : m_name( p[name] ), m_gulp( p[gulp] ) {} }; This immediately bring a need for automatic arguments combining. There are several ways to do so, depending on requirements (BWT I liked interface presented in some other post with using ',' as combine operator). b) Optional parameter support In case of active solutions there should be an interface to check presence of specific argument. Submitted solution will cause compile time error on access to non-supplied parameter. This may not be always most convenient and may not be the case at all with different implementation (runtime based) c) Default value support I specifically dislike an interfaces provided to support default values. They are unreasonably cryptic (who would remember difference between | and ||; and why | ) but also misleading since default value is actually with access brackets: what is p["abc"]? There are several alternatives. My personal preference is : int name_ = p.is_present<name> ? p[name] : "abc"; // you will need some MP trick to make it compilable or int name_ = p.is_present( name ) ? p[value] : "abc"; // this assumes runtime based implementation Active solutions doesn't have such issue. Whatever is there gets set by apply call. d) Type safety and restrictions I do not understand why wouldn't we keep data type somewhere around keyword type and require one to supply specific type during invocation.This library instead invented special mechanism of imposing restrictions. I do not believe we need that (Also my guess is that 8 out of 10 developers unfamiliar with library will be left spellbound facing this code) e) Mix of named and positional parameters I don't believe it's actually a good idea to support such mix. IMO it just adding unnecessary confusion and possible source of users errors.. Let's say I expect 2 parameters: 1. string name 2. int value. call foo( value = 5, "my_name" ) will fail, while foo( "my_name", value = 5 ) and foo( value = 5 ) won't. Too much chances to make mistake IMO. III. Implementation IMO whatever design you prefer implementation shouldn't as complex and cumbersome. Named parameters support is pretty simple task. This submission presents 1000 lines of tight MP code (and this is without numerous includes). In majority of the cases much more simple and straightforward solution is possible (with some acceptable IMO tradeoff). Following 80 lines (I think it's possible to make it even smaller would I use mpl) should basically present solution with similar tradeoff as submitted library (without default value support, but IMO it would take another 40-60 lines, just save it into keyword struct): // Library Code template<typename NP1,typename NP2> struct named_parameter_combine; template<typename T, int unique_id> struct keyword; template<typename Derived> struct named_parameter_base { template<typename NP> named_parameter_combine<NP,Derived> operator,( NP const& np ) { return named_parameter_combine<NP,Derived>( np, *static_cast<Derived*>(this) ); } }; template<typename T, int unique_id> struct named_parameter : named_parameter_base<named_parameter<T, unique_id> > { static const int id = unique_id; named_parameter( T const& v ) : m_value( v ) {} T const& operator[]( keyword<T,unique_id> const& ) const { return m_value; } T const& m_value; }; template<bool> struct selector; template<typename NP1,typename NP2> struct named_parameter_combine : named_parameter_base<named_parameter_combine<NP1,NP2> > { named_parameter_combine( NP1 const& np1, NP2 const& np2 ) : m_np1( np1 ), m_np2( np2 ) {} template<typename KW> typename KW::data_type const& operator[]( KW const& kw ) const { return selector<KW::id==NP1::id>::_( m_np1, m_np2, kw ); } NP1 const& m_np1; NP2 const& m_np2; }; template<> struct selector<true> { template<typename NP1,typename NP2,typename KW> static typename KW::data_type const& _( NP1 const& np1, NP2 const& np2, KW const& kw ) { return np1[kw]; } }; template<> struct selector<false> { template<typename NP1,typename NP2,typename KW> static typename KW::data_type const& _( NP1 const& np1, NP2 const& np2, KW const& kw ) { return np2[kw]; } }; template<typename T, int unique_id> struct keyword { typedef T data_type; static const int id = unique_id; named_parameter<T,unique_id> operator=( T const& t ) const { return named_parameter<T,unique_id>( t ); } }; //////////////////////////////////////////////////////////////// // Example: namespace test { typedef char const* c_str; keyword<c_str,1> name; keyword <float,2> value; keyword<int,3> index; double value_default() { return 666.222; } int foo( c_str name, float v, int i ) { } template<class Params> int foo(Params const& params) { foo( params[name], params[value], params[index] ); } } int main() { using test::foo; using test::name; using test::value; using test::index; foo(( index = 20, name = "foo", value = 2.5 )); return 0; } Strict type checking on top of it. This code works under gcc 3.4.2. Should work everywhere. As you may guess by now my vote is NO to accept this library. I personally wouldn't be using it in current form and IMO as it stands now it's just another collection of neat MP tricks. I do not have to much comments on docs and tests, other then they seems incomplete. Regards, Gennadiy P.S. Why is the RC branch of mpl is different from HEAD? Doesn't we supposed to fix HEAD and only then propagate to branch?

9 45

RE: [boost] Re: Boost Sandbox layout?
by Stefan Seefeld 24 Nov '04

24 Nov '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > I really wish there were a version control system with symlinks in > repository. Apparently subversion 1.1 support that: http://svnbook.red-bean.com/en/1.1/svn-book.html Regards, Stefan

1 0

how does one remove vertices from a graph
by Eyal Farago 24 Nov '04

24 Nov '04

adjacency_list documentations refers to 'stability' problems of vertex descriptors and iterators. it also provides two wrong and one correct ways to remove all vertices from a graph, trying to use the 'correct' way produced an exception from within vector::erase. after looking into the state of the iterators I understand that the 'correct' example isn't correct at all, the iterators still refers to the original offsets in the vertices vector when the current vertex is erased from the graph. i.e. suppose the graph had 7 vertices to begin with and we've already erased the first one, the iterator to current (vi in the example) should point to offset 0 and the end iterator(vi_end in the example) should point to offset 6, instead we have iterators to offsets 1 and 7. am I right? if so, what is the correct way to do it? eyal.

2 1