- Boost - lists.preview.boost.org

RE: [boost] Re: Boost.org Site Suggeswtion was [RE: Re: Adobe OpenSourceLibrary]
by Brian Braatz 03 Mar '05

03 Mar '05

Excellent Ideas! > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Robert Ramey > Sent: Thursday, March 03, 2005 8:29 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Boost.org Site Suggeswtion was [RE: Re: Adobe > OpenSourceLibrary] > > I would like to see this idea taken a little bit further. > > I would like a place where users of boost can add a line describing: > > name > organization > application > which libraries they use > general comments. > > This would be very helpful feedback as to what is getting used by whom for > what purpose. It would be useful to library authors to get a sense of > what > is being used. It would be very useful to people who are considering > downloading boost and want to know what parts have been found useful to > other people. > > Think of it as "boost" marketing. > > Robert Ramey > > > Brian Braatz wrote: > > Suggestion: > > Put something on the web site with links for projects which use > > boost > > ASL would be one of those links > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Possible solution to making boost::regex link under debug, static runtime library for .NET 2003 (VC7)
by Robert Mathews 03 Mar '05

03 Mar '05

Currently, if you try to compile a program that uses boost::regex (either boost versions 1.31 and 1.32) under the debug static runtime library(libboost_regex-vc71-sgd-1_32.lib), you'll get a bunch of multiply defined symbols something like this: LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswlower already defined in c_regex_traits.obj and so on for all of the character type macros: _iswalpha _iswupper _iswlower _iswdigit _iswxdigit _iswspace _iswpunct _iswalnum _iswprint _iswgraph _iswcntrl _iswascii This has been noticed before && stems from the fact that the inline directive is ignored for debug mode, causing those inline functions to exist both in the C runtime library and in the regex lib. I found a note going back to 2002 - http://lists.boost.org/MailArchives/boost-users/msg01398.php - which indicates that this problem is longstanding. Unfortunately, I'd like to be able to use boost::regex, and I'd like to be able to use static runtime libraries. I doubt I'm the only person who'd like be able to do that. Fortunately, the references to those macros/inlines seems to be localized to only one file, libs\regex\src\c_regex_traits.cpp, so I thought I'd try fixing that file. Digging around a bit, I modified libs\regex\src\c_regex_traits.cpp to compile and link correctly for this model. I attached the diffs below; I'm sure that there was a more elegant way, but at least this is a solution that allows the regex library to link under all runtime libraries for VC7. Maybe somebody could boostify the solution and incorporate this into the next release of the boost libraries? Thanks, Rob. --- diff follows 45a46,65 > # ifdef BOOST_MSVC > // Workaround for .NET2003 (VC7) linkage problem. > // This prevents inline functions from existing in both the static debug multithreaded unicode runtime library and in this library, a problem > // which causes link errors like: > // LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswlower already defined in c_regex_traits.obj > > #define iswalpha(_c) ( iswctype(_c,_ALPHA) ) > #define iswupper(_c) ( iswctype(_c,_UPPER) ) > #define iswlower(_c) ( iswctype(_c,_LOWER) ) > #define iswdigit(_c) ( iswctype(_c,_DIGIT) ) > #define iswxdigit(_c) ( iswctype(_c,_HEX) ) > #define iswspace(_c) ( iswctype(_c,_SPACE) ) > #define iswpunct(_c) ( iswctype(_c,_PUNCT) ) > #define iswalnum(_c) ( iswctype(_c,_ALPHA|_DIGIT) ) > #define iswprint(_c) ( iswctype(_c,_BLANK|_PUNCT|_ALPHA|_DIGIT) ) > #define iswgraph(_c) ( iswctype(_c,_PUNCT|_ALPHA|_DIGIT) ) > #define iswcntrl(_c) ( iswctype(_c,_CONTROL) ) > #define iswascii(_c) ( (unsigned)(_c) < 0x80 ) > # endif > 520,521c540,545 < lower_case_map[i] = (char)std::tolower(i); < } --- > # ifdef BOOST_MSVC > lower_case_map[i] = (char)tolower(i); > # else > lower_case_map[i] = (char)std::tolower(i); > # endif > } 915a940,967 > # ifdef BOOST_MSVC > bool BOOST_REGEX_CALL c_regex_traits<regex_wchar_type>::do_iswclass(regex_wchar_type c, boost::uint_fast32_t f) > { > BOOST_RE_GUARD_STACK > if((c & ~0xFF) == 0) > return BOOST_REGEX_MAKE_BOOL(re_detail::wide_unicode_classes[(uchar_type)c] & f); > if((f & char_class_alpha) && iswalpha(c)) > return true; > if((f & char_class_cntrl) && iswcntrl(c)) > return true; > if((f & char_class_digit) && iswdigit(c)) > return true; > if((f & char_class_lower) && iswlower(c)) > return true; > if((f & char_class_punct) && iswpunct(c)) > return true; > if((f & char_class_space) && iswspace(c)) > return true; > if((f & char_class_upper) && iswupper(c)) > return true; > if((f & char_class_xdigit) && iswxdigit(c)) > return true; > if(f & char_class_unicode) > return true; > return false; > } > > #else 940a993 > # endif // BOOST_MSVC

3 6

Boost.org Site Suggeswtion was [RE: [boost] Re: Adobe Open Source Library]
by Brian Braatz 03 Mar '05

03 Mar '05

Suggestion: Put something on the web site with links for projects which use boost ASL would be one of those links > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hartmut Kaiser > Sent: Wednesday, March 02, 2005 11:57 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: Adobe Open Source Library > > > David B. Held wrote> > > > > I just saw this on Slashdot and thought the boosters might find it > > > interesting: > > > > > > Adobe has apparently open sourced some libraries- I (very > > brief) quick > > > look shows me: > > > > > > 1- They seem to be heavily using template techniques > > > [...] > > > > That doesn't surprise me at all. If I recall, Mat Marcus > > works for Adobe and is also a big Boost advocate. > > This is from the docs of the ASL (Adobe Source Libraries): > > <quote> > ASL is being developed in C++, and relies heavily on the Boost libraries > <http://www.boost.org/> which are required for building ASL. > </quote> > > Regards Hartmut > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

RE: [boost] Re: ANN: review of FSM library starts
by Augustus Saunders 03 Mar '05

03 Mar '05

Darryl Green writes: >Why the interest in miminimizinghe effort of writing custom > reactions? They are a bit of a low level access method, and result > (in less trivial, non-ininlinexamples) in hiding what the > transitions destination state is. Normally, you wouldn't use many > custom reactions. HmHmmI'm getting the feeling that I need to completely disregard the tutorial and sample code and try and actually write my own code, just relying on the reference manual. I was under the impression that custom reactions were basically event handlers, and that you effectively wind up with this processing chain: Event Happens -> custom reaction -> current state exit handler -> new state entrance handler. The idea being that over-literal seseparationf states (so that all handling is done in entrance/exit handlers) is too tedious. I guess, then, I'm confused about their purpose. >I'm not seeing what there is that I would want hidden. What do you > think needs hiding? >> I think it's a distraction. Sure, it's great that you've got this >> nice cocorrespondanceith UMUMLbut that's unimportant *in the >> tutorial*. Mention it on the about page, have an appendix all >> about it, go into detail in the references, etc. > I disagree. There needs to be some model, language etc to base the > tutorial description on. You have already said that you don't think > writing a guide to FSFSMss the right thing to do. There are any > number of books and even a standard ;-) that describe the UMUMLSFSM> concepts so that Andreas doesn't need to. It would have been > possible to pick some other complex FSFSMescription language, but > UMUMLs supposed to be universal, and gets plenty of books, tools, > courses etc built around it, so why not use it? Hold on, I think you're reading a bit much into what I'm saying. I don't give rip how you graphically represent the FSFSMs The pictures in the current tutorial are great. People who are familiar with state machines at all will understand the pretty pictures. So go nuts, use UMUMLiagrams until you're blue in the face :) However, in the tutorial, don't mention it. People who know UMUMLill instantly recognize it, other people won't care. People who specifically care about UMUMLocompatibilityeserve their own appendix or section in the reference manual with a point by point breakdown of what is and is not supported from UMUMLomenclature. Scanning through the tutorial, I don't see any terminology that strikes me as UMUMLpecific. In short, as far as I can tell, the UMUMLocorrespondences a detail of little consequence when reading the tutorial. >Ah. So you probably want an example that is a rerecogniseror some > regular language. Sure, but not too complicated. > I'd be very susuprisedf this was an area where boost fsfsms a good > choice, it would be interesting to see how you go. Also, if you want > to coconstuctsfsmso do this sort of thing quickly and easily, > wouldn't you just use a regexp, or one of the plethora of > lexer/parser construction tools and let it figure out the tedious > details for you? I would expect (haven't got around to looking at it > yet) expressive to be just the thing for that, but spirit would do > the job too with a lot less typing than using boost fsfsm Besides the point. boost::fsfsms also not a good choice for Hello World. But if you're going to tell me that you've got a FSFSMibrary, well, I expect to see such an example. Helps me get my bearings. Anyway, boost::fsfsms compile time only, so it's obviously not ususefulor this kind of stuff. Purely didactic purpose here. >This isn't very useful if the fsfsmses more complex event types. And >conversely the dedespatchethod used by boost fsfsms less than >spectacularly efficient if your events really are simple values. I think we might be forgetting all this was discussing the documentation. I want concise examples that A) compile and run, and B) hide pointless infrastructure. The StStopWatchpcppxample file has about 130 lines not counting comments and #includes, of which about 35-40 are pointless infrastructure. I'd like to see that example in 35 lines *total* beyond the #includes. > Think of a state as a scope. Think RARAII >If you don't have nested states then your machine is flat and you > would almost certainly have empty states and place all your actions > and data in the machine. What is the problem? You will have to convince me that persisting state across state changes is inherently unsafe or invokes undefined behavior. It seems obvious to me that you might stick counters, file handles, sockets, database connections, etc in state local storage, or my original example of window contents. To me, this is "obvious." In fact, I can't come up with an example where I *want* this stuff destroyed evevery time change state. Sticking everything on the machine is a non-solution, and creating extra levels of state-nesting and crossing your fingers that you never have to leave the parent state seems pretty error prone. I guess this is what "deep history" is for, but that seems like a lot of work, and you'd have to convince me that whatever mechanism you use for saving/rerestoringistory was safe. > What do you want the accept state to do that is so special? Nothing, really. It just seems like it should be so simple that we might as well have it for completeness's sake. It's not like there's an endless stream of different types of FSFSMso far as I see. > I'm more familiar with the use of the terms rerecogniserr scanner > rather than rereferingo the fsfsms an acceptor fsfsmbut yes, in > lnlnaguagerocessing those terms are standard. Unfortunately, I think > you are going to be disappointed if you try to use boost fsfsmn that > sort of application. Not that that wouldn't be useful review > feedback. Boost fsfsms much better for what wiwikipedianforms me > are called transducer fsfsmsa term I am unfamiliar with, but a class > of fsfsmhat I am very familiar with. Looking at the UMUMLocs, it is clearly based on the "transducer" mold. It would be nice if there were an appendix or footnote mentioning this more academic stuff. I'm guessing that there are plenty of people in my shoes, who are more familiar with the academic stuff than the UMUMLtuff. Thanks- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

2 1

Re: [boost] Re: RPC library
by Iain Hanson 03 Mar '05

03 Mar '05

On Tue, 2005-03-01 at 19:27 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > [snip] > You're absolutely right that it's in no way a replacement for CORBA, but then > its not meant to be either. I wrote it for those situations where you want > something simple and easy to use (there are many such situations, no?), where > using CORBA feels like swinging a sledgehammer at a walnut. No. CORBA is very like C++ you pay for what you use. Simple rpc schemes are a misnomer and dangerous because they don't scale and users end up re-inventing the wheel such as naming service, security etc etc. Just because you can do something does not mean you should. I would classify SOAP and your RPC lib in the clever idea but you should not do it category. /ikh

2 1

[multi_index][rfc] hashed indices, new implementation
by Joaquín Mª López Muñoz 03 Mar '05

03 Mar '05

Just a quick note to announce, for those whoe are interested in hashed indices, that I've uploaded a new implementation on the Sandbox Files arena: multi_index_030305_plus_hash_part_1.zip multi_index_030305_plus_hash_part_2.zip whit significantly less space overhead (1 pointer per node + 1 pointer per bucket, just like SGI's implementation.) Code and docs are 100% complete, comments are much appreciated before I commit this stuff to the CVS anytime soon. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Adobe Open Source Library
by Brian Braatz 03 Mar '05

03 Mar '05

I just saw this on Slashdot and thought the boosters might find it interesting: Adobe has apparently open sourced some libraries- I (very brief) quick look shows me: 1- They seem to be heavily using template techniques 2- They have a "concepts Library" -look familiar?: Assignable ConvertibleToBool ConvertibleToFunction ConvertibleToRange DefaultConstructible EqualityComparable LessThanComparable RegularType TransformFunction 3- They have a GUI Library (appears to have a similarity to the GUI discussion on this list awhile back) Anyways- I am just throwing this out there for discussion. SlashDot article: http://slashdot.org/articles/05/03/02/1449240.shtml?tid=152 Adobe Open Source Library http://opensource.adobe.com/

3 2

[Wiki] trouble restoring libraries under construction
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, I was trying to despam the Wiki, which I have done many times, but for some reason got confused (or maybe I am permanently confused). I ended up removing the spam but not restoring the previous content. It should be revision 90, I believe. Jonathan

1 0

[Boost-bugs] [ boost-Bugs-1155556 ] parse_date asserts on empty string
by SourceForge.net 03 Mar '05

03 Mar '05

Bugs item #1155556, was opened at 2005-03-02 19:27 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=1155556&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeff Garland (az_sw_dude) Summary: parse_date asserts on empty string Initial Comment: the following sample code fails with assert : (Assertion failed: valid_, file c:\dev\externallibs\boost_1_32_0\boost\token_iter ator.hpp, line 57) >>> #include <boost/date_time/posix_time/posix_time.hpp> #include <iostream> using namespace boost::gregorian; int main( int, char** ) { try { date d = from_simple_string( "" ); // never reached std::cout << to_simple_string( d ) << std::endl; } catch( std::exception & ) { // no std::exception caught ! } return 0; } >>> The error seems to be in date_time\date_parsing.hpp, line 119 : for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end(), pos < spec_str.size(); ++beg, ++pos) {... the comparison "beg!=tok.end()" has no effect because the value of the expression is only determined by "pos < spec_str.size()". Therefore the string iteration goes beyond the end of the string and...assert... The function also fails if the given string is not a complete date, ie: "2004", "2004-Jan" I changed the "," to "&&" and it seems to perform better (though i didn't run the boost regression tests). I also checked the CVS repository to confirm the bug is still there. Have a nice day ! and thanks for this great library, it is really good to develop with it. Here is my email : guillaume.souchet(a)bnpparibas.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1155556&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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: ANN: review of FSM library starts
by Augustus Saunders 03 Mar '05

03 Mar '05

I hesitate to call this a review; it's more my reactions looking through the fsm documentation and examples--I have not actually used it yet. I feel like these comments should have been given a long time ago, but I guess I missed all the pre-review discussion. I'm not an expert in this area, but I feel comfortable with the ideas and have fooled around with making my own state machines in the past. My main interest in a library like fsm lies in correctness and simplicity, not performance. Before I delve into answering the "official review questionare," I want to make some overall comments. First, it is obvious to me that this library has a lot of potential. The authors have thought through a lot of issues that I've never considered. My problems mainly lie with the syntax and documentation, and I think problems with the latter stem from the former. I'd like to see some discussion on the matter. Overall, I feel the syntax is too burdensome and the organization of code that I have to write is a hopeless mess (at least, looking at the examples). For simple cases, I really want to see a way of defining a fsm with less line noise and less indirection. I haven't thought through the ramifications, but it just seems to me that some mpl, lambda, and BOOST_TYPEOF loving should make something roughly akin to the following possible: { using namespace boost::fsm; using namespace boost::lambda; // I guess there's no way to avoid declaring // these ahead of time?? class Machine, State1, State2, Event1, Event2; struct S1Data { int i; S1Data() : i(0) {} }; typedef simple_state< Machine, S1Data, BOOST_TYPEOF( cout << constant("Entering State1.") ), BOOST_TYPEOF( cout << constant("Exiting State1.") ), on_event<Event1, BOOST_TYPEOF( _1->i++ ) >, transition<Event1, State2> > State1; // the "data" member of State1 has type S1Data, and is // passed into event handlers struct S2Data { int j; S2Data() : j(0) {} }; typedef simple_state< Machine, S2Data, BOOST_TYPEOF( cout << constant("Entering State2.") ), BOOST_TYPEOF( cout << constant("Exiting State2.") ) > on_event<Event2, BOOST_TYPEOF( _1->j++ )>, transition<Event2, State1> > State2; // the "data" member of State2 has type S2Data, and is // passed into event handlers // It seems that in the propsed fsm library, // state composition is specified bottom up, // and I'm not sure what the motivation is. // We're all used to writing classes top-down. typedef state_machine< State1, State2 > Machine; Machine m; m.initiate(); // process events while (whatever) m.process_event(blah); // I don't quite understand why state_cast is necessary // versus just overloading regular casting. cout << "State1 had Event1 called " << ((State1)m).data.i << " times." << endl; cout << "State2 had Event2 called " << ((State2)m).data.j << " times." << endl; } I'm sure I've messed up some details sine I don't really get why some of the fsm mechanisms are there. Also, I'm ignoring for the moment that member dereferencing is a little uglier with lambda, so _1->i++ would have to be (_1->* &S1Data::i)++. I assume there exists a way to make state-specific data available to a lambda expression in a clean way. I've also ignored sticking in lots of mpl::vector or mpl::lists, as it's my impression that with mpl one can iterate through the template arguments and figure out if they are events or transitions or whatever. So I smushed together the different elements, and presumed for < 10 arguments (or whatever, using PREPROCESSOR lib to configure that) the mpl::vector could be omitted. Finally, even though I've not really tested BOOST_TYPEOF, they use lambda expressions as an example, so I don't think it's entirely out of line of think that it might work. Now, I don't know if this example has really reduced the total number of characters required to be typed, but it is more clear to me. I realize that I've seperated the state data out into a seperate struct; personally, I like that. More importantly to me, I can look at those typedefs and reasonably guess what's being defined. If you made FSM_ENTER and FSM_EXIT macros to alias BOOST_TYPEOF you would make it clear what those entries were for. In general, you don't have to keep refering back and forth to the reference manual to figure out what each entry is. Looking at the examples in the tutorial just made my head spin, especially trying to figure out how states and machines get tied together (this is still unclear to me). This kind of "inline" code would be great for lots of cases where you just want to increment/decrement some counter or push/pop some variable. Maybe I'm hoping for too much magic, but I feel that at least little magic or secret sauce is needed here. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? All the other reviewers have said nice things about the documentation, but I had a lot of trouble with the tutorial. As already mentioned by others, totally targetted at the wrong people. In general, I would drop all mention of UML except for some appendix somewhere (and the reference manual too). "Getting Started" and "Target Audience" should be in a differenct document, and "How to read this tutorial" should be removed. Then, before you get into the C++ code for "Hello, World!", you should work through "Hello, World!" and maybe "StopWatch" using pseudo-code. Even if you can work out some magic like I hope for, I think you need to map out the basic process with pseudo-code, like this: // Hello World example // First, we have to declare all of our states // and events ahead of time. This is because // all states can transition to each other, // so you can't necessarily define them in order. class mystate1, mystate2, event1, event2, etc; // Next, we're going to define some states // for our machine. Each state definition // indicates what other states it transitions // to on each input, buried in "bunch_of_stuff" typedef simple_state< bunch_of_stuff > mystate; typedef simple_state< bunch_of_stuff > mystate2; // etc // Then, we're going define a machine with // states. The first listed state is the default typdef state_machine<mystate, mystate2> Machine; // etc, in this style In general, all of your "remarks" and "comments" need to be in the code! I think the example state machines are basically OK, but I think that it is absolutely essential that you include a simple example that is alphabet-based. In fact, some helper functions for alphabet-based languages are probably a good idea, just to make the tutorial easier. In particular, you should be able to create letters-as-events, and dispatch them easily. The switch statement for dispatch in the Camera example is scandalous ;) The reference manual seems ok, although I didn't really use it. The rationale tended to feel unconvincing, although I'm not well informed on the issues. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? I'm confused about why entering/exiting states causes construction / destruction. It's taken as a given, but I would tend to assume that state-local-storage is maintained throughout unless I explicitly reset it. I'm also surprised by the lack of "accept" states. Maybe it's not universal, but my theory certainly had them, and it's just disconcerting for them not to be there. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? boost::fsm is good, IMO. Don't know about seperating libraries. * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? Didn't look. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? No comment. * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? Tremendous potential. I can't compare directly to other FSM libraries/tools, but just like spirit, eliminating the need for extra tools is a great benefit. * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Looked through docs and examples, thought carefully about what I wanted, and poked around to see what might be feasible. Many hours. * Are you knowledgeable about the problem domain? Not an expert, not completely ignorant. And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I think that boost::fsm will benefit greatly from some further consideration. The Serialization library took two tries and was much improved, to good effect. I can be accused of hoping for too much "magic" syntax, but it'll take a lot of convincing that the current way is best. I'm not unreasonable, but I haven't seen any discussion on it, and Spirit, Lambda, Serialization, and others given me high expectations for usability. And lastly, thanks to all involved in bringing us boost::fsm. Despite my critique, this is first-rate work. Thanks- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

4 5

Re: Re: multi_index_container
by Wusel 03 Mar '05

03 Mar '05

Hi Joaquín M López Muñoz, thank you for your quick answer! I appreciate that multi_index_container exist and I can use it. In my opinion this library is very useful and facilitate many programs. >> 44 //version B: DOES compile >> 45 typedef index<employee_set,id >::type employee_set_by_id; >> 46 typedef index<employee_set,age>::type employee_set_by_age; > > OK, fine. > >> 48 //remove the name index (lines 31, 32) for following versions >> 49 >> 50 //version C: DOES compile >> 51 typedef index<employee_set,id >::type employee_set_by_id;; > > OK, too. > >> 52 >> 53 //version D: does NOT compile >> 54 //causes >> ...\include\boost-1_32\boost\mpl\vector\aux_\preprocessed\no_ctps\vector10.hpp(398) >> : >> 55 // error C2039: 'item3' : is not a member of >> 'boost::mpl::vector2<T0,T1>' >> 56 typedef index<employee_set,age>::type employee_set_by_age; > > !! Here I'm missing somethig... Isn't version D exactly the same > as version B, which does work? Exact this I wanted point out. Version D differs from version B in removing two lines 31, 32 only (i.e. the name index). Version C is nearly the same, too. Nevertheless there is a difference when compiling. best regards Volker Vieth

2 3

[mpl]RFE: unpack_apply
by Larry Evans 02 Mar '05

02 Mar '05

Would it be possible to add: template<typename Application> struct unpack_apply { ... }; such that: is_same < unpack_apply<f<a0,a2,...,an> >::type , vector<a0,a2,...,an> > to mpl? Maybe a better name would be get_args, but since it's so closely related to unpack_args, I thought maybe unpack_apply could be considered OK.

1 1

review of FSM nears to the end - any more reviews?
by Pavel Vozenilek 02 Mar '05

02 Mar '05

Review period of FSM library (http://boost-sandbox.sf.net/fsm.zip) nears to its end in few days. Does anyone need to extend review period? Review can be surely posted even after end of official period - I'll reserve some time for such possibility. /Pavel

8 11

Re: [boost] Re: Boost.Hash + Boost.Unordered reviews
by JOAQUIN LOPEZ MU?Z 02 Mar '05

02 Mar '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Miércoles, Marzo 2, 2005 11:49 pm Asunto: [boost] Re: Boost.Hash + Boost.Unordered reviews > Joaquín Mª López Muñoz wrote: > > This issue seems to have cooled down. Has there been > > some off-list progress, should we agree what to do here? > > No, I've been taking a small break from it. There seem to be no > real > objections to the original plan (fast-tracking Boost.Hash and > placing > Boost.Unordered in the queue), so it looks like that's the way to go. > I'm happy to know you're still on this. Looking fwd to participating in both reviews. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Iostreams Compile Issue with boost/algorithm/string.hpp was[RE: Compile problem using IoStreams from CVS inside boostv1.32 (VC71)]
by Brian Braatz 02 Mar '05

02 Mar '05

Just for giggles, I pointed my unit test code to the boost I got from CVS. Interestingly enough, it compiled with the #include <boost/algorithm/string.hpp> (but it complained about the unit test code- I am guessing there is a broken form in cvs? Or maybe I don't have something setup- when I commented out my test suite definitions- I WAS able to compile the file though) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Wednesday, March 02, 2005 2:03 PM > To: boost(a)lists.boost.org > Subject: [boost] Iostreams Compile Issue with boost/algorithm/string.hpp > was[RE: Compile problem using IoStreams from CVS inside boostv1.32 (VC71)] > > I narrowed this down a bit more- > > In my code which uses filtered_stream if I have the following headers: > > #include <boost/iostreams/concepts.hpp> > #include <boost/iostreams/operations.hpp> > #include <boost/iostreams/filtering_stream.hpp> > #include <boost/iostreams/device/file.hpp> > // #include <boost/algorithm/string.hpp> > > It compiles- but when I uncomment the #include > <boost/algorithm/string.hpp> I get the error below > > > > -----Original Message----- > > From: Brian Braatz > > Sent: Wednesday, March 02, 2005 1:34 PM > > To: 'boost(a)lists.boost.org' > > Subject: Compile problem using IoStreams from CVS inside boost v1.32 > > (VC71) > > > > I am using VC7.1 (and will also be using VC70 for this code) > > > > What I did- > > > > Executed the following from a cmd prompt: > > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login > > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost > checkout > > boost > > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout > > > > went into boost\iostreams and boost\libs\iostreams- copied both into > temp > > area- > > > > Deleted the CVS folders > > > > Copied the files into the boost 1.32 dir in my company's internal CVS > > server (we have the boost files under revision control to control > which > > version of which file we are using to build) > > > > Initially I had to change the files to from namespace io to iostreams. > Got > > through those compile errors. And Now I have this one: > > > > > > boost\algorithm\string\iterator_range.hpp(288) : error C2874: using- > > declaration causes a multiple declaration of > > 'boost::algorithm::iterator_range' > > > > \boost\algorithm\string\iterator_range.hpp(204) : see declaration of > > 'boost::algorithm::iterator_range' > > > > I am digging into this but thought I would throw this out to see if > any > > one is aware of the issue- > > > > These errors point to the end of iterator_range.hpp (pointing at the > using > > clause) > > > > Here is a snippet from that file: > > > > template< typename SeqT, typename IteratorT, typename FuncT > > > inline SeqT transform_iterator_range( const > > iterator_range<IteratorT>& Range, FuncT Func ) > > { > > SeqT Seq; > > std::transform( Range.begin(), Range.end(), > > std::back_inserter(Seq), Func ); > > return Seq; > > } > > > > } // namespace algorithm > > > > // pull names to the namespace boost > > using algorithm::iterator_range; > > using algorithm::make_iterator_range; > > using algorithm::copy_iterator_range; > > using algorithm::transform_iterator_range; > > > > } // namespace boost > > > > > > > > > > > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost.Hash + Boost.Unordered reviews
by Joaquín Mª López Muñoz 02 Mar '05

02 Mar '05

This issue seems to have cooled down. Has there been some off-list progress, should we agree what to do here? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[Boost-bugs] [ boost-Bugs-1155439 ] Correction to configuration for Sun C++
by SourceForge.net 02 Mar '05

02 Mar '05

Bugs item #1155439, was opened at 2005-03-02 14:37 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=1155439&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Correction to configuration for Sun C++ Initial Comment: The BOOST configuration files have settings for early Sun compilers that are not correct for the current compilers. (The early compilers can't compile fair-sized chunks of BOOST in any case.) We intend full support of BOOST in Sun Studio 10 (C++ 5.7) and later. I've attached diffs for the config files. There's a possible hole in these updates, however. The BOOST configuration files currently claim nothing since C++ 5.3 was tested. I am making no claims about C++ 5.4 through 5.6, but only for 5.7 and later. Steve Clamage, stephen.clamage(a)sun.com Sun C++ Project Lead ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1155439&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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Iostreams Compile Issue with boost/algorithm/string.hpp was [RE: Compile problem using IoStreams from CVS inside boost v1.32 (VC71)]
by Brian Braatz 02 Mar '05

02 Mar '05

I narrowed this down a bit more- In my code which uses filtered_stream if I have the following headers: #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/operations.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/device/file.hpp> // #include <boost/algorithm/string.hpp> It compiles- but when I uncomment the #include <boost/algorithm/string.hpp> I get the error below > -----Original Message----- > From: Brian Braatz > Sent: Wednesday, March 02, 2005 1:34 PM > To: 'boost(a)lists.boost.org' > Subject: Compile problem using IoStreams from CVS inside boost v1.32 > (VC71) > > I am using VC7.1 (and will also be using VC70 for this code) > > What I did- > > Executed the following from a cmd prompt: > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout > boost > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout > > went into boost\iostreams and boost\libs\iostreams- copied both into temp > area- > > Deleted the CVS folders > > Copied the files into the boost 1.32 dir in my company's internal CVS > server (we have the boost files under revision control to control which > version of which file we are using to build) > > Initially I had to change the files to from namespace io to iostreams. Got > through those compile errors. And Now I have this one: > > > boost\algorithm\string\iterator_range.hpp(288) : error C2874: using- > declaration causes a multiple declaration of > 'boost::algorithm::iterator_range' > > \boost\algorithm\string\iterator_range.hpp(204) : see declaration of > 'boost::algorithm::iterator_range' > > I am digging into this but thought I would throw this out to see if any > one is aware of the issue- > > These errors point to the end of iterator_range.hpp (pointing at the using > clause) > > Here is a snippet from that file: > > template< typename SeqT, typename IteratorT, typename FuncT > > inline SeqT transform_iterator_range( const > iterator_range<IteratorT>& Range, FuncT Func ) > { > SeqT Seq; > std::transform( Range.begin(), Range.end(), > std::back_inserter(Seq), Func ); > return Seq; > } > > } // namespace algorithm > > // pull names to the namespace boost > using algorithm::iterator_range; > using algorithm::make_iterator_range; > using algorithm::copy_iterator_range; > using algorithm::transform_iterator_range; > > } // namespace boost > > > > > >

1 0

Compile problem using IoStreams from CVS inside boost v1.32 (VC71)
by Brian Braatz 02 Mar '05

02 Mar '05

I am using VC7.1 (and will also be using VC70 for this code) What I did- Executed the following from a cmd prompt: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout went into boost\iostreams and boost\libs\iostreams- copied both into temp area- Deleted the CVS folders Copied the files into the boost 1.32 dir in my company's internal CVS server (we have the boost files under revision control to control which version of which file we are using to build) Initially I had to change the files to from namespace io to iostreams. Got through those compile errors. And Now I have this one: boost\algorithm\string\iterator_range.hpp(288) : error C2874: using-declaration causes a multiple declaration of 'boost::algorithm::iterator_range' \boost\algorithm\string\iterator_range.hpp(204) : see declaration of 'boost::algorithm::iterator_range' I am digging into this but thought I would throw this out to see if any one is aware of the issue- These errors point to the end of iterator_range.hpp (pointing at the using clause) Here is a snippet from that file: template< typename SeqT, typename IteratorT, typename FuncT > inline SeqT transform_iterator_range( const iterator_range<IteratorT>& Range, FuncT Func ) { SeqT Seq; std::transform( Range.begin(), Range.end(), std::back_inserter(Seq), Func ); return Seq; } } // namespace algorithm // pull names to the namespace boost using algorithm::iterator_range; using algorithm::make_iterator_range; using algorithm::copy_iterator_range; using algorithm::transform_iterator_range; } // namespace boost

2 1

Resigning from Boost.Profiler
by christopher diggins 02 Mar '05

02 Mar '05

I am going to have to stop development of Boost.Profiler. IMO there is still a huge gap between where it is and where it would have to go to be both robust and simple enough to be appropriate for Boost. Honestly I don't see it happening without a more robust and portable high_resolution_timer, which requires far more time and energy than I am willing to commit. Where is the best place to upload my current snapshot, so that others can take over if they want? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

2 2

RE: [boost] Re: RPC library
by Brian Braatz 02 Mar '05

02 Mar '05

> > "Jarl Lindrud" wrote: > > > > > I've written a library for doing portable C++ RPC's, which can be > > > downloaded at > > > > > > http://www.codeproject.com/threads/RMI_For_Cpp.asp > > > > > > Is there any interest in Boost for something like this, and if so in > what [Brian Braatz Writes:] Suggestion: take a look at the BIL library- it looks like a merging of concepts might be a good idea. http://tinyurl.com/4s84a

2 1

RE: [boost] Resigning from Boost.Profiler
by Brian Braatz 02 Mar '05

02 Mar '05

I have been talking to Christopher about this. He has been very helpful in my usage of this lib. I am currently integrating this lib and extending it to fit the purposes of a 1.7million line application. (so far have done initial integration). With Chris's resignation, I am picking up the torch with this library. I intend to continue development of the profiler (I need it for a production system) and also intend to eventually submit it to boost. I will continue working with it, and share changes on this list for peoples ideas and feedback. I will not attempt to formally submit it, until I have used it to great success for the problems I am working on in my production application. It additionally needs full support for other operating systems which will need to be taken into account. I do not have a web page at this point in time. I am looking at setting up a source forge project for continued development. Thanks Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Wednesday, March 02, 2005 9:19 AM > To: Boost mailing list > Subject: [boost] Resigning from Boost.Profiler > > I am going to have to stop development of Boost.Profiler. IMO there is > still > a huge gap between where it is and where it would have to go to be both > robust and simple enough to be appropriate for Boost. Honestly I don't see > it happening without a more robust and portable high_resolution_timer, > which > requires far more time and energy than I am willing to commit. > > Where is the best place to upload my current snapshot, so that others can > take over if they want? > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

serialization archive types: random_iarchive, pretty_oarchive
by troy d. straszheim 02 Mar '05

02 Mar '05

Hey all, Robert specifically -- I've got fascinated with all the uses for this serialize() method, and I'm kicking around ideas for a couple archive types. The use case is an "Event" that occurs in a neutrino detector. This event is very big, it contains containers of smart pointers to containers of maps of smart pointers to... you get the idea. 15k lines of just containers of data. First notion is a pretty_oarchive. Currently I have people implementing operator<<() which calls a member function virtual ToStream() (so reference-to-base works) for debugging/hacking purposes, and if everything has a serialize method anyway, it would be a big savings to forget the ToStream() stuff and say pretty_oarchive(cout) << my_class; where pretty_oarchive is something like xml_oarchive, but with the formatting somehow factored out and modified. I admit that other than the header and start/end tags I haven't looked at this too closely because I assumed it had been discussed, thought I'd check for showstoppers first. random_iarchive (written already): The other issue is that with such a large event, you'd want to be able to verify that it makes the round trip to/from the archive intact. Obviously boost::serialization has thorough test suites, but with people constantly tinkering around in these classes, I was hoping to get a test suite going that does exactly what we're doing. You'd like to be able to just Event written_e, read_e; binary_oarchive oa; binary_iarchive ia; random_iarchive ria; ria >> written_e; oa << written_e; // close, open as input ia >> read_e; assert(written_e == read_e); where random_iarchive sets fundamental types to random values, expands containers to some random length (random() % MAX_RANDOM_LENGTH), and creates a T when it sees shared_ptr<T>. I've written this already. Of course you have to write your operator==()'s so that they have value semantics, that is they compare what is on the ends of their component shared_ptrs, not whether these pointers point to the same object or not. The original idea was to set the serialize() method and the operator==() against one another for verification... but if people forget to modify both, there's no way to tell from the test suites, it seems. It kind of started as an experiment and now that it is written it looks like there's no way to keep users from shooting themselves in the foot like this. Another problem is that if a class contains vector<shared_ptr<Base> >, you'd like to be able to populate this with shared_ptr<Derived>, where Derived is randomly selected from the set of classes that inherit from Base. Since serialization requires these classes to be registered, it seemed to me there might be a way to do this. But maybe its all overkill. Anyhow, this random_iarchive exists (except for the Base/Derived thing, above), maybe it would make a good tutorial case for custom serialization archives, maybe people want to use it for something. I'd be more than glad to write up some tutorial material, I'm sure I'd get a lot out of it. As usual, thanks for your time and for a killer library... -t

2 4

mpl::begin<mpl::vector<...> > performance problem
by Arkadiy Vertleyb 02 Mar '05

02 Mar '05

Hi all, I am having a huge compile performance problem trying to use mpl::begin for an mpl::vector of a large size -- the complexity seems to be far from constant (or even linear) time. The following example demonstrates it (I am using GCC 3.3.3 or 3.4.2) ---------- #define BOOST_TYPEOF_LIMIT_SIZE 200 #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp" #include "boost/mpl/begin_end.hpp" #include "boost/mpl/aux_/config/ctps.hpp" #include "boost/preprocessor/iterate.hpp" #include "boost/preprocessor/if.hpp" #include "boost/preprocessor/repetition/enum.hpp" #include "boost/config.hpp" #if (BOOST_TYPEOF_LIMIT_SIZE > BOOST_MPL_LIMIT_VECTOR_SIZE) #warning started generating namespace boost { namespace mpl { #define BOOST_PP_ITERATION_PARAMS_1 (3,( \ BOOST_PP_INC(BOOST_MPL_LIMIT_VECTOR_SIZE), \ BOOST_TYPEOF_LIMIT_SIZE, \ "boost/mpl/vector/aux_/numbered.hpp")) #include BOOST_PP_ITERATE() } } #warning done generating #endif//BOOST_TYPEOF_LIMIT_SIZE > BOOST_MPL_LIMIT_VECTOR_SIZE #define MACRO(z, n, _)\ boost::mpl::size_t<n> #warning started getting begin typedef boost::mpl::begin<BOOST_PP_CAT(boost::mpl::vector, BOOST_TYPEOF_LIMIT_SIZE)< BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, MACRO, ~) > >::type it; #warning done getting begin main() {} --------------- Thanks in advance for any help. Regards, Arkadiy

3 7

What's up with regression tests?
by David Abrahams 02 Mar '05

02 Mar '05

I only see linux tests at http://boost.sourceforge.net/regression-logs/ What about Win32? Weren't there other platforms, also? -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 12

[mpl] documentation bug (Fibonacci sequence)
by Caleb Epstein 02 Mar '05

02 Mar '05

In the MPL reference manual, in the vector_c section, an example is given: typedef vector_c<int,1,2,3,5,7,12,19,31> fibonacci; These values are not correct. The numbers should be 1, 1, 2, 3, 5, 8, 13, 21, and 34 and the final number that gets push_back'd to make fibonacci2 should be 55. -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: Re: Re: Is there any way to get typeid() to return the derived class name?
by Chris Just 02 Mar '05

02 Mar '05

Jody Hagins wrote: >> I'm using MS Visual C++ 6.0. This is what I'm doing: >> When I look at the type_info object's name(), it always returns >> "CBase", even if it's actually a CDerived object. > > > You have ommitted the most important pieces in your code sample... > > > Compile and run the above on your compiler. If it fails, you have a > problem with your compiler. Otherwise, you probably have a problem with > your code. Note that you only get the most derived type, if the class > is polymorphic (i.e., has at least one virtual function). Thanks, that fixed it. I could have sworn I tried that before, but I guess not... :) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: Singleton is documented!
by Jason Hise 01 Mar '05

01 Mar '05

I just got a message from Michel Decima regarding an interesting problem. What happens when you have to use a library which maintains static or global variables that you don't have control over, and you need your singletons to have access to them? The answer is that you have to make sure that your singletons get destroyed before or as main ends, not after. To do so, you have one of three options: A) Use the dependency_lifetime and make sure not to keep any static or global pointers. B) Explicitly call destroy on each of your singletons before main exits. C) Explicitly destroy the secret singleton boost::singleton::detail::longevity_registry before main exits. I recommend option three, combined with some RAII. For example: struct CleanupSingletons ( ) { ~ CleanupSingletons ( ) { boost::singleton::detail::longevity_registry::pointer ( ).destroy ( ); } }; int main ( ) { CleanupSingletons cleanup; //... return 0; } I wonder if this functionality is useful enough that I should add a non-member function 'cleanup' directly in the singleton namespace which destroys the longevity_registry internally. Thoughts and opinions? -Jason

1 0

Re: MPL integral wrapper failure on gcc4
by Aleksey Gurtovoy 01 Mar '05

01 Mar '05

Jeff Garland writes: > I realize this is an experimental compiler, but I notice date-time > isn't building because of an MPL failure. Similar problem in the > MPL tests. I looked at the code, but I have no idea what the > problem could be, possibly something simple? Just looked into it, and it appears to be a GCC bug: they seem to disallow any cast notation in integral constant expressions, while section 5.19 [expr.const] para 1 explicitly allows type conversions to integral or enumeration types: [...] Floating literals (2.13.3) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration types can be used. [...] If you could verify that the following stripped down version of the code in question is rejected, I'd submit a corresponding bug report: template< int n > struct int_ {}; typedef int_< static_cast<int>(5) > n; -- Aleksey Gurtovoy MetaCommunications Engineering

3 4

Iostreams questions
by christopher diggins 01 Mar '05

01 Mar '05

Several questions, 1) There is the (apparently) undocumented pipe operator http://www.ootl.org/boost/iostreams/pipable.hpp.htm . What does it do exactly? It appears to push filters into a filtering_stream or filtering_streambuf, but I am unsure. 2) Can we use it to write arbitrarily long chains such as: source | input_filter | bidirectional_filter | output_filter | sink? 3) why the name bidirectional_filter when inputoutput_filter (or io_filter) would be apparently more consistent with stl naming convention? 4) what is the url for the latest version and what is the status? Thanks! Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

2 1

Re: [boost] RPC library
by Iain Hanson 01 Mar '05

01 Mar '05

Hi, On Tue, 2005-03-01 at 14:09 +0000, Jarl Lindrud wrote: > Hi all, > > I've searched this list a bit and found a few mentions of rpc's (Remote > Procedure Call), but nothing concrete. > > I've written a library for doing portable C++ RPC's, which can be downloaded at > > http://www.codeproject.com/threads/RMI_For_Cpp.asp > > Is there any interest in Boost for something like this, and if so in what > directions do you all think it should be developed? Nice idea. Unfortunately RPC's ( including Java RMI ) don't scale. Thats why CORBA and J2EE were created. Simple RPC mechanisms like this inevitably end up being extended piece by piece until you have reproduced most of the CORBA functionality. Therefore IMHO I don't think it is a good idea for boost. /ikh

2 1

RE: [boost] Re: Re: Re: Iostreams Question: Bestwaytooutputtowin32debugger\outwindow ?
by Brian Braatz 01 Mar '05

01 Mar '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > Sent: Monday, February 28, 2005 10:26 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Re: Iostreams Question: > Bestwaytooutputtowin32debugger\outwindow ? > > Reid Sweatman wrote: > >> -----Original Message----- > >> From: boost-bounces(a)lists.boost.org > >> [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis > > >> Okay Brian, > >> > >> The following apparently works, but when OutputDebugString is > >> called I don't see any output. I'm not sure if the previous > >> version worked or not; I've run out of time for now. > > > > I didn't see most of this thread, and may be totally off-base here, > > but you need to use a tool that can intercept the output from > > OutputDebugString(), > > as that function assumes there's a debugger attached to its process; > > if there's no attached debugger, it attempts to use the Windows system > > debugger, which must be both installed and active. However, I like > > SysInternals' DebugView, both because it's well-written and easy to > > use, and because it's free. Very lightweight alternative to invoking > > a full debugger when that would be overkill. It can do kernel-mode > > debugging, too, which is a major plus, if you need that; got a copy > > running on my other machine right now. www.sysinternals.com. And if > > this is not to the point, or you already know all this, bear in mind > > that I only had this post available, and skimmed it pretty cursorily, > > and please just disregard my post. > > Thanks for the info. > > The main point of the thread was to show how to write a sink with a built- > in > line-ending filter, so the user doesn't always have to add one explicitly. > > Jonathan > [Brian Braatz Writes:] Yes. (sorry if I got off base)- the question relevant to boost \ iostreams was this- Given a device which has different line termination than \n, how do you handle it in such a way that allows for that device to be able to interpret std::endl so it works as the user would expect. (and so the code you write using the sink makes sense to the user) I happen to be using win32's outputdebugstring, but the same issue applies for "printing" to a windows edit control. The same issue might also apply to a daisy wheel printer. And, personally, I think boost should support daisy wheel printers (grin)....

2 1

Re: Re: Is there any way to get typeid() to return the derived class name?
by Chris Just 01 Mar '05

01 Mar '05

Jody Hagins wrote: >> I've been looking through the boost library and I haven't been able to >> find anything that works like typeid() that returns the exact (i.e. >> derived) class name instead of just the base class. >> I want to compare two derived classes to make sure that they are of >> the same class, but typeid() only returns the name of the base class. >> >> If there is a boost function that does this, or if someone has a way >> of doing it could you please point me in the right direction? > > Funny about timing... > > I think I can answer your question, but I must answer with another > question. What do you mean by "typeid() only returns the name of the > base class?" This is surely not the case for polymorphic types, at > least according to the standard. Maybe if you post a bit of code, which > represents what you are trying to accomplish, I can help... I'm using MS Visual C++ 6.0. This is what I'm doing: CBase { ... }; CDerived : public CBase { ... }; CSomething { public: CSomething( const CBase& base ) : m_Base( base ) {} CSomething& operator=( const CSomething& rhs ) { if ( typeid( m_Base ) != typeid( rhs.m_Base ) ) // This never fails. { throw exception(); } } private: CBase& m_Base; }; When I look at the type_info object's name(), it always returns "CBase", even if it's actually a CDerived object. __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

3 2

Select overload revisited
by Daniel James 01 Mar '05

01 Mar '05

I was thinking about the overload resolution functions suggested a while back by Arturo Cuebas[1] and had no idea why the compiler needs to be told the number of parameters in the first place. So I took his code and removed the numbers from functions, and it worked (in gcc). I guess that it didn't work for him because of his compiler. Well, it almost worked. Sometimes there is more than the one function that fits the template parameters. So I kept the numbered overloads to be able to match them. It might be possible to get these to work without the number of parameters by making the compiler prefer overloads for functions with less parameters. I've attached a demo. Daniel [1] http://lists.boost.org/MailArchives/boost/msg69451.php

3 4

Added "restore" member functions to ios_state
by Daryle Walker 01 Mar '05

01 Mar '05

See "BOOST_ROOT/boost/io/ios_state.hpp," CVS version 1.3, and "BOOST_ROOT/libs/io/doc/ios_state.html," CVS version 1.7, if they uploaded OK. (I had a temporary[?] wait on my own lock.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

build boost1_32_0 lib on solaris 9.
by JIM WANG, BLOOMBERG/ SKILLMAN 01 Mar '05

01 Mar '05

Hi all, i am building build libraries for version 1_32_0 on solaris 9 but running into many errors. For example, there are similar errors like in compiling serialization/build/../src/xml_wgrammar.cpp:14: #error "wide char i/o not supported on this platform" The command i used is: bjam "-sTOOLS=gcc" --with-python-root=/usr/local/Python2.3.2 install Are there any detailed procedures for build on solaris 9? Thanks

2 1

Is there any way to get typeid() to return the derived class name?
by Chris Just 01 Mar '05

01 Mar '05

Hi, I've been looking through the boost library and I haven't been able to find anything that works like typeid() that returns the exact (i.e. derived) class name instead of just the base class. I want to compare two derived classes to make sure that they are of the same class, but typeid() only returns the name of the base class. If there is a boost function that does this, or if someone has a way of doing it could you please point me in the right direction? Thanks, Chris Just __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

4 3

[mpl] sequence details
by Tobias Schwinger 01 Mar '05

01 Mar '05

Hi, What is the best way to convert the result of a mutating mpl intrinsic metafunction (such as 'mpl::push_back', for example) to numbered form ('vectorN<a1,a2,..>') ? I tried using the type-member (which only works on some compilers - not with GCC for example) and figure 'copy' could probably do the trick (but is a quite complex operation) so there might be a better recipe for this. In a library I'm currently working on, I use a decorator pattern to make a class model of a sequence it holds (i.e. give it a tag type member and specialize *_impl with delegate semantics). After applying the delegate metafunction I need the sequence in a form I can match with partial specialization. Thanks for your help, Tobias

2 7

[numeric/conversion] doc's example not up-to-date
by Samuel Krempp 01 Mar '05

01 Mar '05

Is the documentation for numeric/conversion finalized yet ? It seems that at least the code sample in numeric/conversion/doc/numeric_cast.html hasn't been kept up-to-date. This sample 1/ includes inexistent header 2/ uses boost::bad_numeric_cast instead of boost::numeric::bad_numeric_conversion and same for the other exception classes and most of all : 3/ // This works, because unsigned integral types cannot cause overflow. unsigned char c=numeric_cast<unsigned char>(l); But this line does raise an overflow exception (as it should, I guess). I guess the comment was about unsigned types implementing modulo-arithmetics, but in the end does numeric_cast check for unsigned overflows, or not ?? -- Samuel

2 1

Re: [boost] Re: review of FSM nears to the end - any more reviews?
by Iain Hanson 01 Mar '05

01 Mar '05

Hi, On Tue, 2005-03-01 at 02:56 +0100, Pavel Vozenilek wrote: > "Jonathan Turkanis" wrote: > > [snip] > > I think the review should be extended. If you do so, > > I will commit to writing a > > review, even though I don't know much about FSMs. I am also working on a review of the library and will submit it in a couple of days. > > > > I have not read the FSM reviews yet, but unfortunately IMO even if all the > > reviews are very favorable there simply have not been enough yet to > > justify > > accepting a medium sized library. It looks to me like only four people > > other > > than you and Andreas have posted on FSM so far. I agree. > Perhaps it could be interpreted: as the library reached > mature state where everybody's happy enough. > No. I think that silence is probably better interpreted as apathy or I don't have enough time to review something of this size and do it justice. I would not like to see libraries adopted into boost by default when they have not received a decent review. Just my 2p worth. > I feel current model of reviews is not designed > to deal with big libraries well. > I very much agree. /ikh

1 0

mpl::vector & push_back question ?
by Zhang, Karl 01 Mar '05

01 Mar '05

Hi: When I am reading mpl source code. I notice that push_bck algorithm, Look as following: template<> struct push_back_traits< aux::vector_tag > { template< typename Vector, typename T > struct algorithm { typedef vector_node<T,Vector> type; }; }; My question is: when generate new sequence, vactor_node<T, vector>, why skip "size" argument ? How does it increase sequence size in push_back? About push_front, It increase sequence size when generating new sequence. Regard Karl

2 1

RE: [boost] Re: Iostreams Question: Best way to output towin32debugger\outwindow ?
by Brian Braatz 01 Mar '05

01 Mar '05

> -----Original Message----- > On Behalf Of Jonathan Turkanis > Sent: Monday, February 28, 2005 3:09 PM > > Brian Braatz wrote: > > First off THANK YOU Johnathon Turkanis for help with "tee" earlier. > > That saved me a great amount of pain. > > Glad to be of service ;-) > [Brian Braatz Writes:] :) > > Below is part of what I am trying to use it with. > > > > My next question is what is the best way to deal with an "output" > > device having a different cr\lf than another one? > > Have you tried to use a newline filter: > > http://www.kangaroologic.com/iostreams/libs/iostreams/doc/?path=6.2.2 > [Brian Braatz Writes:] I have this sinking feeling this is like when I am standing in front of the fridge and say "Honey, WHERE IS THE MILK?" > ? > > I'm not familiar with the function OutputDebugString, but you might be > able to > do this: > > struct debug_out_sink : boost::iostreams::sink > { > void write(const char* s, std::streamsize n) > { > std::string s(s, n); > OutputDebugString(s.c_str()); > } > }; > > void Test_Profile() > { > // Note: library now uses namespace iostreams > > using namespace boost::iostreams; > filtering_ostream out; > std::ofstream log("log.txt"); > debug_out_sink dbosink; > out.push(tee(log)); > out.push(tee(std::cout)); > out.push(newline_filter(newline::windows)); > out.push(dbosink); > > out << "LINE ONE" << endl > << "Next line" << endl > << "third line" << endl; > } > > Jonathan [Brian Braatz Writes:] OutputDebugString() is a win32 function, basically when you build your app and hit the "debug" button in the IDE, it launches your app as a child process. If your app calls OutputDebugString() the text sent is marshaled across the process boundaries back to the parent process (MSVC debugger) and then it puts the string into the "debug window" in the IDE. (I point this out because it is semi-important to note that the process OutputDebugString has to go through is SLOW. I.e. just for reference, you would NOT want to call OutputDebugString() for each char) The problem with above, IF I UNDERSTAND iostreams properly, is that I just want a filter on the debug_out_sink because it needs the \r\n. Everything else needs a \n. Doesn't the above line apply the filter to everything? Do I need to weave in the filter on the debug_out_sink class? (either by "has a" or "is a")? What I am after is the "user" of debug_out_sink can just "push" it in without having to know about \r\n vs \n weirdness.

3 6

Global cleanups and typo fixes (affects whole tree)
by Julio M. Merino Vidal 01 Mar '05

01 Mar '05

Hi, I'm resending here several typo fixes and other whitespace/indentation cleanups I've been sending during the last few days (in these messages): http://lists.boost.org/MailArchives/boost/msg79319.php http://lists.boost.org/MailArchives/boost/msg79267.php (Can't find the third one in the archives.) This message follows David Abrahams suggestions (as seen in http://lists.boost.org/MailArchives/boost/msg79323.php) I.e., non-gzipped attachment, a single patch containing everything, and a descriptive subject line mentioning that it affects the global tree. Note that the patch is straightforward and non-intrusive. It mostly fixes several typos found in documentation and comments, and also solves some formatting issues in the jam build files (incorrect indentation and very long lines in help messages). In case you have questions about some changes (I really doubt so), the previous emails (linked at the beginning) have some more information. I hope it's better now. Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

6 8

RE: [boost] Re: Re: Iostreams Question: Best way tooutputtowin32debugger\outwindow ?
by Brian Braatz 01 Mar '05

01 Mar '05

Are you running it in VC in debug mode? (you have to do Debug-Start from the IDE- then View Menu- Other Windows- Output- you might have to scroll it) Too bad we don't have a boost.socket, because it would be fairly reasonable to take and make a sink for debug out, on windows it would use OutputDebugString- or on windows \ unix\ it could spit debug info to a socket). If we had a Socket library, all the rest of the pieces are there... I am going farther down the profiling path, (and Christopher Diggins has been INCREDIABLY helpful there). But as I think about it- boost isn't really that far off from having a profiler\debugger\logger. I think the iostreams lib would be an excellent thing to build that on top of... Anyways, just mindless meandering.. Ill give the code below a run tonight and see if it works for me (3-4 hours from now). > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > Sent: Monday, February 28, 2005 5:11 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Iostreams Question: Best way > tooutputtowin32debugger\outwindow ? > > Okay Brian, > > The following apparently works, but when OutputDebugString is called I > don't see > any output. I'm not sure if the previous version worked or not; I've run > out of > time for now. > > Jonathan > > struct debug_out_sink : boost::iostreams::sink { > debug_out_sink () > { > using namespace boost::iostreams; > chain_.push(newline_filter(newline::windows)); > chain_.push(debug_out_sink_impl()); > } > > void write(const char* s, std::streamsize n) > { > chain_.write(s, n); > } > > boost::iostreams::detail::chain<boost::iostreams::output> chain_; > }; > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

multi_index_container
by Volker Vieth 01 Mar '05

01 Mar '05

Hi, using multi_index_container I've got strange errors. Simple source code leaned on official examples doesn't compile. Hardly modified code that seems to be equivalent does compile however. I've reduced it to two examples. I'm using Visual C++ .NET 7.09466 (i.e. cl.exe 13.00.9466) with boost 1.32.0 under Win XP. This first example is a shortened version of boost_1_32_0\libs\multi_index\example\basic.cpp. It reveals 4 subversions, but 2 of them only compile without erros. Why the other don't? 01 #include <boost/multi_index_container.hpp> 02 #include <boost/multi_index/member.hpp> 03 #include <boost/multi_index/ordered_index.hpp> 04 #include <string> 05 06 using boost::multi_index_container; 07 using namespace ::boost; 08 using namespace boost::multi_index; 09 10 11 struct employee 12 { 13 int id; 14 std::string name; 15 int age; 16 17 employee(int id_,std::string name_,int age_):id(id_),name(name_),age(age_){} 18 }; 19 20 21 struct id{}; 22 struct name{}; 23 struct age{}; 24 25 26 typedef multi_index_container< 27 employee, 28 indexed_by< 29 ordered_unique< 30 tag<id>, BOOST_MULTI_INDEX_MEMBER(employee,int,id)>, 31 ordered_non_unique< //remove for versions C, D 32 tag<name>,BOOST_MULTI_INDEX_MEMBER(employee,std::string,name)>, 33 ordered_non_unique< 34 tag<age>, BOOST_MULTI_INDEX_MEMBER(employee,int,age)> > 35 > employee_set; 36 37 38 //use exact one of following versions, remove the other lines 39 40 //version A: does NOT compile 41 //causes basic.cpp(42) : error C2976: 'boost::multi_index::index' : too few template arguments 42 typedef employee_set::index<id>::type employee_set_by_id; 43 44 //version B: DOES compile 45 typedef index<employee_set,id >::type employee_set_by_id; 46 typedef index<employee_set,age>::type employee_set_by_age; 47 48 //remove the name index (lines 31, 32) for following versions 49 50 //version C: DOES compile 51 typedef index<employee_set,id >::type employee_set_by_id;; 52 53 //version D: does NOT compile 54 //causes ...\include\boost-1_32\boost\mpl\vector\aux_\preprocessed\no_ctps\vector10.hpp(398) : 55 // error C2039: 'item3' : is not a member of 'boost::mpl::vector2<T0,T1>' 56 typedef index<employee_set,age>::type employee_set_by_age; My second example consists of 2 tiny programs. The former compile fine. Using the qualified name should do the same, but outputs ...\include\boost-1_32\boost\multi_index_container.hpp(60) : error C2039: 'multi_index_node_type' : is not a member of 'boost::detail' Where's the difference? 60 #include <boost/multi_index_container.hpp> 61 #include <boost/multi_index/ordered_index.hpp> 62 63 using boost::multi_index_container; 64 65 int main( int argc, char* argv[] ) 66 { 67 multi_index_container< int > mic; 68 return 0; 69 } 70 #include <boost/multi_index_container.hpp> 71 #include <boost/multi_index/ordered_index.hpp> 72 73 int main( int argc, char* argv[] ) 74 { 75 boost::multi_index_container< int > mic; 76 return 0; 77 } -- DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

3 2

IoStreams- can it basically work in vc70 with limited functionality ? was[ RE: Iostreams Question: Best way to output to win32 debugger\outwindow ?]
by Brian Braatz 01 Mar '05

01 Mar '05

In working with the code below, I just moved it to VC70. The iostreams docs point me to not officially supporting vc71, but they do say some of the support has been left in. While trying to compile below, I got caught up with a static assert, I noticed the #ifndef BOOST_IOSTREAMS_NO_FULL_SMART_ADAPTER_SUPPORT Was around the static assert. So being a gambling sorta guy, I #defined BOOST_IOSTREAMS_NO_FULL_SMART_ADAPTER_SUPPORT and that got rid of that static assert. I am now having issues with detail::resolve_traits // Deduces the return type of resolve. template<typename Mode, typename Ch, typename T> struct resolve_traits { BOOST_STATIC_ASSERT(!is_const<T>::value); I have been digging through trying to figure this one out. I have not yet. My Question- is there a workaround that allows for minimal \ limited useage of iostreams with VC70. (I have a project I am working on code for that is STUCK on that compiler).. The code below is what I am trying to make work. Many Thanks, Brian -----Original Message----- From: Brian Braatz Sent: Monday, February 28, 2005 1:54 PM To: 'boost(a)lists.boost.org' Subject: Iostreams Question: Best way to output to win32 debugger\outwindow ? First off THANK YOU Johnathon Turkanis for help with "tee" earlier. That saved me a great amount of pain. Below is part of what I am trying to use it with. My next question is what is the best way to deal with an "output" device having a different cr\lf than another one? My basic problem is this- I want to be able to take cout << "hi" << endl << "there" << endl; and have it properly give an end of line for the MSVC debugger (the same issue exists with the windows edit control) the problem is with both the windows edit control and the MSVC debug out window, you need to give it a \r\n instead of just a \n As you will see in my code below, there is "stupidity" (i.e. look for the memcpy :) ) My question is this- What is your suggested way to do what I am trying to do. (code below DOES work) using namespace std; using namespace boost::io; struct tee : boost::io::multichar_output_filter { tee(std::ostream& dest) : dest(dest) { } template<typename Sink> void write(Sink& snk, const char* s, std::streamsize n) { // Write to the downstream Sink boost::io::write(snk, s, n); // Write to the stored ostream: dest.write(s, n); } std::ostream& dest; }; struct debug_out_sink : public sink { debug_out_sink() { } void write( const char* s, std::streamsize n) { // copy the incoming data into a new location so we can NULL terminate char * sout = new char[(n+1)*2]; memcpy(sout,(void*)s,n); sout[n] = 0; // make a std::string from null terminated string std::string ssOut = sout; // replace all occurances of \n with \r\n // this is the end of line sequence used for the win32 debugger // (this is also for edit controls on the windows platform) boost::replace_all(ssOut,"\n","\r\n"); OutputDebugString(ssOut.c_str()); // clean up delete [] sout; sout = NULL; } }; void Test_Profile() { using namespace boost::io; filtering_ostream out; std::ofstream log("log.txt"); debug_out_sink dbosink; out.push(tee(log)); out.push(tee(std::cout)); out.push(dbosink); out <<"LINE ONE" << endl << "Next line" << endl << "third line" << endl; }

2 1

RE: [boost] Iostreams Question: Best way to output towin32debugger\outwindow ?
by Brian Braatz 28 Feb '05

28 Feb '05

Yes I think so, (still trying to get my head around iostreams :) ) What I am working on: I am integrating Christopher's Profiler lib into a large project. The project is based on MFC (GUI Library- cout doesn't work here), so I was using the iostreams to allow for his profiler lib to generate reports to both the MSVC DEBUG window and a log file. The nice thing about the debug window, is that I can immediately "see" the results" of it (as opposed to having to continually open the file) Thanks to Chris and Jonathon for their help in today's chapter of death defying journeys with boost libraries...... -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of christopher diggins Sent: Monday, February 28, 2005 2:40 PM To: boost(a)lists.boost.org Subject: Re: [boost] Iostreams Question: Best way to output towin32debugger\outwindow ? > My next question is what is the best way to deal with an "output" device > having a different cr\lf than another one? Hi Brian, My suggestion is to create another separate filter which does nothing but convert \n to \r\n and add it to the chain: class newline_conversion_filter : public output_filter { public: template<typename Sink> void put(Sink& dest, int c) { if (c == '\n') { boost::io::put(dest, '\r'); boost::io::put(dest, '\n'); } else { boost::io::put(dest, c); } } }; Does this help? -- Christopher Diggins http://www.ootl.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Iostreams Question: Best way to output to win32 debugger\outwindow ?
by Brian Braatz 28 Feb '05

28 Feb '05

First off THANK YOU Johnathon Turkanis for help with "tee" earlier. That saved me a great amount of pain. Below is part of what I am trying to use it with. My next question is what is the best way to deal with an "output" device having a different cr\lf than another one? My basic problem is this- I want to be able to take cout << "hi" << endl << "there" << endl; and have it properly give an end of line for the MSVC debugger (the same issue exists with the windows edit control) the problem is with both the windows edit control and the MSVC debug out window, you need to give it a \r\n instead of just a \n As you will see in my code below, there is "stupidity" (i.e. look for the memcpy :) ) My question is this- What is your suggested way to do what I am trying to do. (code below DOES work) using namespace std; using namespace boost::io; struct tee : boost::io::multichar_output_filter { tee(std::ostream& dest) : dest(dest) { } template<typename Sink> void write(Sink& snk, const char* s, std::streamsize n) { // Write to the downstream Sink boost::io::write(snk, s, n); // Write to the stored ostream: dest.write(s, n); } std::ostream& dest; }; struct debug_out_sink : public sink { debug_out_sink() { } void write( const char* s, std::streamsize n) { // copy the incoming data into a new location so we can NULL terminate char * sout = new char[(n+1)*2]; memcpy(sout,(void*)s,n); sout[n] = 0; // make a std::string from null terminated string std::string ssOut = sout; // replace all occurances of \n with \r\n // this is the end of line sequence used for the win32 debugger // (this is also for edit controls on the windows platform) boost::replace_all(ssOut,"\n","\r\n"); OutputDebugString(ssOut.c_str()); // clean up delete [] sout; sout = NULL; } }; void Test_Profile() { using namespace boost::io; filtering_ostream out; std::ofstream log("log.txt"); debug_out_sink dbosink; out.push(tee(log)); out.push(tee(std::cout)); out.push(dbosink); out <<"LINE ONE" << endl << "Next line" << endl << "third line" << endl; }

3 2

[logo] call for artists
by Jonathan Turkanis 28 Feb '05

28 Feb '05

Hi all, I have an idea for a boost logo, but I'm having trouble drawing it: a car battery, labeled "Boost", with both poles marked positive (+). Booster cables would be a nice touch. I'm attaching my sketches. Maybe someone could do a better job than I have. Jonathan begin 666 boost.png MB5!.1PT*&@H````-24A$4@```0D```%!" (```#K`<TR````!&=!34$``+&. M?/M1DP```"!C2%)-``!Z)0``@(,``/G_``" Z ``=3 ``.I@```ZEP``%V^7 MJ9G4``#**$E$051XG&+\__\_PR@8!:,``P`$$-- .V 4C()!"@`":#1OC()1 M@!T`!-!HWA@%HP`[``B@T;PQ"D8!=@`00*-Y8Q2,`NP`((!&\\8H& 78`4 ` MC>:-43 *L . `!K-&Z-@%& '``'$,M .(!E<NO?RQ+4G?-SL-CJR,J+\-++E M]Y>/;\_L8V1FX5,SX!27I9$MHV P`X `&H"\\>/']]>O7W[[]I6)B8F1D1&_ M8J \(R.B<INPY<;,K9?^_?L'X?J8*_<FF1)O-3,S,S'*?MXX\W1RT8^W+R%< M$6MOT;0V1G8.%A86+BYN9F96/CY:Y<G!`T;+(( `HG?>^/;MR[U[M_?MV__A MPT=[>QMF%F8&K&M6X%D&2?;-YY_3MEQD9..PL]6[<^WNMT^?-^\^Q,'X+=M# MF51G8.9(9%?\7#F1^=US-0WYWQ*2+\_?OG%X]XOO?P2CBKFY.'5U#?__9WSY M\MG__PP2$E*DVDM/,%H&40@``HC^>>,S+R_/KU\_WW_X("LK#8RV_Y"4RLCP MZ]=O-,6,J$GVQ(/'?UDYE.2EY>5%7SY^QO[_]S<.]A>/[HF*FH,50Z+_/TPK M3K/^@R&Z+ S\^_[U[9TS(OP<O"9ZOS]^^\0OP/[C_^-[=[6E)%A8@*YE^O?O MIX `_[?O7TZ>/**O;\+!P4%1B- &C)9!E . `*)WWOC\Y0,_OZ"5E>6M6[=? MO7H#%P>6$)\_?_K[]R\>O;LO/&9B8M;6T[2PTKYT\K*0"/_')[_^??KR]LT[ M*KKPQ^E=O/]^\PF)B-F;?=U[^BVO`,LOU(a)??.7]\__7___^G3T[P\7'Q"_#S M\/"JJ"A=N'#:Q,026,Y1T0%4`:-E$.4`((#H&JD_?_[X\N4SL+J4EU>X=^_> MGS]_(*F*BYM37$(46-3ASQMG[W]F96.3D17^_.G[SQ_?>;@X_OSZQ<9*5/5- M//A_\2 K$P./E#@#%^>WEV\96=D^?W_+SBOYX<,'1C!X\^;]UZ_?Q<3_" @( MJJ@H7[QX!AAS@RU[C)9!E . `+S8NPZ",!0&8*2M!(B7@4$'2!SQ_=^"@0?0 M!1,OT1 *%BB4%D]HPF8<))RQ7?[VY'Q).^L?+C#&.2]+YKI.&!Z3Y*+7E512 M"L_SR/+KX<_W=UI)Q['WNTV6,M5U1M]WHG5M:\*$JN'H%$$/[(-O-**FS$2$ M5;6UWL)N/Q0AA//F]4SSG&*"@L"/XPCF?,(8?Y8V2(@6#,(8C=FT00C]:/I@ M$!X-,A?&7 9Q:[4%@XJB@/</&'2[/BC-$#:U03-?\D<`T35O_/SU`T@"\P:0 M(2,C#2R#OWW[Q(a)#J-?[\_/D+/S\?&RL;$XZ8.WGW`P,3$[\`G[ PU]LWG\#I M%%C\_69FHJ87?ET[P?GO-P<7!XNBS/]W'[]___6/D>GKCU]LW+P0!4!;(?W: MKU^_O7KYYM.G#VSL+ H*LF?/GAP\V6.T#*(*``@@NN:-W[]^,8!*M9]?OW[F MX&#7T]-]].(a)Q1.K]^P\_?WX7%Q=G9<%>/EUZ_)F1D4E45(B;D^7=FX],C(S MG &,.0YV5BJZD/G]"U!A)L#'*"G^_\7;GW____W__]NO7UR"PG UD&@#QNN7 M+U_!V>,C&SN;HJ+<Z=/'!TGV&"V#J (``F@`Z@T@^/+ERX^?WR4E)7EX>("Q M!13Y\_OOIT^?V=A8.3FY6;%5WX[:8ASL+!+BHHQ,#!\_?&!A9OK[YP^P&.1@ M9Z.B"UD=0O\Y17'*R##P\_YZ\>8?(_/O/W^___K#A3J8"(PY2-L7&',O7[S^ M_/DC!R>[DI+"R9/'!D/V&"V#J (``HC>_0T(`]@4_OKE"[ I#(RVQX^A-3ZP MG?GM^U<)"3$F9F;,X7@//9$%21K.2LR,7SY__?R9!:CF_U]]56DO1Q+&W0D# M)N9?[JG7?5MO?E!ZRJW^5\7DM[RN7E26FIDUFL)___YQ<G("(PD8<\#L`8PY M3BYV966%$R>._/Z-/A!$9S!:!E$%``00(SWWBU^]=N[;MR_@P1X&5A96<0E) M=C;.HT>/_?W[1TQ,#*B EY=;7%SLTZ>O[]Z]^?4+G^=__OG'RL3(Q$1@2HO6 M@(F)"=AW!&82'I#+1?GX!+Y^^?;HT1-34TLFJC9"2 *W;E_Y^/$=))P%!82$ MA45?OGQUY,@1+2TML)L9I:0EN#BY[S]X\.OG+\SX?_+^YW,V*2%5^5ES=OYX M_X[UW\^_+V^6Q3E+B@E1UYU,__\(<GUAN7CJP^/G/UFX[O_ED+?W8L*8-P2& MY->O7YF9F7EY><0E@(',_^WKCSMW[IF;6P,K%NHZ"1D`!!!=\\:Y\Z!LP @% M#/S\`B(B8N_>OM^W;[^V-BC:@((2DF+\? (/'C[\\?W'OW]#X)P'8,R]??M. M4% `6*0!*ST>'CY@Q?;LV0LC(U,F)BJ/[1 )1LL@J@" `*)?V09LMO[Y@]+8 M`-7XW[^)B(@H*2D^??J4`52',KQ_]_'GKY_B8A(T+1(H!^!%%@S@_N)_+BZN M.W?N_OKY^^6+5U^^? (6;U)2XF?.G,(_C4 [\//G#[@S__P%MOH^`QM(6EJ: MKU]#)SJ [<"OW[X*"0FPL++B3_?L+$P#GC$8P"U8`0$!H+-__OCUZM4;8"!S M\W#)RDJ?.W?JWS]:!3) `-%O,(a)78V4!;U0-,.E^^?N'@Y%)55=VQ8P>P60R, MAQ\_?@*[(N+BTB(BDK=O7P/V0!@@<[%@"#,`49)!BHW_X,0*+. 05H G:"'< M_PS_&>'SN> <R B?M66$B/R'VP)CPR6A8R;_&6"Z@.2___]A!@!E?_WZ]?SY M2S4UU9\_?[]Z^1IH"B\?G[3T_S-G3IB86!"YN(A:`%(&(0<UL SBX>:!ET'2 M0)>!RR .#DY@&?3LV=.?/W_1TX4D`7B,P\L@8#@#RR &"6#MQP\I@XR-S6@1 MR `!1->\@28"]#9X#)Y;4%!02TO[[MV[JJHJ#*"QE(]"PD+L[-Q<W.RL;,R@ MI,G "$O(X*2)2)E8`"(3()('-*G <P@2`R:)% D(]R$R"%:+H+IX>7CEY)Y# M!'^ "K;70#D^?C[I_PRG3ATW,[.D9_88+8.H!0`"B'YY`S)X@A1K(-;?O_^ MI1HG!S>P2 /FC9\_?[*SL__^_>?QHR?R\IS@</L/"79&6(8``S %#EVP,!2# M!^,94" D!F D*L& D(&)H<A!Q8GRG:*B`IS]_?O/U\#LP<# +\ /-/_\^3,F M)N8DAQ>Y8+0,HA8`""#ZY8W?T#A#"0*@E[]]^_KM^Q<!?F%@=_SRY2OJZFH, MH#&[[]>N7:*;VP@"$1%1?G[^ER]?`MONQ*C_]NWGF]=O@(D!V$>'9 ]#0Q-: M.Q("1LL@:@& `*)CO0'K(*+-7?S[]__KUZ]<G-QR<G+7K]_X_/D+L"]+DLE: M6CK<W+P/'MQ]_?H5M5R+!CY__B0OKR@D)'+UZF5@9B9&R]>O/QC ?5\A84%@ MS)T[=]K(B*I3,3C D"Z#=N[<??;L.3\_'QT=;6+4T[0,`@@@^HU3_?J-7M?# MX^\;*-Y 64)?7^_QX\>DFOSTZ1-@9:JHJ,+.3N5ES"PL+-S</'Q\?,!2]N7+ M%T!;-#2T1$7%@$A,3%Q<7 +(P#.>]O7+][=OWG[Y\DE81%A(B/_,F9/4=1Y6 M@+\,^O7K![ ,`OH+,A5($LC/+W)W]]Z^?2=5W(D5Z.GI'C]^LK"P]-:MVT1J M`99!KU^_^?+U$[ ,`@8RL RBEF,``M!N1:T-PD"85=LU4C4F"%T1W%\9_6/^ MN#(HI?1-!]'A@Z.V+PY\T\3VLVXP*):-V2.$>[KODLLEWQU$"X)@*%NW99]G M7?^DZ[M?Z.?#=QNT#>3C9&)9=I[G*+D,P[AMS7&8;=/9S,0\;84@WM ),1CC MG+L8H-=2RFO^_7N9SY]\_QD)@!<#+L$Q(,$^X%I(0CK<LNPE6E55-XW2]!&E M3*E:".%Y]_WY>3A^=.7XCTW^TK$;X[%.J8-\CJ+(==T_6>:<(3'6Z\UR^8+[ M8D"?B^(S3=,LRT#\3-/<;G>KU2M(K!!)&$9A^)8D[T#O.Q5U)962NJYA::=3 M$\?Q8N']WZNS`*+?W-^9LT> [L:1-T#C(< T)RHB_N#!PP,'#NGIZ> W#>AY M8/: ./[OW[] DWEY^<$K-[]__/@!TBX&AM>G3Q^!B(J^D)*2EI-3`%IQX\8U MXH,.F(N!_4A&1A9@K<C-+:"KJT=%)Z&!RU?._/CQ#5<X<W-SB8J(_?_/M'__ M?C8V-F I@M\T8!I]_1K4IO_Z]=OOW[\W;=KR[MT[!05Y`P-](/?'CQ_ P <6 M$][>GL BGVPW+UZ\#&@RT IF9B9@)')S<P.3`5 <:)& @ !8D V8)&)CH_ 8 MPL?'+20LQ,,-[!:^>//F@[FY%=GN@0" `*)3?P-8D@&3+[((<HW/"![1`S>( MOTI)2<G*RCQ__D)24@*/@<^>/0$B9!%!06%U=4TV-G;P@/T/7!HI!$##@?$D M*2FEH*!T__Y=(G5]_/ %V'%D9& "IJ23)X_3-&_@]_OW[]^_?/T"+(.TM;6! M91#!O %,HT>/'F,&`PX.=G!?Y3)0$%B%&AL;`<MX8,+EXN+&W$M($@`F>K1T M#\PMLV;-!=8575UMP#Q,C"&?/GUE9&+\\_L/L#+____-Y<N7* QG@ "B4[T! M;'-?OW&!`:F.QRS2@(0PL.H0E?KTZ=.A0P=!VPQ(G!I75E8#MG\^?'A_X\95 M2ER+'"98PP?8"0%F=6 Z`PWA,R(65#,P,&!C,$#JL4^?/C]Y\O34J3-3ITZG MT8P'L RZ>.DD`R*<$6$+#W1@4U!45)R%F>WPX2/ @A]_&80)#ATZ7%O;"(R: MA0OG2$M+T\(7$#!API2U:]?[^7F7EA81KXN-G158!@%[L->OWTI)2:?$`0`! M1*?^QK=O7]Z]>XW9`D:+/]"Z2U8604$Q.3EY8 [Y^?/GOW__X*K1DBPF>/?N MS=NW;]Z_?_?[]R\T]8RP072XC4 `F<\"G\+!B))M,0`\>8''#QB!Y@-+2MBP M)61H$^C2_V $6M,-1G_ 4]10!&0"^Y?W[S]@9F;Q\/"D43A___[MS9L7#'C+ M(*!+6%E8^/@$@:7/PX</@"TBDC*JO+S\TZ=/;]^^\^C1$S<W%TI<BS]"S<U- MK:VM-#4UA(0$__]'5X]<!L%B$^R[/W^!O1=@. /+("\O;TI66P$$$)W:5#]^ M?@?3Z .+:&Q@B@/6^<!&"Q<GOY&1V:]?/SY\>/ONW5M@"0U,B_ Y6G@0(0V: M0X?.P9MXH(F5`3PX@Q2D_S&#&&5<'393!4E/B,DMI,P!RDB@M7?,3 C "(%X M,A;$Q)>O0 #87:$L+/$!R(HU0@?N,'S]]I7SZT<A(3$W-\^;-Z]#1J6905L# ML)1!F-JKJLK#PT.!31U(R851;4++(/B,'DP-Q$"$.8Q(#OV/.B$"4::FI@)D MP",1+/@/+3919TU 3&#'_=$C8+^.A\+*&2" Z-??@##P1QLPL( E']#_'.R< M__ZQ`M,=)R<["PL3, Z M3]BVI41.>'"$S2(!B=2\(%,X&3+#$JYA)(O=)D$ M`_I<+6(F%Y%B8(4:J);X__\?G(4D^!]>F3 @YL08@#W7KU^_`'VAIJ9.W;!% M!G0K@Y25E8=]&0000'3*&Y"=:*@`*70@?%B]_QM4^/UG80%U-MC8.5A8&;EY M.(1%A.#*8 P4'BST_\/2*F;R121CU.3+@!SQ- +?O_\`HB]?OD(V4= (C)9! M5"R#``*(3GD#OA,-M2)%!Q Y9E XPWOA?[Y^_?SERW?(\ M-DR]-P=>OWX"E M,A<7CZ2D).UL&2V#J%@&`000O=M4^ %D?2>XX0MM*?[Y\Q.RQ73HY@H(`,;6 MMV_?%145:6K+:!E$Q3((((#HL6;DW[^_D($C.$!>BXE6I#& 5VK SF;]__OW MS[]__^&+YZ$`?O_^\_4+:/Y&65F%IA91I0P:NAF#@:IE$$ `T2-O_/J-5M'C M3.A,X,X8L(\(5P.,[+]__P[@WFNJ`&#S%UB8`8LT'1T"\_V4@-$RB+IE$$ ` MT25O_$1;-<V QD7I^3$"XPPZ#_K__]]?OWX!&Z]#/6]\_0K,&M_!$^HT[&R, MED'4+8,``H@N>0/:0210)L$'15A8H$?H0?(&\O#Y$ 5?/@-+L^\*"K3M;(R6 M0=0M@P`"B!YA\?L/M#S#EL+A0K!Q/E [&-I!_/?O-V2ASI#.&Z SK(!MX&_? M-30T:6K1:!E$W3((((#HD3>PK7Z#MX!A?,2"7"9FV.#)W[^_@ D+^<Z4H0A^ M_/CY`SRJJ*Y.PUD_AM$RB-IE$$ `T2=O( 9/\ \L@B*,A9F1$3JR#(SL/W_^ M#ND(`X)O7[]_^_Z=F9E%3DZ.IA:-ED'4+8,``H@>P?$'L>,//96C1AOFX,D/ M< =Q:.>-S^!115J/WC*@YHW1,HAR`!! ]!G#11ET1QY81&9 RC-6T#0M1.0_ M>/#DWY NST"'&'P&U?2JJFJTMNOWK]$RB)IE$$ `T3S9_?OWCYAC?2$M8 9& MY [B/_#@R;_!/WC"Q,BHH:XN*X-E'R9HW.3'CZ]?OFEJTK8CSC!:!E&[# (( M()H'!R/J!:186\!0&AQI2 .+?\"#)^@=1&"!Q\'!P<7%Q31HV@`\/#Q )_W& M5@1\^_8#6-,#?4?KSL9(*(. '=>RTOJY<Q9C2M&B# ((()JOIP)F#!YN_B]? MWV.51%(%S3,LS-"\`1X\^<. .G@"+)OAVS@O7[G",$ 'SB(#5E96R,$"0%<* M"@A EE-_!2_K88 N8:!'@PI6!L&7>U!:!GWX\/'3I\\_?_Z2DY-F9Z?FI4UD M@^O7;[UX\<K,W!A3BA9E$$ `T6.MH8R,_+7K[]":LYB#)XS@]<[P@<4_V 9/ M@"+ I :L-/Z M])1Q7G ^H>3BXN5A05B^#_4U43,S,PBPL+\_/S ]/'__W]@ MT05TY(.'#R&#;Q) ("X.42D.8P#!\^?/@7D#5M%_-S(B^?9A4@$PH'AY@&70 M!ZR22*J(*H/FS%E\Z. Q"'O:])[!D#?>OGU__ASH**U_?_\=/7H2F&F!4:"N MIJ*DK,! FS((((#HD3=X>/A86=F!<0`3P#;\#J[KF9B9D%:_81D\>?[B!3 , ME!05P=L,0 "T8 Z4D;#G$SY>7F"A#MFA]N7KUW=OWR(G?:!><3$Q$1$1>'/B M]^_?#Q\]^O(%>G83,$TH*RD!M0.S#5 *R.#FYF9 6J;ZX_OW=^_>"0D)`8O> M5Z]?@S:_@MLVL#O$?H#/+OBJJ4G#/1MP(".C<.WZ>:J40<!PDY>7??CP,2\O ML,'(317G`9/R@P>//W[XR,O'JZ0DCY;?@(E[[YZ#Y\Y=>O[\)2LKBYBXZ*^? MOW)R4R#;V=>LV;1IXW:(RBU;$ =D!0?[`O,&C<H@@ "BTQIU45')%R\>X5G. M`.D\L((&3R!YX_]O'"M\(/=,`Z6D)"4%! 0@AU `D^:;MV]?O4*<:\C%R0FL M7I$OI08J!M8`=^[>A;3+V5A95514@-J_@A=G_P>?8L_)R0G,>%>O78-42M)2 M4D %#Q\^?/_A`\21"@K F/@+FX%F^/#Q(Y -S!N?/G]^\^8-`RH`[R7X#DR0 M0%WDAAP)@(IE4%AX@(JJXH3^&=+2T,47P+0++%_X^'@QS00&R.7+URY>N/+F MS3L65A9-#55[!VODI _4NW'C=F#2A_>(^/GY,C(2M74T(-SGSU]T=$Q\_^X# M-S>7L+#@Z]=O[]ZYSP`[H!H(9&6E;6PLCAPY(2(BY.'AS,W#S<G)P<L+RF,, M-"N#``*(3GE#4D(&,V^ `<K@"0O*X,D/8'D`V7F###C @0YLY#! ID*_?&$# M`V!6869B`E8L#.#.,3")`\U\^?+EQX\?@<J S3 9&1E@5@$V@9X\?0J44E)2 M`G85'CU^#"SX(28#"WXU555@]@`&^@=(9@#'C:RL++#I]!M\@,*[]^\A4G ` MM(L!M%H!R_%MG\%+&%14:-[9@ ,JED%/GX!.908FP:5+UYPZ>1;H;R!74$C MQ=G>U\\#KNS>W0>S9B]Z]O0Y7.3LF0M[]ARLJBX2$ #%$3"AM[?U`;.-LHJB MMK8&T.I3I\X]?ORTOW_ZA(EMD$IIV=(UP(R1GIY@;0,ZT!98PTR<.).'&W2! M#L1,<W-C41%A8-[0U=5R<W="<RJ-RB" `*)3W@"V7H2$Q#Y\> T30(L]Z (X MI [BOY^@#B*65=.0J@#8JGGZ]"FPKH (`IM&DI*28F)B+UZ^!&I0D <5)[?O MW(&T;8#@U\>/0"V*BHK I _D"@D*`LUY_?HU/&- S 16S$ %P#H$(O+XR1-@ M7@**L !=QL8&S ; *N(9*^NKUW"/,$ .VX-;Q !.?__ F]^^?/X&--#0T(R" MD",-4+$,>O[B)9 \?_XR`^B>)QX-#=67KUX#4_#JU1N!:1%8L0#%KUZY`4SB MP*+'Q\?=Q,0`V%BZ=^_!HH4K@#WFC1NVQ2=$`@N4WMZI[]Y]2$J.<7" WIGH MY>W:4-\)S![ VL;2$G1&,-! (#EW[I+UZ[<`<Q2P065K:PF1@H/K-VX!22UM M#4R_T:@,`@@@^IT5+2(L_O;=2Q;4HQ^@*T-A5SZP(@86_T .N<$LSR"-J,? M\OX]8NSKY:M7P*XP4#$P$0-+?2 );.$@IU<&6)\$TE@"J@&2'S]]0E8`U YL M70/3]%>P1GX^/FX>'F#W`^$%$1$9:?1!&V /!)BI@.UW-D9&8'X#ZA(4% 16 M34^>/ 6MEZ;+S 8<4+$,@M0;P#")B0EU=+*%G-D!3/%KUV[>MFUW8) W,*"F M39L+)&MJBE54E2"Z1$6%@;7WI$FS'CP$G6M\^/ )8)7BZN8`SQ@,X)$]%15% M8-Y@98$FO^24F/7KMCYZ_!38&P'6,+=NW3UR^,2[=^^]O=W@NN[=>P@DE904 MX"*0T^!I5P8!!!#]\@8?GP`G!_?OWUC6_$!&%<$+&:!Q]O??;_ V-/0(8P$# M8/I^C]JP@6S?!Y\']8<+7#-@]L[%P5?=(5<4P.X'L+,!Z5@#LYR\G!PPK('5 M$:19#&Q*@2QC9@:J80`?>0;LD "M@%=6$ !T)S"R-6!K>(!1!;0"V.X"EF3? MP*.*].EL('F*.F70*_#Q_<G),;9VEG!!'U]W8,\!&#Z?/GT!EOK `MO1T0:> M,2" %]PGX>$&5:= -4#2R!#E?,'OW[Y?O7H#&. 0C6=.G[]YZTY6=C)<P:Z= M^Y8L60WLE"/KNG7S#M"1P.+FY<M73Y\^!_;:CQT]%1<?869F1*,R""" Z)<W M(a)$!82.SYBT>P6(#7\HCQ$_C(a)R=\_OW[__H.E004NLS'%(a)?T!H.#[]^^!"1TR MA"4J(O+MZ]=/X&X`L.4J)24%;/P`%0![SPS@'"(`!D#![Z!%.,R0`:AGSY^_ M!G>I(3=;`QE"8, `;G$!^S9/GSV##Y%!P+W[]X%YC(65]<_OW\":"J@&,A3V M!53/?U=55:5:\!$'J%(&??CP\>O7;\!JT,(2Y<A^8*X`9GX.3@X^/IZ'#T U M*B]J[QQ8=FS<N W(L+$%Y2A(EMNSYY":N@KDE$I@RIXY8\&K5V\BHX(A'9+Y M\Y<!\Q@P<4.R"M#8,V<N`/LY+B[VR"8#%7_\^*FFNA7"!68M6UL+<S.CKS0K M@P`"B*YY0UQ<^NFS!YBWIT*W]H,.<H&O?ON)N<('F%AYP&TA8(@K*RD!&_W M> *&$;#S`.P)`$MW8,IF`*=[8.,'&*_ WC:D3F $GQWVZM4KB (@`.:9^_?O M`YMAP+P!- %4$;U_#^Q^?(>E>V"*N7/G#C"#`LT!6O?O[U]@NL<Z4@Q,+L!. M#IH@T#I0(_CK-T,#>MRY@08H+X,@9?:_?RA'& -#:<V:34!!:RLS8$*'#&'M MWK4?V$ R,- %R@+;0BN6K[M__Z&%A8DY>(8.F'Q/GSIW]NR%DI(Z!7DY8!S= M`0] A8;Z>WJ"SD1\^_8]Y+8#8#\;B!C D0OLVT1%A\C)H:S!*2[)WK?O,+#1 MQ2_ KZ0DKZFI!FG<OGSUED9E$$ `T35O`+TM)BKU[OU+]($4\-9^M.W+X(%% M1$4/3,2J*BKP6.0!`P@;F!#?OGT++-$A<0DLMF_=NB4,GK!C`<_H@68VWKW[ MA7H^S4?P&>M,X-%^K-.(7\!-J5]83K4A#'[\^ DZ"08TJDB_S@8<4%@&`2L- M8)N'`>SWSHZ)P*XS.QO;ZS?OCAT]>>/&;6!." L#=<2!;:T]>P\!NQ-]O=,@ M]0-DX8F7EVMHF#_$*&">R<M+V[QY)S##`/OQP H'F&T\/)T5%*"SU\+"@I55 MA4)"`L!FTL^?OX#5!;!'@76D&%AO! 7YH G2M P""""ZY@T&T&GG(F_>O@#/ MUS%(a);.U'&3P!!C0+"\)YP"A\"^XJ0,9M@8TKT$0U>/;M\Y<OD#,RX "8/8!- MH]<8$PZ8`-3^H<'"D^^@)0S?&/[3N[,!`9240;=OWVMMZ877&,"J`(C@QMK9 M6T5'A7!R@7ITP/!O;"P'EN7GSUV"W+8%;#@!*PKXP"L$F)@:`A&PWPRLH+!. M(P)K``90?A;#E"((:%H&`000O?,&+R\_!P<7L#6,/NC.R,C*`MW:#QH\^8F^ M?1D8N$^>("X5(a)$]=#TX`.0E&29GF2T5P`;++(!X>+GM[T,T5P(Z$IH8:L''U M_,4+8$3(R<IH:6L`BWED6X#9`]@T@K2.\ -P44;]A2<T+8,``HC>>8,!-!(J M\>S9`WC>@!T&R<#""A\\&=I;-/^#KA,`]<2UM0T&R@UDET&2DA*)2=%P+GSJ M>G "FI9!``$T`,N2183%85UD,!]VJ35\]=O?OZ#!DR&:,8#@YX]?H"4,7[YJ M:Q-UH2.-`+ ,0C^T?)B600KRU#D\`0T`!- `Y U@*07,'C >=&L_$]+@"7CU MV]^AN]7FV_?OX 7J`]/9@(/1,HA"`!! `Y/^1$0D(;T]Q-9^T&'RT ;>GS\_ MA_3VY:]?O@$SA[R"`HTN9R(2C)9!% * `!J8<.'DY&)GA][Y";DUB84%?C;K M_R%]QAYD5/'KUV_*2@/6$8>#T3*($@`00 .6_L3%I.$3<PR@50PHVY<A%P(- ME-LH`< 6/+ %_/7K`'<V(&"T#*($``30@(6+@( P9'(*MC(4/GCR]^=0/G\2 MLHQ*4%!8:1#4&PRC91 %`"" !BS]`9,^/Y\0`W0A`_+6_C^0"U:&4)S![A/Z M#RR&/WWZS,+*FIR<,M".@H+1,HAL`!! `S"_`0<2$K+O/KR"34@A!D]^_1I$ M9^PA7['U#P8@"W[A60)8AH$OX&9A8V-75M;P< \8#!NL(0!2!GW\_'9XE$$0 M!C *Z% &`0300.8-5E8V7A[^__]_,S(A#9[\@6Q?IGF$(=_<B)3H000DW3. MX^#WGS_,3, V.A,[.P<7%S<;&S/X"DEN=@[0AB<@FX.=DX.#<S"7OJ-E$'D` M(( &,F\P@/;?23Q_<1?87X1?KH5U]1NI`%= _P6G?0;86FL&\ 6G'!Q<P+!F M8V-C9646$N0%Y@$@8F1BYN3@!#* J7\PIWMBP&@91!X`"* !SAL"`D(?/K[Y M^>LK(P-L]1MXBR9\IS\:P QH2"L?`B"9X??OWT V^/Y=9G"Z9V-F9N/B`H4L M.QL'&SL[$R@"0.D>^:2%X0U&RR R`$ `#7#>8 #M[5:[<_?JZS=/^'B%6=E8 MOG[["DS<+"R,D,/VD-,]**#_@R#H!!EF%F!]RLH*6L$&+%8X.;A8@0'/SL'" MS I,\<"D#]E),PH@8+0,(@,`!!#C(+GX$#0<]^7CEZ_OW[YY_>7K=V!R!X8I M, <``QU8K@`+%1!B&P*-^\$,@&40'Q\/I QZ^O36DR?/(=V/T3((*P`(H,&2 M-T8!?<!H&40\``B@T;PQ"D8!=@`00".Z8!@%HP`/``B@T;PQ"D8!=@`00*-Y M8Q2,`NP`((!&\\8H& 78`4 `C>:-43 *L . `!K-&Z-@%& '``$TFC=&P2C M#@`":#1OC()1@!T`!-!HWA@%HP`[``B@T;PQ"D8!=@`00*-Y8Q2,`NP`((!& M\\8H& 78`4 `C>:-43 *L . `!K-&Z-@%& '``$TFC=&P2C #@`":#1OC()1 M@!T`!-!HWA@%HP`[``B@T;PQ"D8!=@`00/0[9V1$;;X=#(<%C@8XA0`@@&B^ M7YQX\VGG$JJ;C!P3N&)EH++':(!3"P`$T,#D#?B97WC4$)0:$/4,\%M>4!D, MV.)F0++':(!3"P`$(.Y:<AJ&@>C8=:"B'P2B):B58-$+@-1ND7H6#L8!6'. M;EBQZ F(NF9)H\8>V\PGBH #E"A27B9O9CS/&Z]>CNK=]M,&3TS!(J*GB13+ MS1YA8(!PRV1@^'M.2J/I?<S;:M^$N"A/)^-"."R,&JA27M=%VT;)TG3MK.LA M<A97\2S%03(Y2-W\(;UO</M&JS&S.[M\3)=38VQ97H^&4X!B-+QRKI"_D]MN MS^#W]E#-_SU<_1&\1OAJ6DT."$TD)5M.C;S.F#C((#/H7B%A\[G#@# N<_^< M@CH5@3HP65-\XFDQ<5D00(20&(#HO _Z)"87UXN"Q'>A7E?/#]6+!_=Q<?]Z M^[0[6S@+\YO>:AZ7`US/\N#$'E/P;P%$VWH#V?#_"/#O^8M;UV]<^/CQ@X ` M'V[/P&^294!2P7CYT??).]\\>0N]4-Q8D;,R0)R+G0EVJP2Z;ER $9V 0O!1 M_(R_-B]A.KR5@8GI#\1 9A:N_%9V!54Q,4%9*0-&1N:GSVY^_?I?5D:-"0DP MP@"*173,'E@#')@T&T\S+CSQY<V'KVR\@LCG0\/2%Q#^ASJ6X3]2J(# WW>/ M?UW;]>_K.PB76421T\"/"7;F-",#<BC^1];(R/@?7*Y!&1!'`:V"WP8""1@F M\ 'O(6<KO&],@@?X;R:V7N\#S\4,OPJP6%HP2K SG#O_*X;K4ZP^!]T"'"" MZ)0WD.J*?^_>/WSZ[,:FC;O>?_@2&>7/"KH*'NP]:'C!4RG8?0RH/F=DB.N[ M=.G)3S%1H;^_?GQX_YGAST]#)>YY)69(MB(3H%H!#&$LA$G 2()$%=R1#! E MP.KG?44L^Y?WDEHJW(:Z=W>?O?#XM8R"K&A)F[BXC+"0^,_?+YF9.=^^>?WD MT6=#0SMF&$".,.1PH%OVP!K@O9<9FTXQ_SBZCOW;"V6O9 86%F!RA![+!LDH MC/\9H8$/"B<F<$9AA*7XZQL7?'WW"CG N<1DM()3&"!J@,$%5O8/=NWF/U#] M`VGS@ 3A118CK."".1&B!13LC/_^-BZ4$_WY"CG ?XMK3_$_+*+ RB7!>.(. M`S,K`^.[OV',][N\1.@3X `!1-=Q*LC9DE^_O1 2%I"6EOC]^QDK"S,P,4*: M4BS,S#_!1ZQ"$C,HFM'@__^?OO^Y^OPW)S>7@;'&WY_?'UZ[]?SAO7-7WSU_ M)DM%I_Z^>YW_TUM)$3Y)7Z<W9ZX!VVQ2`KP7OC"%"H@^>_KHP8/;7%QL@H)\ M`H*"?__^NW+UI(:Z,2LK*]!YD(OG(,<!#GCC"A[@<^ZR,_$QL8@J,+WZSL#" M!DR1P/;,OS\,_Y@8?OYB!(8WI,SX!PIA2#!#&,"6+<._7]\_?WC'C1K@7Q]> M.GN?\3_!JIEHH/'JL.CW%V@!ON0#)ZLPZ[6;_W]>9/S#QO"'FX&=CWG55P7! M_8]*;?GH$. ``42GO $IPX#Q].O7K\^?WPN+"!L9ZP##]O/GSW UP SSZ?/W MOW_^X3'GY*W/O_\SR4A)^079;%]_%.A],1&!5]>/,3!84=.YET\"VVB\8B(< M:@J\E^YR\ M__?GI.SO/DR</@$75GS]_/GSX#;I%DHD1Z&9@'7/CQCDU-0-@ M0H0?#CO@V0,>X%]__GGXCH.1CX%-3>\7`_.]M]##H8%)_S_O__]?@!D%32N* M(_^]N LDQ5 #_-Z5LXS4RQA 8/MD#6: OV 6O7T;F/H9&?[^8OX*[*!P_ 3: MRL<RXX,L^]&'.99\M YP@ "\G,T.P4 0Q[>[VRXE)45+1.)-/*.[=_ <$@Y. M$@Z<"(T6_=J6[MJF"9)&#X(YSV'GMYG_[,PF\X^_OT=Q%T:IY_D^I:%A-H4: M>:Z?^915TM"U$B'%X<PV5/1BG4Y+QO!D.RK![!;+Z)OW)$1+7DPQ@I5^%T#D M[VVAM6Y 2:T.TDZ=88Q%($$06P?G?#D;IJ[5DN5J'D61R'R1.=F&_9=AP)/# M%\]9%,(+\*W+DE!*1QYU12JI/'0R'Z: I"HA!?)">.RXS@/G;[:O?V:0W0:[ M<1YX4&Z#%#A/GU,\0?$57P!UP563AU9O-#G]&OA=`.:L70=!( @>`3S$T!A% MHQ@+3+3Q/_T.O\5..SL?(188$I\@<!P'XN)I1>S0>/44NS.9W9W<C_[%N530 M!HE\Z 3\`1X8CT>V[7! 3%E(2*O=D.6/O*?W;&'%HB09ALYBYKL>K%064Z52 MIE2)M5(#%V,9FWWD^>$M!,'\*,*:]BHCO2L*SD=R0$^'W!Z=KJ[6Z'JS_"M[ M<,*MZS,0$$0SA,U!<MAR@,!02E$&?A>%3S7!F,C.NR+AZ!W$2WG#X\Q@3I%P M4FUR`-A#J*AP!<+-+7J(0.2IX\F^-YU?ODKX0P#FSF0%81(a)(P].]&A5*M>"" M^AB^H4_CR?<0/"DH>+,(5;J03FS5.JT@@O56Q3F&(<E\X9_EE)_6#0H`,6^B M..>(<;MM.8[M>7DFH]"BB--8SAA3M?)4MG'%"<$P]<' #@/:(*8QC)[*J%0; MTFJAR\!:#7G4SP['^$Q-GL1%8A9UXV%T6\/0A3@CID?/#T)_..K5F=CMUO\@ MCU?@6[\X3A1*:"J*Y=R"/2W(&<@(B01J3<H^\,M"%R[X#AS4*G\2F[CS4N#( MND^?7!Z:"0G74E BB".X=FK3_7BV#+X'_"Z Z%IO`%W_\Q>H$07T!;#J^/OO MCZ:6ZJM7;R!J/G_Z!@1B8D+ 3CG6UNRE1S^ )0HO+X^X.-^[-U_^_O[%Q AL M+?SBYJ#F%1"LVD;,;*R\8L(,(D*_G[[^_8_Q]]]_WW[]X1$60E8&] X/#]>' M]Q^_??WY[MW'CQ\_R"M(,[-\>/KT_B#)'I `?_@9',7@JN/'7P9V!9F_[Q]! M??J=X?]/AG_\#(PXJH[_0)78`IR1E9N*3CTG[?N/A1TSP'_PR" K`P8D(R?_ M_R^O6'XQ,'T&U1Z_Q3AK[LGNOOF91(a)$.$$ TS!MH$T_0JPU__X3(@O(!Z Y< M?B4E.4C+"JC\XX>O?_[^%A049&/%XC ]!2Y65B9A(0%^?O9W;SZ"IOQ %ZG\ M9F>CYHC"?T7-#YFM7_6M_[*P_WCQYC\SZ\_?O_^S<0C+2*/Z#I0]^ 7X/G[\ M_.7SCP\?/GWZ]%%95?[WWQ>/'MT%1M7OW[_IG#VP!OBSK["0_ FJ.OYR,[%* M*?]]`VI9`<L?YF^@>3=67L9_+%A*(T9A109F%LP`IVZ]<5'$(=K^P@ZYR*], M7/ `_\3,]T5$"]5WX.S!+<+P]0WK3V#-PO 56'M(<A=>E=I]_0,M`AP@@.@W M3@7I&O[^\XT!,O+][S^P9<7%Q:FJJGC__F-)R7],3$S?OOT$9AA^`7Y@0OOS MY^<_U"$K#4GV67'"9SYQ<;#^>_?F`Q.H0?R/G87!S5:3NJ[]*RQY75CRYOU_ M;%I>?^4^_V%B=8H49\:XDA02VMS<7,#LP0!=T<"@JJIP_?J=Y\_9)"7ED!73 M>>0*'N#W/L.B^#^XU\'.P"TK\O74/28A!48F9F 9_/<'PV\>!I:OP,H<U-!" M<3.?)*-)' OO6V!W'![@?QE9F32\J>O:A]QJ<0QU7.M_*3$X\2F^_L; ?D5# M^P\+>NWT']QU8N+@^__E#2N#R&]@XYR1@5&*I^"*Y%R.5Y9*?"B.ISC `0*( MAG-_\&(,F)6!>?K'CQ_ S/#@\3%@!H$LAP$V7D5$1(0$!:]=NW/W[D-@!0(4 M96-CD9 4_O^/^?GSYS]_HH\O0DUF9'KSE>'#IY_LK$SBO S4[6^0"H#!#2RT M@'T/`0$^02$>`0%^;F[>Z]?N\G(K2$K*LK.#;G]D86&AP[0@U@`WWBCY^B<X M>S""$3\#%S )/?KTZ^E#%BE=H/ ?9H8_@@P<C R_W_YG^HT],; P,;#]^?SO M^T=F%M:OS +4K3=(!< `8_KS[?^O;PP\8K^ V8>;@9>'@?/)A]DF+TT5^:D8 MX `!B#N;%02A( J/Z<U4A"#ZHQ\J".K5>E=W/4";(' AV7@=1;W--1 7M0O= MSNZ>N<-W#K.8;K.XAGS>KDN94$:[_88QPNWD(OM&1#ER+,=QK6^@![W&K:9N M=5R([<3L=S"@?@6W@Q5/4XHBC)\<F_!T/L1X"\-'P_KFHF0WYNHC.!4JI)8^ M2H=RRD L?5"E*K2_-4LP"'(+A&U4/[X#IV,Y\,E;)_:\W\& FAY*>'KSF.&0 MTZL$3"!=C2_!['I__5'PMP"B>=Y ;@3_^O45EFNA)+ %!>QV<'-QZ.BHW;__ M!*(%V.L`"HJ+B["P#'"Z1P:0$@BR5 %\XS4K&^A62'9P0<4.Y-ZY_1"8^-Z] M^PQL$/[X\4U#4_'5F^LO7CX%]A3AL07O#"";3-WL@1S@#X =<?C:#P@)['P# M&U%LC.Q*ZG^?7X6(L7YE^ <4%V!@9,$YGDMGP,3(P,P$JJ\X6!@X61FXV1AX M.1CX.!@$N1B$0.@_)SO+GZ<7@8YG^\+P'Y@]OC-\DA1,.")P^=$':@4X0 !> MS24%81@(PTFM:74A8E%$5 JZ\G4NS^5I/(!2*A8L77?31Z@(QDFFB2Y<B*"; M,(a)ED.OWI))GA^T>]8;8Q..?-I#G95-71GDQ'81A!JD %(KM8.7<<U_<727(N M2_[YNS#WY%VS!@>?+)JFMD!WBVI^B+Z&8CP(81@ZI+ 41G&7DFI=\8^CFG;K M-7K!+5(?2](TAYENERY7\^/AU+29Y_6-?\0<R"]K#R-X4KS;7*ZDJDAGT+K& M3%09=3O8S[TQLMZ0.!"\_/C6(<64AJUR$#$M6>*K(:6U@FI8*TWU$EP.<ME6 M;4/@EC10;45;P?U0* Y2( 6)_(a)4\/8=%%XZ85K.0S>@"G(_[V[W8L6PV? ;Y MM> /`42GO ')P;]^84GEP)8Z,'N(BHCJZ6J>/'E>0U,%*/CITS<^?AYQ*3$! M?J&;MR\`O<?("%^KQ@#IJT!7$$(3*2-R(0%?-0A5P@A?P0B)+/3EC+"H@W-A M5B$OE&- N `Q$@0#C$S 7K@\U+___K]]\PGH0CY^?BUMI4L7+K"RFO+S"\*] M3.OL`0_P!Y^QY8U?H*KC)R<#IXKZMZL76.5-&<#CN;^Y&<0D&:5%F:Z>!J9! M>,""+B3_#T[N#+ ^"R/C?TBR_O\/$A3@M5BPP0D&6*$"U,O,"%UFRP3L)(+# M%<*%& O.)[# 9?@/I:"Y`+(8%)QC_C/^`UOQ#[RR'4H"I:2-(-8!\S;;9Z"W M0-F#05(L=O^?-1[?I(40@4E>@ ,$$&WS!B*=0A/2+ZS*0%4'-Y>4M(2@(/^[ MMQ^$A 7 I>]'<;'OP+J1"5*D@'S"`$^D8&/!B?4_M&@'E^$8UH-3*GC[!V@7 M!S3)(&%8,H>J1=T"1!K(a)X^.!LX'6O'G]$1CT_/S\NGJJER^=45(T`68/>"5& MH^R!%N#/?^#H&P!['=\8^$58F7B%_GUZP<0G`4JUGQE>?V40`%8"S/]8F2!Y M`$%"$C&L@?8?7/\R,#)#0PI2:H#'D8"=06@Z!B'P_HW_H'7RC) L]/<?M$Z M+FW\S_@7NM*1";S D?@EC,P,7,)P#C1[`&L/'@9&::F874^6NGV1$N*A), ! M`HA6>0,Y?<$+\U]_OC.@-V% X.?/7]^^?N46Y=;153]XX"0P;P`%OWW]>?WZ M56!S"]2F@J=@: ,'8BC,?-C:<YHNYN/G$Y&547_YZN'K-T^(4?_W+R1[,/'S M\VGK*E^\<%)#S0J8@^ *()4A6O20G3VP!OA#K/4&$/P&S?K]X&+@4E;X<OXT M,&\`Q5A^,KRYS/"'C^'[U__?P8MPX14"+!T#2Q-&<!Y@A"1B*B[%Q016TO_S MC/^MNL&X[A91O6)@]F#]S/ ;G#V>24C';'^TRN>;"#]"`:D!#A! ].B+(QH@ M?U'J#60G??D"S!U?Q,5%I:7%GS]_!1'\^O73Z]<O?B-F=?Y"MP;^0RG:@648 M!SN7K(P&#X\@`\W YR_O.3EY=+2MQ43E"*L&`V!O\,WK]\"N.;#,TM-3N7WG MU)<OT($4R!35OW_X%AV3!Y #_,4/W"L&@,VJ;PQ,0LPLHK)_WSZ B+U]QW#W M`>/[[RQ ]/$GRZ=?+%]^LWS]S?+]#\N/ORP__['\_L_\YS_S7P9F21[&'&,& M?3$:=MTOO&10$F!8ZOL_5)W84&+^Q\#ZB>'/5X:O_QF?2LDE[F1\^^D;V0$. M$$#T&\/]#VK58&]3`0'0]:#Z@>F_II8JL%E%:J)A8F91438P,7(#ENX4NQ<K M`.7C&S=/_?GS6U/#3$1$6H!?5%A8"IA/@(B=C1.7MM^_@=GCP^?/GUC9F#6U MY&[=/O7MVU?,<49D+60VZ5!-@("GWW'GC3\,_W\P?/O+P*D@^>_3<^B^8J(! M%RM#FQW#D6A0Z4ZA:[$"R"J6S)U,GWXRS/;X[Z?RSU;FO[<R*)\`D30/3DN! MV8/E$\-O8/9@9+PE(I>Q^_^GK]_)"W" `*+5W!_$6,BR!?#4V(_/GS\^?'(, M==2(`8G!R,K*(BHFRL?#?_KTA:=/7RHJDK9=24%>1U%!]]OWSZ=.;X/O"*<< M\/$*&^@[,#-C:7S^_?L'LL?]QX^OYR[L0QHJ0 ?L'"RBHH)\?/Q?/G^_?NVQ MOIX=)R<7&QL;*RLK\N8UN'HRFE68`?[BPS?=#;*PT2+DO:HPDIF!48!!`-B( MNO[V[^L7S)+:)-E8;?F_QHKA[GL&HX4,O_Y2K7%E)OE_6^@_;FR9^NMOAI_@ M;>X//S&XK&#ZBWMY_1\64..0C8>!X^=_XX]WYOMR<'-QDAK@``%$C[SQ\^?/ M[]^_O__PZL6K"PQ(F0%.PAG IKFHJ.CG3]]W[CRHHJ* ?WZ#C8U#1EJ-E96# MA865";3^@5500)P!U'L!]6J G@>?=<#T_<>7"Q?V_?CYE6R_<'+RLK-Q`!F_ M?O\$>DA(4%Q=S?3KUX]GSNW^1W1QR\G)*BC,S\+,]O;MAQ?/OAL;V7%P<$!F M<"&3N,@SN!3F#4B GWWVVVLO> T8RI023 .$P<W +LC _?/_QY-G6*0-&)GQ MK=H4Y_Z?;<@@PL7 Q\; SLS Q\Y@!RZ^GG\!D1 1%B:&AQ\9W%8Q//I$?FY1 M%?PO`5XO\N8[*#,XRO^?XOK_VAL&VZ5,D#,?B &_61G^\OQG8F9@_?(OAOUB MHZ<XJ0$.$$ T'\.%U^_(DQL8`.HR8+,*V/<6%A;2TE*]??N^LK(\'I.!S1LF M1F8V5O9____]^?O[YZ_OW[Y]DI)49F?G?/;\[J=/;X""H*+][]\?/TF8(<$$ MW[]_ABRMAX!GS^]Q<'#+RVEI:UE=OG($3W6!:LCOOZ_?,_QG!.;8EZ\>O'RE M)B$NR8@**'$D', #_,E7W"4+W*H?#+^^,7 *,+(K:/YZ?(U%6A^/R9]_@C* M*">HY/[TB^'%5X9;[Q@2=!DD>1CF7V8X^8SA\R_0L2/ TOWI9SS&$ :WWS/> M?H_@WKO$*,_WK]3\_Q+??Z$;\%47R(#U-\/_3PS__O_^P\*Z^!ISHL%;12D1 MD@(<((#H,88+`7_ @U1H`&W:#;QA")@]N)64Y&[>@$X%XC(<6$3>N7<>0_"? MK(PZL-=QZ_89*K:LT,"]^Y=__OH![')PL'.B93SX("H#:D,6&!,_OH/<\_7K MAU>OWCZX?U=(4!A>OX-F2) J4[(!<H _^$(H<AE!:]?__V3X]I.!5YK[YZ._ M_W]^9F3GQ:4<6&:7'T07_/GW?[81@[DD0\%>:K:LT$#=$:877_]923-(\P)K M)!0I:"PC9K/@<U.,S'__@VJ'SQ]^O7]Z]A:3M @?20$.$$ T7Z/.`!MK__T; M^P`N&@#FC:]?OP@)"9B8ZKV #5@1#^[=O_CUVR=N;GY@<XMT)R-<"P&@@3'P M(C 8`S'9]_CQK2M7CW[_\>T_[+ ," D^/XD)/-D"1,S@<SQ TUS@\?[_+UZ\ MN7SIUJV;]X$BR,NJX?,2E "T`'^(=5(<$X"KCO]\C+R:VO !*^)!W6%0[:$E MP@!L;I$'(&-JL$#_"UEV!PYK$/H/0?__3COW/W;S_\>?_C$Q_&5F!"$6,&)E M^@]$;,S_V4'H'SO3/S;FO^Q,?]@9?W,P_69^__C?@V,,3\\"Q4D-<( `HDF] M@76L'6V0"BV3P+G@K=C?OO_XH:MC#<S;CQ\]YN7C@4_<$ 3 T#Q]9CLOK]"W MKY_^@H\'@RP!@3L'J9R 3X8C!"&)&\(#CWQ#W,^(-"T([Z']9\ 8X4#M1T&Z M4HR@HHJ9"=B;!_KBUZ^_+"PO6%A9Q<6E@%'%"@:01,'$1'XYA37 G^,9I$+1 M#%I%\NT'@XX-^V,FQ7=/7C%Q"S$R$9LP@)6)Q>)_)N(,-]_]QS6X".WIP):0 M,")%-RRHX 4,9*KJ/P,\D,%<V#*O_[#3L\#SC[!)2<CR'U#P,8$63(#68C$S ML(a)`1,.LPLKQ_]_<;*Y.6K "I`0X0@)>S5T$8!N+X):D?J(N(X*B;J_@2/H,/ MX+/JYB+H:!=!D+:!#DT;8BY?K0JB(*9+.I2TUW\^[W?WIS45QB[+-_N-AZ*[ M1I[S;CM9+E:S:7R.CYQGNL>;SU<U\>0S6CTJ'AOE_ ;&UV-'!^(0'7PVC!?* M_HF7$C@KXAN@3)N;4184SK!*+995YP]K<BC@- "6P]*7=*42I1@-QQ8C?XK% M43_RBUN#Q_G'X9 %B!RN"6S6(a)\.IO]N++-7S/&#.! 70/.ARE%331PZE)-L+ MUCM10]_.O%[KYN6L12P6`@82J7$24A_2!'VCQ"-HH=V1I&($DV<AAT*)Y[7< M\&9N%?5+69R')+I?TU0493F?])2LOC7X70!>KE@'01B(MM4$UJJ+BX.#&Q_@ M3_M!;CH8,9#86L0`4ML[*%1,-)IX86(XR.7U7>_Z>O^KQ>_>P5\OVB\2B)87 M:?EU'$PG"\YG0NZ.<7R12@AE52"U\]U]Q6_)==#&]PV^#8.[L5^6SRFCWG@\ MVI);V[] [Z1+^1#9RI3X)6I1^B*N]YNB)$FO6<[YO +#Y3+LN/]B[F>\PXVG M)M7 ZHS$![()R7I%(Q[LMT2<R$WI0A4>OG%"FW-&6WP#>;,>H5# -T/^AL?@ M>\1 =XC09\11BEMF31) ::<-NL4W[+1T7<+5%%-<:_)YQ,]I6N8J6H9?!/PA M`"W7KH,P# .=4&!!/"90-YCY_V_A%Y@04=JBYH6=%Z$PH(IZJ)0LD4_7BYU> M.N&[46I8KQZ85Y;C]_@8HP)8=Q>WW?: *6AM_9ED@^UO-:\\OWDF.(\,9SQ[ M8GDZTH^/Z!WT\NU"^Q OZ&H[(/>/%!\7J%M24L%X.N[S9]H_+EH"?FVATRQZ M`P?Q=<:!$F0"V<Q +N"B0#0X9=9+K#U8*E&0T)'BU$XE(7])"HU"J>."Y8T@ M1\P-A%R)Z/2W85 %V-,!CIMTWTK3R7.]&@'X4P#1J4WUY_</+'D"=9 *T0:% M#; Q,[,Q,K*PL?(+\ N_???ZWS\.'AX!<'#_@RX@^0NL^G]#%Q"26(33'WS_ M]N/'CY\_?_X1$!"BD5,1E<979@+C'HSH7&!9+L#%H,+%(,[)\/H5P[_W_UE8 M_\D+L8 #G &:LD%ME7_@M/[_#RC04==J#C+PY_NW/S^^<_[[JB J1D: `P00 MG=I4O[$-X&(#\.E !F86)A9F+K#(a)O^\_/GS\^.GKEY]?O_ZDG5-I#;Y^_0;, M'L#L3<D<'T$`"7!B!ZF0VEK "D& EP&H[=,?AB\?&7Y]_O7GYY>7OZEYA@N= MP:_O7W[__*8K@EBA35* `P00;<=PX57\GS_XTC1&EP,D`)J\9.0`"_P%MJD@ M9VS2SK5T`)\_`S/'=UX>04;(0"]XG 3KGF;R`'* /_]&2JD'MIR%E4&0&Y0W MOOP&K6 'U@XLM%S73 ?PZ^NG/]^_JHFPD!?@``%$J[SQ'_4\&,@@%5*K"9]> M2+W!Q@9L4('.S_L/S/\_?P+;4.#.WE %OW[^`HV_??DF*BH!GX&"K)JFRM0X M6H _(35O,#*PLS,(<H!ZW,"Z^1>H>_B7@E'E@0=_@2'^_>O?[Y]U97C("W" M`**^[]':<_^1)OXP`:;;X X&+VYE!IOP\^>/G^"]=4,XKH!5QH_O/_[]8Q(0 M$$0^(A]"4IXKD+G_D(_>(0A@-G-R,O"S,?P!UAO?@'D#V)+]RS*4`_SW]Z_ MSH80RW<986[R`AP@@.C1IOH/&GHCJI^ &'8%UANL7. 998:_?X'5QB]@YX^) M<0A'U;>OWX&Y@Y.3EQD5X#HJA@R '.#X5J=C`O!<`0\/`P\S:&?IUZ\,OW\! M>]G_F(=R(_8WL+/QXZNJ( /9`0X00#3/&[ U%G^09+"N"X7)P::3V=@@1W<! M^_'??OWZ`YHP&K+%&# </G_^`LP>0H*BD&-*@ `YMBAO4S&@!OC+'TC'.>,+ M;Z@(,!?P\3%P,C)\_\_P]0O#W]__F!C^#]V\`0R'GZ#.QA<="7:R`QP@@.C1 MWP`WJ"#3=8PXNARH`[B@7,#$P@(9I *=W//GSQ]\$U>#'H":OM]^?/WZ34Q, MD@4&T.*)0BN0`_S)%Z:?_Q S/%@`(RH;-$D'&J1B9P#M=OK^E>'OGW]#-E^ MP-_?/X%MJG_?/^G)\I$=X `!1(^Y/[RKTY$!> (;=! %`\@C3) 5N'^!Z0J8 M-X9NI<$`[FQ\__'C/P,+-S</O/2"Q!8MVE2/\:Q.1P9(-0D+,X,@#ZA[]_4/ MPW?P(!7[H,\<(IS_Y?D9^-G_<X,/L%IUG?$?;/GZ[V]??O_\+L;V4XB7@^P` M!P@@>LS]_?E+T@`N^,0A5E9&Z `NZ.S*OZ +Y(9RWOCR#=C;$. 39D$"N(HQ M"OOE0/#R.\EAQ<8&.A8-:/&7GPP_OP,[B'^8!WUX%YC^\U:!CD,\^,"PXAHB M,0,[&W^^?]638*4DP $"B![UQG_0\2I$K:)CA*T@8V=C!U8>8$-^_OCQ$Y0W MF ;O)!0[&X>8F/2SYP] EQ5B`%!GX].7KU^_BXI*HK5]T>X[I= 9\. 69/D% M78Q)#( ,X'(P"+"#KC?[\AW8`@2M9T:^!45)X+\@!Z*$%N+XS\8,ZJ)\_07: MAW3@$:+ I@5@8OS/PPI:J/+^!XHMAN*(`;J7WQAU1?]??@U>C0=,-%\^_OGQ M14.5C9(`!P@@FI_!`V1PL//_^?.?C0T^-\F QD#F0D@V-M@@U3_((-4_%I;! M6XY)2RN*BTF_>OWL[U\L0]4_OO\$-JB^?_\E)BJ!V2FD;G\#PC 3_<G'^.T3 M`Q&W9,#"G)N;(a)8\%-DCU$W2P%#.L$<O*]']5P%_<U<C_D\\8LW8RD9<]A#G_ M*PO\YV=G>/V=X<9;QA](6UZ!]H9H_'=1^*<CR@`Y]/C[;X8=]QC;CS/QL#&L M#/@KRH4PQUSJ_]77_RZ_!JG[\_/[[Q_?F']]T9(2HB3 `0*('N<:`MW!SB;\ MG^$],2HA([ALH-M/0*[_\^?;[]^_P87@X&W^\O,+_?H%VJ0-="1H\SH3,V3/ M.@1\_?;MQ_<?S,QLG)Q<R U?"*#6I#@R8&9DB)1],_,Q<3?(@!NQ?'P,7$P, M/\"#5']^_P.=JPESE;(``_[V%3!=`M'QIPA?`$MZ!7X&#6%0>?_W/\/C3PQG M7J#4+4 %(>K_([7^*2 NPP(E?6"ZWWP'9)DDS_]I;G^198& DY4A4/W_RZ__ M[GY@1,X80/#E%P,PBT+8X-';[S)<O_BXV2D)<( `HM/]&^RL@M]^OF-"=.]0 MAA7A3H5D:2#)"KT9Z/^OW\"\\0=^R[B$N*R@H"@;*VB \N+E$_1Q/#,3,R^? M`"OH]N%_P H`Z,;/7SY"I.1D57AX^#C8.8&EM;FI$V15`I!]ZLQ^^#%"X+6W M/_B1.AMH]3NR7=3*)WY2[^<\EO[+`(M?7,.XD$$J)@9^/@9@]^[U/X9O7QG^ M_?G'S(APB3P_RMSBK[\,N^\S6DK_%T+:K2R"Q/95^9>D]P\M60.S1\$>YGL? M0&9RL_Z?X/+71)(!#0"3?KW-OTNO&!]^8FRU0V2,K7<8I7C^&\*.N.5C9[C] MCO'\"P:XR-WW#"'K$2GYU]?/?WY\U1)CI3# `0*(5GD#>5H>Z!I@&^G#)V8. MSO_XAQ49(:L,F>&K#"&#5'\98;-^P+3(#-X#^.'C.VHY58!?F)>7'US8_WC] MYOG?OXBI&*!=<K*J8J)2R 'ZY<O'RZ C8QG86-F!>14B]>/'-Z#VWW]^`;L< M'SZ\@6<,(./K9]#UAK(R"I@#[40N7B &H 6X% ^#*=>+$]]E" SCPE89"O(P ML$(&J4!YXR_RM5EJ0BAY`Y@0:PXQ5UO]!39XX()?0==#@&J#%KM_GLI8%KK* M\C&TV/V-V@1*;]56_^ 9X_H;8#.)J= ,&ES "DI/#-29@:?[CS\9Z@XSM=K] M@V]$N_H&E'E$D.H->(W!`-K<\_?7MT]_OG_6D>2@,, !`HBV]08DGB D*XL@ M`\-;M/U,6%<9LK+"5QG^!I;3R'GC]-D#,M)*,M**W[]_(6@[L+P7$A(#-GA8 M6=E___[Y[OWK=^]0-J"+BD@",QL;&^+06%D9I6O7SWW]!CTG0U/=D(>'_\W; M%Y\^??C__Y^(L(2 @# \6_[Z_1-8/R@I:@([&S=O7_K^'<LQ/]^__P`-W_[X M+2(B3KO16SA #O PZ=<G;DL3LU*=%;S*D!'<,@$V!O___<N"-("KBG+/(2AI M`DE!#A3!N^]!@L!F$CQC_/W'4+R7*<4`U%N `$T14!<"F$F0,\^2JTQ?40_T M`V8S&UF$@D_@,<YG7QC6W&!\^97QRV\&8.,-V.*21;JDZ>P+A&O__/C^^_MW M]C]?U:0H#7" `*)AWH"781#W`7ODWWZ\8\-[L0EDBRLPL3(R@D:E_O\'W8<$ M7DD%':0"]>PY0"4&Z(9R,6DA`5$N+M )S<!&SK-G#^!I&@B A3TPW;.R(J:' M@3D!F#UNWKH(X0+S&# G`!/TW?OWOG_[RL3,)">C#,P)\O*JP.S!`+JLC(^7 M5^#'S^^?/KW_\^?WK]^_[MZ[QL/+CY;!^/@$?__^A35C,("7B@#S!CL[%_QD M)+0JGEJCMPP8`6XF\E7^P8>'?PF=@PI99<@)FIW]\IWAYP]@(?"7&6F02@&U M305LZP/K!SVDTSZ![25(a)00X4!.8$N."M=PP''S.E&R)$@!D/V)'Q4$(9R@.V MH+Q1ZYE;[QAM9!"Z@'E@IL??&>>9SKY U&5>R@@%P$QXYCG"M;_!Z]*5^/YR ML&%O4Q$?X `!1-LV%7SQ(SCOLO[^!4SVO[ VJV#;A4%2;*S UBO(8?_^@[8" M_?OWGQFI,\C!`6K;RLNI`DW^#[Z:$9@!V-DYA 1%KUP[\_4KZ(062+H')NM' M]ZY]^/#V'[C(5Y!7`ZH!5B,?/[X3%A('*GC__LWMNY?A`Z\WOGTQ-K3EYH*6 M2,!F$C#1`_L2RDJ(2QE?OGJ*G#?8V3(a)X.;C>O'V)*QR^? %VQ;_S\0EAUN_4 M6BH""T#T``>F#3>!Q[/?".);40"6XN1BX&-E`%V?]XWA]R_0;CUXO0'L&\BB M7*/'(,']O]CL/[PK#&SS-!X!M7+UQ!B0^\? Z@582R@C9<S'X+-S+)'." 7J M??*9T5 "D=#??0>)O$0M9X -L#F2_\Z_^-=[BAE2:YE(( P!9L)/OQ ^_/GM M\Y_O7[4D62@/<( `HE.]`7$E![OPW[]/<9U6"!NC`B8X+O@@U:]?OT&'=\,N M-P-*<W&"*@I@KGCPZ/;+EX^!M0HP@:JIZ?%P\P';6L!J(a)8]7`)CNOWS]=.WZ M67BZ?_'R,2\/OXB(! <[UT>&=W)R*D"-=^]?0YZ1^ =F_X;=9 LL/\]?. JL M*(#]"H@/)"7D@,TGT"W)OZ S_=P\H(3S[1NT@0>T6EQ,AH65]?H-T,%90,,_ M?_X*S!VJ*IK,J "S#*-%@/M+?USXYM<O!C8<&J"K#'EY&7B8&'Y"!JE^_6/\ M_X^)$9HP9#%.JXK71:3+O0] (ZIOOX-\82Z)4OS?>,NH+," ?.$<)+>H(;70 M@)4&D-001F@\`VX=S;O$I"3XSTT1Q4!@#V2>]]_@=<S S&."9-<II,[&O[]_ M?GW]]!>T5(2'\@`'""#:]C>0XPE\"1C'EV_ F@YZ- X:@!\VP<H*N<CB_Z_? M7T&K#!D0&1W8H()4%S=NGO_T^0-$$)A2GSRYIZ%N`#F94TI2`4@^?'@+;28. M<B+ SY_?@0X!U@:_0 =0H#1UY>14@18]>P&Z?IN3DUM'R_3MNY</'MZ$G-?" MSR<$VOC^Z^>OWXAI?A;P(9DRX/D-H+% 9;___+YW_SI$%K0)]ON/7S__"@EB M&:2B8J4!!V@!+LC)[,3[9,<7)>RJ45<9?OP'766(/$BE+8IO!ZFSPG\%_K]) M6YF!);<J:I?]ZFM&-+WG7Z+G%J"($GAR`PZ .0I(`IM>Y?N9-]SZEV6$Z*X` M`5 OT,R__QF0JS*@(7#V'V!5#]T$*T-Y@ ,$$,W'J9!C"[1=Z1O?___OD=S' MB-0OAZXR9(6N,@0F1)2.. ,XR0))8*Z 9PQD4R"-?FYN4%D'7IZ(`,!>`; = M!2S@/WX"]:2!J1S8O%-44'_\Y-Z_?W^!=8ZTE"*PG_WZS8M7KYX"%0`5`QT, M3/' 7LK??W]9F$%[QX#FW[YS!7F_Q.LWSS@YN8"&`^N<#Q_?OG__&DC"%7P% MKZ/BXD)9[H;6+T3S`M4#/%#\Q8[/"@SP,$2S!+S*4) 75+-\_0M=284\2"7+ MAY*^'WQD./B(,5C]/P^L*@*VFH#-I)WW&9&'LW[]!79+&((UT'.+N12:",K< M-@.X$I#G^P_,9D#S@=W]R6>8Q+D9FNP0C:YGGQFU11!:@)T-Y+P!GMGXIBW$ M0)4`!P@@VK:IX,U?2#$&!)P<?-^^O^7F9L(89@>=40%>9<C"S 09!/D#[#" M1E21_, %SAN_?Z$LT *:+RVMR #N# #);]^_`M.]JHK.W?O7@7T&8%4C+"0& M; []^?OGSMVKD(3[^,E=8(]%0EP6B""&`"N91X_O/'WV`,(%5BEOWKP`>H"= MC1V8-X#E/S#=O__P!LV/0-,>/KJ-*P2 #2I@[A 4E(#'$.: "=4'J= "7$OH MAS+SZ[O_Q3'"&[+P`!C@L%6&OT!;8?^C;H75$$:Q`I@Q)IQF-I/\HXETE0.P M,\C'AM(MN?L>5/8C)V)@UP+87T\U0#G=#5A+N"JB=-:!G8?);O_@62AW%Q-R MT@<JN/&6`;Z&"@@>?T;M;(#7I>LJL5,EP $"B!YCN,A1!03_O_. ;H''NG,# MM%J$E9$15,O^___K.WB5(1,C8B45)[BS(2PL_O7;EP\?W@!-!]824A)RP/H$ M6 -\^@R:>@>F>V ]P,7%HZMM"M<([)$#FSKP?L*SYP^!'1)@!QW8$ *6E,!: M"-A\`G;KX>I?OGH"1)3X_??O/Z#S2[]\4Y 30QY)1*[B*3$?*\ :X$%BS[I? MB.$:S 6M,N0$-3>__ `/4OU%&:22Y46;W !)2:%V0NZ]9T3N,S!@ZXA#NA; M%A224:!DC3S>!<QXP!R%/-7X[ NCDSR"N_4N(UJ64^!GV![^QW,E>.3FSV_P MB3N?M:2XJ1+@``%$VWJ#`:D%#(DG8"W/P2;X^_<W8)1@3FZ !G!9@1D#,H#[ MX^>/7^!!*I Z8#I64@3U:"$JY>54@ BB$=C$OWOOVJO7SR#<+U\^7KAT#*@> MF$. W.\_OKU[]^H;QGS(IT_O(a)8AVWO\.`C_^_6/DYQ?$-9A(];XX`[8`=Y/\ M/./E]\\,7!@:0(@3O,H0LA7V-[ __O\O,\Q5P-H`+1O<?L<HPXO20X UGU"4 M`2L$8)\;N6MQY#'(3.2Z!9CN@<TG>-<<V#H"=L&!#$ZD)(F\CNO99U 3BP$T MX\&(?"#E6=@`[N\?7X$-*B'F[U)"(E0)<( `HG[>8&1$N=,#LR0#-G@^?P&2 M_Y#4(+K;[.RP0:J_H.MVP(-4H! !ZOOZ]1,P&P!+=V";'ICN@2) ]N?/'X!- M';0]T\ 6T7-PEWH`P1?0NO0?W-P"S-B6@J+%$R69A&" <[.SNO,]7O-9'54; M1#$#-P\#+PL#L)'ZY2MTD(H9=ABN$NK4""0;>"BA3Y,#RW(A#I3&TN-/#,AS M%*^_,6RZ`^X0_F& =U1L9?_;RD('2X 9H_H@$V1%R:KKP*87U I(Q@#*KK_% M",P87W^#%%0>8')2^ \L,('MM$\_00N!H<[[]N7/]V\&(HS4"G" `*)YFPH" M(*Z$U_),C&@]<H1*-M @%2-X*^Q78+/D/RS7`-,Z<G)'FX ;A. +J+/Q34A( M'EZMTWJ0B@%W@/N*OU[_2?4OVH9[^"I#\%;8;Y_!6V&1!JF4!5"R`3!EEUG\ M0\L;P(80R+._4,KR:>[_X.4]L)-0O)<9LL!VX66F$G/T`Z6OO&;H.L$,65X. MTGN.^>"C_P;BH.[X]]^@FVZ 70[D3@60O>$6EG #G;CSXXNN(OIF)K(#'"" M:)(WD$LR> <1:227C9.3]_NW=]P\J/D8LLH0MA7VYR_0*L,A>G["KU^@ZPN_ M?/ZFIB*&M7ZG;G^#8( K"_PT8']^]I<TDA[H*D,!/M!6V+=_0:L,_Z*NI%)" MS1O IE0(ZM#3BR\,JVZ -.RXQQBORP!??0C/&,>>,':=8'H(N\-IZ56F"R\9 MS:2 K;+_W_\P`JN7JZ\9'V+<\ 3LKD#F^(@'H+N)@)V-;Q\U)06H%> ``42G M->KPV(*79%^_\?S__PV\3@\Z2,4('G&"K3+\`SFOC=(a)-.H,,? .?N,/"PL'# MPXMK=I9VMF,-\&#19V>?2C&(a)G(K.P P>I&(!E^Z002IF)(<IXUYN`FSG''L* MFOB#[#=Z]8TQ? .SNQ)H,P8P8P!;.\ .^ID7C$\^4R'=$P-^?_\&[&S(<O\6 MYN.D5H #!!#-\P;$3?!:'EZ2<; +_/KUA8,#VE\#.Q^TRA"R%?8_;"LL$R.Q M-V\,*O 5O"Z=EP=Q%!5:_8ZLF!8]<LP`MQ3[+/[\\\O_L.XPTBI#!LA66/!* M*A9FA&/$N?Z_^,KPYAO#F^^,[[\SO/_!\/(KX[L?#,^_, (['C]0K]X#JEEZ M=< *LM_?/O_Y\4U3E)F*`0X00#2<^R/4(V?[_(6=G?T/8KL?RBI#8+$+6F7( MC/=VQL$)("?N`#L;XJ)26/N%-!JDPA_@'&RLW@*/Y[U'N@P6=I8A="OLC_\, MJ*L,`]?1:7L/A0!\XL['/]\_:ZJBG[A#28 #!! ]6O,09V&.N[,P"X!:33 % M#$AG&?[]^_T7^+PVQB'8WX <[_GC^V\)"6D6)$#/-A76``^0>,L,OST+;#\7 M>)4A9"OL'] JPR%Y)A7D>$_6WU]UY02H&. ``43#E(<Y#(4<6\!Z@YV=\^</ M%L@R*MA9AMRP02J4[7Y#"X!6BGS_(28F`ZP6H:4`;4X500,$`UR8F\6)%SP+ MA+3*D)L1M!7V"V@K++"S0>G%40,"()M@'979N#C8J!C@``%$IU(95TG&\)\' M7#E AJD@V\09(.>U`?/&D.B(PT\3_//GSZ]?/W]\__[^W7LV5GY%!0U6)(!K M50^-`*X`]Q=]"3Z"!*0&6$/P@U<9?OO'\/T+="OLX ?P`/_]Y\_/G[^^?O_Q M^<,[.]'/8?I\U UP@ "B^?P&\M@BEJJ#C1>8EMC86%#/,H1=*C X&E2P(P,1 MUYK!+@'Z"[JBY<_?7[_^_/KY]_]_)M"=IO^ )*^P$!<'!P<[&,!W-2'W"VF4 M/0@&N)[@)X5';Q\PB$!7&?*!M\+^'ESGM4&\`+D[]B_H!CG(143@H/__G^7O M3_9_W_@9O@@R_>)F_"7,\MU ZKTX#Q,G!S=U`QP@`&]7L,,@"$,1U.!TR^+^ M;!^VK_1NLF2*K)11&PS&7:7AP+6O+<UK&EY6LG7<A MNS.\+R83NM@R_9C$! MAVQ#JA(a),3-.?],]6$<LU^^EX7P!X!X++`$BY2,8DK-(a)[8KVZUM$X5.DS=C;9 M2.TOX,_'\!II5; J1=_N_VO+U3@VP$G(#QVXT'4=*XX%Y$M<&C]=\=,IVPC3 MR_FFK"[L7=&EEKB5/0-.8\\3`/\)(/KE#4B1ACDM!6Q^_/KU!IC5D589_OS^ M_2=XUP35!JG D0&_QAIZ9RN$!IU*"B[[@8G^WU^&WW^ BIC MS""N/_^,<)3 M/P/J4G!V=D9D`$F%\*CBY.3DX@+5'FQ@@%:,P<.$6A[$!+@"W$7\T^QWWS\S M<$+.,OP'764(2JK(@U04`G##!U39_H5=T_X;=FLX,#\`4S_7OZ^\C#^X&7]R M,7P78OG)R_23D^&7$/-W'E9$ZF= #7 PS4ZW``<(('K,;Z#5\FC+&8 ]\@_O M&3DX_H!W)H'<\_<?EJVP^ 'R2<G__L&ONOP#/704V,W\\^_W[W^_0,> @,Y? M8F!@!DL",P#C?VCJ9T:+#&"XLJ#?9((63R@,> D-'F9@YP0#2$D&*<9HMU0$ M&1 ,< %.UEB^:].^&G!R,@M +MR 72K PD1L10T/\'_@Y ]I^0`#_!_X_DM@ M@+/\^P5,]#S_OP@R_N1F^"[(^IN7\3LGXQ\AUF\\3+^)3/T#&^ ``437-A76 M' ]>F2OZY/%]45%QR,@B[%(!%"\AI7Y(R0^YS_@/O"H`IO]?OX!5\S]0H@>7 M^J!Z`"7U,Z*5_22E?JQL-!)>/+/#`*08`XK@FH<:D `/E?U\Y<K5!XS:7$S, MD$&JO[_^H0U2(5(_N''Y%]ST(a)=S.#2Y^0&4_]_^OW S?>!A^<#/]%F3ZQLOT M@X/QCS#+-QXV*J3^`0]P@ !"F3"B'4 ^D1(VI//KQX\?7\'@,QC\_?=.54U> M2%#\TY>']^\__/;M%S#U0B[T!E<&?X&M'6"7%U0V_0.W^T&M(6"[G^'/7P:D MU(\2'\B!2TEDX(H;N!2\&(.7T&Q(`%*,(9=DT-"G63XA)L#7ON"]+Z<F*,%S MXS;3TWO?&']^Y6!F_ M+_<#V/S#U\S)\X?K_G9<)6.I_XV/ZP<?\FXOQIP#3 M=^2R?[(a)&.$ `#4#>^ _N;_W^_?LGY-IP6&P!R2]?/C,R_?SS%W1^+#""@!4] MJ/O[&][K14K^A #^"" C,HCA0@HJ2$D&[_XBCYD@%V,DQ1.-`OS=IV\WOW/< M^\+^[BOHFF0!QJ_ &H '6!4P@K(!"R,B]8_ ``<(('HO"F"$E3%P+P%S^1\P M@ P1??_.]/<WT_^_K, *`MB2!<8KZ+)W9BRY`FL$(#,88)>"4BLRT"S%%&>& MW2C'C+KIC/ZM*2(#7.#?/SWF[^JL'WYQ_P**0$8F8/K06SXC+< !`HA.>8,1 M=;4/Q#_@T]%9@&U$R'0!1 &\=X4:59AM5M(*),HC`U,*JV)D@%QTP<%H@ ^5 M``<(H %83 :)-D9PI@<68\!(`O:?(%'""#J''%2V_0*/*&%&%?$%$HTB`PTP M8&OF8;6(@<:-J-$`IWJ `P00O><WX&PF\#%3D-B"M(DA@I!*']@X1HXJK&&! M)PYH%QEP+AH#4QQ-"C,T1@-\D <X0 `-S")D1J1=__#X8T(:9X34[_!Z'W_@ MXH\)ZD8&`T;H8^5BL@<6C 8X&0`@@.@]OX&YQP!8I\,#%!)5D'B"E&%XFK]$ MQ@2U(@,K`RN78""0'G)D@M$`)U4Q,@`(H ';O,((*\G@7$BT(:WD^X<UJHB) M#P9J1P96$2+].$C :("3"@`":" W=L%C"Q[$D+$4S'ABP!'TPRPR: U&`YPD M`!! =)K[0P9H-B(OA4(#<%FT\"4F2AB&8&30"(P&.'D`(( &(&\P8,06`U*$ M,:#.Z<(5$!,9Y 7KX(D,VH'1`"<#``30P.0-!FRQ18S4\(X,FH+1`"<5``30 M@.4-!KQ10BH8'I$Q"@85``B@@>^+CX)1,#@!0 `-B@W9HV 4#$(`$$"C>6,4 MC +L`"" 1O/&*!@%V % `(WFC5$P"K #@ `:S1NC8!1@!P`!-)HW1L$HP X` M`F@T;XR"48 =``00L?,;NKJ1S,R,3$R078@0!J.@H*BDI.RO7]^>/+G#R,@( M%T=E,R!K@8DPSY\?QLS\X=LWGI*2G<G)#A<NW#M__BY,#;)Z)E%1"28FAL^? MWP/97%P\/WY\803O\4<V4TA(E('AW^?/'V#KZ$!NAE"P91'PTZM `N"3-/Z# MCX=C^_W[)XS['[;H#JH`IOZ_@ "OB BO@ `7.SL+(^/_KU^_.SHJ"0MS/GGR MJ;5U#U@/`YHAR BR,P*"MF^?0;/8' 74! `!1&S>@*<V1O#YVQ#TZ=.;[]\_ MJ:EIZ^J:W+IU^>_?WXR,*&HPM8!%0&G_SY]_P,S&QL;,S\_&RLI^Z]8S3$LY M.+B &>/[]R\?/[YG8^-D86'^]NTS(_3P"[B9(/#[]V]VT#&#R Y&+ <"[W$# M,2&;W9#GX__]^\L(.EGT#W[OOWOWZ<V;C[!L\P]HE(*"@+"PM+ P%]P*O*'' M"//^@*U"& 6D`H `(F%>''E],AS\^_?GUJU+VMH&AH:F5ZZ<!Y;!\/0*2Q!( M' 9H@K:S4V!F9OK[EP.80SP\+#]]^OGY\S<FU(.*^?D%143$W[Y]^?/G=V9F MUC]_?H&N<6*"50JHX.?/;SP\/ R(5 BUBP%<8\#3+F8B_O__+_0.>A1!E+5W MR#K^PPYRW;'CNJ&A%#!O2TCP/'_^&3.LD$L$T(&_2&&(!FQLTL%'9# "PP2. M%!75/WY\^^W;1\CQ`,#B`UA2_/W[\___/_#*65A85%%1Y<&#NT)"8J]>/3$T ME X.5OS_G^/C1]8#!ZZ=.G4+.0H80+<T(a)8X.^?OW%P-J88<<N0("0A(2TL^? M/_[RY1.2&N2HA @RPSW%PL+^^_</!MA!;\@DI,)$(O_!JU 8`UZC0NK>?Y : M'K9D_G](B'E0D-2_?U*3)AW[^?,_,)GMV;/C]NU[\*7#< 9<+S(7S3T0Z^#N MN71I$69TP % `,;.9D5A&(CCD01;; EE8;$HXAZVEX45A06/GOJDOH17'T$\ M>!'1P H6)&P1*6K-3A,M;>)73FU2TLED?O^90S]>SQNEF"MJ-K39;-+K_81A MZ+KV:K60U9<@!'6[`<;"=:NVC0D1&(-(GRFM>IX%7H*>S>;H^V_#X4A#""*E M7F^NUPR"7C*3WJ-"M33-ODUF636U267+T0--EWX$/"J:HAL(Z<=1M#N=4BBQ M@N!=8^-F&LG3YCTS$"H-Q_&?XU!(a)0\T$.3E)8E5D2ILS9S0:;<ZYXWB,S8&9 M3J<E?\U.#H?S8/#=[W]-I\OQ>*)6"76LC(SCU4*UFR+7#NDHP?D6/ DS0RI. MDKVZ!ETD)H-<]F2(Y<LIO/TA\LC6"LNG8!2#N(@'8UN$/N".E%9\_Y.QWRCB M)ACF*3*>-3:''K=_`43:>BK4EA(C,O?2I7-/GCRPMC:7DI+\]^\7%Q<;$ %# M`](a)4.7'B"= Q7%RL@H)<4E*\-C;R[.SOF9D9/G[D>?'B_[U[]]^^_8A6:;"S M<P!3`[ %!10'QAIFT8X)OG[]Q,O+#\\;Q*_5P@A6:.I'#E,&!H0X`RQ[0 X> M('AH+VI+#X\ST-F02ZV0G G$T&8AD"\CHPBL3KY]^_[Z]5-(DE56%F=B>OKO M'W]/SS(@U]W=5%U=7DU-X=&C5]>N/7CZ]!6P[F5@0,D)R!4LG/S\^=/SYT]$ M1:4?/KP-:<$R0 Y@9?P/*[O^(]<VOW__02ZSD0II1*Z 9PRDKA<Z`[FZ@&>/ M"Q<>_OOGSL3T")C;CQQY\N'#[T^?/B!'&7)VPA:5*#D'%H]$90^ `"*AOX'< MIL*0`J&/'S^\>?/VRY>OMV_?A!3S.CK*QL8:ER_?AW7!&:=-"^;F!I6%GS[Q M+EUZ0UE9Z<R9*ZA)!!0!W-P\?_[\1A:$)4T\50>PI/O-QL8!J]^Q)$0\R[0Q M52)9BIQ#$%D%HO#+EY]P0;AKD0,'7D+CLAO54HAZ)BXNWE>O'B$9B.(9/CXA M45&9!P]N??CP"E*L9&2XL+ \!RI[\. UQ($[=IQB9#RMJZNBH:'HX&#Z&W0\ M).AN[V?/7KYZ]?;#AX_?OH$NQP(VYX E$1\?+["N!FJ''(/&QL8N(" B*BH) M+)X@WOGPX>WKU\_ ?2WDC %IJ:+D#4A[!GED`GJ .E+&@&_"16Y-84WEGS]_ M!_OXGX `Y]Z]Q]35]8!%!K9L@(7!P(">#3 9> ! `)%:;R"WJ3 !`S!I?OOV M"IZ+P)V*?_"@9&-CX>%A!UWB_H>OJFJ+L;'1X\<O@'F)">-*% $!P8\?WV$Z M`.QM1N32'5GJQX\OP"0%KSJP>1_8)F$!-J+^__^-5+3 $1I *8%@MD,9H+!C M`5U%\/[]-[@#" 4=L1UQ$1'I3Y_>_05=B,&$ZO'_X)J*75%1Z\F3^^_>O8 T ML?CYN=75)1D8'O_]*SMMVG*(,HB-ER_?N7(%- "HHJ(@)R?-SR\@)R<K+B[^ MZQ?X2&WP!;W "O#W;_!!PZ TR@"Y@.K-FS><G, 2ZL^G3V___OTK* CLVPB^ M>?/TPX<W<.] *Q&0.0S@(]41K7SDI(_1ZR"JTH"0G)SL$+L^?0(V7)F ]20X M?S(0S!BX291(Q ,``E!V-3T$`U%P=]$@I3X3' 07P;TW/\5_Y6>0(.D!09JH M1+4],+MTNU62ZJ%I-NG;['N9-S-[V/W+;T3\2V*N(QK,YPN.XX2Y(]6J8=M7 M^==H-,3Z&2.B#)"/G<5BKL[R>+,\+95T6,QP&3^Y0NWNE&\,\&/N8=S%CAE5 MPX:-A,\@;FLH@Y?@\N]W-PZ&#YS\J@$QS6XNET&EUVM;T5K)_I0RP=&CZS7 M&]AX`>,C"9I6& PF:.&'@R4$)Z>4V6S*&(0KNUQNXKXK&>PEG_AKN=RL5EO" M@=?H]WN&4:,T"]YP77XV+H0*4N%Y7A!XP*3L;JU6U_==X.%XW-7K[4JEJ6G% M\WDOY1E1>O,CX7U5FY&>-/ M`X[''4K!G]2R3ACW_2!9$?(%*K%.%T:+JI.F M+D\!*+&"%85A*)A*0C6X% NF/2RRX-*[%R]Z]R/\/3]%_ !/LNYE$?0@M!99 M;4!:AZ2MH637W1S3U]>^)/-F)O_V&\0FJTA)"W#8.=99\P!"PK"_7G_H@.ET M['DO4H+$"4[5</B.-8KCN$Y5`8,$@9 RP]G5>50E#ZZ@%+[%X[P#!96FB6Y: M509HWXPQ%]@PJS>[?I[?\"(HS76[O9[ %%RORM,85H0\)F>S2$ES:;0Q0GZ& MQR^[T7@$A9,DAQH8&A7ZNXQQ(099]KW;?2JU5G+1=GN(HE?'N?I^.I]/%HME MY;/+7E,8!N.H!J54B)#S+F-M5(#=NP$FUXNZU'9JX;3??P7!`'@`)\/8G,^I M[PO,`$NGTU%?59FGTXJ-IZ1AWBDUVM!H] :]7!2MU6J#_T,%.KC:4"M"[ 12 M!Y"_P>,N`&57L)L@$$2W2BHQ2%%801(/;2]^@(E-/'OE;ZNW_H QZ<&#!YLT M6!HL!FH13 \-?>LF"U$T+0>R&V"S.SOOS9M)@'^_VR1<^510=3IV%'T6!%55 MTVZ62Q?MX?"A4JE.)D^CD5.OL]!AVUW770D\%!I E+5>^T<LCB$MRZ34`"H@ ME&$FY"2&04%R:$?1!DZ/I]&5I&N^;%'#/:$6W(:@`<V]456=4K/5HK[O`2)" M)6>LL'/5;&J ,;K[_7<0;(7%>[TVI:QD/)N]E>Y-T>FAXC"KRU85$T-82-.$ MY#S'=10[UVH-B!PLTW5?Q25>81N/G^%VCG-'2-SOWRX6[]/I"]^5@V'SSR,( M3@,!>]Z*M[$UT**RK*BJF:9;P(#D&>9/&'X@]T!X@5,FR1=H"W<J2H/2+KIQ M')("_HO5THS]_.1/V,C.I]2#P7T0R+HNS>>/2;+#")CO0167HX(<8Z9<*I.+ M;,6/7P$HNY;5A($HFFC4QI&8!H:J+2((7;HH0L'O\"O]#2$+=ZZZZBJ4,N91 MDXQ:$S">9&J,L?0Q#"1,WO>>,_?,7,C\:RQ>W/]&YP!AC+WE;NCW>YX7X*O' MXR?(XOG<1/MF$U&*+=<TU31?<F2(6454G$D(88P)UQK&+:4&,*II+=\/&+,= MQRYFQ$E:6MWN`R0RYT$4?8KEFG*'G8PE)87)$Y'%0_4\VW6=3N=^.'S$M;:] M4M4;7=<HQ1/3T!2&`,JA5I,5)04*YSO+<D>CNVJ5QW%S-EN>;E[TTU=+H]%4 M%'6?KEW(_VAG!+T,F@+ZYZZA7B?@&-0@U!34OS _^OOL=U-R-O)>4JI-)B1) MK.GT>;%X+;)"/F=X+@`A/ 6^!<%'&*XA1X%[C&?B>)<?W6YYI5(CQ/#]57;R M'J8&51# 597H>@\OS/FZB+RK.=S##]Q(KM(:N0T'`T@X: THS,AQ4JV.(-]N M4]=]+[%"DDHN*%%"NFS\G1@H1P$XNX*=A($@6I%(U[+=NBJ'AA3EQ =X]<8' MR,E_X6\(9WZB'CAX(/'$P8/$B+4&$R1 U=3Z.FN6;22:V$L[39,V\^;-O+>' M[7^\N!%N. -!A63%\:-^IMD,)I.'1N.$<S<,0W6;>)__. MJ"A/<,HBAAKZ4 MPO-8NWV.^0`@UNMD/E],I]%H](QNH?A 'U)2=8,NFR0KE+CK>M6J6RX?H<2) M(>^H;&HPJHQT4O)KM#TA#J!>R(E^TFZP;T(($*-2V76</;QW.+P=C^],V#AG M07!8KXM:C</7: B+/>\;`T"(.IO-GI)DH:FX%1%#+MJTQ> '.6P-)&C)$-KV M/DP(!!6M^)64FB(YI)96=_K]JU;K4LH7QN).YVPPN#869[/B4K(.,B-$[>9U M3RH+B*1:`L".2^FC86LKDJ8KG&%1$#+&.3^FD;+,-G;\;V[H;I7],.(JM]WN M!;+A.*^]WHTR(5%T[_NG4'?6MEEA%:AB(F)0Q$C[[\>7`)R=3VZ"0!3&#?+/ M-M@F:AICV#7I(8R-*R_0GL@#>!'W/4.)"WN"=H&)&Y(.-M"1=$I_`B)H=%$6 M`PD#\^;-]]Y\'T,R_^!417GDZV[W3HC/LH)I&L@&SWL;C1X][S4S:^?5=ALQ MH"?)U63BC,=/V^VO$(F4/]E6AA:(5PK-T%BOP]5*1%$<X?*=3/P"#'O$%/BN M6I7]<!4R;Q"?^;8]4&3+TE"6&1E0>^]#_%Q,Y57H3H#(LZV6;A@Z(0<L3!,< M;!:+CR 0E3$K8D,(@C!:+M->SQX,;I6RR[MI?2'6=>\US?3]=Z!<3V"75 ?< M)HXW50E.8#2;)JZSK&MR,^#+4P-MY3RV7'/(+V:SE^GT6=/\X?!A/O>J/*J> MUH[6Z6M6@7LLH<=E;%!**6DS2VT'>J:4Y(PGF=.PT+8-^JO4=WKF4U6I0*H5 MTC.$JM^',MS _9+$H2^YZQA-4JKC=,(P.(V*QDF0G-$>%\;A</P)P-K5M"@, M`]%!*I2R(EJ"%!1/LKC@_E[_BJ?]!U[$@PA6>ZC*1DJA4J*T[K/ICOT03_:4 M!B:DG;QY;Y*A?=NW%%JMSGZ_X]O)Y,OS_-'HTW5=\"!GU0C-1(B+R73Z<SI% MCM/M]X5M=Z+H$H9GWY>'@P0D]'D(N,BR+ @)P["50O2]_B?E^;K)$,+>3>'1 MK+3D&L?Y4C!-. PQ'CUG0$((!X)DLUE+*<OG4%Q-4(UD16QPH]TVB1X.8-?J MQGC\G::-U6J1$=>MF#(a)!NO57IXVA6S#/(HAN.1\`&"9DO:X6T43!O,$G^IIX MC\=0RD@(H#U %CN?;ZFLHVIB^-D^=U8*Q(;:1-W_)-O0V*B/@[F!O?$(H+YF M\T.I.$DN3[%1X9,7@FHPZ!(%AF'-9DO>N:([=7B]WC (?KFGDD*4J>,!#!Z9 M"A!Z<?T)P-JUJR ,0U$C4NCBD(J#@X*/043P)_P3_\\/442<1:&##G81.]14 M$T]RTQI3P<6,(32/FW-S[DGH_0\VR.1I>C6JHKXJ[G9[(%2@+KO=EME7&ZK? MCX(`@>8S2;!!+T;G.>WW9PI@R@>\17N6Y^)VRW&D(ZP'3G1V/^TO&XCS:2-B MAY3.E3):Z1SE1O*';8 '<&4T",/F:#3%9^/XB.C"<6#^(UF/!U>P80'0;B,0 M%X[R:.LYY^/Q)$VSS695_'K9FB&*HL%@R'FKNGJ%G3#?C&194QAUBJG!1Q*9 M+ .,;^>&9:?+Y6JQF"D5SN?3]?I 77(a)DRBNN%.O>P[B7WT((XWJD6_DYA=KC M<3<0TCE&&0NDS$H2575#ZA>AZG1X7:<4%'&<N-B0$F,11CIS10L:QGL]*R>& M\B#TL[P$8.WJ51"&@7!:BT5+"X*E%(0.'10%W\'9T6=P\SDK?0%Q4.@B.+@X M%+36GZ]W$DY:G<P40I(VR7W)]]T%\A]L.(Z7YY#7/9!XSW/C. :K*HI2LBFD MQ6)*)[69)!F7ZQ5AW:&J)\ 5&4%E]^0=592Y8RNBN^LHJ()6($V69=,S5OQ@ MC\FM0-<!#1LJN.OZ_H"#ZX[CGDY'B'ARGMETMI1?4"'9L!)XT'%?1<+#AK6 M"LKRR60T'(ZA7+;;A(%!*.J'81@$`4:WWV?K=;I:S>L32)T\1/[=9[O=R?,S M;P$,#*F_J?K;$Z5Y3IKNELL9V*+OMP3S?-9.C(_O-^8E## @ONZI!#W[C&]H M$\2L7/FF#]&P>QT;3Q'3J!,J[C.*^J9Y,8S;9G/0CG).8+]805U;-VGZF09@ MZ!G^8=)(+P%(NYH6!($@NGY%:(=.7@0OTK63?R'P'P?^"0F\=1'<[)!08$E6 M:N/L*JN6'=J#+.)A=X?WWCQGQ'^Q`3X,3+!MK^#T#,,H"G (X TJW]^"56C+ MYVP=X$D,D&N@_S@^LW4B!=8=%[)480P/PA%2M1E4A26JAS3Z:$02&B*QAKA4 M%#6*]BP.&!B"E-QP\'?=Z&+64PQVU309( F3-+VQ9RS+=-TUB"2E!UU?>-XF MRRZ09JCJ+,_O27(*@AVEQRYG& Q,AV2 ,2"\+7[7*+]SI.&*K98AA/3\-Y_4 MO!&0QQM[-!KW@DT)4XHQ/40,8+;Y&F!#W )I"5L@E"<><N\UKJ 8WQ(JO@O' M,67Y6I9.&%)!&9H)_JQ0$L5$! DA0SQ\O/-SO 40.7D#6&/R\/#S\O)S<G(! M&R_ 9/KIT[M[]RY#4J>QL0FPC_'ERQ?D23U(.7?LV(O04'%@.(>&ZI\^_1A6 M^*%D#[ AD.B'V(7('FA1\O\_`^S ?$A'ENG_?\22.(CPAP_OD),U<F,71Z6! MDCV0<P@\"D-"])B8/C* &KZ?9&5%/3VM144%OW___>;-1WY^KA<O7K]\^59$ M1 I81;QY\PZ\#@^]4$0#8&/_@C,&//Z @< *+'&!R8 )>L<DM'\%OR,`/K6' MW*""APQXH F4^=$&;;$"7*D%.6] KNCX]^\?FA3<!,QR&JUK@5$M8PED!J0N M@9@8W___7X"M#_AD'SRX0!?+__D%#U#D+,& 474P(+(N6C^$0+ `!!!I>0/8 M5 'F"F![YO__WQ\_OGWU"K1L0514&M@]@A1=`@+ -A7_P8/[85$"3?T0\MBQ M5X&!*JRL'\7%>6!.0V0/2!S#,P:DZD"-(90``O?OF>!L8 C#Z@T&!O0%YXB2 M"=;AAG<V,#N(Z'UKY+P!!*ZN:@P,G_[]$_SZ]7MHJ/VK5U_FS=OZ\.%SY&2A MI:7+SR_Z_/DKU*R%L]"":60$RS.#T^(OI!7ID(P!JE=A`07MI\-S"'+X@%?E M,$ 6CV-M2F%U!J88<MX`CRO\`T^M,*+),I"8-_ZC+A+!VME(a)`+6$.8#>_/3I M!W+]``% $6!?%-DOR+)HO0XX&\; 61:@`8 `(C9O<'#PLK-S`MWZY<L'8&L2 MOFU54%#BV[?/X#%64"PJ*"C?OW\/W'1&-(@AJ1]2Q=^X\4I7EP-8[L;'FRY8 M<!JY*\F(6/'.`)G/A?3L(24E/#- TA!LX.L?LK+_L'(4$IWP\$+*&PR8-08R M]_]_].R!%M^IJ1;L[)^!QK]X`5K<L7CQGJ=/W\*:.HB^QXT;-XR,S(!]GL^? M/_U'`5C"%IXK("J 39<_?QB1VE?(&0-MSR/:(G.HZ4"5P"I'4) Y,=%A[MS] M#*@=`V1[X6Q@UQ98=X%3X7_XF@=8>H(DY-_@$7;$&"[<7K2TB)0W<%87:$TI MS,Z&E94J"PLPXIDN77H$[S5!I('-%F#&0 Y-M%H%*531^A@H;3#LD8$$``*( MV+,4@ VG+U_>?/T*;"3\@%O#Q24`'@OZ!!$!5RGLX+R!GJ2 F)N;']@*GS+E MV/__@D"W65K*X>K^8B+,,25@>0\I\B'KGV&(`2(.E@+F&7965FX6%FXPR07D M,C*"MOZ Q[L@*O]AYA-D053#05P#`TF@XS]_%GSX\,W$B9N?/'D+B^]_R+X& M=A8?/GR@J*@&2^[_\=0;2 $%#R[TA(5:UF(=/T!XY,F3=\+"CYF8[CDY\4R> MG,#+RXG54^ JB(6/3TQ86):=G9N9F9V%A9V)B0U8<0%E?P']\//'KU_?@5'_ M![0&[2?D@B?B$%K8(AC("PUQ[.4`L0L+O9B8[OS[I[Q@P<%_<%$P`.:-'S^^ MPX,4J=KY#U>#VHY%2XHH604/``@@8NL-8,<7?AT6!(#GI!B^?_\$[VW+RLH_ M??KX/ZR3#2?_0RM]9G#N8OSTZ2<?'Q,W]Q\9&8$G3SX@*8:VIE#KD/](M02T M<@"+P+>_07JB_X%1R\W-Q\8&&LS]#UK)`XI/8,L$&*_@42G$\AY8M/W%F@]1 MF\(,:"0/#_OOWZ 9\5FS]L'5,#"@*P.23YX\9&7E4%14OW/G.L'^!DP!I&T) MCT+(,"Y$%7I/#%9I(*I*^&!42<G2:=/2A838F)CN"PF]FCPYOKEY_<V;SY!M M9V9F%104X^3D!O85W[QYCNP8.!NY/0:T#CR_!'4)3!"B!=D7D,H<7@=B;5 A M<CA&P@69%1!@*B4%+$#?/GKTYN;-YVBN`@8+,,<R,* TI= "]C]2=<' @&X^ MP5P!`0`!1&S>@)L&LX\1F 2_?'D/3K4@$4Y.'@X.GENWKH.ED3,&`WCVBNOG MS^\0Q^W;=]O/3_G?/_;B8L?\_'7(F0&MB?4?W(Z"1P`D8T!:4."Q8* (JZBH M.#<W+R0_?/_^!8@@:T:070X/%UR9`;G0_8\ZPXT4H S2TOR,C,#:G/GIT]>0 M;1MP*>1<`8^,NW=OR,NK*2BHW[MW$UXK8H8M.#\@<@62FG^0"_H(a)V0.YP<D` M;?= 1*!<B'<A.B]<>/?]^P=G9V4NKJ>LK _JZX.2DV=_^0(*%C$Q:5Y>8,IC M_/CQS:-'MR'K('&D%J@H+"_$a)[?.&%!S#L2_P!(=V""$)T3DZ@X>R/\QQJ:0 MLP?$)>GI3DQ,MW__5BXMG8)9HH %_F)M1Z&)8+:IT$3P`X `(JTO#C<.,HD+ ML0-2<LO)*3]]^@C8$(1-'B$R!I !'LW\"%F&L&3).7]_;4;&[]S<W.GI=C-F M'$3-'FCS6<A9`MJU$!(2%!86YN7E`R8<8(/^U:N7?_[\^_GS"U)M@SQ$ADB[ M:-D`5XV!J](`]L*9F;\#>P([=ES_AS* B&81(@[NW[\I+BXK+Z_^ZM7SSY_? M8XT0L*6@:9]_T+$'B';(4 1D^]%_5!*>,?[#QZP94&<P/GSXRLTM>/SX%VMK M>0Z.!\S,]Z=/3VYMW2\@(/'NW9O7KU^\?OT<.8C0XA<.D#O<J-.""#8L2;" MAU;_(8<`6H,0K4Y&:H@BRA1^?BXA(= :9V!%=_?N2^1"&<+X\^<O<A&#+6,@ MI+ 57BA9$0\`"" 2\@;8+$B9#:K>@64S9%8!*"(@( P4>?;L$;RRA64/D#XV M-NX?/WY ACC^0[?:`',+4(1%144B/-QLQ8I3&-D#D4/ BEDD)"1$146 ^8&= MG>WKUV\?/KR_#UJ-`JJX@&UET+#>W[^P?2.0E@:BKF> #FO"E_%@J2Y0,P9F MI0&B556%&4#3+[Q[]]Y&,QP>$QCY!+0%@IV=DX]/F(N+[\L7]!-)8!HQZPWH MJ!2,`6G)0+O"R+4'4JY +"A\^_:S@(#0\N6;5JUBGC0IDIW]`2?G8Q<7IY<O M7P&;LG_^* &U/'KT]/CQ8W /(KD''(58UB:B5%#(#2X6%@Y@_8.V% `S2Z#F M#43^079#9V<$(^,M8*-OQXY+_S!&J!C JX;A(KC:J$@!B$ CA>"`"" B&]3 M_8=-P;(`HPJVN@%2KC.)BDH_?OS@/Z(UQ0!3#%];^A.6,1B <</,#%JS#8R_ M=>MNA(59WKSYZMRY^_#A5_@<A9R<I)24N+"P$+"&>?_^PYLW[YX^O?'NW7M8 MXQND#MQ]9/GV#33/"$D_:*.62+&%IUD%K^YQ-H*!A)@8S___P+XI-/\P(/(& M2F; C)7OW[\!`=#)O+S"F&&+F2M@9T<@L@=2IP+?"!4<G#MW54Y._O7K=T"/ MM;5MK*P,X>"XI:[.V-.S!** DY/+R,C(V]OOU*F3SY\_0XIE%("M4OJ/Y!)0 MK@!V78#I`;(3$#/1(V<,/*TIB,TJ*N+&QHH,##=^_5):O'@V`[;4#S$$T[7 MX&5GYP`O6N7AX>$#ED1L;.R?/W\$5I(O7SZ&NPTMUO `@ `BM=Y@!J]"@[9M M&$ ;. 6![==W[UX!NW2HK2EPY0+:U@.L`7_#,P905T:&!?BL-*;]^V\=/7I; M4E(X,-#RS9LO#Q^^AC>IM;14# VU@'WI9\]>7;ERX^G3YY"8@,]\0QI:'!S< M;&P\GS^_94 Y" .M>8J2,?ZCC[MCK33^84WHP(XXL"D([&D@%76(2,*:*QB0 M,B>P9'WW[@76@$5K3?U'[8(S(+H93 RHO7 &U",_X.#QXV??OOU44)"_??ON MAP]L-V[\,S!@D)3\:F*B=/+D'0;0XK<OAPX=4E!0,C8V>_CPX<6+Y["F%>0^ M!69-`LP5P++IZ]</2 D/I=* U\#(C2NTB@6NBYN;?<F2+":F&T"##QVZCC4# M,("&A?Y"+#$Q,0?V-EE9V6#37(P_?_[Z^O7+)]"FQ#<O7CP!-BZ +1H1$2E! M08FW;Y^_?/D(K2& 'P`$$&E]<<A\PG_8*(JXN!PPISYY<N_W[^_(&0/6FF($ M+]" GA3&"#MQ0UY>B($!M-#?V%AZTZ:KJU<?!V;VB C[>?/VO'SY3DY.PM+2 M(a)(.#_=2IBW?N/(2U'R"Y`I+C&,'KU5EX> 2 7?!/G]Y"MG'",P9:'Y$!I;^! MUJQ"ZX(CRCGD' 4Q(3[>A(4%-+-Q^O1CM+R!9A%6!O*@%F;8PIR'J#>P=<$9 M(",0N'KA:-GCWKU'\O(*8F*R0)//G#EF8&#-P/ [.]OM^/';<#??O7OGZ=.G M1D:F3DZ>3YX\>O3H/C!MH;D.N9: BT*8K*PL\,ERI%(9.>ECR1AHV0-"V=IJ M]/7%L+'=`K+?O9,N+&Q64Y-34I+AX^-Z]NS=V[<??__^"VR:BH@`T[H8-S<? ML'+X\N7[G3MW[MZ]]?;M2V!K#M+@1 YB(//]^]? @AO8W9604! 1D7WUZA%R MM.('``%$[%V8^OI1P-0)6=('1, "6UA8XM>O;Q\_OD(NSN%-&C"#"=9"A0N" MR,Q,2Q\?34;&=\"$_O A8V[N>J!@4I(''Q_/Q8L/='55KEZ]>^C0.098PQI^ MQ"V<*R @"JPTOWSY^/7K>V0I1EBJ@4<B1DF&J!\P*PUXQ0)G($?YVK5QW-Q? M?_WB]_:>BQP'R-D#1S6"DM..'U^(%K::FM'(Y_\B,^!-1[CO4/,&?"P5??(; M*" G)^?O'WCPX.%+ET"!N7U[.3/SG=^_5;V\.AC0T]!_8(*3D5'DY>4':OT# M!N I(!#X_?O7CQ_?7[UZ`MDKBQR\P";B[]\_(>*X_$M,QNCKBW5PT&)FOO;O MG_S?O]RO7__Z\X?Q^_>_KUY]^?X=V+L`K1 %YL1'CUZ^?/GVX<-G-V[<`K:< M@-6+L+ 8!P</L#?[\N6SUZ^?@<=V,0LL:'2(BRO\_/D=OF<0Z)"'#]?@2?,` M`41R?^,_:'$H%S^_Z/OWKW[]^HHTP@VM,?XC#I_]!X^[_["]_$#.M&G'7K[\ MDIAHPLS\7EZ>8<($_[R\#7/G[DA+\S4WUUF]>N_]^T\8H!D#OI ..IC+QR<@ M*"@*C+GGSQ]#FFK(U05:*QPUPG"VJ3!K?[1&,)!J;'3GY@:&.].)$^C3M,BV M8+#1!TF +1"L80NOBF%YF $^0@49G8/WOY$R!@/67C@<B(I*OGGS_OSY,Q#N MLV?O966!I=MG966Q6[=>(-O.`#JF\24005P+F3L"QR839'<`L(J6DE("IJKW M[U\R(&5%8$H`KY/ [EF87] 7B?Q'ZF\`M6S:5"(O__;__ZO__BE_^O2_IV?# MER\_@ WLV[>ARV\AQJ:FAC]__GK+EGW(?GSPX"X#Z,0F$6!Q*2.C#G3,V[?/ M@-D5V6OP&'G^_)Z(B!P/C_"G3Z^)J3H``HB$-A7,8TQ<7(+ =O.?/S\@>]# M]B(WJ!B0,@,#<D^#`;:48_7JBZ]??RDO=V!B>J>LS)R28C9[]JF5*_=G9 "[ MC.S ^A%SP JH75!06$)"[NG3^]^^?<2L+I [&_#(0XLPM#;5?_3!$\RC+J F MF)K*,C!\^/2)JZ%A)UJQ! \?!HPL`6<#TQ OKP`G)S?6`QK_H4YH,"#-)R#G M!!S'"F)9?,X(/B@,F* O7[X"-WS[]DLI*;; `B4\W*:Q<36:^Y&YD!0)-O8O M^%BCW]^^??GPX:VDI *P[_WFS1.(A<"V`WA'QV]DSR+7'MC&:K'4&S(R0L!Z M"\C>MNU\6=DRM""%N^WBQ1OFYL98$S2PX03>ZL0(+++Y^,2!21_8HD&+%XC& MUZ\?"0A(\/**?/SX&M,<- `00"3UQ4&(AT?HRY=WP X&K#L.K2O0)C3 .J!K M>!@19_M!(P#(W+__CJ@H3TJ*.K 1[..C-7/FB7?O/IT_?UM;6^W2I=N80[K MYIRTM,*C1W<^?_Z G!-@S3EHEH#5&^@E.G*)A5Q=8/8TD.H-J-Z2$@<6EH] M4[=NO0%O:S&@YPW0FG 1$5%@!XR%A05\@B!H"1DPC8*/6OSU_OV[ER^??OV* M90P7G!;A>08QH0$V$[WJP)8QH$$*!\" 4E75?/'BQ<6+9^""&S:<24EQ`"K6 MU)2&;]]#=C^:"%(W`R3U\^>W!P^NB8K*B8DIO'X-.B!&2$@*6$0BU:*(H@%K MO8$U8_#P<# S`XMYYLN77P(S!EI^0';/A0O775SL_\..J\262?Y_^/"2E148 MX-S@H=%?<&7(L?GNW3,N+@%P[?$&,RZ0`4 `D="F^@_:NL %+"? NQ\1&0/) MG8QP3\&K"TBH(7,98$EVY<H+WMZ:DI*,K*P?&QL]MFV[">QF1$7Y`_M;KU^_ M01O255?7^_#A'3"%P1?;(O7O$7.%F*T+U%H>O<N!5&,@#R^BA*:KJRHP2/_^ M%9X^_1@#>I8`MKEY^/D%='2T(a)?[[^O4[L.W[ZQ=HI!](_OSYX]V[-Y\^?8!L M/X2;B1&VZ-D#G.(1)"-L"3IJ3P-EG H"N+GY9665>'GYSIX]@78PY*=/W_Z# M-^7R\@*;Z3RO7W]"C@M,`"]N_B,=1/_JU4-@H2LL+ NLPU^_!F;UC\@I!"FT M488?\/0TI*0$P8K_W+__$K.=@\P%!NS;MQ]T=34O7[Z&''1H`+PJXB<S,RNX M+?,/[BH&I"+RRY?WK*S #HL`=I_#`$ `D31.!=I4\/W[9TA4_4?I8S P(&9) M$?-$R-4%(])YYG#!)4O.%A?;,#'],S 04%.3^O#AYXD3WQ44Y%Z^?(W<>0#Z M@XN+^]JU"[ \QH@T>(4^*X+A<D2<8587:&-3:(-4#. N."OK!V#"O7;M)5"6 MDY-=6EJ$CX^7BXM34%"(CX\?V"!G8N+X^/';BQ>O7KUZ\^+%TT^?T$\Z1&NA MH8%_X#6V_Q'CMHBQ*0;4UA3::A$&U$$D(2$)8)L3&/'7KIW#&HDO7WZ0DGK+ MS?UOU:K\QL8U>_=>Q17=D"R!Y 9$/@&V1GAX>($!\N?/?_ FRA\,2(F/`6^] M@98Q@ PK*S6PR;\N7GP$SU2HT8=@7[MV6T='\]*E:Z@*L%0@?_[\A(MCK=" MU>"_?P0.1@(((!+:5,!$`&S&00["0<H/H.R!O$80[B#D7($L@NR?[=MO%!?; M`\,-V/V*B%A26>FEJJKQX\?O6[?NOWOW%AXQW[Y]8V-C@^UW0ZXT$*4I<B9! M"SC4J@-ET!9MZ11RW@!Z<]VZ!$'!;W__`DLC@1,GKC4U10"+Y/__F8&=ZN?/ M/]R\^?3<N<M7KMP$!PX+-S>?@("PN+@<+Z\HL,_ZY<M'V$&QZ 4J&O@'6QN" M,6[[']*^0NZ(PV31AU:!&8.75_CAPUN?/[_'%8.!@?VK5A4P,(C)RU]M:@I5 M5Y>:,F475I7P;/D?<4(2_(0K8%4I].C1]9\_?W)P\+"P</SX\?G__S_(WF2 M)43DG@9FQ@!B&QO0\9!___*M77L:N8Q'BT$(N'7KGK:V)K;\@[WNPY-C<6E! M!@`!1/S9;:!>%R/C/_BL'W*]@4PB90;$487(G0T&U'$D8.BQL#"QL[,`&\'S MYEV(B9$Q-)1F9?4X>O3TG3NW&&!#^\ JE8.#Z_OWKYA=$8P5J6CU,@,L:!"I M'T<7'-$73T@PC8LS!AKW_3LW,&]\__[;U%3Q^O67RY<?O7SYH:NKJ8&!VO;M MAW_\^ DQ'-C'!?96@>@_Z,@V;BXN7FYNP6_?/@';5F@.P!:%_^$#4_ =X;#U MMO]0,P;*Y"92O<K'SL[SX,$-R.0T:L2A!$5P<-_\^?4?/\KP\?V/B;'4TY-+ M29F-J066#>##\0@18(,>V*<"-A2!@K]^?0?OVN<`KWK^`2\+T%(A/%21)WD@ M#&5E<: ?W[__]OW[+R1W8F]9/7GR]-\_T!G[6)?>H,4X`U*N8,"6Y0CF#H ` M(GZ-^F_(B#O8MQ##L60,K$TI!J1\@N9Z2'S#0U!&1G;+EL/&QF*ZNJJ_?ND# M.[77KU\%F\8`/@2:^1_ZYAZ4Z@)MD HU@+#T-S#S!D2DK<W+SHX?W-CYSL# M55JZZ<*%IPQ(D;1KURD)"5$O+ZLU:_9AVO7C!V@Y,!,3"_@Z&)16+ZYZ`[;E M%65E(5+21!ZZ14FU#. 3.X%YX^7+1\BKC_& 4Z?N??TJ8V8&M.*3@8'XOGW5 MN;D++E]^#%<`,QSSF@Z0B*2D''@W/-0K8$M_@ \680'6'I"CP!B0<@AFQH#K MY>/CX./C!%;"V[8=P94?D$1 Y-.GSW5U=8X=.X[?CW#MR!D#K=(@F#D``HC8 MO4U()0&6A16H`<& 7 "C-F!0.L% P,?'#K[V@>'U:U!BXN3DO7W[[H(%^XX> MO:*NSF=O;ZZG9PS1^^O7+U96-LSY['](ATKA0F@*( O[T#(&W%@V-F8;&P5@ M:<# P'+CQG='QVGGSS]!\QH0;=Y\6$E)5DQ,",V;< /!]X'\0#JY%6=9!<NT M*.,Y:&,&,.?]PQ1A9>4"=KM__/B*/Q#@Z/;MAY\_,S<UK?OSAX>!X0$O[Z]Y M\](+"CPQ8NH?QC@>B!(6%G_UZAD\!B$`V*8`-O&!-3]R:"#-:6!9;0`$CH[: MP/SVY<OWYN9U2&GW/SQ!(R,(N'#ALHJ*,E*X80>H.0%9);X*' T`!!#Q>0/3 M)K1Q:_0I`LSD@@P@LJJJH@P,OX%%TO7KKX6%Q=Z]^_#M&^A,XK5KCZQ<N4]: MFLW9V=3/+X"'AP_8N@5VQS%2!N$C$9 1N#R&+'- EX+[0D5%!-@Q9F 0N73I M14+"2B2OP>,8Y*,W;SY>OGS'S<T*619K-!%LYO[#,7.,M2! 3KC@M A:$/WM MVT?BPX&/3_CSYV_KUIUV=&QY\4*"D9&7F?E&;*Q.9J8K4I9 'J[X]Q]1CC ` M8^'MVY?__Z.''EC97UCXH"1$K!D#"(#MJ&?//JQ>?0HUK!"9`3,T[]V[]^O7 M'T5%)>20Q![NV/H;,/4X^W[(`"" 2)K[@[:,X0?D,* <(L: -N4'=S<#M F+ MQ5A!04[PR;;_P1<"LG_X`#K)'%)WGS]_BX>'V\)"3T2$.S0T[,V;MR]>/+U[ M]PYF@^H_TG$;#*@M;*2@`3:4.8')"5B68U8:_Q&)_K^RLC#8P/^G3CU&"T"T M^-B\^5!24K"]O=F!`R>1`PI3/7(+&UO8_D?>$8ZZ+QQK1QRYPP;,(=_@)D&E MF%D96&$3\$PL#"PL(!$(CX/K"Y?8C?=_F.6U/OSZ[9*X+C/;0UM/[=??M[). M+O^WO_K_!70@-".O* ,'#R,+*]1.T+T0[(Q,3)R<'/=%I)FL`X N`J4#%F:( M]']@Y0^T")0FP*UN9A80"700,^M_V"G@_UG8@>)L_WZ8/5UG\&K?/T:6)]^> MIB___IC#D2W+GHOM.]N'AV]/GOU]XSP#TK'SF$%V_OP%/3T]8$K $I38PA\M MGZ!%"AX`$$#$YHU_L"D>V"E)B.S!@&,N'*(>/D@%XZ*DW </W@$3`["+[^BH M?/'BCU.GGL$+5Z#"PX<O&!EI+EFR05Y>7E_?1$-#[^7+-P\>W,7H;#!@IAZ$ M#UE !U$R,C(#^P#@H3WTGC=:J::E)0[VQ9^+%Y_]PU@>@A:F:]?NCH\/O'CQ M)K#&PZ,,'CU8,P>DKD#+&'C.VD$.1D9&I#L!@6+VP8S*QLS UB<W'W@]&RH` MI>C_NT!K>9A9`U59P68L>LW L!=("__]\)Q91OC_#];_X#$Z)@$Q3DU')O") ME4!=3+!P?L? P"VMP@"J@A'6,H Z56#G@8LA2.<3?" K>.0&7C(R,GA<Z;%_ MM0(a)H_N?_?XT/#QS.[9KCN.R5D/8W/F9#0WF1++M]!UX_F;.$X?HIK"')`!K) MO::KJR\L+/+F#<[).Z0,@+V_0;#2``* `")M[@_60(*?/(D\HHHRV(<\$L6 ML8@##BY??K%DR;G86",FIE])27IOWOQ^\ `Z-@6VZ]_SY^_T]36.'#EW]>IU M.SLG?7TS(2'QLV>/8LL;4#:P`<;.SLG$!(I4R)('8*[X^?,;9K$ZWR?NCJP MF0?L^K/ #E]$Q UF@+Y___'HT?/>WLY+EZY'OKH2,Y.@&846MO"U!?^0#K!# MJC<0.02B!6D`%\E$*T\V6Y]?YW8Q?7\C;A_"R,((3+[0# +-*)"Q14A'GQEJ M"'0ZZN_]*Z=__O@L+"CP[\^OSY^^_G]S[\_5;RINP>#R!GF7,T(a)YT.1_H."% M%D:@C %6`/8DA %R&>3<DK_P9M*_?V;/MG(R,XBJR')JJCTZ>N7:L[?N9QL6 MNJR2Y&7X$%A_T,&)@%1GI3\SZL7,QS?@26PP.#!@P<:&MJ'#Q_ I8 !(U_H>-B$,`VN@M3!#!GCSYB*RL@+V]G(# Z]14 MB^?/[UV[](a)R6HQA.GKQL9V=ZZ-!9(/O @;U\?(*FIK965NX7+AS[]NTS+$M MK08B>7EU(/O#A[=__GR%;+A!;L\@DV@S&W!24I(?V!%_^?+[/]1-9[@:5R=/ M7A 0$/#W=U^_?B?X($JT<$-O5F&&+5J0(M<;_U%N+D:9=D .7B@P=V3@9F(4 ME&;X]P/8F $Z_\\_AG]_&/XQ,?SZQ0B^Q9(!DE[___L-"6!(:@9M)?C]]]NG M#YP<'!K:2G]__7AVY\&;YX^_/OUPY3%BLQC4=OBB%;04@NQ-2,L*DFP8$ S% M-Z<%?[P2%> 6<[)X=^DVL+,HQLNUX2,[LP#K[7O_?UUC^,/&\)>3@8V7B2<X MYO/W[PSG#V &%Q"<.7,J(" 4,R[0`*[^!K(L'@`00*3VQ>&U!TI3!+D[^Q^U MYPWOUB$#M-YA:>F6.W<^`DM\1<6G_?VA#@XJ\,[ [=N@=:]*2G(0D8\?W^_= MN^G5JQ=:6A;"PE)HYB@J:OW^_?OAPYL?/[[Y^O7CKU\_X:TFY*$"Y XN+)] M%2@I"0-[/O_^L:Y=>PFI>D'IB\.[XW"T8\>!]^\_^_JZ<7-SHWD321FT4XLC M;-%"&#E(__]''2E"=@/":PQ,_[E$?S$RL"AH_!92>_B>^=%[YL<?F)]^9'[V MF^GU5X8W7_Z_^?K_W3>&#]\9/OYD_?23Z=-/QL\_&;_\9/S^F_';ZT?__OX7 M%!5S<C-F`QU$QB HP/?GP]-_X*;1/UBF@HQH_ /OX?F'BOY#Q$'J&?]ARQA MTN3%#C;&_]S"@NP*,MRL;.R\_-^8.5XQ"=V____G#\;_?W\S??O%](7QYQ?& M7UPL/%$I_[4M_F,#P%C^\N6KN+@TCO!$A#E:QD .88)I'B" 2!K#15_%C9SF MD!,9AA3Z`"[:V XPRB,B%M^__QTRAM[:ZNGGIP57=N[<#5U=362-UZZ=NW7K MDHB(/!^?&%Q00$",C8W]T:,[N,9G8"Y'<3-JKOYO927/"+J*Y>>\>:=1/8N> MYY$S`!#MVG7P\>/G[N[.HJ*B:-D)GJ;_(XU%8H3M?U3S$;&(,5*$,!.YW/G' MQ?_O-\OO7PS_>%G_LW'\^_$1DF3_L#+\YF1D8&7Z"[*'";2P%FC@?T;(\510 M?P&5O7O\#[2W68B9F>GC^X_LK,S EA6P/@,;\@>6,< .8V"$9P-D!,\PD&P` M4L^ Q :I^&OV<B<+(R.7M#BPBOS^^CT#$^O7;S^_LX,;L7__@SKN__XR_?K- M])GAQQ>&7SRL/+%9#.K&:"41!#UX<%]!01FK%#P/(&<&M(Q!3/8`"" 2Z@VD M5(*<'Q!9`BUCH!=L.%(57'%0T((;-_Z#3V)^4UGI(B\O"%%S[MQ5%A9F-345 M9,-?OWYZ__Y5`0$)9F;0!9SL[!Q*2NJ/'MW%G3$8X-7%?]PUR8</WU^\^+1T MZ3F,A(@SG\/!R9-GSYZ]9&]OQ\O+B^9-Y'##%;SPS(.1/=#8Z'47U"6$O^ MR?\'P\__#*QR"K_?/H*V_G\S_/W%$\7M*P%7+HS@E?X,H"W-_\#E_'@VR4_ M/&5B8A:3$/[S^\_7SU^ 3;I?/W^!$BNX;PT[V(/Q/U@OO!I!N &YBD!B_T/* M+0KOSDC\?L7&QLPF)\7PY>OW+]^!3<FO/WY\9Q>"!,H?8!YDY01ECY^_&;^ MLL=O`7:N^'P&%5W,$+MV[;* `# GLV!)6$BY@@';"!4\S/&G>8 `(F&<"NFD M>[0U5)#6,/H`+MQN1A;0D")LG ME2!$T,@C2RO2?!>22\.)3Y97N,K)RO_Y_ MBVM*??SPXXM[#QX]?'?H\5=I,U=F=FE@J0<94F1D9?_*S/2.DX==1I65F4%8 M6.SVUT^?=869P//$#,Q *\!=4<A.8B:0X?_!C/^,3-!H8V8#<EG__31YOEGW M]<&_C"Q/>=5/<-IMVZ+X]Y\J?[8[Z\='[T]?^'7S`GQ($4]H0F1NW[XK(""H MI:4%F;A%5@^/(6QZX7TVB#+TH3\&:,<#;9 #=6&E@#A(_0^&?\ F.S<S(Y_P MWT^OF'C%07V,[PP_>?^SL3'^`=474)= QI2@D?OYU;_?WSFX>"4D!#Y]^O'] MVW=>-L9?OW_^9V:#=*890<=G_69D9$58^!].('D$F?R/TIH"FF'P<@\KXW]. M;BXF:8G_K]]___G['S/#MY^_OG.*P4/E[]__S"SL_WY\9F%F_?V%X3LC`X<0 M!T=<X?>YG0P/;J#9]N?//_#><<S Q!+F\'P"+VLP(P(-``00:>-4R$M]D/OB M_V%70/Q'7I0&3)KV@8Q*1DRLK*Q<?+ 1$W!V@K(88!$$C2D@-?4NP_\[?QD9 MF?]^?/[GWFV&'Z#;69F8/KYX]H3=VH>%E0W>+P0M)/G_GYWA_R_&OQ_ 2W*Y MH(;_A_0R&6$[UX%!`10&5_%0,4BZ`C*=KTVR>;T<-*3X[[_:AP>V'_<NL)O_ M2E3S&R^SOKZ<2)KM(a)4.OGRY8_O_Z&>2@P!-0;]Z\DY650ZL?D LPK&$+]1/L M$A^D[,& RF9 [@-#PQDB( "^]0;HR1\,/](a)8.*4EOU^^P K,&PP,+#\8?K'\ M_\,+"JG_?Z%#KV"MH$H`M*;EPS-@D<'%Q24BPOO^]8<_P)89&_N?7[_^,7. M(Q1\LR$#Z___OY@8@+D%O&H8HR_.@-X=1\D80/*RN'/8BR7<P@(,0OR_;SW^ M_8_QS]]_WW[]^<$EB>P]8)./B8/W_]<W+-PBOX#9XS\#IP0/1T+I]YDM#,_N MP95Q<_.!KUE#SQNPD$$+>?2,@5&+8 $``43:.!6DM&) /?D<8^(/$F&,_\W< MV*Q]?IW?S?3]C:1], ,S$RQ'(0TI0FH<<+Z"["X'&P5RU;TK9WY]_RPL)/CO M]\_/G[[^>WV?Y>]7!9= R+@4D 1BT%33WW\,?Q@9V%G M3S$-% ]S@0>W(2( M0 (!J2G,"!F<`6+C%SLYF/Z+*,EPJJL\/G[MQO.WSN=:ESHMEN1A_/"1\> C M!D9^4:[X["_KEC&<W(4_-"$>__;M!_A:*?32BP%WIH($+-*D$".V[,$`JUC0 MU^%#ZP%>8:CRGPQ_?S+\X69B$9?_\_8ALY \2/8'TV^V?QS<C#\_,S#_@1H+ M"0]0* K*_G]^48"?CX>7[?[-SZ!SA4$'E?_^S\3['S(W`1V88@/7(J#)^/_0 MH[O1G<$`RQ4,#"@9`\B^+F299[ZMA&.3"R/GWU=O@17$S]^_/C/Q?!52_8]J MSO^__YDXA?Y_?<?Z7^@W(ZCVX)+FXTBN_#&[A>'%0XCAG)Q<W[__P!,C\-!& MSA@X56,#``%$0KT!FQ&'CS B#7DC[D9!:E"9.3+R,#$)2C/^^_$//*3X_Q^P M(@0/*?YF!&5XL&YHLQ7B<GA#]O>/;Y\^<7)PJ&DJ`MG/[CY\\_S)MV>WKSYE M!AH!&>]G`I5GP*@%-8K_,H*K*<0X(P.\7$,OS,!5!R2?R+\])_C]M8@`MZB] MV?LK=_[__2/*P[7I$VA(\=:]_[]N,/YA8?C+Q<#*P\P5$/7E^W>&"X<8D!(! M5@",,' +!%T1_C85+&,@6E.PL(7[@ &II,9FB) 4`V1/W']0U?&3C8%+4NC7 MRT>,`C) C<R_F?X":P\>!N9OP'8+`Q/,,8S@%B8#MQB3;C 3SWL@]_V[CXS@ M599_&%@851S!C@(W!QB@V008\']!-P^R_/N/4G6@A3,#:L: B#_A5,K_7\"Y MX[<L@Q6OS+MO#&PWE=7^L'"AA2HXFAB8V(&UQSL6!J'?# Q?&1FXY039DRI_ MS&A@> O:["XL+/'V+<J^5LRP1>MO,""J#J*:50`!1-+>IO_PUC#:H<[PY;1( M#2IF!F[1G\ .A;SZK_],C]XS(T*0^___K^!1#!3 R( 4^?]>/P:63H*BH@XN M1D?VG@-Z1%" ]_'MJRS _,D([JN QEI C;+_H*LU64#C+PS0LP<8,=(.-$LP MP(I*&&GX8C<KPW]N07YV>2GN&P_9>/B__?CRFE'@_@/P$:-_?S/]`E;:'$!? M_.=AX0Y/^OSS)\/5$WB#"'3NT]^_C&C!CE2&X0M>6#C@8J"$%3K@$T68_Q/4 M*?_-R\@JH_+[Q6T6<8W_?_\Q?6?ZP\; SL?X_SW#?TC5P<CT[S]D:S@3(P?_ MK3_\]1O^L_U5_R<C]9:%]:=$*",+&R2(a)H*4.M$7 !+LGA %T7 83$[*_4',( MRBP'`XSQ[1_K#585!E:82M1<`0^0_XS,3,!NZI<W+/]%?C$R?/G/P*,HPI9< M\W-6HR0')SL[Q_7KV%?CXNYR8.F1XP$``1@[FYV&81@`.Y%3Z#:$5$T3<.(" MXHIX&V[<> ;>C5?@MC?@!A)LVOJSMC%V2M*4K6A53HE554[L.%\J^UA.->0V M?UA*MZO$`F33<[O#1@B)@21MBW6'+%J$>J* %W/$Q4,+L+SY>B>IRYPAZM7W M^M0@!\'D_)WU?-!E0V<3J:U+4"5&X3B,(/EA\T,QCY>TX \?KQSHI5<+7B7% MYPHT;HLR/YFS?,-G5FTDMO9(L9J:Z>,SW=[_PXA)_I_+^;-<^9X#('MLWSBD M50KSZO4S_K!FSK)>DQ9L"44%N)B1;2U/@Y3D`*J@U(2):E4(DK6KRO>[1&O+ M'GI6II<;,^>#./E8.HI%.ZM0W4T-N1R^%,!4+Z_&#&,@%O?L>S0>Q8E,WVYK M<B$*FQSPYB)Y>LFN[Y;+MU%EQ.\?]/0>ZA@C^1& LC/8:1B&P;"SIM8JT"JF M365B6@\[<.$!> 0>@E?@53DB(7%'H+%;4==F-7;2=LE60*MRB*I*;1Q_<?S7 M4LZNPQW$PY=TVWXZXS6E*55)*E[E9MM)BD9VPS0!BIPBKAJON6><I,B1)[N> MUI65%-6HYM30QO'.LLR)EI2!(G$_.3Y 3I?K[>Z,W4^ +R9:,1[R[7-6?:(> MX7)A)<5O)D0D19PZ8D5QUU*>J'9&,1X%5"DFCT^TOO-Y#MBV)&PV7_/YXDBV M[O]1#-GV+SQ.^D.07&5DJT=(M3D$58)'':LX7YN/5V<07?!F5>TG<C)4$SIE M,!#_YDG'$=+6%,J0]\$"UU-QI%/1P?N[J&(W3E+!PI\#&''."$D,%PB7".G8 MMH3&J,W["[\/"\&C*$'?WKS=/^PXI/PR"X<@%G!"WD+S/QA\_0A V17L1 @# MT9FR!9ITLUG-NHD'[^O!+S)^@U?/'OT']U?\"P]>-EE/K@>S12J(K9T"74!) MM+="H65*F?<>,_ OG>K PKM1AM;V,%7=&$E2]+PP=I"=)$6S?T$O*1(:EA G M6!G#S* 7.MRHG>,87,B3Y3Q3)"G*&,NRL"SVT^"8AD\`L@VEM^"X;T4^W[&7 MK\IKPI/NI?\*?R]V#XVD>+JTKV^ZJ(R _*/48A'PL?,>49380D5L9A1H@/1( MI)?7^O[.;A[';*747@C9M?Y@MOYF\#!P&"<>;9DM?G(0+,EU3(_38LM-D6$B MZ?&@L>2P6L'S$^C\T-:$!*8PVDZ?]"%)7^6LD2@9X3"ZI^EW/^A%C\AAH' ^ MQ#8$BYR:9Y41-HO!S0"KQ<+PNI#27#RE:0,671<4X,A@'O/--J^'-,DHGR$3 M.#T_XU<WG^M;T.]]H]E^M;<]+(S!WK'R+8!(.Y\*WD>$3W? 5_BAQ=]_/A%0 M.?87/J0H\?W*118>4(9A_LX`C)Z_/, J'G3[*&;-]>\C:$B1@Y-31)CG_9L/ M?W[_9F1E__/K]S]F#F90LPI4`D.L!6<'R+@M*#/\!:WI!=8M?R!C5."6,<S] M#+ F,JPPNR+J$/1\&;<0'X,(a)W^_;CX&UQ.\_?[_]_/V=4P*2BR"^_@NLU-GY M_G]]P\PM\N\+P[?_#)SB/.SQ): AQ>?WL8;5BQ?/-#4-L.8'K/&!%+ ,< 9L M3=I_V+0&XG #+!E,4 (Y#J#&_@)/!0HPL"NH?+]YA45&'RC(\AW8IF40$6>4 M$&:X>0'4I()$'_1$5=!!)(Q@+L@H8)^+B1%>"?]';ATQP,?B(2I!=W:R0$0@ MY23TZ#+H>5M(HUT(K\)\R@"IB!@@BTW^@:<*( @8^* VE80>-&C^@[/'?\8O M3 S<AFK__E;\F=?"@+';$3EXX+F"`36K(&<27 `@`&57K],P#(3/=E!ITT 2 M(0:$Q,3&AN !>!4>@*$,O !+7X&9G84784)LG4 "*D5IJLJ)'>[.5>,D10)/ M)\?Y\1?G_-UW3O*__(;7-:?A^E)5D]^@5DQ_R=24EZU&4AV>F/E,.DF1'X]! M*'1.OPOW3T2[Q,?U^TL2[Y.D^$:2(AY<8[Q!DB*T/G_&6JZ+L/G&2%XIO<-> M4''_C3/ YP9,WEZ3R\G%T\WN\Y48FL\Y$C9=EKD,B^34UBXK0L5RO.(D156G M5@!ZV]%1-+B^6SW<P\>LCU6>9T6QC*(TR[X[&/Z&K0>L;W3L34VOH"<"@%Y3 M=$PX.>RE@0ACG(W%^( <>@Y?6 GHYFT@W3/ 8YIM`4;PN\\,="T95A;-&7J7 MAZ)X;RWW$8^E<1R4%>DC%4\%-*9YD]DLM;*B6I/;9LG)E@ON($-M% S3ILI8 MM1!($A8AC,_/EJO;ZG$*NON6?-L?M>*-O_$I*C\"B.3Y#3 />0`>ZV(a)C`X.0 M%*1)"BH*OC/\9&7@DA3\!AI2E 46Y\R_0+T.8 $&'E*$C",B+&+@%F?2"63F M^0"L63^\^\SX'WPP*P,+H[(#;+[B'Q,#?)(/.D,"SR'_(8413. ?]%9R:$S\ MA_5J@,J><BJ4_L]AW_5;]K\%M\R[[PQL-Y34_C!SH3>+(0:Q\_[_\H[EO]#O M_UB&%-%BXO/GSUQ</!\^O$&5(C*HH:&*-+#+@%298#&%45 "/A"'`GZ#FK4_ M.!DX%.2^7C[/RBL.E <&_IMK#+]Y_W__!H[1?^"TRP#ME?W_"XTW2&R#]^ S M,L!*//C$*P,#@@L'_T [0Q##5O\QPA!9"NI9!D93B?]I^O\VW&'<>A=G[Q>I MR >V'!B9OX#FM(#9(a)]O*^.N_HK^+NY&W0R$%(Y*-J!F#F"X'0 `1>U:TH* G MKD.+D;;\PRI-()T[G8$?=M<$4(J/@8.'@>'9Y]\OGK*(:P#%_C S_.5G8&=D M^/W^/]-O;/$-;,XR,;#]^0)L[C,QL_Q@YF-@88.UH*"^9F)$<*$Y!/=\+2CF M@#T3I*B"+K:#=448D/N."+T(\YC^?/__^SL#M\@O+F#=P<##Q?#[]O.?LYH8 MWK^"*@9K`W8V%!4UKET[PX *($']XL5F-'%.3C>T4&5@0 M;I(!%#R6P4$H7 M@ZPZ`]SSR"2P].-CX.=F^'[M^=\?OY@%9='V/"&;":T50/4FY"A%!DGN_UXJ M#">?,5Q[`YU794"V`4DO+,W]98#,HR/E`>2,\1\C5#F8_V\*_J<EPI"UDW'C M'0*#0_!.+3!O_ &F"&Y@//S_LN_0OQ430<OQT17#M,#THF6,SY]Q;A$!`H ` M(J/>P)R?@K4&X8M_@/TN7B%D5<"&[W=6!AY1GI_/_O[[\Y.1A9WI+\,?2*>< MC?$WL->!/MT!MA&HAI$'M#F3$6H!U#1H#F$$C;%"EH= [(7-@F-<P0&N5AB8 M_Z$VJY S!EK\P;,*PA!0:'']__6#\>=7UO_<P%K\"["&4Y'\GUCU<U8C`_A4 M*$B(2THJ/GIT![/0P5\*(;>L,*8"P1*,Z-,FB+Z'@!BJ64CL/Z"JXQL'`X>L M^.>S9Y@$9!A0,@.JJV"=#P98;'.P,%19@,0B-OT_^X(1I=. U4=(+5BX`I0* M!#XG"Q9A!GNT>!_32O]__<[_?_S]]_$G(R^P@PH>3#GUG/'Y5X1S__^#3:)7;D9N![LO/W_^6S,5K=Y$SA4(Q\ R!L%*`2" 2+[3##-[P'(R M7 18RX@C3U"#P$^&_VP,O_@86>64?SVXQ2(%6ED);%#]9F4`K?,!=\H9&3"* M?#@?:C8T+3!"<PBD(<"$W*"".14VY((P`-S;`X^APFH))K2,\1\\H@)>NP** M`D;(FA1(BQR\H(6)Z?_W/\Q?GUUEE3=C_<H`FI "-JXT9/\E5?^:T\SP!;0M MEI=7^->OGY\^83E #6]_@Q&6O7$VJ+ !R. 1!P.W`'KS%AD`RR!V!@Y^)A9I MY;^O;C.#ZVWT$$8.9P9X4/Z_^X%QTMG_1:8,/0X,KJO^__[+"&^X8NOW( 4X MF/4/Y@6TX@9(&(G_!^8';E84[?.\0 J__F;X]8?AYU^&QY__!ZYC^OL?7ELQ MP7JY(,#\E^$?,'L`>X#<C%S.KE]^_?R_<1:*8W TJQ@8$-T// `@@$B[8X"! MX3^V[,& %">08DP4LK0*YB4P"6SX0H84G[#]^P$:4@0%,[A3#AU2_ Y?( BW M%*64@@[Q,8+[B*#B@XF%X1]H$S_DMAH&T(9^1NCP'T@+$[R9!Q\_`8WV@@3_ M_OO/#$[L4,^ #]6%]!K_`EM>___]@0TI,L!&'AG )@NRL3UX_!T2JM A108& M'AW%?[$5D"%%;FZ^]X@F%F;5@2][X*HQL.801-^#7Q1;8PMN-+CJ^ &J.C@E M^#^_>,CX]S<C,V07.$;9"=8ERO4_18]!D/T?L/SF8&'B8P>)*@C\/Q(-,HZ- MB8&7G0'8B7_\"5B9,#S[@E(/P.UD@)8[_V'+.A'CA! I8"WDOI))C LD\O8' M*#/8RO[O=OQ_XRV#YRJF[W^Q9CV4)@'0$.8_H.SQZ]__W\P,K-9>OY[<83BS M%RE4D8,7O?; ;CX2``@@TM:,X,@>#.A914 <I1B'`,20HO+WFU=990P8P$M$ M@3UR87%&<>'_M\!#BI#5J) R&V@&"Q/44) (>$@17 0QPFI&>,4%[6Y#1G99 MF/Y#A@Z9H+D)MO&?$3+(!9HH`P^P_ $/PC#]AZX6@KKT'R0BP4.*?__#QQ,9 ML0\I,H!K#]B0(AL;YZ=/#^ A@VO$'540<0`D<O9@1&PP1BZ&$/J@-+!!A;=> M`8%O_WZR,7'PL[#)JO]Z>I-%4@<:G=B,_/R3`9@!1+F8?OSY__DWPZMO#'?> M,T1J,8IS,RR[QG#^Y?\OOQB^_V'X]IOA^1<&M,E,1'*$DLR0[,& E"O@[#L? M&&\CU:_W/S+*\/[+-_D_R_-?_!:DZ@)F(+Q-A0Q8@)7,9_#:2&;6_T:.H&VT ML(W[:&TJA.W$C54!!!"%]09:]F" =CGX1! !P( D_Q,\I"C(RL@M\/?S*R8> M4"N9\0O#FZ\,_*!2^1\K$S1]P],Z,Q,TE4!2+BCO,(-3/!C AA3_(^9B(:,N MO\$CAJ!S]J#B?R#BL+3^'[1^%[1EY^]_\'X=R+8UU#D0J,>1`P%C2!&4/<"M M7OB0XL\#&T#]492@0PM&7,&+F-- #E("#2H@$)3$H0!N^C]0T_#[OZ\<3#R2 M7#\>_X5.!6*8#<DMW_XPUA^%F(X8GOKY]W^*/H.Q.$/U(<8_2)U#M&8OC(U< MF3#^1\T2F#4,'+0>9WKY]9^Y%(,$#\,3I',]P9$(/A?USQ^,#,W(]!=</'[^ M^/_S*P8>;H;W'V&Z4+($7(3(_@9 `)%QOSAF]D#S(R.#@ 3VAB]\2%%>]NN5 M"ZS@O,'\D^'M=5"OX_NW_]\A2\=AZPO^P08`P!,.T--<(%-%2,-3\!74.,<6 MT4LLZ-(&!@:482MHK\-4XG^R_K]-MQFWW(5T^Y#Z@MA"$Y1=D(84WP!+MF=W M__[XAJP&?RD%J?>0LP?J!!^XA8AUR@\"!,5Q9A^H`>#"Y!?3KV\,_T49>=0U MO]R^PR*A!3,;S34(:_]##ST!B;4?9W"08U 79DC299AQ`>HD!HS$C9GN__V% MG9CR'W1=) /D6CX&]-0);SS/OL PYP(#> L"=(X<VG>$Q#(38A#@/P-LS2/# M_U_OGX.6QCR]`)KKP)$E&%!S!<&J`R" 2&M3(1VEPX!:;Z"VC_E%&)!["\@` MF#>^,; +,#,+2?UY]YA94!8H]NX]$#%"MFU `.K (D)$DNN?ES+#R6?_K[^% M#T_!5D\C=1 Q/?T?B?K/@#I(!5I\SPSG7G[-(,_'.-V=@7'G_TUWF3 C&Q,P M_6-@_@1JU7_E9N0TU?O[(^O_LGZT(47\$8&9'_ WJ% 4\XOB,Q?H._ ):R#7 M_P2M1]*R8'O"*/_^V6LF+B%&)F9<XQ]@)T'F4D'<KW\875?^,Q0%-H3^8]QL M@Z(5/B$,B1Q@)Q#2J )YA@7L:C &)VUXN/R'"L#CZ3^B[&.$3KU#RC%&9O : M+$8F\*(59D869M VT+\,+!_>_7W_[R_#9T2IA'4&$%,*%P`((#+;5$BU/UI? M',SF%\/9'D :4OQR_APCOS1F"Y(!+5\Q(D0X6!@K0$.*_Z,W_S_S@A$22TS, M3(@<@JH+V0GPB5CDAA,HGS""NN60$17((?&E^YE6^(&&%'_^_?<!=4@1WO5$ M`\!F&1.X<?6/DXG;SN;/]^]H0XIX(@-I20%R?L#9H$(?S!66PIYK_X/'W9B8 M$;(_&7Y^97CU@2$QC/OZ;:[3EWY_^@!JI/R'5"RPJABZR@-ZW0<C(ZS4_O6' M\33HNC\&5M#&F?_0L8K_T*H741/ `OK_/TC!#UO7`XY"R"P)(R01P=(W& &- M90*-K#"!EVF!I1#W$,$J#Z -3+!&]7_(2N>_H)VT'QE^_?C]^S^PE,7(#_# M0!8D)F\`!!!)>8,!1_: BX,!*R=\2/$_?(\%,H .*3*S2(&'%"4T&+ #1,T( MKW#O?F"<?/9_H2ECISV#^^K_O_Z"`@Z^R0:^6@Y)-PH3+5<P(-4>AN(,R_S@ M0XI0'7,QAA0#UJ'W$>& ^2]HQ/T/(],W;@;,(45"]0:6[(%U#166J7$^<41) M`"ML03N8F)FQ6/2-X>5SAHT<#.8JC-H"[$_N_/_X"IAA_O\">A*6OD%F@!L_ M3(C&*B)]@^9DH5U , %)Q*#R&[2SDP6<RE'3-P,C;-H0DL_ IR1"FS4,L,7+ M?\#G>8,.^/T-*J?0#NL@F) _O'WWZ]N7_Z]?,V#+#PP8S2J",0($``%$:G\# MI?8`BS'"9: M+K0A18C'$)/9T 6(P*J#2TKPT_.'C'^@0XKH=L',$^7ZGZS[ M7XB3`5A^LS.#2 ;0D"+#H2A02(.'%/^S,#$\^<00N9GA^1?TG @S#>X%]%P! MD3W[DLESU7]1T!8TAK??&7[^8;#!&%+\CR-7P %T2/'/W]^L3*S6WK^>W(4/ M*1(LJ-"R!UP<]2 \#'.X!!(a)X.,%R2/X$F<*$X,+;J.!(^_4)U.3G96;(a)9V.X M^8OQT[?_#+__\;+]`]^1S<C"Q,C*"DKES$S@) ZZS1FRWA9<P3/"F_W@10G@ MY?#@=BEDGP`TH8..L .OQ__]'[Y2'S:B]1_97>C%%IH@*L 9^'___/KY[<N? M[U_^OWW/@"T_H'&)J#- `"" 2.YOH&8/!K0<`L+\8BC)$ZG]BLA0/T"]#C9^ M1E99-?B0(@/&D"*DQ@`/*3(*<S#\^L?P^=?_5U^!M0=#A":#.#?#\NL,YU\P M?/G-^ ,\I/CL"SYOH\T](1@P<?"0(M1?0.K^5489WO_@(<7_\5L8__['GNO0 M`&A(\1\3;$C1`3RD^(<!;WP@C>'B6V^+.2\.`J"N'=*<$"0`@>D45FG IA2A M0< `FHIFX.=B4.9B$.=D>"W%\/?#?Q:6?W*"+)#T#2JS(5<R@$;Q&/X"RW%0 MNF9 E."X4B[:6@1L'+0L\1]#'!8@!,H@- !LP?[^\?WOIS<,W[ZC92%<8^C$ MM*D``HBT>V(QL@<#EAPB* F)8FQ&P%3]!?<Z?C*@#2E"DP6JCF]_&!N.P<6A ME0FP)Y"LQV DQE!]\/^?/_\9P4D!?6P/X_!VY"A!SA5P<>B!Q["X:3W."!]2 M?/P)+32@PRT8B861\==?T&&SH"'%U_ A14)#5?\9D-I+\ H$4PH=8 [@@O<K MH_>V&!$DL/CGYP&UBS[]8?@";*=__O7GYY>7OU&J;N20Q#6OR,B /=FA"&)C M8V8)4C,#&@!6&K]^?/O_\B4#HI&/TV'$Y H(``@@$OH;:#L*<-4;#)!=35A] MBRSV`S0C_@\QI*B-L NM$$(M%"&52?MQ1GM9T) B,(=,/P]=+ IU"G)-A<: MDN 6-?APA__0IC6TZP3N(,&R_G\L0XH(3R#8\*5FL"%%EO\_WSS_^^86\I B M,3&"M0)AP#^ RR^"):"9F# 2"((!;, *<(,ZW)]_,WS_#FR0_&5%+/E!*$?D M+E@]AF886EV%9@^JO[ YA+C\0$Q"_OGUT^_O7_^_?8-'-:[V%1X`$$!DM*D8 M$(41(OZ0<HB * /JZB;LX!^XZ@`-*;+#AA0%&9E88-:AE'R0K(+<*0=6)FXK M_QF*,=Q^!ZS\$=442H$'=21DZ `R#HB(==AZ$09(GP\Z@@B=,(4MT((W4+$- M*4)ZE^#%*^A#BG\86#Y^1 PI$C._`;<)<5 +K)9$TXT2L$+B4%G(AF#0A@PF M+$D$7F\P,K"Q,0AP@)1\_<GPZSNP_OO#Q(@EI:*54(B,BNE^/'Y#JSIPYP=B M"W,,\/?7SU_?O_[]_IGA';'U,Y$`((#(:U-ACIQ E8 (T,X-! \G8$0,*2:$ M\ER_S7WFTJ]/'_^!ML@P0-O*\'&2_Y#%4>#X@I2)P!3Y^R_C:=#6"496)DA. M@JVM11I2A+L;S(",!4(W7B+.`X<L4 $/NT#&#4%#BBR,K. A%T9&?$.*D(%. MM"'%/W_^?6+XC3RD2$1''"5[,"!R!4(CZN02#(C(0AGP2V;Q!#@X2(!==SXV MT%CZEV__?_T$W;7$S(9]93C6I(RH+O#VOXBI%C#UDY)TH>#7MV_ SL:_]Z\8 M?J+O<(*926:^`PA VIGD``C"4+24A0L.X!V\_ZG4C8G$2&+4%F10<61)F@9( MFU]>&+[45-P1%U2^64Y5>A:Q??Z0=ZL9*1:$%"M"BM U,/:ST<;%>A3?SMD4 MD")R5@AW@SQ!BLP3(2!%M'$L)'K4&]C9`2D"(T5Z)H >U-HCQ?O%WI!B^Z:@ MXMFE&0))2IQYL4<0G.F98L0ZP[JA%"@)Z_IJ+<Q(DT.4.:6Y'/#K3<*?9,@9 MFJ%?=6-NZN>^'AHN`HBT->H88_!0&80B+GX&=D[X4-]_Y!5\Z&U:Q) B,&7R M,3-\86.X^9OAT]?_P!J!E^T_I/QF90:=E MF(a)](W,R,C?.P<FAG EC%![AV' M#2DR@%/SW[^@'>2@M/X'/)0(&82AVI B3O#WSV_,(44B2R_D"@1-(R,CMK0( M7H(`!8P8),Q,J AX,I"/CX&3$;3Q_<L7AC^__X%+%I2^#507,<XE'> *!O*L M`P8.L+/QY\<7AM<X[W#";R\>`!! )/0WD+,$VOH?N"I05*%/;J#&*?I8$J@V MX.-D4.)B$.5D`&;^O^^!F>&_G!!L2!&(H+>\@HZB_ -)VK A10;4P1L\Y1AZ M3Q-5\#_,CU@4DUY _OG^#3RD^);AVS=D1Q$9/9A]7Y@XAGX^408V#K!J'&:A MA3PC:*4F/R\#.P/#N[^@4X7^_OG'A)X5B7(D@<XD$>90)>_]_?T3V O_!^QL M?$ ,(Y+;AD('``%$6G\#J9L!;I9@]CH$4=<O((TLH0!X'?(?M*8!&%M,D"'% M3SB&%!G1=</<A,(E&";_L;%I.:1(OCF8!3D6("1!E%E(-0FPG2D`'L#]\@>4 M<__^_<O.A*_?(a),MR,M(?D3HP39;A_2_._9\/?&[5]S\,>QX@>D>_OG[]]?/[ MO[<O&?Y@/S2:$@`00"2OPT4>=,<R?(=<Q1,$8-W,+ P"7.#8^@U:P0Z,+5:, M7AY:[D(;!,/6Z<$N!3<-4P%5AQ0_PX84J5""89J!\#NO,+H<(<#&QB#(!0JB M+S\9?GX'=L3_,./=H4VCEA74<.),G^[^1XH7REYS@Q$Y;_S^`6R[`ONLKVC@ M.@: `")M/17RK"T#`T:E`02"./;9H"4\)#5L[* 3[/Z!AQ1__@!="<P(/=46 M7<>0&E+\P@"].99<@W #A)F?WS+\P^B@X 7 T!9@!P]2?6?X^9,!-$C%"HT[ M#I;_LKS_^=@9("4T-^M_00[0<8- \/X':)O>M;?$GH))V.78`+ "XV$%K7[X M\0?A(TF>__",`01??X,6*SSY#!W$^_GE(ZBS\?8=A0[#"@`"B.3U5&@C[FB9 MA$%$#FER#$M2AFE#)&H.#M#"'F!L??X&.H9KZ \I?H4-*?XF4@N!WC8></\* MPZ=7H(%!@@#6K.+F9N!E@0Q2,?S^">K,,</609M(_)_HBJ]E,OG,_P67L:Q? M) B B5Z6EP'8+F)F9'CYC?'>!Q1O"G/^#]7X9R/[3TV0`5*)O?S*L/ RT\KK MS':R_VJM49P4K_L/F$LA>>//S^^_?WS[^^4]P^?/##0```%$6MY@0!U]9\!( M/="C/B%2!(<!P?+<// A18:1.:2(9#N*%B*RRG^&HQL8O-*),AT\IL?'Q\#% MQ/#C/\-7R" 5Y'0V,% 1).#@+*-_2Z\R_?Z'<!4PT6N+_%?@!]4YP,+^QEN& MV^]1RC4^MO\)>O^\E/]!%G%"P(./#-4'6&Z\`YFC*_IOBMM?'C84B\2Y&<HL M_MUYSV@F!5ICB@P^_F2X\!+J@-_?OP"+(88WK] WYE()``002?/B6$;?&5"C M\#_RP:R0#C<RB0Q@0XJ\O P<PVI(\3,Q0XI$FD98T>E=#&X)#*SL4"Z.85Q( M10VL(8!Y(a)X.!X?4_4$D$':2"5;BJ0BC6/?L,3.B,]G((06"A#FQEO0+O'0)F MA@3=?\'J_]#2[N''_RH.,$,:1<#&#W)7`0Z >:G;Z8__6A9@"PJ>,?[^8UAR ME0DY%P&;=H<>,7HI,_##/ ?L;+0?1Z387]^ 0?V5X?5K!D* O.D_@ `BK07Y M_S^6Q(28$>,5^<_&`:Y6<.C'C"W8D.)WW$.*Q" B78Y'XW]41!Z #2E^0AY2 M1',`E0&P17'U*(B!/\PAPQ[,#((\H'LOOOX!';+\[\]?Y(ZX/#^*XW;<9RK< MR_+@(XIA'W^!`H>+%9CH_Z8:H&<,(+"5_1^K`YJ>!V:>*6Z(C+'^%N..>P@G M2H&:6 P^JO_@-<:^AXR3SC C5P"WWC,^^LP(SQ@,H+UE3/ (^O?O+VC,X]OG M_V_?_B<$<(8>7@`00"2WJ1AP#\##AQ0)N 4UMH;7D.(7\)#B*UH,*>($1S8R MZ#L2Z)&#)5E9&02YP8-4OQA^?@=V[?ZRP(HB5J;_R@(H.FZ\!<VHBB.UA1Y_ M@O:2F^W^ZHE!PP58O30=99[A@?"O(>A@409?E7^R? B]<R\R`SL5R*'^]1># MI12"^^4W*,N=><X(#-)7WQB!;2=@I\)+"645#+"G`6?_^?']]_?O_SZ]`]W* M01L`$$#DY T(0)ET@[B95PB'6IQ@F XIOJ2!ZW"#!Y<9GMYFD%4CH(R1@9V= M09 3-"0(&J3Z`=JHP<P*36W 4IP-M9M]^QVCJN!_3J1YII//0(K5A?XY(#6T M@-4+,!<A:_SU%Q1-/BJ(9 W,5,^^, )[)L@B'W\Q2O$B1 +5@.R_T\XS/T?: M=6PLB3#D[GN&]S\04J#.QL]O#*]I&-0``41^WD &T%3U^=V('U+\1+LA17S@ MY%8&&35\XQ5@*4XN!CY6\#F9WQA UV#]_P>O-S2$T<,"*!*@ADB:P,;5S N@ MT'>21U$)S!AH>H&]%& 77%,810VP7H)7-1 1!M!X%*,"/TKV\%/YL_4N8]\I MYD^_0 I,)!"RP 85LBW@53E?&=X0[FR0#0`"B#IY`PI&AQ2A0XI?R' 51>#< M7@;O- 9.;NRRC%#$R\O P\3P$S)(]>L?XW_0=240)0K\Z'FCW0'J4V ]`/3^ MG(O0$2H32?2\X:KP#TT$F%N0Z_^K;QB5!/XCUTOGP6--W2>9.QW^* LBQ(&Z M_%2!N>A/R'H68%&(W"H#-K?@[']___SZ^NDOL%_W#LO9JM0"``%$ZED*4(!C M>'%T2)&&0XKX`+!U<68G(a)VT0=EFP`^&K##_^`X7VW]__F)&.OE?%'=K - WL M=HMP_6\^"DHM&DC#69!>`5J]`<P)'HHHN068$[1%_Z.)`$E(a)J12UB058.Z7H MH\0(, :!-3:DWP(!?_^A=3; Z](_O04=(TLS`!! 9-8;./O^HT.*KVFR?H$P M.+:)P2: `7Y_`%K9!1X2%.1E`'KNZU_0VIQ_?_^R(I4;P'(=63FP:_'F&X.W M"DJ#9\K9_]RL#,@]$$C3"#EO`.M88(<!6018[0"516HA<LN77Z!<`>RW`*L% M8%,9&.R9.UG"-/Z&:?Z':P%VS9$;5+?>,T!:61 `+H:^,;Q"N?F$Z@`@@*C: MIF* #2D:.)$WI,B*=TAQREGF=4&_@4D9#B!#BL#PG>KV%[DY"P>0(<79%Y@Q MAQ0Y61@\E*!:($.*CO+H0XH>2.,DM]XS_OW/@#FD" '_$4.*[VBR4(0@>/6( MX?YE!F5]+%L?P:'*P@(*;6;P`!$P78$&J6"5!K S@-QZ`8+YEYB )9&W"OJ- M%IA5!+ J1M9[Z17(3.2XN/N!`5BW(W?$@6J (3G/ZR\\FZV]R73K/6(*#)@S M__UG-!!'!/[M=RCI"32)]/T+PRL:=C: `"" *.W.8@%'-A).'+0<4LS8@=() MP36D^/(K2G#C&E($5@[3SC&U'V<"-AX,4;,?G8<4"0.$0\:$N0$I;XO/\"# M5'__,L/.- 2&#/H@U7M&21X4HX#-I_<_T)M/F!WQ2Z]!N44<J>-S]35Z_@&6 M.T %\(SQ[CLHM)V06@0;;C&A)0!@)Z3-'II1__WY_>O;%] FV ^HDR_4!@`! M1.UZ@P$RI'@+>HT0'C ZI @#5*MF+AUB`&9.`8RET. 6+"<';$CP&\/OGZ!! M*F9&)D@I!6Y0(?P"S@9,CO)_D04AH:HL@)XWT#KB!Q\QH64J8)GBKH02^-ON M,4GQ(!0`F\''8O_ HWOW?<;]CYB ]?SW/PS(';_S\'[=CZ_ !M7_]Z\8?J-7 M:]0%``%$@[P!!">W,<BHCPXITAO\^\=P8@N#1P**(#A$@:TG;A[0D""PZ_KE M*W20BAEV<@5:1QP2&FB5)+#Y!"3%N%$$@;T+Y![@O@>@(3M)'F0E# 6FB%@# MYKK*@Z#NWX./_X$M*W@40#(&L/FPZ#+3O,N@@ 6JB=W,8B;U#]CZ^O23\=-/ M4(T$4?SKV]<_P [3*YI/(@$$$&WRQNB0XD"!D]L9G*-!K55D`!\29&3X_I_A MVV?0(!43TB 56FT`[(D!&S"N"BB"!Q^!%(.K2H3X@:@_$H<6)'6'P&%*;"F M!5;IYE(HVO_^`YG0>QI:#P.[$TG;F.UE_RL+_@=V,K_^!IWF>NH9(_*HX\-/ MC \_81FC_P79!/N6"BO6\ . `*)-WA@=4APH`&QI7#O&H&^/$($-"0KP@=:M MO?W+\.TK^$PJY$$JU- &%N=ZJ/<'`M/ZY=>@`XR /0$K:<0,#R1C`$-C_2W& MB6>8O_Z&ADG>;F9@?0)LM0*SV;L?#$\^,9Y\SOCV.TI#`I@]]C\"(M+\]_?W M3U!GX]M'S!5K5 <``42;O,$P.J0X<.#P>@9]._AQ%O#-E8(\H#L<OL &J9B1 M!ZDPQK7AX/MOALUW&">?A9;?>QXP16YD<%7\+\4#.L,>6(T``Q,SW0.+_ST/ M(a)(CZGOL-.M[SV__7+QAP771 /0`00#3+&Z AQ4L,R@:C0XKT!G<O,KQ\Q" A M#^4B#0DR0-:M@8<]6&"#5,!:$=CK!;9J@*7/Z^^,[W^ 4CRP3 'VOH"5,+!? M]P]U8\S-=TPWZ;XF!@Y^@R:1OM%G$@D@@&B6-X#@R"8&)7U<RZNP#"G"!JE( M&5+$TK5 %J'=D"(;\Y^J@Z#0H]N0(K$`Z/"CFQF"<Q BD"%!#M IQ%^^,_SZ M\9\!:4@0&+9V2[&<8S$`7A[S,<_H",,Z9$[`0*(V/D-(O=1H*!+A_Y_>@>^ M) D5@8Y>8^3D8!1@9_S#P/CE&^/OGPQ(0XK CC(#HL/.P/CQ)[ P8](01A&\ M`5YHB#FDB%PA,! ]I,B)5$1 AA2M9*"Z($.*P$[Y=]1*B_Y#BB2 4SM $T80 M`'8F%WA($+)N[0]H2/ _,Q/V,FLP`^A>_,_ %BU--L&B`8 `HF6],5*&%+_0 M9TB1!/#C*VCQCJT_]$PJ$ @-R-HW1IX<R6PL_&?Y+WI@P#\_@[:B\]P_SYM M]RK `$ `T3)O,(R0(<7/]!E2) T<V\)@XP<Y41A($.'!%__90!VB_[]^8=Q MR=]@!-!3NT$']H).7_WS[]^G-Z^_G3O)</LF?1P`$$ TSANC0XH#!9[>87AP MC4%9&SHDR =>M_8;.B3(/C@:5)#4#SVT\M^_/W^!`)(3_H+NQ/GRY<_G]W_? MO?[_]?/?+Y\8/K[]=_T<J"BE%P`((!KG#89A/Z3XC6Y#BB2#@^L85$"WFK"R M, AQHVZN)*'BH*CY`DO]H%.W@<0?8/'_YQ_XC&)@G/_]]?7+GP_O_GU\"TG] MC!_?,@(;J%\_,WQXP_#U$[#(I,1JR@% `-$^;XP.*0X4N'R$X>,;!F$1R,;C M?] A05!2A0]240X@9Q7\AUR!]A>$?D-8(/P?F/K_?GC[[_-'$/KR@?'S!P9@ M-@"F^W>O0<V[@4[]^ % `-$^;PSS(<5/=!M2)!G\_L6P<19#0CDG)[,`Y,*- MKT"Q?^!U:\3NEX2L@_P//G\>F/PA+9\_P,(??.G5GS^_?P/+_D\?@&4_-/4# M&S]?/O[]]N4_)/7_&=2I'S\`""#:YPT&$"B3S+R=:;8AA1IL%J>QH#.0XKD M(a)).[&6256>-#N)B8(8-4?W_]0QND@G=YP5<8@XO_/W]!37]P/P!<]G_^^^'- MOT_ LO_#_V]?&#Z^8_CZ\>_7+__?#_G4CQ\`!!!=\L:P'5+\0L\A13+!FADO MWC[<PA0CK23\XB'3CZ_?&'__^O3E]U]8Z@?V`4!E__O7_X%)_^N7?Y_>`1E, MW[_^`7(_O!W>J1\_``@@NN0-AN$ZI/B&GD.*9(-?^[<?/;R;757COZC,'V8. MT$'<G]XQ_O@*[ <#LP'H8H?_Z ,)=#Q=:_ "@ "B5]X8JD.*_U"'%#\,X) B M1>#/GY_7KS `T2@@&@`$$+WR!@.UAA0I`MB&%/^B#BF^'[1#BJ. S@`@@.B8 M-P9L2/$OZI#BNR$ZI#@*Z P``HB.>8,Z0XJP0150\O^+8TCQ(^:0XFCJ'P6D M`H `HF/>8*#MD"+#^]'4/PJH"0`"B+YY@X&:0XI#<-1W% PE`!! C$3>3L#( MZ$A-:UE82!I2Q.$D:KJ(;N#?O_UH(E0.VU% -/C_'STND % `-&]WH `:@PI M_B?MR/91, I(`P`!-$!Y@TI@0 [7' 4C! `$T-!;Q30*1@%]`$ `C>:-43 * ML . `!K-&Z-@%& '``$TM/L;PP/@'RT9!0,%``*(V#'<43 *1AH`"*#1-M4H M& 78`4 `C>:-43 *L . `!K-&Z-@%& '``$TFC=&P2C #@`":#1OC()1@!T` M!-!HWA@%HP`[``B@T;PQ"D8!=@`00*-Y8Q2,`NP`((!&\\8H& 78`4 `C>:- =43 *L . ``,`Y3C#,8I/L<\`````245.1*Y"8((` ` end

3 8

documentatation for boost any
by Robert Ramey 28 Feb '05

28 Feb '05

While perusing the documentation for boost::any it seemed tha tthe documentation for the class "any" wasn't there. In fact I did find it by clicking through a highlighted link. I would have expected to find it in the table of contents. Robert Ramey

2 1

Boost Logo Contest Extended
by Joel de Guzman 28 Feb '05

28 Feb '05

Hi Y'all, The deadline for submission of entries is technically over but I still keep getting new entries. I am extending the deadline to March 1. There's no reason to hurry, I guess. The more the better :) It's also been a busy month and I still need to setup a system for getting and tabulating the votes. Any suggestion on how to do this will be highly appreciated. Right now, I'm inclined to just do it manually. << Currently, there are 73 entries + a few more in my inbox. See: http://boost.org/more/logo_contest.htm >> Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

11 29

[mpl] rational_c, fraction_c
by Andy Little 28 Feb '05

28 Feb '05

Hi All, What is the current status of compile time fractions / rationals? Various directions are 1 Alexei Gurovois in boost/mpl/math/rational_c.hpp 2 Cromwell Enages work on the files section <http://groups.yahoo.com/group/boost/files/mpl_math.zip> 3 Hugo Duncans: http://tinyurl.com/2qrpq However the three are not compatible with each other In Cromwells (named fraction_c) and Hugo Duncans the numerator and denominator are mpl Integral Constants not values, as in Alexeis original. mpl::rational_c<int,1,2>::denominator; // == 2 against mpl::rational_c<int,1,2>::denominator::value; == 2 Cromwell's version is not a nullary_metafunction whereas Hugo Duncans and Alexeis are. This is the right thing IMO because the type can be reduced eg 2/2 ---> 1, Also see http://lists.boost.org/MailArchives/boost-users/msg06245.php I appreciate that there my be advantages to Cromwells and Hugo Duncans versions.. Ultimately either the version in the release should be removed/ modified or 'lived with'. Anyone have any thoughts. And is anyone still working on this? regards Andy Little

2 2

[program_options] Deprecating 'implicit' and 'multitoken' options
by Vladimir Prus 28 Feb '05

28 Feb '05

Hello, the program options library allows to mark an option as "implicit". That mean that specifying a value on the command line is optional. One can write either --someoption foo or --someoption --someotheroption In the first case, the --someoption has a value 'foo', and in the second case, it has no explicit value. This behaviour is tricky -- we try to look at the next token and figure out if it's option or not. In particular, we'll fail for the case of --someoption -1 and we'll also fail for the case where the token following "--someoption" is an option recognized by the user-provided "additional parser". I would like to deprecate the 'implicit' options and eventually remove them. Another alternative is to require that value for implicit options is specified in the same token: --someoption=foo Another problem is with the "multitoken" options. Those are options which allow the value to span several tokens on the command line. Again, we need to check, for each token, if it looks like option or like value, and this is tricky. I'd like to deprecate this behaviour as well. Any objections? - Volodya

2 1

utf8_codecvt_facet location
by Robert Ramey 28 Feb '05

28 Feb '05

I've made changes so that the serialization library uses the utf8_codecvt_facet in boost/detail. Now I have a couple of questions: a) Where should the documentation page be moved to? I would expect that there should be: boost/libs/detail/codecvt/doc - but its not there b) Where should the test be moved to? Right now I'm running the test as part of the serialization libray. But I would be happy it moved to somewhere else. Looking at what we do to import the same code module under different namespaces makes me think we would have been better off just getting it officially into boost. The current system seems adequate - but its a little cumbersome and different than all the other boost libraries - so its one more thing to figure out and keep track of for someone who wants to use it somewhere else. Robert Ramey

3 3

special_functions_test
by Gennadiy Rozental 28 Feb '05

28 Feb '05

Hi, Hubert For some reason I couldn't locate message to respond, but here is reply to your last post: > Well, actually, I am held up at the moment by what seems to be > internal Boost.Test problems. > I checked in a few days ago some modifications to the special > functions tests, which take into account the modifications to the > BOOST_CHECK_PREDICATE macro, but compilations still fails (Xcode 1.5): 1. You are using unit_test_ex.hpp. I forgot to remove this header. We don't need it anymore. Boost .Test now works with boost::function out of the box without any extra support. Just use unit_test.hpp 2. I noticed that your test could benefit from BOOST_TEST_TEMPLATE facility. I spend some time and look on attached version that do the trick. Fell free to use it if you want. 3. Usually It's not good idea to do ant thing from within init_test_suite function. This code is not guarded and should only be used for test tree creation. Gennadiy begin 666 special_functions.rar M4F%R(1H'`,^0<P``#0````````#;Q70@D#,`)@,``#4(```"^,CM3-U@6#(= M,PX`( ```&%C;W-H7W1E<W0N:'!P`+#Q:F 1W0S,S/T8$7NO"CCO$JR1)NVS MC(Y,R116R99\<K5O58FD6V<J:2J^$C<N3W>Y7)*VBD@4DVTU4YQG4\"O@-&@ MG1I/C@&@D$ :`#G[_F;F#P(<TTQ1.%A%"2#.8"MD$PR[!B2Q//:,Z_&^*,8' MB,E8;T<R682NN04#((C7(@@!*(:B(E'7LKY<.*..>*^1\/#K97!?"W;^*4XY MS%-0P+\7D:"K-$H.^5V2XR[SN"'O8?T;I*R22 FZ+\1_`%"*XE;2D?O$).32 MN2NXWF',LC.&C5O3T**]=Y5>XN8\.20D-;,AHDR89Y24Z%[@T#O_PE?/24H_ MPIUI9%#T>Z1!EN*505W3N[-AQU/[&&.34KW'5$SFB<;S#)TI!?-R>I1["0=/ M4SKNO_:!RR#'R798@( B;9N2DE)KI^KL.63F6K&:RT:K37"HMZN1]^:C.]TJ M41BZ"..LDTO[0.$B@.F0QP<$CC6<8OP<-E #ZQ6<$]!Y8^+(!R*5-\K*[9<< MTU-$KB)]T9XZB!H?6?->4?1W(),V%T. R[Z1'C?;!B_$+9HMW!&IE\<@](0: M-0BL*MC*$_/3X\B/#9A?#-,3@9?6*03QUL'HH747$?\#\-X^?FVIV^0+9+W; M$\J%WWGG#KYZA"!EALC6HDV35.E#E37!@0Q/N#JRX'7B@AR]G9>6765#)3DO M*AZ]7;T\F=7^?WZU%NCLZQTM0=P=T-$:6GJ)CJS+W)]%1VE@C'NS.+$5R?FW M)J'1NT'#HKD_29:U,^7;H7;?"47.\5<[P75@MZN-$\.TE:JKN>3Y0S/AD:#= MMOA#Q=S]RV?UW-Q&<=HT^U);D%Q4M$/Q!"!Z;^]OVT4ZW\WT:SPZ]N*<ZJGU M7[?LKS="@(L.E[;<U<"Y/U%,X>?H[J JF!V?(4+E#K5CY1D*FI\3V*0[G2M: M^8P=.@44S<1&?R/:+]G$^R2J?A^T_&3!63:>+8I^I@54RT[%?#N4HQD:K%-$ M6Q*M,&J1!W>'4:9&_.V%F/BJ0J#;&B[$;U+VZ57U]@"0]X[F^C_U;%2\;:7C M@V\K[0Y:S>[:.IP=2-5FV"M4=&W\0-P"=""0,P`?`P``*0@```)Y,YW V&!8 M,ATS#@`@````87-I;FA?=&5S="YH<' `\".12!'=#,S,_1@1>Z\*..\2K)&F M[;.,CDS)%';)EGQRM6]5B:1;9RII*KX2)RY/=[E<DK:):!23;353G&=3P330 MT: =&D^.;H! (^)!S]_X;@\"'-1043A810D@S& K9!,0%<Q6<3SV?.OR/BD& M!XC)6&\_,EF$KKD$X]!$:Y$D@(B&JF)5U[(^7#BDCGBOD?#\=;.2+X6K7QLS M#G,4U# OQ>1H*JT2<\Y770*[SN"'O8?S[I*R0\!-T7XD^ *6*W9M63OWB$F) M6&67<;S#F0[.&>[>GH5N]=ZZO;7,>&,Y(7JR%DF3#-(T'0O<&<=_^+-]%)LR M?A4J2J:7H]QT&6XM"@KFG<TN''2^L@8SZE>XZ8F8PI(\HRE"2+Y>4U*/62B$ M]40NZ_]G'*X*CPNR<H@")=FSTDH,Z?]<AR'YT58S66D5:6X4^/5R/ORT9GNT M)1&+G(Y*CEE_:2 (LMA1Z<' =QK,,7X.&N@(**^"SH@\LC5<$<BT)OE97;+C MEFHH*HB;=&:0H L?73=?B3I+.)*V&5' 9-Z1'C';!B_$+9H;F"13+XSCT #3 MI%:PJFL@3]%/CC3X:\'PRS$P3)ZQ2"?G6P>I.N1<2/@/PWML?7R!C<O=L#]( MA[T*UM[6@98;(UJF]DL4HWU2NTP(8GW!TY<#KQ22Y>SLO++K70\*\EZZ'KU= MO3R9E?Y_?K56Z.SK'0TA#(a)[H61I9^GF.K*O<GTNCL+!&1D_,,$5R;FH?4.BQ MH.&"N3=(MC4RJY<#*CX2%T.^KH=Q<6#'Q<::(=BS8IK8B;\H9GPG:#=MKA#\ MN9NW:1Z[FXG,&GM[J2V,7%0S='#B$#TW][?M)J5/IOIU'AU[?*\]U7ZK]OVN M\W0J"*CH>HW+7 N3]12N(GZ>ZD*EH=?Q^QIICJ5CY)^:>M>*,$I=SI6M?+@. MF8* S,1&?R/:+\F$^R2F;A9I_D>"HFDT6M3>B!33IIV*^'<-/J-JH4SQ:TJT MP:96#N\.HQ&WYMA8HU3(TAZMH-B-ZF;-*K:^O<D/>.WOI_]7!4/#M,TX-O)] MH<M9?=O6XK4C51M@K$_1G^**;W0@D#,`= 0``-P2```"UE[C`]5@6#(=,PX` M( ```&%T86YH7W1E<W0N:'!P`/ W!C\,&8T,S0_-@1N[_%8'0'4JXVG-VSC& MY )KUV[!9LD%;MZH)I8V\&II/5\)&MNS_O15+NMI)HXL23242FQN2Z+PS@DT ML)]/PSTG,3_,'T_3"<)'A\ P$\#R()SD@@)M8C0FALZC(148DFDELUO-HT:\ MNP\^9X6=`TR)*Z^^E-HBZS)D^RV_<=:L``1U\\5]?0XP3+F>CW-XQL!V75(L M+U7+GKMQ(OM(_1\&-OO%`:B@S#GL77 +PKY&NU)C7N@B8X(!\ OY>]D&6+AM MW+<#^$8X(a)1)--?/HV0.0,Y3/;T<]_!TX<"/"B^=K3 2#Z)@Y00/$I;#FM''K M';]2WC*RK;WY4*"H?6^A^$"":K>Q05Z2)H<.69[7@SP:DT<LU*B$D'GA&0CE M&B[*$LQZ13++U L]T?\,BTR(7HBFDR,$F'96!,<8B3RO-.0<[*L[]L3RXH;A M&T]1&PQ#1J>S8DV\&LG/5IAE_JL5";9++L,<?' XIJ$L;-VFR"A-/DI[(._Q M<4R&LWL38(FBJ3/#-&PJ*3%%.J+,(''VLW;T>YYH!(6PU36 DWT!Z'_*@1;D M%/85[(\KZN6 :-"./F![$*AAP%XK-.TGW:=!\G82B0W/&"@EXNJ!T&GD+D+Z M#OE:JAA@8:;$[)R=, D#BS? Z_Y1]ZD(9325&I*#3Q=".0LQ^7P--L+'35<! M]W ?GV=75AQ(XL =+_-AP!^??U]'-J4?T_CIOXN?JZ3HRIE,7P`Y7I!2-D>7 M[D4<T2>]TP\WZX#J^((**OXDL1%HK1# PMP4"N8BT5OFO*[-Z\!B& 4D2TV( MEIOWL0%O(G'ERZ]NN?=HLN_[L%_]D>O]\'MY[X3,.DC*#EE$?Q;@J `_[@E8 MAQ2<1.<7(,?<M?+1?*X>&-J>H'ZQ33[&1_^QSO6>AQ0]6A!I[1RO5_['O6C/ M79=WRDC*K$6:$0*@7+H=KVKX;A?S9LF4&HJEK!I!)H.*2UQ7-D5#V<1]V>L^ M"UE*Y'>DR1.>E\YTFG+5`<X831<O(+QHML6*@,LNX9P>V^.V3>_Z][7<IMO8 M+GU'77\SSYDP^ZL;J6X3V+D4V[H0;]\&:_;,-/X'>8MY[O;:I;6(G4K^9+]% MN/2>&G)0,3%FTIC(\B:9)1=O&'%X-C2I0"C9M*'I,F:%@2++*):5?]/!JU- M3$_2L*=G36-3R%<=34JY*F'7'4R(H[4XI*SQ6'NNR>H.36E$4%=M9MD.7#L2 M8(D`57$'+86#7NGC5QV(V!5VY5W%]JPU2&!+Q09DF48#,GUGD<%8L>26S0?W MQ<F2.H -PL=247I*761M=IW#Q!9\J,!O=5%C7)XRKY\>4=[5?#;AWHU8$ZB8 M=22?;?XR6J2PL6_Y>JGB^SSHC_G\_%:5EW_6J6U9N31&J[Y$GW-IVJJYC<FQ M-6M\B[T]N>!>G^F>?2DW9NL/E%#=8S_BS(T:QG2<$\R?P%H8#[X%_B1+S[9, M=T[QG4S^1:_EJ\;]:VW2RUOUK_Z4R)UL:?.>3C;5/$OBKF^MO^TWS'0@D#(` MM@(``$8(```"5XF2;]!@6#(=,PT`( ```'-I;F-?=&5S="YH<' `L& ]60V9 M4,S,_101=Z\*(=TI"-I)VB:7'8 XHK8Q9TBMV[4$TBVR*FDJNB= HGN]%CLK M;71A**=:C5 C@>BZ#H2)PYT<SG,2\<X<Z3G,PYA'VO_3_X(HH*-TD0HAPZ#& M1P8H2.M)Y7W]->@U-E!@^-HC+FGR(:B(\[#0_H8Y+#00"0$BLD)9Y_O@)DRZ MHYH\0X ]/.2DB]JJON3,[<I)*2 Q1YS851L=$_<CSP2O`]CB[68-.YR-#E@' M9%]=7PA2Q6TU4Y7\`QFDK+33V9]EWOE9R4"SGOK+].!=BVQ(>+NE) :M``R) MB- F.B?N:1V_P3Q%H4]7Y%/-"I(>3V!>SD<R@KM-SSX<>PUU!FEU(_LLB@,P M'=^VS&&HRDBYVE#EPQXRE)IK80IJ*%0+'ZH=ZYU+X8:9A&#R`!+2,\TY.KJP M86,*X>%KV!<-O1U\][0L?#Z=*V&_U=*)E:8?(:B61813\_A 0:C#HR%V7+F< MWH&<4/%G]V/,. DH;A,TU.VZF%'D+?MRX>GI"&=Z`YT>+!>^*Z-C" .%B#NP MB.FP,@&&-UL#K(Z;'VP@(^KMT1</9)3>=[\_;K,Q%W#QRRL(I%Z["=A*I0K< MRZWR8Z_FORWU@(9$]@<EWA8']XY9@C)-6=<_HA>J)P87JD;.(1HITQ%Y*I)6 MO,RM^)+^QM4DF#0W\YQYU$[P`?^&Y).?&'KTL#EEXD/1*3Z10[@I1QY_QJ8= M_G"IE19%;.C-.K0MMX*8B-8O/J5Z0['B-EY4K /RH ZE7RC:^R-8KFX(,?MU MEP4[0TCJ:(1!>\2O$'J[H[:I=O!P4![17FW+=>(!Q=L]W#5*C944YW,<]<T= M7XU.R):X54E$!;IJLD0EW_0.[H+6WH\3@ZHOTL]X#%,JWP/@8EY!5HXJ=&\! MW4E\M@2H_+7A78[BL'S3^4#V'70@D#,`N@(``)T(```"8[W"]-)@6#(=,PX` M( ```'-I;FAC7W1E<W0N:'!P`/"$CRD-W5$(S/T8%7O/"M3O2"C@#M4Z7'8D MX0MC5GQ5;M[1##6WJHP*?"?!53W>JR6UL-9FZ ZPA$JXGT3HWH W,YO,YN<Q MOQS/KS<S<Q?DO_1_\)44%&Z2(40X=!D(X,4)'<S2>9]_3GH)'S!!?&T1ES3Y M4M1$>=AG'X8Y;C00`C$BLD)9Y_N@)ES21RQXQP!Z><*4+VJJ^Y,X;D)+24&. M/Q-A56QSGG&\\!7A>R1=C,&G<Q&AE@';%]9/A"EBN)JIE?PC&<E9::>SOLN] MQ6<LZMYL"R_1A78N,2GB[2D@M6@0)4Q'X6HZ)^[I'9_1/&:@3D_*I6XJ2'\> MPJ#3D>I05ZGL\V'%L19 SEU(_LPC(&H#M_;8AGHJDJIF5*+;L>&IKNBPXAKI MJ&8#'ZG#604WAAIF$8"@KQ:1T&?'T].'$QB7#PM?PKA\\_5S7]"Q\/IT+8L' M3T(SN^8?(>BVQ8A3<_A 0:C"3E-\7;LD-Z!G'#P^,;5D#=CSC@(4QPF?5G0, MKBCK?1&L?NW::WL#Q_$ZXY_!AO_%=&UB!(,14C1$=/A1`,,@FP88CI\F;6M. MWKPC8LRSF5[GQL.LZF+V+B+@PBD:7:3M)<->FK<JZWR8ZOFOR8%@M(C1U9PO MD+ _O&6H".7UO7140LDC2E#2Y73*$:,Q,1MRJ26_6A7/`E_N=5M:=/#?*@X\ MZC0(!3=Z&UN/1D%_^Y^O(#=ZL>BCJGJAX4<*A-'>RV('<%OH"K:\H\!4C88, M^BP1UO$;-NUOZ'])`OBL9AM?9&P?OT+,@(,'J7*,PP:1DJ(1!>\2O"'J]H[B MIOG>WIU//7?*::\:QQ=DWG!.,KZ,Z*;ZY)NM6-7\QT0B;_ JDH@+;-6!`"GS MD5MJN;>CQN#JK*F'N!9TE[=*T#%S**Q7-21N!>5"XW0Z,6>_SL@A6CYVGG(? ME-#J=""0/P`2`P``!0D```)?#DDJR&!8,ATS&@`@````<W!E8VEA;%]F=6YC M=&EO;G-?=&5S="YC<' `L&QW%@P!#0S,_101>Z^*T.<4F'6H[1>+:K <<4M8 M#CD%3D HMH032UI:(FD@O"N007_>@1NQM;K9U)J-R52!V"=%P7AI)PYI.'5\ MV3I\,T[I)P9@S@1G#..'.B:8HQQ1BQD='H'X110#9(P[I<CS,9'WHJZ"`.XD M;J0KK\'9"1MPKOI)B'"'A]TCPO?P\/PKYUQD,44&*0R30B_:*(SCAEN)]\)* ML_CCRL0Z=?(R/.!UA=,OQ?TBL5^&N9]88Y@9AEE_) P]V&9;G+-^]=5P+*KV M%RGCZS$@:&0)14QS0FHZ."SI&7O*^(\JKR^VGY(9+6)P&/9=DU)B4-GD,\2" MWNZ<T4F;=U/6B <<@I6QZ5)ZUR1KQCH=_3=EW7V_*%U(@]? %J>-@Y3L==6K M%S/"(G=)G4?F9#2(a)VDQ(U(^R`;S&0H\.I<+:2,QB#P%8KG8KG96@.AA,<IE) MQJ\E[ JOA^W/H,%SE51+8'@20OQM%;8O, *'?\N]H,"G(R)EQ@]O'LPJB712 MSF$<<D+PN []M"_?>FY_V:XW7R^-E:I&33\F)T=.S+5YO<=$)K7+-G;9W'"! MFROP]4J3?<4DLCJH$.Z;7B;51E2.M.<U?O^4D.U 0=;X*SXS_(7%S<RV'5"J M'9;HO:-&ILQBOW=,$U#FPXD]3H6!1(!6W0'5*I-16M/M_6W-PMS2]-82*@&# M0]UMAII'=F;MQ94/7EY[]P" 6U,M;<!0O0E:_X!XB=V'P5C-YFQF@)[ $N>R M`,R/QOG1]?LQ9],"' 7C>.CP0M@6MSJW;UR^OR=&"[AO<V!:<=Z5?K+YH9^> MKO+-GRK9LV?'QO(AA\.0Z<X^ZU*(_T-U&FB0>U\FDQ,-G*^Q2D@'+<\NE&UH M'I"BA)K0=)D+BA7$YTY=3RUSYAA <!: NFHE3-J H"C*C8^.OU107C&)\-+9 M1; ZBD@+9THIO$;LQ<]=!W<KFX#T^S:@O#<//0&C+8/V7('"(RX-GJWE(*,J M?40)LFLU%"_/513GF1Y#@&\T29;].KO2W154YZK;/S\//IAP_,?X@,0]>P! "!P`` ` end

2 3

Querying usefulness of a macro for inheriting from STL containers
by christopher diggins 28 Feb '05

28 Feb '05

When inheriting from an STL container the constructors and local typedefs need to be redeclared. For instance the vector contract class at http://www.ootl.org/pwc/pwc_vector.hpp.htm . It seems to me that it would be very useful to have a single macro for each of the different STL containers to ease inheritance of them. Does Boost already have something like that? If not would anyone else want something like this for Boost? Or am I really missing something basic here, and this is a bad idea for some obscure C++ reason? i.e. #define BOOST_STL_VECTOR_OVERRIDE(NAME, ELEMENT) /* */ \ typedef std::vector<ELEMENT> inherited; \ typedef typename inherited::size_type size_type; \ typedef typename inherited::reference reference; \ typedef typename inherited::iterator iterator; \ typedef typename inherited::const_iterator const_iterator; \ typedef typename inherited::reverse_iterator reverse_iterator; \ typedef typename inherited::const_reverse_iterator const_reverse_iterator; \ NAME() { } \ NAME(size_type n) : inherited(n) { } \ NAME(size_type n, const ELEMENT& t) : inherited(n, t) { } \ NAME(const NAME& x) : inherited(x) { } \ NAME(const inherited& x) : inherited(x) { } \ template <class InputIterator> \ NAME(InputIterator x0, InputIterator x1) : inherited(x0, x1) { } \ /* */ Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

6 21

Filesystem efficiency- search sample
by Terence Wilson 28 Feb '05

28 Feb '05

I'm interested in using the filesystem library, however, I was disappointed by the performance test I ran. I wrote a simple recursive find file function using win32 to compare its speed with the find_file sample in the 2 minute tutorial, I found Boost to be 2-3 times slower on average. Does anyone have any thoughts on where the slowdown may be? Terence Wilson

2 1

Re: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions
by JOAQUIN LOPEZ MU?Z 28 Feb '05

28 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Sábado, Febrero 26, 2005 5:40 pm Asunto: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions > Thorsten Ottosen wrote: > > I think tr components should be allowed special status. What's > the point in > > putting tr components through a normal review, when there can be > no interface > > changes? > > > > If the definition of fast-track review is not suitable for tr > components, then > > let us call it a > > tr review. The important aspect of such a review is that it > should be fast. > > Fast as in soon? Or just spending less time on the review? I don't > mind > waiting in the review queue so unless anyone really wants to see > this in > Boost as soon as possible, I guess that Boost.Hash should be fast > tracked, Boost.Unordered should go in the queue, maybe for a > shorter > than normal review. Is that okay with everyone? > Is perfect with me at least :) I guess the review wizard should allocate a period for fasttrack reviewing Boost.Hash (which, if I understand it OK, can run in paralel with other regular reviews.) Tom? As for my negative vote to accepting Boost.Unordered for fasttrack, my main concern is that other authors are patiently standing in line for their own reviews, and the size and scope of this library does not justify for a fasttrack treatment, in my humble opinion. Other than that I think the lib is needed and will eventually make it into Boost. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[program options] optional/required options
by Stefan Slapeta 28 Feb '05

28 Feb '05

Hi, I don't know if this has been answered yet, but is there any concept of optional/required options in the program option library? Currently, only "allowed options" can be defined, no? I would be great if you could define different sets of required option groups (because it's possible that a+b _or_ a+c are required) and provide some validatation for that. Otherwise, you have to do that by hand again and again. Stefan

2 3

Boost library inclusion: generic tree containers?
by Justin Gottschlich 28 Feb '05

28 Feb '05

Dear Boost library members - My name is Justin Gottschlich and have just recently joined the boost mailing list. Since this is my first post, I would first like to apologize in advance for any e-mail inequities I manage to include in this e-mail. I'm e-mailing is to ask if there may be interest in a generic tree container for addition to Boost. I have created four generic tree libraries which I am currently using in my online game (Nodeka). Additionally, my former company began using them in a rather small scope in 2002 and has since requested additional use of the libraries throughout their product (QuarkXPress) and my current company is now showing interest in using them and will begin using them within the next couple weeks (Raytheon Company). Due to the increased interest of the tree libraries, I am now bringing them to your attention in case you feel they may be of interest for Boost library inclusion. The four containers I have written are: core::tree - creates a generic tree that follows std::set functionality per tree level core::multitree - creates a generic tree that follows std::multiset functionality per tree level core::tree_pair - creates a key/value generic tree that follows std::map functionality per tree level core::multitree_pair - creates a key/value generic tree that follows std::multimap functionality per tree level In addition, I have four iterators for each tree container. The containers are written in an extremely general manner so while they have ordered behavior through "insert" functionality (like set and map), they can also achieve unordered element behavior through "push_back" and "push_front" behavior. The reason for this is so the generic tree containers can be used as a basic framework to build additional, algorithm or purpose driven behavior (nested sets, compiler based control trees). The containers are by no means up to "standards" quality - so much work would be needed there. =) I have written two articles on my tree containers (one published on gamedev.net) and the second article in the process for publication on gamedev.net that is currently being reviewed. I have posted both articles on my site for review (if you're interested in reading them): http://nodeka.com/TreePart1.pdf http://nodeka.com/TreePart2.pdf The second article really explains the design thoughts behind the tree containers. The first article simple shows how I've seen C++ programmers build trees using maps and why that's bad. =) If you are interested in the reasoning of my design for the trees, I would recommend reading the second article (http://nodeka.com/TreePart2.pdf) The current header source code can be seen here: http://nodeka.com/tree.h http://nodeka.com/multitree.h The core::tree_pair and core::multitree_pair are undergoing some changes so I haven't posted them just yet. If you feel generic tree containers are not suitable for Boost, I will completely understand and my feelings won't be hurt by your honesty. =) Thanks for your time and consideration, Justin Gottschlich ( <mailto:justin@nodeka.com> justin(a)nodeka.com, jgottschlich(a)runbox.com)

16 48

Welcome to Jeff Garland as a new Boost moderator!
by Beman Dawes 28 Feb '05

28 Feb '05

Jeff Garland is now a Boost moderator. Jeff is a Boost contributor (Date-Time library), runs the Wiki, and has been generally helping out for a long time. Adding an additional moderator gives us a bit more depth. Welcome to Jeff! --Beman

3 2

Re: Boost library inclusion: generic tree containers?
by Dan Rosen 28 Feb '05

28 Feb '05

Hi all, This is my first posting to the Boost mailing list, so apologies in advance for any gaffes. I wanted to jump into the fray a bit on the tree container discussion with a couple little thoughts I had on the topic. There's been some excellent points made, reviewing the thread thus far, about separating the concerns of tree structure from tree iteration. I agree that it's very appropriate to consider designing the fundamental structure and operations on a tree a distinct exercise from designing how the data might be accessed, traversed or mutated by standard algorithms. Talking first in terms of concepts such as TreeContainer, which behave similarly to (or refine) the existing standard library Container, seems like the right approach. But there has also been some mention of more refined concepts such as AVL Tree, Red-Black Tree, Splay Tree, BTree, etc. which have some intrinsic algorithmic properties that distinguish them from what I'd call a "basic" tree for lack of a better term. I believe that an AVL tree, for example, is not actually a refinement of the basic tree concept, because you can not treat an AVL tree polymorphically as a basic tree. Inserting into one of these types of specialized trees, for example, may invalidate iterators or violate other ordering assumptions that are safe to make in a basic tree. I'm picturing a particularly hairy instance where you have iterators marking a range in, say, a red-black tree, and you call std::transform() on that range in-place. In other words, I think the only tree structures that are appropriate to consider are the basic TreeContainer and strict refinements thereof. Taking my own argument to an extreme, I'm not even entirely convinced that binary or k-ary trees should be considered, since they aren't strictly substitutable for basic trees... That aside, the real idea I wanted to offer was this: If we want to provide the type of behavior that one of these various self-balancing search trees, etc. would offer (which I certainly think we should), it should take much the same form as the heap algorithms present in the standard library do today. The operations push_heap(), pop_heap(), make_heap(), sort_heap() and is_heap() operate with typical, characteristic cleverness on a sequential range of RandomAccessIterators, imposing an ordering more specific than that offered by the RandomAccessContainer storing the data. Similarly, operations such as is_k_ary_tree(int), is_avl_tree(), avl_balance(), etc. would serve to impose and maintain a useful, more specific structure on top of TreeContainer, and would avoid having to make a messy hierarchy of structural concepts. So, this is all just to say: if we adopt the approach of further separating the concern of specialized tree structures, then I believe the exercise of formulating good concepts for basic tree structures becomes simpler. Furthermore, I'm guessing that also makes things easier when we do get to the step of worrying about standard iterators and interoperability with standard library algorithms. Hope this is a useful contribution! Cheers, dr

2 1

[range?] Re: Partial specialization matching
by David Abrahams 27 Feb '05

27 Feb '05

The following message is a courtesy copy of an article that has been posted to comp.lang.c++.moderated as well. [I'm Cc'ing this to Boost because IIRC some people were struggling with a similar issue recently. Of course it may not apply ;-)] "Nicolas" <nicolas.tisserand(a)gmail.com> writes: > Ben Hutchings wrote: > > [snip] >> I believe it was considered unreasonable to require implementers to >> do that kind of analysis, given that it could involve checking for >> specialisations across the whole program. > > Got that. Thanks :) > > In the code I posted, I was trying to specialize a class template > (IteratorTraits) according to the relationship between an Iterator and > its Container. > For instance, I wanted to be able to produce a specialization of > IteratorTraits for what std::vector<T, Alloc> advertises as being its > iterator type. It's fundamentally impossible [unless the core language was to make exceptions based on special knowledge about certain standard library components]. Forget everything you know about vectors, and now consider: template <class Iterator> struct IteratorTraits; template <class T> struct vector { typedef char* iterator; }; // This would be the syntax, if it were legal. template <class T> struct iterator_traits<vector<T>::iterator> { // What is T? }; It's illegal because there's no way for the compiler to deduce T. > Is there a way to do that without having to examine a given STL > implementation and find out what the exact type of std::vector<T, > Alloc>::iterator is? Technically, no. *If* you're willing to assume that std::vector<T,A>::iterator is the same type for any A (which is not quite correct in any real implementation because of vector<bool>), you could do this: template <class Iterator, class Enable = void> struct IteratorTraits; template <class Iterator> struct IteratorTraits< Iterator , boost::enable_if< boost::is_same< Iterator , typename std::vector< typename std::iterator_traits<Iterator>::value_type >::iterator > >::type > { // whatever you want here. }; This specialization of IteratorTraits applies iff the iterator type of a vector of the argument's value_type is the same as the argument. I'm sure you can figure out how to deal with the vector<bool> anomaly. See http://www.boost.org/libs/utility/enable_if.html for information about how enable_if works with class template specializations. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

RE: [boost] Re: IoStreams Question: How do I get "tee" functionality
by Brian Braatz 27 Feb '05

27 Feb '05

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Sunday, February 27, 2005 12:20 PM To: boost(a)lists.boost.org Subject: [boost] Re: IoStreams Question: How do I get "tee" functionality Jonathan Turkanis Wrote: <<<<<<<<<<<<<<<<<<<<< I apparently didn't test that code, because it contained two errors (write takes a const char* instead of a char*, and only multi-character filters implement write() instead of put()). At the end of this message is an updated and tested version. I plan to include a tee filter in the first released version of the library. It should be slightly more efficient than the example. Jonathan <<<<<<<<<<<<<<<<<<<<< BRIAN BRAATZ WRITES: THANK YOU !

1 0

lazy exact arithmetic
by Brandon Kohn 27 Feb '05

27 Feb '05

Hello, I was just posting to see if there is any interest in developing a library to help with exact arithmetic using the lazy arithmetic strategy? I've been working for the last couple of years with computational geometry algorithms, and have found that such a library is really essential to overcoming problems due to floating point precision/round off errors in most computational geometry algorithms with non-brute force complexity. The idea behind the lazy paradigm is that exact computation (using rational arithmetic with arbitrary sized integers) is too costly to be used all the time. So the exact computations are delayed until such a time as you cannot reliably make decisions with the information you have from the 'lazy' filters. The lazy filters are implemented as a layer of calculation that uses interval arithmetic to compare numerical quantities. If the intervals being compared are non-overlapping, the result is considered to be sufficient and exact computation is avoided. If the intervals do overlap, exact computation is required to unambiguously decide how the quantities compare. This is just a rough outline of how the method works, and I'm sure there will be plenty of kinks to work out (my background is in physics and computer science... so perhaps a mathematician in the group would step up to help guide my efforts :). A library such as this one exists in the CGAL kernel library which is available under the LGPL. I find that while the LGPL can be useful in cases where the library is already organized as a single DLL/shared object library, it is generally difficult to implement into commercial solutions due to the dynamic linking constraints imposed by the library. Further, I think that this type of algorithm (which solves a very big problem with floating point arithmetic in computing) is really something that should be standardized and freely available. Sorry for the long post :) What do you guys think? Kind regards, Brandon

5 6

IoStreams Question: How do I get "tee" functionality
by Brian Braatz 27 Feb '05

27 Feb '05

However, I am NOT (yet) an expert in the Iostreams library so please excuse me if I am missing something obvious. I add 2 sinks filtering_ostream out; out.push(file_sink("Report.txt")); out.push(cout); I get an exception thrown on the second one (regardless of which one goes in first) In searching the archives, I noticed this mail: http://tinyurl.com/6soeb where Johnathon Turkis writes: "For this we need to define an OutputFilter which stores a reference to an ostream and has a member function 'write' which forwards all characters to the stored ostream as well as to the downstream sink (you don't need to understand the following code -- the point is that it's just a few lines): struct tee : boost::io::output_filter { tee(std::ostream& dest) : dest(dest) { } template<typename Sink> void write(Sink& snk, char* s, std::streamsize n) { // Write to the downstream Sink boost::io::write(snk, s, n); // Write to the stored ostream: dest.write(s, n); } std::ostream& dest; }; We use the tee as follows. Given two ostreams ostream first; ostream second; we define a filtering_ostream which passes data through the tee to both streams: filtering_ostream out; out.push(tee(first)); out.push(second); out << "this gets written to both ostreams\n"; " Which looks "good" except I suspect the library has changed since the above is not compiling for me under VC71. (it complains about wanting a Put() instead of a write()).. Any help appreciated- and also - a request- if "tee" functionality could be officially implemented in the streaming lib for output sinks. OR if it already is, I request that how do to it be spelled out more clearly in the documentation. Thanks Brian Braatz

2 1

Re: [boost] boost::multi_index::key_extractors status
by JOAQUIN LOPEZ MU?Z 27 Feb '05

27 Feb '05

----- Mensaje original ----- De: Loïc Joly <loic.actarus.joly(a)wanadoo.fr> Fecha: Domingo, Febrero 27, 2005 7:04 pm Asunto: [boost] boost::multi_index::key_extractors status > Hello everybody, > > I'm discovering boost::multi_index, and something strikes me: I've > been > dreaming of something like boost::multi_index key extractors (and > especially member) for most of my std::set or std::sort uses. > > I therefore think that this part of boost::multi_index does not > belong > in this library, but is more general purpose, and deserves a > library of > its own, along with a way to get a suitable less predicate from > the > result of those. All the arguments that make such a framework > usefull > for boost::multi_index can equally be applied to STL containers > and > algorithms. > > I wonder if such a proposal has already been made (maybe it even > already > exists, boost has so many parts that I may be unaware of this), > and in > the positive case what were the arguments in favor or in > opposition of it. > This issue was considered during the review, and those who gave an opinion about it thought it was better to leave like it is now. Anyway, there's nothing preventing you from using the key extraction sublib for your own purposes, as it is headerwise separate from the rest. You'll only need some compose classes to plug key extractors into comparison predicates, something like this: template<typename KeyFromValue> struct key_less { typedef result_type bool; template <typename Arg> bool operator()(const Arg& x,const Arg& y) { return key(x)<key(y); } private: KeyFromValue key; }; ... typedef std::set< employee, key_less<member<employee,std::string,&employee::name> > > employee_set; HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

boost::multi_index::key_extractors status
by Loïc Joly 27 Feb '05

27 Feb '05

Hello everybody, I'm discovering boost::multi_index, and something strikes me: I've been dreaming of something like boost::multi_index key extractors (and especially member) for most of my std::set or std::sort uses. I therefore think that this part of boost::multi_index does not belong in this library, but is more general purpose, and deserves a library of its own, along with a way to get a suitable less predicate from the result of those. All the arguments that make such a framework usefull for boost::multi_index can equally be applied to STL containers and algorithms. I wonder if such a proposal has already been made (maybe it even already exists, boost has so many parts that I may be unaware of this), and in the positive case what were the arguments in favor or in opposition of it. Best regards, -- Loïc

1 0

Reading the contents of a directory
by Dark Haruka 27 Feb '05

27 Feb '05

Hello :) I'm searching a library for C/C++ which can access directorys. I have read that the boost library can it. So I have downloaded and installed it. But I'm searching a function with which I can look up which files are in a directory. I'd like to say a directory to scan to the function. The function should return the names of the files in that directory and if possible the name of subdirs. Does anyone know this function? Thank you in advance :)

2 1

Object-oriented preprocessor programming :-)
by Arkadiy Vertleyb 27 Feb '05

27 Feb '05

Hi all, If one needs to manage a lot of PP code, some code structuring technique might be helpful. So, how about the OO? The example below demonstrates this techinique with the canonical shapes example. An object is represented as a PP sequence of properties. The head of the sequence contains the "class name" and is used for dispatching. I believe this proved very useful in the BOOST_TYPEOF project where we polymorphicaly treat type, integral, and template template parameters. Comments? Regards, Arkadiy -- #include <boost/preprocessor/seq/transform.hpp> #include <boost/preprocessor/seq/enum.hpp> #include <boost/preprocessor/seq/cat.hpp> #include <boost/lambda/lambda.hpp> #include <algorithm> #include <iostream> // #define VIRTUAL(Fname, This) BOOST_PP_SEQ_CAT(\ (BOOST_PP_SEQ_HEAD(This))(_)(Fname)) // #define CIRCLE(r) (CIRCLE)(r) #define CIRCLE_RADIUS(This)\ BOOST_PP_SEQ_ELEM(1, This) #define CIRCLE_AREA(This)\ 2 * 3.14159 * CIRCLE_RADIUS(This) // #define RECTANGLE(h, w) (RECTANGLE)(h)(w) #define RECTANGLE_HIGHT(This)\ BOOST_PP_SEQ_ELEM(1, This) #define RECTANGLE_WIDTH(This)\ BOOST_PP_SEQ_ELEM(2, This) #define RECTANGLE_AREA(This)\ RECTANGLE_HIGHT(This) * RECTANGLE_WIDTH(This) // #define SQUARE(x) (SQUARE)(x) #define SQUARE_SIDE(This)\ BOOST_PP_SEQ_ELEM(1, This) #define SQUARE_AREA(This)\ SQUARE_SIDE(This) * SQUARE_SIDE(This) // #define MY_SHAPES\ (CIRCLE(5))\ (RECTANGLE(3, 4))\ (CIRCLE(3))\ (SQUARE(3))\ (SQUARE(5))\ (RECTANGLE(2, 6)) #define ENUM_AREAS(shapes)\ BOOST_PP_SEQ_ENUM(BOOST_PP_SEQ_TRANSFORM(OP, ~, shapes)) #define OP(s, data, elem)\ VIRTUAL(AREA, elem)(elem) double MyAreas[] = { ENUM_AREAS(MY_SHAPES) }; // int main() { using namespace std; using namespace boost::lambda; for_each( MyAreas, MyAreas + sizeof(MyAreas)/sizeof(MyAreas[0]), cout << _1 << "\n"); return 0; }

1 0

Autoconfiguration problem with wcs* functions?
by Julio M. Merino Vidal 27 Feb '05

27 Feb '05

Hi all, I'm using the autoconfiguration framework under NetBSD 2.99.14 to generate an user.hpp file. The libs/config/test/boost_no_cwchar.ipp test passes successfully, so Boost ends up thinking that wcs* functions work. In fact, they do, but in C (defined in wchar.h). The problem is that those functions (I'm referring to wcscmp and wcslen, but maybe there are some others) are not (yet) defined in the std:: namespace. (The wchar stuff is being worked on at the moment, AFAICT; at least, it's very recent.) So, what happens? As the BOOST_NO_CWCHAR constant is not defined, the build will try to use cwchar functions. And it will fail at multiple places. The "problem" is that the code is using std::wcscmp and std::wcslen because it thinks it can. I don't know which is the correct fix. Just temporally, I've changed the test to use the functions in the std:: namespace rather than the other ones, so that I get a failure and cwchar is disabled. But this seems suboptimal (basically because the functions do exist). Any comments on how this should be handled? Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 1

Type of Review for Unordered Associative Containers & Hash Functions
by Daniel James 27 Feb '05

27 Feb '05

Hello everyone, I've just uploaded a new version of the unordered associative containers, this time in the 'Hash' folder on the file vault. There's also the file 'hash.tar.gz', which is just the hash function object. The hash function objects are ready for review, the container library is almost ready, it mainly just needs more documentation. The implementation has been split into two libraries. Boost.Hash implements the hash function objects which would go into <functional>, so it is proposed that these are added to the functional library. This is needed for Joaquín's MultiIndex library, so it would be good to add it to Boost as soon as possible. The other part is Boost.Unordered, which implements the unordered associative containers. This is a little larger and more complicated, and there's no immediate need for it (unless you count Boost.Tr1). We're not sure what kind of review these libraries will need. Since they're both based on the draft standard, their design isn't really up for review here (right?), but the documentation and implementation is. Do you think they require a full review, or will a fast track review be appropriate? A fast track review is tentatively scheduled for the hash function objects after the review of the finite state machine, with Thorsten managing it. The full container library could be included in this, if that is considered acceptable. Or it could be added to the queue for a full review? Any opinions? Daniel

7 10

runtime rvalue detection for Visual C++ 6.0
by Peder Holt 26 Feb '05

26 Feb '05

I was looking through the FOR_EACH - implementation, and noticed that it lacks rvalue detection for Visual C++ 6.0. After some investigation, I have found one very sleazy way of detecting rvalue-ness runtime without evaluating the argument more than once: # define BOOST_FOREACH_TYPEOF(COL) \ *(true ? 0 : &::boost::for_each::wrap(COL)) template<typename T> inline static_any<simple_variant<T const> > contain(int const& position_test,T const &t, bool const &, mpl::false_) { int rvalue_test=int(&t)-int(&position_test); bool rvalue=(rvalue_test<=8); return rvalue ? simple_variant<T const>(t) : simple_variant<T const>(&t); } Since this relies on the position of objects on the stack, there are probably cases where it will fail. Pointers (e.g. string constants) must be handled separately. Regards Peder

3 2

typeid/type_info proposal (long, go get another jolt cola)
by Jody Hagins 26 Feb '05

26 Feb '05

Warning: This is a fairly lengthy post, as I have had a difficult time putting my thoughts into words (also, I have had very little free time lately -- though it is hard to say that with a straight face since I just spent the holiday weekend skiiing). If you want to skip my monotonous musings, read the summary only, and possibly skip down a few paragraphs until you see a significant amout of vertical white space, then read some more technical points. I would really appreciate any thoughts or insights, as I am quite frankly not very satisfied with my own. SUMMARY: I would like to delay proposing a typeid() replacement. Instead, I'd like to submit my testsuite, and ask people to run it on various platforms and report the results. This will help us decide how best to approach this seemingly simple, but very difficult, subject. I would like to propose a boost::type_info class now (or very soon). Meaningful instances of boost::type_info will be constructed from a std::type_info resulting from a native typeid() call. Once we figure out what route to take wrt typeid(), then I think it can be used in a very straight forward manner. Now for some rumblings, where I try to sort out my experiences with typeid (I apologize in advance for the lack of polish, but I want to get this out for comment because I am going out of town Friday afternoon, and will not be back until Sunday night). A while back, I had some of my own code to use typeid/type_info. The code was inspired by the TypeInfo class in "Modern C++ Design" by Andrei Alexandrescu. However, I ran into some issues (namely the infamous g++ shared library problem). A search of boost found an implementation in Boost.Python. As has been mentioned in the past, this seems like a useful utility to have around, so I made an attempt to bring it out of Boost.Python, and give it life of its own. David suggested that such a small exposure is a good candidate for a fast track review, so I naively thought that meant it would be a small amount of work. Along the way, I ran into several portability issues, and decided to make sure the code had the best typeid/type_info support I could imagine. Unfortunately, this took me down a very twisted highway. I could not find an existing test suite, so I wrote my own, based on the standard (5.2.8 and 18.5.1). Well, this turned into a nightmare, because I have had a hard time finding any compiler that will pass all my tests. I have had to move to gcc 3.4 to get most of them to pass, and still some fail (though it may be due to my tests... I am still looking into that). I will say that I now know more about typeid() than I ever thought I'd want to know (I could quite possibly quote verbatum section 5.2.8, and a fair bit of 18.5.1 to boot). Anyway, getting a portable typeid/type_info library working is not exactly as easy as it appears. A previous post of mine attributes most typeid problems to older msvc/intel compilers. This is only mostly true. They are the worst, because they do not even try to remove the top-level cv-qualifiers. However, even relatively recent versions of gcc has had problems with this in esoteric cases (multidimensional array with cv qualifiers mixed with typedefs). All this to say that I have my doubts that many compilers fully support typeid() correctly. To top it all off, many implementations have trouble honoring the comparison mechanism across separate shared libraries (as noted in the Boost.Python implementation), so there are some workarounds needed for type_info as well. Since I have seen so many problems, I am no longer certain that the review of typeid can be done quickly. While the implementation in Boost.Python works well, it also has several holes, so I do not think it wise to simply "bring it out" into boost. Thus, I have made an attempt to "industrialize" it. With this in mind, I thought I'd give a rundown of the major issues. I recently posted some of my concerns, but due to the length of that post, and possibly its ramblings, I have not seen any replies. Yes, I know, this one is longer, and possibly more "rambling" but I am hopeful yet ;-) I will leave the more minor issues for later, but would really like some input on the bigger ones. The library, as used in Boost.Python, relies on calling the no-parameter template function, type_id, to get the type info object. Use of typeid() by itself is absent, because of the problem with compilers getting the typeid() implementation correct. For example: struct foo { /* ... */ }; boost::python::type_info ti = boost::python::type_id< foo >(); Unfortunately, boost::python::type_id<>() has a couple major drawbacks (and a number of "minor" ones). 1. It only supports type-id calls, with a specific type passed as a template parameter. The ability to compute type_info based on the result of an expression is scant (a bit more functionality can possibly be obtained with more tricks like the ingenious typeof() stuff recently posted). 2. To add support for expressions and lvalues, overloads of type_id() can be provided. This works reasonably well (with enough machinery to get around compiler problems), but the spec for typeid() says that the expression is not supposed to be evaluated (unless the expression is an lvalue of a polymorphic type, or dereferences a pointer to a polymorphic type). I have yet to see a way to call a function and prevent the expression from being evaluated (maybe with some modern tricks and is_polymorphic -- but we are then probably leaving several compilers behind as well). Also, I have been unable to get the "workaround" to throw std::bad_typeid when dereferencing a null pointer, as specified in 5.2.8.2). 3. For compilers with bad cv-qualifier support wrt typeid(), it requires a fair amount of machinery to get rid of the cv-qualifiers. Unfortunately, the same machinery makes it difficult to preserve the polymorphic requirements of 5.2.8.2, and I have yet to find the right code to get this to work (though I think it may be possible). Thus, we face a dilemma. Either always use the native typeid(), knowing that your compiler may not fully support it "by the book" or provide some workaround, that will not provide everything either. By fixing some things, others are broken. We are left with some options: 1. Always use the native typeid() in code, and live with what the compiler does. 2. Always use a "workaround" and live with whatever level of "brokeness" that provides. I am not convinced that we can get a consistent level of brokeness for all compilers, though it is more likely to be close for all compilers than just using typeid(). 3. Provide a macro BOOST_TYPEID(), which is set depending on which compiler is being used, to get the "best" effect. Depending on the day, I feel differently about which option I like. Thus, I have written a fairly extensive set of tests for native typeid(). I feel fairly certain that they can tell us what to expect from any compiler relative to typeid conformance. We could use those tests results, from "all" the supported platforms to see where we are (my access to compilers/platforms is quite limited). Maybe if we had a better idea about what each of the "major" platoforms do/not support we could get a better idea as to how we want to proceed. In any case, I do not think this will be super quick. So, let's move to type_info. I think this one is a bit more clear (though we still need some compiler workarounds). However, the only real workarounds I have found so far involve "broken" comparison operators. I think these are fairly well known, and mostly solved. I also have a fairly extensive set of tests for native std::type_info, as well as the new boost::type_info. However, I am still hung up on the whole typeid thing stated above. I tend to think that most use of typeid() will work as expected. The "major" problems concern quite old compilers (I think), and some of the problems in more modern compilers are in the "corners" of usage. Thus, it makes sense to get boost::type_info in place, and wait until we have some test results to see what is the propor course of action for typeid. Thanks, and if you read this far, maybe YOU should go skiing ;-)

5 8

Gauging interest: minimalistic test library
by Pavel Vozenilek 26 Feb '05

26 Feb '05

In sandbox http://boost-sandbox.sourceforge.net/vault/ is small (1 header minitest.hpp) Boostified library to help with testing. I use it instead of other frameworks as it doesn't require any work. Example of use: _________________________________ #include <boost/minitest.hpp> BOOST_MINITEST { assert(....); } BOOST_MINITEST { assert(....); .... } ... boost::minitest::execute_all_tests(); _________________________________ Features: - no helper classes, functions or naming conventions needed - allows to execute tests randomly (I found this very helpful) - it is possible to execute tests only from last N modified source files. This allows to re-run tests after every minor source modification (i.e. Test Driven Development) - no *.cpp files - works on systems w/o exceptions enabled, doesn't need RTTI - works with DLLs (it is needed to "register" every DLL). DLLs can be dynamically loaded/unloaded. - tested with VC6, Intel 7, BCB 6. Should work on UNIXes (I don't try yet). - allows to re-run failed test immediatelly if user wishes _________________________________ Disadvantages: - tests must be written on top level (i.e. not within functions) - no mechanism to select what "exact" tests to run is available (by design - I found it rather useless for me) - testing a DLLs requires few lines of support code per DLL - the "test only few last changed files" feature is rather brittle - it doesn't deal with headers and dependencies (it is just quick an dirty tool) Would this tiny tool be useful as part of Boost? - as complement to Boost.Test. If there's interest I can write docs and add tests. /Pavel

2 1

portable lock free algorithms
by Maxim Yegorushkin 25 Feb '05

25 Feb '05

Hi there, I've just read the paper "High Performance Dynamic Lock-Free Hash Tables and List-Based Sets" by Maged M. Michael at http://www.cs.tau.ac.il/~shanir/reading%20group/p73-michael.pdf and wonder if the subject has become feasible. The paper basically states that the algorithms can be implemented on most current processor architectures using CAS or LL/CS instructions, rather than rare DCAS/CAS2 instructions. Is that true? Is there something going on in boost with regards to the subject? -- Maxim Yegorushkin

2 1

Wave accepted
by Tom Brinkman 25 Feb '05

25 Feb '05

The boost::wave library is accepted into boost. A couple of review comments are summarized below from Paul Mensonides and Joel de Guzman. Paul Mensonides stated: "I think that the design and implementation are good. The library has reasonable performance in preprocessing complex examples and is more conformant to the standards than most other vendors' preprocessors. Nearly every tool that analyzes C++ source effectively needs to have the ability to preprocess that source. Having a plugable preprocessor is a boon for tool developers--including possible future Boost tools. That said, the potential usefulness of the library (as a library) is fairly restricted to tool development. OTOH, the driver can be used as a replacement for faulty preprocessors without a great deal of effort. Furthermore, the tracing ability of the library (and, by extension, the driver) makes it hands-down the best tool for debugging complex preprocessor metaprograms. This is especially true because tracing can be turned on and off mid-expansion with pragmas (in particular, with the _Pragma operator borrowed from C99). My use of the wave-driver has spanned a couple years now, and during that time Hartmut has fixed nearly all problems that I've encountered. Beyond the utility and capabilities of the library, the existence of the library makes a worthwhile political statement to compiler vendors. I endorse the concept of a Boost preprocessor, and I endorse this particular realization of that concept. Furthermore, I endorse the author (Hartmut). He has been a very responsible and responsive implementor/maintainer--for Spirit as well as the Wave project." Joel de Guzman stated: "I think this (wave) is the most flexible pre-processor I know. It's a c++ library, so I expected full extensibility. Hartmut was very thorough in his design with more than enough links and hooks through policies and callbacks to do almost anything imaginable. The structure is highly modular. The implementation is very good. Hartmut has been a very avid Spirit developer and I've known him to be an excelent coder. I took a peek at the code, sure enough, he's a Spirit expert who can churn out really cool Spirit parsers." Review Managers Conclusion: As the wave library has been in active development for three years, has the endorsement of key boost members, and has demonstrated great utility, I think that boost::wave should be added to boost without delay. Congratulations and thanks to Hartmut Kaiser for his submission. Tom Brinkman Review Manager - boost::wave __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

6 6

proposed extension for boost::any
by Frantz Maerten 25 Feb '05

25 Feb '05

Hi all, While using boost::any with pointers, I realized the following problem for polymorphic classes: \code class A { public: virtual ~A() {} } ; class B: public A {} ; int main() { boost::any b(new B) ; try { A* a = boost::any_cast<A*>(b) ; } catch (const boost::bad_any_cast&) {/*failed*/} } \endcode Of course the following code failes, since rtti information is used for casting. I extended the boost::any concept, and incorporated a boost::any_dynamic_cast (see attachment) This extension uses boost::is_polymorphic and boost::remove_pointer, and allows dynamic casting if possible. Does anyone need this features, and can it be incorporated (after some regression tests) into the boost::any library? Thanks for any comment about it. --Frantz Maerten

2 1

[test] regressions with Borland and VC7
by Jonathan Turkanis 25 Feb '05

25 Feb '05

Hi, Starting yesterday, unit_test_suite.cpp fails to compile with Borland and VC71. Here are the errors I get (I just ran cvs update): ********** Borland 5.6.4 ********** borland-C++-action ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\borland\debu g\unit_test_suite.obj c:\documents and settings\turkanis\home\libraries\boost\libs\test\build\../src/unit_test_suite.cp p: Error E2268 C:\CBuilderX\include\stl/_algo.c 432: Call to undefined function 'rand' in function _STL::int __random_number<int>(int) *** 1 errors in Compile *** "bcc32" -j5 -g255 -q -c -P -w -Ve -Vx -a8 -b- -DBOOST_TEST_NO_AUTO_LINK=1 -v -Od -vi- -tWC -tWR -tWC -WM- -w-8080 -w-8001 -I"..\..\..\bin\boost\libs\test\b uild" -I"C:\Documents and ettings\turkanis\Home\Libraries\boost" -o"..\..\..\bin\boost\libs\test\build\li bboost_unit_test_framework.lib\borland\debug\unit_test_suite.obj" "C:\Documents and Settings\turkanis\Home\Libraries\boost\libs\test\build\../src/unit_test_suite.cp p" ...failed borland-C++-action ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\borland\debu g\unit_test_suite.obj... ********** VC 7.0 ********** vc-C++ ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\vc7\debug\th reading-multi\unit_test_suite.obj unit_test_suite.cpp C:\Documents and Settings\turkanis\Home\Libraries\boost\boost\test\impl\unit_test_suite.ipp(83) : error C2558: class 'boost::unit_test::callback0<R>' : no copy constructor available or copy constructor is declared 'explicit' with [ R=boost::unit_test::ut_detail::unused ] CALL "C:\PROGRA~1\MICROS~1.NET\VC7\bin\VCVARS32.BAT" >nul "C:\PROGRA~1\MICROS~1.NET\VC7\bin\cl" /Zm800 -nologo EHsc -c -DBOOST_TEST_NO_AUTO_LINK=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope c:wchar_t -I"..\..\..\bin\boost\libs\test\build" -I"C:\Documents and Settings\turkanis\Home\Libraries\boost" -Fo"..\..\..\bin\boost\libs\test\build \libboost_unit_test_framework.lib\vc7\debug\threading-multi\unit_test_suite.obj" -Tp"C:\Documents and Settings\turkanis\Home\Libraries\boost\libs\test\build\../src/unit_test_suite.cp p" ..failed vc-C++ ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\c7\debug\thr eading-multi\unit_test_suite.obj... ************************** Jonathan

2 10

STL containers with contracts, any interest?
by christopher diggins 25 Feb '05

25 Feb '05

I am writing a set of contract verification classes for the various STL containers. These are wrapper classes which verify DbC style contracts (i.e. preconditions, postconditions and invariants). I have already written one for std::vector you can see it at: http://www.ootl.org/pwc/ Is anyone interested in seeing this submitted Boost, if I extend it to cover the basic collections? e.g. list, map, set, multimap, multiset, deque, queue, stack? Thanks, Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

5 9

Boost.Test as DLL
by Gennadiy Rozental 25 Feb '05

25 Feb '05

Hi, I am trying to finally implement DLL version of Boost.Test components. Here is several issues/questions I have: 1. main() function AFAIK there is no way to put a main function in DLL on windows. What should we do instead? I reworked the framework specifically for the purpose of making this kind of separation easier. But I still would like to hear what people think in this regard. 2. main() function again On unix(s) there is a possibility to put main info dlls (If I am wrong please correct me). Should we use different semantic for Windows and Unix(s) or use the one I implement for windows? 3. init_unit_test_suite I need to call external function from inside of DLLs. How it should be declared? Cause I am getting unresolved symbols error 4. runtime-link In my Jamfile in default build section of build rule there is <runtime-link>static/dynamic. Should I keep this? Should I use static for lib rule and dynamic for dll rule? Nothing for lib dynamic for dll? Thanks, Gennadiy

4 9

[Boost-bugs] [ boost-Bugs-1151823 ] boost::filesystem::native() should reject '/' on non-Win32
by SourceForge.net 25 Feb '05

25 Feb '05

Bugs item #1151823, was opened at 2005-02-25 14:25 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=1151823&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Bright (sircus) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::native() should reject '/' on non-Win32 Initial Comment: On Win32, filesystem::native() correctly checks paths for validity on Win32. For other systems, it just returns true, presumably on the theory that for Unix, anything goes. Unless I'm much mistaken though, the character '/' is not allowed in Unix filenames. As such, native() should be changed as follows: BOOST_FILESYSTEM_DECL bool native( const std::string &name ) { return name.find('/') == std::string::npos; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1151823&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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

none_t in the boost namespace
by Fernando Cacciola 25 Feb '05

25 Feb '05

Hi people, In the users mailing list, Yuval Ronen pointed out that optional<> uses a type "detail::none_t", documented as such, thus prompting people to use a type in a namesapece which is supposed to be hidden to end users. A straightforward fix is to just move "none_t" out of the detail namespace directlty into boost. However, this little change introduces a new type in the (main) boost namespace, so before I do that I want to make sure it won't have any undesired impact. If you see any reason for not doing this (putting "none_t" right there in boost) please speak now. If no one objects, I'll do it. Best, Fernando Cacciola

2 2

[test] automatic test problem
by Jody Hagins 25 Feb '05

25 Feb '05

Working off current CVS, I have the following file... #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> BOOST_AUTO_UNIT_TEST( test1 ) { BOOST_CHECK(true); } BOOST_AUTO_UNIT_TEST( test2 ) { BOOST_CHECK(true); } as shown in the examples, but when I compile, I get liner errors for missing main and test functions. shandalle:jody> g++ -I${BOOST_ROOT} 5_2_8_1.cpp -o 5_2_8_1 /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x18): undefined reference to `main' /tmp/cccXBUDu.o: In function `test1()': /tmp/cccXBUDu.o(.text+0xec): undefined reference to `boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_ result const&, boost::basic_wrap_stringstream<char>&, boost::unit_test::basic_cstring<char const>, unsigned, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned, ...)' /tmp/cccXBUDu.o: In function `test2()': /tmp/cccXBUDu.o(.text+0x242): undefined reference to `boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_ result const&, boost::basic_wrap_stringstream<char>&, boost::unit_test::basic_cstring<char const>, unsigned, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned, ...)' /tmp/cccXBUDu.o: In function `boost::unit_test::make_test_case(boost::unit_test::callback0<boost::un it_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>)': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test14make_test_caseERKN S0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE+0x3b): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test ::basic_cstring<char const>)' /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test14make_test_caseERKN S0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE+0x70): undefined reference to `boost::unit_test::test_case::test_case[in-charge](boost::unit_test::ba sic_cstring<char const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&)' /tmp/cccXBUDu.o: In function `boost::unit_test::ut_detail::auto_unit_test_suite()': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test9ut_detail20auto_uni t_test_suiteEv+0x4e): undefined reference to `boost::unit_test::test_suite::test_suite[in-charge](boost::unit_test:: basic_cstring<char const>)' /tmp/cccXBUDu.o: In function `boost::unit_test::ut_detail::auto_unit_test_registrar::auto_unit_test_ registrar[in-charge](boost::unit_test::test_case*)': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test9ut_detail24auto_uni t_test_registrarC1EPNS0_9test_caseE+0x26): undefined reference to `boost::unit_test::test_suite::add(boost::unit_test::test_unit*, unsigned long, unsigned)' collect2: ld returned 1 exit status

2 1

exceptional handling at boost/serialization ( reading bad archive )
by junyi.sun＠supportlinux.net 25 Feb '05

25 Feb '05

Hi, I have a class using boost_1.32/serialization to save/restore object data and it's working fine for load & save its own archive. I tried to make it load an archive saved by an unrelated class in order to verify exception handling of reading wrong/ corrupt archive. It dumps core at basic_iarchive_impl::load_pointer. Is it a known issue or anyone has similar experience ? Thanks. Junyi Sun Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libtcl8.4.so...done. Loaded symbols for /usr/lib/libtcl8.4.so Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () (gdb) bt #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () #1 0x081c0d23 in boost::archive::detail::basic_iarchive::load_pointer () #2 0x08060344 in boost::archive::detail::load_pointer_type<boost::archive::text_iarchive, MyObjectP*>::invoke (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:450 #3 0x08060304 in load<boost::archive::text_iarchive, MyObjectP*> (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:529 #4 0x080602ea in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at basic_text_iarchive.hpp:60 #5 0x080602c6 in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at text_iarchive.hpp:59 #6 0x08060298 in operator&<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at interface_iarchive.hpp:92 #7 0x08060260 in serialize<boost::archive::text_iarchive> (this=0xfef3bc80, ar=@0xfef3c240) at nvp.hpp:58 #8 0x0806023d in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at access.hpp:106 #9 0x0806021b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:78 #10 0x080601f9 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:121 #11 0x080601d8 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:318 #12 0x080601b6 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:366 #13 0x0806019c in load<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:529 #14 0x08060182 in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at basic_text_iarchive.hpp:60 #15 0x0806015e in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at text_iarchive.hpp:59 #16 0x08060130 in operator>><boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:105 #17 0x080600b8 in operator&<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:111 #18 0x0805fe43 in serialize<boost::archive::text_iarchive, std::string, MyObjectP*> (ar=@0xfef3c240, p=@0xfef3bf70) at utility.hpp:47 #19 0x0805f59f in serialize_adl<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70, file_version=1) at serialization.hpp:121 #20 0x0805f48f in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load_object_data (this=0x8a3f6c0, ar=@0xfef3c240, x=0xfef3bf70, file_version=1) at iserializer.hpp:155 #21 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #22 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #23 0x0805df95 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:328 #24 0x0805df6c in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:366 #25 0x0805df52 in load<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:529 #26 0x0805df38 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at basic_text_iarchive.hpp:60 #27 0x0805df14 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at text_iarchive.hpp:59 #28 0x0805dee6 in operator&<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at interface_iarchive.hpp:92 #29 0x0805deae in serialize<boost::archive::text_iarchive> (this=0xfef3bf60, ar=@0xfef3c240) at nvp.hpp:58 #30 0x0805de8b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at access.hpp:106 #31 0x0805de69 in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:78 #32 0x0805de47 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:121 #33 0x0805de26 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:318 #34 0x0805de04 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:366 #35 0x0805ddea in load<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ---Type <return> to continue, or q <return> to quit--- ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:529 #36 0x0805ddd0 in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at basic_text_iarchive.hpp:60 #37 0x0805ddac in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at text_iarchive.hpp:59 #38 0x0805dd7e in operator>><boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at interface_iarchive.hpp:105 #39 0x0805d2d2 in boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::operator() (this=0xfef3bfae, ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:110 #40 0x0805d192 in load_collection<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > >, boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > >, boost::serialization::stl::no_reserve_imp<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > > (ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:158 #41 0x0805d110 in load<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4) at map.hpp:61 #42 0x0805d0f5 in boost::serialization::free_loader<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:55 #43 0x0805d0d3 in split_free<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:66 #44 0x0805d0b1 in serialize<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at map.hpp:81 #45 0x0805b339 in serialize_adl<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at serialization.hpp:121 #46 0x0805b03b in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load_object_data (this=0x8a3f5b0, ar=@0xfef3c240, x=0xe3693e4, file_version=0) at iserializer.hpp:155 #47 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #48 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #49 0x08058aa3 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:328 #50 0x08058a7a in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:366 #51 0x08058a60 in load<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:529 #52 0x08058a46 in boost::archive::basic_text_iarchive<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at basic_text_iarchive.hpp:60 #53 0x08058a22 in boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at text_iarchive.hpp:59 #54 0x080579b8 in operator>><std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at interface_iarchive.hpp:83 #55 0x08056615 in encode_function (domain_id=208, bat=0xe728070, info=0xea2c339 "22 serialization::archive 3 0 0 4 1 1 3\n0 0 0 0 1\n1 0 1\n2 0 1\n3 0", info_len=65) at encode.cc:102

2 1

[Boost-bugs] [ boost-Bugs-1150829 ] Files missing in .exe
by SourceForge.net 25 Feb '05

25 Feb '05

Bugs item #1150829, was opened at 2005-02-24 00:19 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=1150829&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Files missing in .exe Initial Comment: I downloaded boost_1_32_0.exe and boost_1_32_0.tar.gz, and noticed that many files present in the .gz file are not in the .exe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1150829&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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

4 4

MSVC 7.1 bug with recursive template typedefs
by Samuel Krempp 24 Feb '05

24 Feb '05

As I said in the thread in [boost-users] about "using boost::format with STLPort" ( <421CC3D6.4010600(a)crans.ens-cachan.fr> ), I've come across a bug with recent MSVC's (tested on MSVC 7.1, and apparently MSVC 8 fails the same way). Does anyone know if this is a known MSVC bug ? Or should someone report that ? The following sample causes error C2244 ("unable to match function definition to an existing declaration") template<class T> struct A { typedef T* some_type; }; template<class T> struct B { typedef typename A<T>::some_type le_type; le_type some_f(); }; template<class T> typename B<T>::le_type B<T>::some_f() { le_type x; return x; } Replacing B<T>::le_type with A<T>::some_type when defining B<T>::some_f() seems to work around the bug. Regards, -- Samuel

2 1

RE: [boost] Re: Boost library inclusion: generic tree containers?
by Brian Braatz 24 Feb '05

24 Feb '05

Extremely interesting. I am working on a similar thing. Except I am doing this- the iterators take policies which tell how to get the parent and children of a node I am sorry I have not dug DEEP into either bodies of work yet. But in a nutshell, I am holding a tree of objects, and then using a template library (similar to BIL- except it is "classical Interface based programming") to QueryInterface (QI) the objects. (this is the opposite of how BIL works) I have gotten working the ability to QI the objects and apply operations to anything in the tree from X node down based on interface supported. This very curious technique is one I am working to evolve into something for controlling dynamic UI objects. In any case, I am writing this to share what I have been working on. Maybe it will give you some ideas. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard Peters Sent: Wednesday, February 23, 2005 12:44 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost library inclusion: generic tree containers? ----- Original Message ----- From: "Rene Rivera" <grafik.list(a)redshift-software.com> > Additionally, I'm also of the opinion that the "iterator" concept should > be kept as it's currently used in STL. An object that does more than an > iterator, because it happens to be an iterator in a tree should be > called something else, "cursor" comes to mind. If it's really > masquerading as a sub-tree, or a tree, then call it a tree. If it's a > pointer to a node in the tree, then perhaps a "node_pointer". Mixing the > terms will just cause more confusion than it's worth. Reading some of > your later posts I can see the confusion already creeping in. My > suggestion would be for you to formalize the different parts of a tree: > > * node; Holder for the value, structure pointers, and tree coloring > information > > * cursor; pointer to a node with tree specific operations to move the > cursor within the tree and to interrogate the tree > > * iterator; linear traversal of the nodes in the tree > > * tree; the container of nodes and producer of cursors and iterators, > and the needed allocators I think these formalizations of different parts of the tree is a very good start, but I'd like to see the iterator eliminated for a while, or at least totally decoupled from the tree: The reason for this is Separation of Concerns. A tree class is a container quite similar like the standard containers in that it stores values, but the big difference is that the structure of the tree matters, instead of the sequence. Therefore, I think the tree class should provide functions to navigate through the tree, and functions to alter the structure of a tree, like insertion, deletion, and rotation. These functions should probably work on things like the above-defined cursor. Once this tree class is built, then it is time to start thinking how the structure of the tree should be translated to flat sequences. There are of course a lot of options: depth first, breadth first, only a single level, or from top to a single node. Navigating in this way is done via 'normal' iterators. These iterators work on cursors, and should not be a part of the tree class itself (the iterator type should not be a member of the tree class). These iterators are like 'cursor-to-iterator adaptors'. So I guess my point is this: The tree doesn't need a normal or default or any iterator type, because it doesn't have a proper meaning: a tree is about structure, not about sequence. Translating that structure into a sequence can be done outside the tree. best regards, Richard Peters _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[typeof] template template parameters, etc.
by Arkadiy Vertleyb 24 Feb '05

24 Feb '05

Hi all, The typeof submission has been updated to include the latest features, most notably support for *template template parameters*. Please take it in the in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/ (typeof.zip). (Most credit for the template template parameters support goes to Peder). Among other additions are support for enum template parameters, and reused template parameters, such as in: template<class T, T n> class x; Also the REGISTER_TEMPLATE_X macro has been eliminated. Instead, the REGISTER_TEMPLATE macro has been "overloaded" to cover all the cases of template registration. Please see the documentation for more details. Regards, Arkadiy

3 2

RE: [boost] Re: ANN: review of FSM library starts
by Simon Gittins 24 Feb '05

24 Feb '05

Hi Andreas [snip guard discussion] > > The equivalent with a custom reaction would look as follows: > > struct StState : fsm::simple_state< StState, StOuter, > fsm::custom_reaction< EvEvent > > > { > fsm::result react( const EvEvent & evt ) > { > if ( cond ) > return transit< StRes0 >( &StRes0ActCtxt::Action0, evt ); > else > return transit< StRes1 >( &StRes1ActCtxt::Action1, evt ); > } > }; > > For a human, IMHO this is easier to read. Easier, but less consistent. In complicated fsms (many transitions, lots of state local data and functions), I find it extremely useful to separate the 'state' (as it would appear on a state chart) from the 'other stuff' (local variables, local functions - anything looking like 'normal' c++). Given that guards tend to be fairly common in real world fsms, we should be able to spot them in the same way we spot normal transitions. > > > I haven't thought about the implementation too much admittedly. > > Having > > this would be a big help in automatically generating UML state charts. > > Agreed. It is much easier to implement a tool that only needs to look at > the state declarations than one that additionally also needs to analyze > code inside functions. For this reason I think I will eventually add a > construct similar to the one you suggested. But, since such a tool does > not yet exist (to my knowledge), this is of fairly low priority at the > moment. > OK. My argument is largely philosophical. > > The library produces large binaries. > > The produced binaries certainly will never be small. Out of curiosity, > do you have any numbers (number of states -> size of executable)? > I just ran a few tests. The original camera example compiles to 103k using -O3 and -DNDEBUG (and the other options specified in the Makefile in the distribution). When stripped, the size came down to 56k. I added a new nonsense state in Shooting.hpp: struct Shooting2 : fsm::simple_state<Shooting2,Camera, fsm::transition<EvShutterRelease,NotShooting> > {}; I also changed Shooting's EvShutterRelease to transition to the new Shooting2 state. The compile size increased to 111k, and the stripped size increased to 61k. In my application (as described below), I added a state with 9 transitions that was empty otherwise. When compiled with -g and stripped (our current 'release mode'), the size of the executable increases by around 30k. I didn't spend too much time on these tests, and I ran them with a version of boost::fsm that is a few months old (my apologies). > > It does however, appear to scale > > reasonably well (anecdotally, it seems about linear with the number of > > states). The in memory footprint is of the same order of magnitude as > > the binary size. > > I guess that is for the hundreds of machine objects you mention below? Yes. The in memory size is not important for this application (we have far more RAM than persistent storage). Regards Simon Gittins ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1

value_initialized docs problem
by David Abrahams 24 Feb '05

24 Feb '05

The docs use "impll-defined" where they should say "unspecified." -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[any] checked convertion to reference?
by Vladimir Prus 24 Feb '05

24 Feb '05

Currently, boost::any supports two kinds of conversion: 1. Unchecked conversion to pointer (NULL is returned if conversion is impossible) 2. Checked conversion to value type (exception is thrown if conversion is impossible) I'd like to have another variant -- checked conversion to reference. The following code does not compile: boost::any a = 1; int& i = boost::any_cast<int&>(a); There are two issues: 1. Documentation says: If passed a value or reference, it returns a copy of the value content if successful. But even if I change the above to boost::any a = 1; int i = boost::any_cast<int&>(a); it does not compile. Docs are at least inaccurate. 2. Can we make the above work? I attach a patch which implements casting to reference, and passes all the existing test. I'd like this behaviour because currently program_options contains code such as: template<class T> T& variable_value::as() { T* r = boost::any_cast<T>(&v); if (!r) throw boost::bad_any_cast(); return *r; } which is plain ugly. With the patch, the above can be written as template<class T> T& variable_value::as() { return boost::any_cast<T&>(v); } - Volodya

5 13

Re: [boost] Proposal: Library to manage processes
by Julio M. Merino Vidal 24 Feb '05

24 Feb '05

I'm not replying to any particular reply to my original message because I want to address them all at once. First of all, I have started to write a little document listing all the requirements for the library. I'm focusing on my initial ideas and on all the interesting comments you've made. Then I need to learn more about Boost.Thread (mainly to see if its design could be appropriate to the process management library) and Boost.Iostreams (which should be used to ease handling input and output). Also it'll be worth to look at all the existing libraries you've mentioned. In fact, what I had in mind is quite simpler than what some people would like to see in the lib. But after reading your comments, I realize that it'd be worth to add the features you request. WRT my existing code... well, better forget about it (somebody asked for it, or at least some documentation regarding its interface). It is not worth using (I was going to refactor it anyway). Better to start the design from scratch, get it powerful and correct, and then implement it (which should be the easiest part). I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...) Anyway, thanks for all your great comments! -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

6 9

Incorrect usage of test macros in octionion, quaternion, special_functions, regex, fusion.
by Martin Wille 24 Feb '05

24 Feb '05

Hello, several test macros are used with the wrong number of arguments by several tests: octonion_test: BOOST_REQUIRE_PREDICATE, BOOST_CHECK_PREDICATE quaternion_test: BOOST_REQUIRE_PREDICATE, BOOST_CHECK_PREDICATE sinc_test: BOOST_CHECK_PREDICATE unicode_iterator_test: BOOST_CHECK_EQUAL_COLLECTIONS Fusion still uses BOOST_TEST (which doesn't exist anymore). Regards, m

5 9

Re: Boost library inclusion: generic tree containers?
by Jeff Mirwaisi 24 Feb '05

24 Feb '05

Since the interest level in a generic tree library seems to be high, below is a link to an incomplete tree library/type constructor framework I have been tinkering with. It, perhaps foolishly, tries to present the building blocks for the construction of a large set of different tree types with different balancing and book-keeping requirements. Keep in mind it is not complete, some of the balancing schemes need to be checked, it has no workarounds for broken compilers and for the most part only basic/range insert have been implemented (erase is just a placeholder) http://24.221.194.82:8080/src/trees/index.html There are a number of meta programming techniques used in the library, including execute_if which i brought up in a separate thread, the techniques link via the above link describes a few of them (template parameter mapping, execute_if etc). http://24.221.194.82:8080/src/tc/index.html The above is a start at defining some of the terms and concepts used in type constructors/builders/computers, once meaningful terms are agreed upon the tree documentation will change to use the new terms. Stroustrup on a generic binary tree library: Matt Austern, Bjarne Stroustrup, Mikkel Thorup, and John Wilkinson: Untangling the Balancing and Searching of Balanced Binary Search Trees. Software - Practice & Experience. Vol 33, Issue13. October 2003 (google only has a link to the example code in this paper) Stroustrup on binary tree iterators: http://portal.acm.org/citation.cfm?id=268114 Feedback is appreciated, -Jeff Mirwaisi

3 2

[lambda] throw_action is sometimes declared as a struct and sometimes as a class
by Yariv Tal 24 Feb '05

24 Feb '05

This is not serious, but does cause warnings on my VC7.1 (I could suppress them but I like staying tidy so I want to be warned when I am not consistent with the struct/class usage)

2 2

RE: [boost] ANN: review of FSM library starts
by Simon Gittins 24 Feb '05

24 Feb '05

I think the library should be accepted in boost. Comments below. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] > On Behalf Of Pavel Vozenilek > Sent: Monday, February 21, 2005 11:31 AM > To: boost(a)lists.boost.org > Subject: [boost] ANN: review of FSM library starts [snip] > > * What is your evaluation of the documentation? > How easy (or hard) it is to understand library > features? What can be improved? > The tutorial is good. The few times I've needed the reference, it has been sufficient. > > * What is your evaluation of the design? > What features are supported better by > alternative FSMs? What could be added > (or removed) from the library? > Three appealing features of boost::fsm for me are: - No code generation - Hierarchical. - State local data ('state is an object'). In my application (5 state machines, each with 8 - 40 states), I was able to use the fsm to manage the lifetime of objects local to the state (and any inner states). To me, it seems natural that states have the option of 'owning' information. Managing the lifetime and access rights of some 50+ variables used by a state machine would be unpleasant. I think that custom_reactions that act like guards should be discouraged, as they effectively hide part of the state chart in the implementation. When I read a particular fsm, I want to be able to clearly see all possible transitions and actions without having to search through any decision logic code to fill in the gaps. We should be able to specify guards as part of the state definition. Something like this: struct StState: fsm::simple_state<StState,StOuter, mpl::list < fsm::guard2<EvEvent, fsm::switch<StRes0,StRes0ActCtxt,&StRes0ActCtxt::Action0>, fsm::switch<StRes1,StRes1ActCtxt,&StRes1ActCtxt::Action1> > > >; I guess this might make the cpp code look like this: fsm::guard2::result StState::guard2(const EvEvent& ev) { if(cond) return fsm::guard2::result<0>(); else return fsm::guard2::result<1>(); } I haven't thought about the implementation too much admittedly. Having this would be a big help in automatically generating UML state charts. > > * The library documentation contains > few not yet solved issues (name, > separating the library into two parts, > exception handling). What is you opinion here? > I have no opinion on the possibility of splitting the library in two. I've avoided using the exception handling feature of boost::fsm, but the description in the documentation looks fairly sensible. > > * What is your evaluation of the implementation? > Are there parts of code too obscure or > duplicating exiting Boost functionality? > Can something be factored out to standalone > library or among general utilities? > Implementation appears concise. No real concerns here. I was able to add a new type of reaction (in_state_transition - trivial though it is) with no problems. > > * Are there performance bottlenecks? > Does the library design fit requirements > of real-time systems? How is it useable > for embedded systems? > Is the documentation clear on performance > tradeoffs? > The library produces large binaries. It does however, appear to scale reasonably well (anecdotally, it seems about linear with the number of states). The in memory footprint is of the same order of magnitude as the binary size. My application is fairly soft real time, and runs on an embedded 486-like system, with a few hundred individual state machines and a few hundred events delivered per second. In this case, the performance of boost::fsm is acceptable, and does not threaten any timing constraints of the system. > > * What is your evaluation of the potential > usefulness of the library? Can you compare > this FSM to other implementations? > The library has already been useful, and I see myself using the library again. I believe that boost::fsm is a good solution for many non trivial compile time fsms. > > * Did you try to use the library? With what > compiler? Did you have any problems? > Do you have tips for better support of older > compilers? What are possible portability problems? > I've been using an older version of the library with gcc-3.2.3 > > * How much effort did you put into your > evaluation? > A glance? A quick reading? In-depth study? > I've spent quite a few hours developing using boost::fsm, and about half an hour catching up the on the latest documentation. > * Are you knowledgeable about the problem domain? > Not overly. I've built state machines with switch(), and have had to build a flat dynamic fsm framework (and use it) in the past. > > And finally, every reviewer should answer this question: > > > * Do you think the library should be accepted as a > Boost library? Be sure to say this explicitly so that > your other comments don't obscure your overall opinion. > Yes Simon Gittins ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 3

type_info/typeid
by Jody Hagins 23 Feb '05

23 Feb '05

As noted eariler, I have been working on moving the type_info/typeid stuff into a more common place. I have been using the implementation in boost/python/type_id.hpp as a reference, because that code seems to have addressed many issues related to different compilers. However, some of the workaround code prohibits standard confirming calls, so I wanted to get some input here. I am conflicted as to giving a summary or providing full details. I will probably end up doing a bit of both... The biggest problem is that on some older compilers, calls to the typeid() operator incorrectly leave outer reference and cv-qualifiers when returning type_info. Some interesting code exists to workaround this problem, resulting in a type_id() function. I have expanded this functionality to get most of 5.2.8 working. However, there are several pieces of 5.2.8 that are not possible (at least to me), using a fix like this. I have tried using macros, and some other tricks, but can not get full conformance to 5.2.8. So, maybe I can get a little help. The "bad" compilers are currently recognized by this incantation. #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) \ || (defined(BOOST_INTEL_CXX_VERSION) \ && BOOST_INTEL_CXX_VERSION <= 700) What versions of MSVC/Intel does this include? Is support for them still necessary? If so, is it reasonable to leave in a type_id function that does not conform to 5.2.8, letting the buyer beware? Also, it is remotely possible that implemeting 5.2.8 fully is possible with a workaround, but I have been unsuccessful using gcc. I basically "force" the workaround to be used by adding defined(__GNUC__) so I can test the workaround code. The closest I can come is defining a macro... #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) \ || (defined(BOOST_INTEL_CXX_VERSION) \ && BOOST_INTEL_CXX_VERSION <= 700) # define BOOST_TYPEID(x) \ // Some funky stuff #else # define BOOST_TYPEID(x) typeid(x) #endif but still under the "bad" compilers, some code does not compile, and other code causes tests to fail. This leaves users with some leeway. If you do not care about compiler bug workarounds, use typeid(). If you do care, use the BOOST_TYPEID() macro. However, if you are using a "bad" compiler, some things will either not compile, or will give the wrong behavior. FWIW, the current workaround only supports static types, and does not support lvalue at all. I have added this, but it has some problems. FWIW, the most difficult parts of 5.2.8 to get right with the workaround are: 5.2.8.2: I am having problems stripping the qualifiers and still leaving the most derived information 5.2.8.2: once the expression is evaluated, unless call directly to typeid(), a segv happens instead of std::bad_typeid exception being thrown. 5.2.8.3: The expression is not supposed to be evaluated (the expression is only allowed to be evaluated if the expression results in a polymorphic type or a pointer to a polymorphic type is dereferenced -- see 5.2.8.2). I would gladly appreciate any questions/comments.

1 0

Yet another typo fix
by Julio M. Merino Vidal 23 Feb '05

23 Feb '05

Hi again, you can find attached another typo fix; this time it's a change from neccessary to necessary. I first noticed this in a documentation file (from Boost.Build v2), but then decided to cleanup the whole source tree. It's gzipped to keep it small. Can anybody please apply this one (and possibly the other patches attached to my last two emails)? Thanks a lot, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 3

Re: Compile-time conditional function invocation
by Jeff Mirwaisi 23 Feb '05

23 Feb '05

documentation, but just for completeness. Given a type trait TT which you want to select upon. Given a template function TF which you would like to call only for types that TT selects from within template function G. We need a type which will delegate to TF, that doesn't bind the template parameter types and is a first class type (a holder) template <typename T> void TF(T) {} struct TF_holder { typedef void result_type; template <typename T> result_type invoke(T t) {return TF(t);} }; template <typename U> void G(U u) { execute_if< TT::invoke< TF_holder >(u); } G is the generic template function for all types, TF is the conditionally targeted template function for types for which TT is true. Hope that helps. Jeff Mirwaisi

1 0

format lib patch
by François Dumont 23 Feb '05

23 Feb '05

Here is a small typo fix for the BOOST_NO_LOCALE_ISDIGIT macro that is sometimes spell with an additional I (ISIDIGIT). It is even spell correctly only once!

2 1

Boost TSS crash under Win32
by Schalk_Cronje＠McAfee.com 23 Feb '05

23 Feb '05

We have encountered a Boost TSS crash when used under the following circumstances with VC6: * Main program dynamically loads DLLs via LoadLibrary. * The main program does not use TSS at all. * TSS is used by the components as class variables. * Main program explicitly unloads DLLs before exiting * Data in TSS is reset long before the unload occurs. The issue seems to be related to the fact that the final cleanup handler kicks in after the DLLs have already unloaded. I hope I have not missed something from the archives related to such an issue. The following diff show the changes made to fix this problem: --- boost/libs/thread/src/tss.cpp 2005-01-07 13:01:27.000000000 +0000 +++ tss.cpp 2005-02-23 12:11:38.000000000 +0000 @@ -52,10 +52,14 @@ tss_slots* slots = static_cast<tss_slots*>(p); for (tss_slots::size_type i = 0; i < slots->size(); ++i) { - boost::mutex::scoped_lock lock(tss_data->mutex); - (*tss_data->cleanup_handlers[i])((*slots)[i]); - (*slots)[i] = 0; + if ((*slots)[i]) + { + boost::mutex::scoped_lock lock(tss_data->mutex); + (*tss_data->cleanup_handlers[i])((*slots)[i]); + (*slots)[i] = 0; + } } + // delete slots; // Should we be deleting the slot data as well, when the thread exits? } void init_tss_data() The above diff also contains one line that is currently commented. Should we delete the tss_slots instance for the specific thread?

1 0

format lib patch
by François Dumont 23 Feb '05

23 Feb '05

Config: STLport 5.0 beta and MSVC 8 (but also reported with 7.1) It looks like this compiler has a problem with the relation between the basic_string::size_type and basic_format::size_type as soon as the library is not the native one. Here is a patch proposition that return a basic_string::size_type rather than the basic_format::size_type. I think it is quite a secure patch as the method is already using a static_cast<typename string_type::size_type> to return its result and not a simple static_cast<size_type>. Bests

2 1

[Determine interest] Deterministic/nondeterminisatic multitape Turing machine
by Alex Vinokur 23 Feb '05

23 Feb '05

Is there any interest in a library which simulates a deterministic/nondeterminisatic multitape Turing machine? Current version C++ Simulator of a Turing Machine can be downloaded at : * http://sourceforge.net/projects/turing-machine/ * http://alexvn.freeservers.com/s1/turing.html The program simulates Deterministic and Nondeterministic Multitape Turing Machine (TM). Detailed log file is generated. Resources used (input size, output size, TM-space, TM-time) are computed as well. A simulated Turing machine is defined by the set of setup files and data : * description file (optional), * number of tapes, * state file, * alphabet file, * transition file, * file(s) of input word(s). Set of simulated Turing machines is defined by a metafile. Each row of the metafile contains data related to some Turing machine. The following demo Turing machines are demonstrated with using the C++ Simulator : 1. An addition program : Deterministic, 1 tape 2. An addition program with marker : Deterministic, 1 tape 3. An addition program : Deterministic, 2 tapes 4. A multiplication program : Deterministic, 1 tape 5. An Euclid algorithm : Deterministic, 1 tape 6. Recognition of palindromes : Deterministic, 2 tapes 7. Partition problem : Nondeterministic, 3 tapes 8. Conversion unary-to-binary : Deterministic, 1 tape 9. Computing Fibonacci numbers : Deterministic, 1 tape 10. Computing Huffman codes : Deterministic, 3 tapes Log file fragments are shown below ----------------------- --- File metafile ----------------------- add.dsc 1 add.sta add.abt add.rul add1.in add2.in add3.in add4.in add5.in add6.in add7.in addm.dsc 1 addm.sta add.abt addm.rul add1.in add2.in add3.in add4.in addt.dsc 2 addt.sta addt.abt addt.rul addt1.in addt2.in mult.dsc 1 mult.sta mult.abt mult.rul mult1.in mult2.in mult3.in euclid.dsc 1 euclid.sta euclid.abt euclid.rul euclid1.in euclid2.in euclid3.in euclid4.in euclid5.in palindr.dsc 2 palindr.sta palindr.abt palindr.rul palindr1.in palindr2.in palindr3.in part.dsc 3 part.sta part.abt part.rul part1.in part2.in part3.in un2bin.dsc 1 un2bin.sta un2bin.abt un2bin.rul un2bin1.in un2bin2.in un2bin3.in fib.dsc 1 fib.sta fib.abt fib.rul fib1.in fib2.in fib3.in fib5.in fib7.in huffman.dsc 3 huffman.sta huffman.abt huffman.rul equ.in fib.in arb.in ----------------------- ========== Data selected from Metafile metafile ========== ---------- Nondeterministic Turing Machine# 1 ---------- Description file name : add.dsc Number of tapes : 1 States file name : add.sta Alphabet file name : add.abt Transitions file name : add.rul Input words files names : add1.in add2.in add3.in add4.in add5.in add6.in add7.in %%=========================================== %%=== Nondeterministic Turing Machine# 1 ==== %%======= Machine Definition : BEGIN ======== %%=========================================== ###### Nondeterministic Turing Machine Definition ###### ###### This Machine is actually Deterministic!!! ###### ====== Description ====== An addition program. The program adds two numbers. A number 'n' is represented by n 1-s. Sample : 5 is represented as 1 1 1 1 1 3 is represented as 1 1 1 Input : Two numbers separated by symbol '*' Sample : 1 1 1 1 1 * 1 1 1 Output : Resulting number without '*' Sample : 1 1 1 1 1 1 1 1 ====== States Definition ====== Initial states : q0 Halting states : qf Internal states : q1 q2 ====== Alphabet Definition ====== ------ Tape# 0 ------ Empty symbols alphabet : b Input alphabet : 1 * Internal alphabet : x ====== Transition Rules Definition ====== Rule# 0 : q0 [ * ] ---> q1 [ (1, N) ] Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] Rule# 2 : q0 [ b ] ---> q0 [ (b, R) ] Rule# 3 : q1 [ 1 ] ---> q1 [ (1, R) ] Rule# 4 : q1 [ b ] ---> q2 [ (b, L) ] Rule# 5 : q2 [ 1 ] ---> qf [ (b, L) ] %%=========================================== %%======= Machine Definition : END ======== %%=== Nondeterministic Turing Machine# 1 ==== %%=========================================== %%=========================================== %%=== Nondeterministic Turing Machine# 1 ==== %%========= Processing Input Words ========= %%============= Set# 1 : BEGIN ============== %%=========================================== ##### < Run 1.1 > Input word(s) & head start position(s) on tape(s) ##### Tape#0 : Word = 1 1 1 1 1 * 1 1 1 ; Head pos = 0 ##### < Run 1.1 > Processing ##### ----- < Run 1.1 > Initial Configuration ----- State : q0 Tape#0 : [1] 1 1 1 1 * 1 1 1 < Run 1.1 > Applied Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] ----- < Run 1.1 > Configuration#1 ----- State : q0 Tape#0 : 1 [1] 1 1 1 * 1 1 1 < Run 1.1 > Applied Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] ----- < Run 1.1 > Configuration#2 ----- State : q0 Tape#0 : 1 1 [1] 1 1 * 1 1 1 < Run 1.1 > Applied Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] ----- < Run 1.1 > Configuration#3 ----- State : q0 Tape#0 : 1 1 1 [1] 1 * 1 1 1 < Run 1.1 > Applied Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] ----- < Run 1.1 > Configuration#4 ----- State : q0 Tape#0 : 1 1 1 1 [1] * 1 1 1 < Run 1.1 > Applied Rule# 1 : q0 [ 1 ] ---> q0 [ (1, R) ] ----- < Run 1.1 > Configuration#5 ----- State : q0 Tape#0 : 1 1 1 1 1 [*] 1 1 1 < Run 1.1 > Applied Rule# 0 : q0 [ * ] ---> q1 [ (1, N) ] ----- < Run 1.1 > Configuration#6 ----- State : q1 Tape#0 : 1 1 1 1 1 [1] 1 1 1 < Run 1.1 > Applied Rule# 3 : q1 [ 1 ] ---> q1 [ (1, R) ] ----- < Run 1.1 > Configuration#7 ----- State : q1 Tape#0 : 1 1 1 1 1 1 [1] 1 1 < Run 1.1 > Applied Rule# 3 : q1 [ 1 ] ---> q1 [ (1, R) ] ----- < Run 1.1 > Configuration#8 ----- State : q1 Tape#0 : 1 1 1 1 1 1 1 [1] 1 < Run 1.1 > Applied Rule# 3 : q1 [ 1 ] ---> q1 [ (1, R) ] ----- < Run 1.1 > Configuration#9 ----- State : q1 Tape#0 : 1 1 1 1 1 1 1 1 [1] < Run 1.1 > Applied Rule# 3 : q1 [ 1 ] ---> q1 [ (1, R) ] ----- < Run 1.1 > Configuration#10 ----- State : q1 Tape#0 : 1 1 1 1 1 1 1 1 1 [b] < Run 1.1 > Applied Rule# 4 : q1 [ b ] ---> q2 [ (b, L) ] ----- < Run 1.1 > Configuration#11 ----- State : q2 Tape#0 : 1 1 1 1 1 1 1 1 [1] < Run 1.1 > Applied Rule# 5 : q2 [ 1 ] ---> qf [ (b, L) ] ----- < Run 1.1 > Configuration#12 ----- State : qf Tape#0 : 1 1 1 1 1 1 1 [1] < Run 1.1 > Success : Current state (qf) is halting one ------------------------------------------------------------- --- < DTM #1, Input #1 > Result : Input word(s) ACCEPTED --- ------------------------------------------------------------- < DTM #1, Input #1 > Resource Report ------------------------------------- < DTM #1, Input #1 > * Input size : 9 symbols < DTM #1, Input #1 > * Output size : 8 symbols < DTM #1, Input #1 > * TM-Space used : 10 cells < DTM #1, Input #1 > * TM-Time used : 12 transitions |==================| |--- Statistics ---| |... Transition ...| |------------------| | Rules : Times | |------------------| | 0 : 1 | | 1 : 5 | | 2 : 0 | | 3 : 4 | | 4 : 1 | | 5 : 1 | |------------------| | Total : 12 | |==================| %%=========================================== %%============= Set# 1 : END ============== %%========= Processing Input Words ========= %%=== Nondeterministic Turing Machine# 1 ==== %%=========================================== -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn

3 3

RE: [boost] [iterators] request for utility iterator
by Eyal Farago 23 Feb '05

23 Feb '05

you can easily achieve this using (make_)transform_iterator and boost bind: make_transform_iterator( map.begin(), boost::bind( &MAP_TYPE::value_type::first, _1 ) ) (give or take a typename before MAP_TYPE::...) I think it's so simple that you don't really need a utility class for it. I'm also quite sure that boost bind takes better care of const/mutable return type and any other bad things that you may stumble across when trying to implement this functor youself (same goes for boost.lambda). eyal. -----Original Message----- From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] Sent: Monday, February 14, 2005 4:19 AM To: boost(a)lists.boost.org Subject: [boost] [iterators] request for utility iterator Hi all, I often want to iterate over just the values of a map or perhaps just the keys of a map. Therefore I would like to see the following iterator adapters in the iterator library: template< class Map > struct map_key_iterator; template< class Map > struct map_value_iterator; template< class Map > struct map_const_value_iterator; I have outlined an implementation in the attached file, but basically it just a wrapper around transform_iterator<typename Map::iterator>. Comments? br Thorsten

4 8

typeid wrapper
by Felipe Magno de Almeida 22 Feb '05

22 Feb '05

Ive searched in boost a typeid wrapper like the one Andrei Alexandrescu uses in his book (Modern C++ Design), but didnt found any, except one in the python library. It seemed very much what Im searching, so I'm wondering why it is in the python library. I think it is a very useful feature outside python library either. So Im asking if it shouldnt be a general class in the boost library, instead of being a feature to be used by the python library only? Thanks in advance, -- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida@ic unicamp br, felipe.m.almeida@gmail com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com

7 7

Proposal: Library to manage processes
by Julio M. Merino Vidal 22 Feb '05

22 Feb '05

Hi everyone, a while ago, I started to write a little utility that aims to interact with multiple VCS systems. I chose C++ (and I don't regret that decision at all), so I had to create multiple classes to interact with system internals and keep the "real" application code clean from such OS-specific calls. A few days ago, I decided to switch to use Boost in that project, basically because I was interested in the Filesystem library. Doing so, I have been able to remove some of my custom classes that dealt with files and directories (and which were quite ugly). Furthermore, this change has allowed me to use many other Boost goodies. Among the classes I wrote, there are some that provide an abstraction layer to launch other (child) processes. Once the process is launched, the code can access its standard input/output/error streams by using the standard iostreams framework. I'm willing to reorganize (well, mostly rewrite from scratch) such process-management classes to follow the Boost policies, aiming for future integration in Boost. But, before I start to do so, I would like to know if such library will be adequate to be integrated and/or if there is interest in it. FWIW, I've searched the mailing lists and found some people that said that they missed this functionality in Boost. Any comments? Thanks in advance, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

12 20

Dynamic Exception Handlers [repost]
by David Abrahams 22 Feb '05

22 Feb '05

Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python? http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162 Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 7

Preprocessor question
by Arkadiy Vertleyb 22 Feb '05

22 Feb '05

Hi, Suppose I have the following macro: #define DO(x)\ BOOST_PP_CAT(STEP3, BOOST_PP_CAT(STEP2, BOOST_PP_EXPAND(STEP1 x))) #define STEP2STEP1 Now, DO(5) should IMO expand into STEP35. For some reason, VC71 expands it into STEP3 5. Where does the space come from? Can one CAT two tokens, and get a space between them? Is it a bug in VC71 or is it supposed to be like this? If I use BOOST_PP_SEQ_CAT outside, it does what I expect. Can anybody explain why? (the above exersize may not make sence out of context. I don't think the context is relevant, although I can provide it if necessary) Thanks in advance. Regards, Arkadiy

2 6

Priority Queue in boost::graph::dijkstra_shortest_paths
by Lloyd J Lewins 21 Feb '05

21 Feb '05

Perhaps I am missing something, but I don't see how dijkstra_shortest_paths works currently. The priority queue (mutable_queue) in dijkstra_shortest_paths should order (gray) vertices by their distance from the source vertex. The ordering of the mutable_queue is achieved by the compare function, which therefore should order vertices by examining the distance map. However, the default compare function is simply std::less<D>(), where D is the value_type of the distance map. I.e., the compare simply orders the vertices by their vertex_descriptor, using less for the value_type (essentially a cast). I would think what is really needed is a less function which is bound to the distance map, and compares based off distance. For example: template<class Map> class less : public std::binary_function<typename boost::property_traits<Map>::value_type, typename boost::property_traits<Map>::value_type, bool> { typedef typename boost::property_traits<Map>::key_type key_type; typedef typename boost::property_traits<Map>::value_type value_type; public: explicit less(Map& m) : m(m) { } bool operator() (const key_type k1, const key_type k2) const { return m[k1] < m[k2]; } private: const Map& m; }; In which case the compare function would be somethink like: less<DistanceMap>(distance). Lloyd J. Lewins Fellow, Raytheon Co., llewins(a)raytheon.com +1 (310) 647-8832

2 1

Apple GCC conditional in boost.python ??
by Marshall Clow 21 Feb '05

21 Feb '05

In boost/libs/python/src/converter/registry.cpp, I found: >#if defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__) \ > && __GNUC__ == 3 && __GNUC_MINOR__ <= 4 && !defined(__APPLE_CC__) ># define BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND >#endif I have no idea what defining that big long symbol does, but I think that the conditionals are incorrect. <http://developer.apple.com/technotes/tn2002/tn2071.html> says: __APPLE__ This macro is defined in any Apple computer. __MACH__ This macro is defined if Mach system calls are supported. __APPLE_CC__ This macro is set to an integer that represents the version number of the compiler. This lets you distinguish, for example, between compilers based on the same version of GCC, but with different bug fixes or features. Larger values denote later compilers. I can't see any case where __APPLE__ and __GNUC__ are defined, and __APPLE_CC__ is not defined. Metrowerks? ==> No __GNUC__ Not on a Mac? ==> No __APPLE__ __APPLE_CC__ was defined for Apple-released versions of GCC, starting with 2.95.2 (so says Chris Espinosa at Apple). More historical info is at <http://developer.apple.com/releasenotes/DeveloperTools/GCC2.html> So, I think that that whole #if expression always evaluates to "false". -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

[boost::signals] connect/disconnect management suggestion
by kolach56＠yandex.ru 21 Feb '05

21 Feb '05

I used boost::signals in number of projects and found one thing inconvenient. I could easily connect anything to signal but sometimes it became hard to disconnect form it. It's ok if a connection time is bounded by a lifetime of trackable or connection objects. I used to use Group id for disconnection, but sometimes I needed it for call priority. ( In that case I would write a special GroupCompare function but it looked ugly. ) For experimental purposes, I constructed an alternative approach. For connection/disconnection management I used the following syntax: struct Test { void test( bool, int ); }; void f( bool ); signal<void (bool)> s; s.connect( &Test::test, t, _1, 5 ); s.disconnect( &Test::test, t, _1, 5 ); s.connect( &f, _1 ); s.disconnect( &f, _1 ); I just form a hash code from the arguments. It certainly makes the process longer, but in most cases I don't need something extremely fast there. In my projects, the performance is important in invocation process. It's only a variant, there might be a lot of other ways. So actually my suggestion is why not to have both approaches of connection/disconnection management? One for fast connection/disconnection and the other for extra control over it. -- Best regards, Nick mailto:kolach56@yandex.ru

1 0

Review managers needed
by Tom Brinkman 21 Feb '05

21 Feb '05

The following libraries are scheduled to be reviewed in the coming weeks. Finite State Machine (FSM) Andreas Huber Review Manager - Pavel Vozenilek Policy Pointer David Held Fixed Strings Reece Dunn FOREACH Macro Eric Niebler typeof Arkadiy Vertleyb,Peder Holt If you are familiar with one of the these libraries and would like to volunteer to be the review manager, please contact me at reportbase(a)yahoo.com. Tom Brinkman Review Wizard __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

3 2

[Boost-bugs] [ boost-Bugs-1145183 ] Can't build on cygwin
by SourceForge.net 21 Feb '05

21 Feb '05

Bugs item #1145183, was opened at 2005-02-20 21:32 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=1145183&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build on cygwin Initial Comment: boost 1.32.0 from cvs while i'm trying to compile it under cygwin with: bjam -sTOOLS=gcc install i have an error: unknown target type for <@boost!libs!test! build>libboost_prg_exec_monitor. Anybody can help me? Thank you, diabolo(a)gcnet.ru ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1145183&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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

wave gcc "bits/c++config.h" invalid name
by Larry Evans 21 Feb '05

21 Feb '05

Getting: cd ~/prog_dev/boost-release/boost_1_32_0/lje/libs/fields_visitor/test/ wave -S/usr/include/c++/3.3 test_link.cpp #line 42 "/usr/include/c++/3.3/iostream" #pragma GCC system_header /usr/include/c++/3.3/iostream(42): exception caught: boost::filesystem::path: invalid name "c++config.h" in path: "bits/c++config.h" Should the criteria for valid name be changed?

4 10

Two more typos
by Julio M. Merino Vidal 20 Feb '05

20 Feb '05

Hi again, another fix for two more typos is attached. Cheers, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

1 0

Re: [boost] Re: [multi_index][hash][rfc] Hashed indices preview+Boost.Hash
by JOAQUIN LOPEZ MU?Z 20 Feb '05

20 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Domingo, Febrero 20, 2005 7:53 pm Asunto: [boost] Re: [multi_index][hash][rfc] Hashed indices preview +Boost.Hash > JOAQUIN LOPEZ MU?Z wrote: > > The implementation I adopted (2 pointers per node + 2 pointers > > per bucket) has O(1) iteration, insert() and erase(), whatever > > the load conditions (provided the hash function behaves, of > > course.) I agree with you bidirectional iteration is of little > > value, and my main motivation was to achieve O(1). So, I'll be > > happy to go for a lighter implementation if these issues > > can be solved in another way --or if there's consensum that > > costly iteration under low load conditions is acceptable. > > FWIW, if you can find a spare bit in a pointer, I've thought of a > non-portable way to get something closer to O(1) without the extra > memory load. The nodes are stored in a singly-linked list which > includes > the buckets, so the last node in a bucket points to the next > bucket. The > spare bit is used to indicate if a pointer is pointing to a node > or a > bucket. So the data structure is something like: > [...] Hi Daniel, We can get rid of the spare bit if only iterators store a pointer to the container: then we can test whether a pointer points to a true element or a bucket just by checking if it is in the range [buckets.begin(),buckets.end()). Still constant, though admittedly slower than the bit thing. Main problem with this is, as you point out, that traces of empty buckets will be left when erasing. Still, it seems somewhat better than the classic implementation, at least wrt to theoretical complexity (in practice it'd probably be significantly slower.) Joaquín M López Muñoz Telefónica, Investigación y Desarrpññp

2 1

is_convertible patch for HP/aCC
by Toon Knapen 20 Feb '05

20 Feb '05

The latest incarnation of the HP compiler (version 6.0) looks to be a hugh improvement in respect to earlier versions. I'm looking into porting boost to HP aCC and I suggest to apply following (minor) patch (see attach). OK to commit this? toon cvs diff: Diffing . Index: is_convertible.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_convertible.hpp,v retrieving revision 1.28 diff -u -r1.28 is_convertible.hpp --- is_convertible.hpp 4 Sep 2004 10:34:48 -0000 1.28 +++ is_convertible.hpp 14 Feb 2005 13:09:41 -0000 @@ -125,7 +125,7 @@ }; #elif (defined(__EDG_VERSION__) && (__EDG_VERSION__ >= 245) && !defined(__ICL)) \ - || defined(__IBMCPP__) + || defined(__IBMCPP__) || defined(__HP_aCC) // // This is *almost* an ideal world implementation as it doesn't rely // on undefined behaviour by passing UDT's through (...). cvs diff: Diffing detail

3 4

profiling library and documentation update
by christopher diggins 20 Feb '05

20 Feb '05

I have now uploaded the new documentation for the library at: http://www.ootl.org/profiler/ I am no longer including the high-res timer as part of the library. I have moved the timer to http://www.ootl.org/ootl/misc/high_resolution_timer.hpp.htm for those that want, but I hope the library will be evaluated independantly of the design. I have tried to take into account as many suggestions and comments as possible, but it is hard to track their relevancy/urgency as the design has evolved. I would appreciate it if anyone has suggestions or concerns which they feel are still relevant, to please bring them up again. I am particularly interested in knowing how useful the library is in its current incarnation, and how far it is from something that could be seriously considered for Boost inclusion. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 1

Problem with multi_array and serialization
by Matthias Troyer 20 Feb '05

20 Feb '05

Hi, Trying to combine boost multi_array and serialization I found a very strange compiler bug (?) on MacOS X, using eother the Apple version of gcc-3.1. The following simple code will not compile: #include <boost/multi_array.hpp> namespace strange_namespace { class access { }; } int main() { boost::multi_array<int,2> x(boost::extents[3][3]); int y=x[0][0]; } It fails with the error message src/boost/boost/multi_array/multi_array_ref.hpp: In member function `typename boost::const_multi_array_ref<T, NumDims, T*>::reference boost::multi_array_ref<T, NumDims>::operator[](typename boost::const_multi_array_ref<T, NumDims, T*>::index) [with T = int, long unsigned int NumDims = 2]': test.C:11: instantiated from here src/boost/boost/multi_array/multi_array_ref.hpp:512: no matching function for call to `boost::const_multi_array_ref<int, 2, int*>::access( boost::type<boost::detail::multi_array::sub_array<int, 1> >, index&, int*, const size_type*, const index*, const index*)' src/boost/boost/multi_array/subarray.hpp: In member function `typename boost::detail::multi_array::const_sub_array<T, NumDims, T*>::reference boost::detail::multi_array::sub_array<T, NumDims>::operator[](typename boost::detail::multi_array::const_sub_array<T, NumDims, T*>::index) [with T = int, long unsigned int NumDims = 1]': test.C:11: instantiated from here src/boost/boost/multi_array/subarray.hpp:261: no matching function for call to `boost::detail::multi_array::const_sub_array<int, 1, int*>::access( boost::type<int&>, index&, int*&, const size_type*, const index*, const index*)' This looks like a compiler bug, since the code compiles when removing the class definition access in a completely unrelated namespace. Has something similar been observed before? Does anybody know a workaround? Matthias

1 0

Re: [boost][multi_index][hash][rfc] Hashed indices preview +Boost.Hash
by JOAQUIN LOPEZ MU?Z 20 Feb '05

20 Feb '05

Hi Howard, I'm glad you jumped into this discussion! ----- Mensaje original ----- De: Howard Hinnant <hinnant(a)twcny.rr.com> Fecha: Domingo, Febrero 20, 2005 5:31 pm Asunto: Re: [boost] [multi_index][hash][rfc] Hashed indices preview +Boost.Hash > On Feb 20, 2005, at 10:21 AM, JOAQUIN LOPEZ MU?Z wrote: > > >>> 1.4. Usual implementations use one pointer per bucket, whereas > >>> Boost.MultiIndex has two pointers per bucket. This addresses > >> potential> performance problems of insert() and erase() under low > >> load conditions, > >>> as discussed in > >>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf > >>> issue 6.14. Is this convenient? > >> > >> Well it's not unreasonable, you need what you need. > > > > BTW, have you read the committee's resolution to this > > issue? It doesn't make any sense to me (Bill Wade's concern, > > OTOH, seems very rasonable.) > > Imho the committee's resolution is quite logical. > > The hash containers exist for one reason: As an optimized > solution, in > both memory consumption and speed, compared to the tree-based > containers. The speed department especially concerns lookup, > insert > and erase (in that order), but not iteration (there are other > containers which optimize iteration, vector being the extreme > example). > The coder who carefully tunes his hash function and loading will > be > rewarded with significant optimization. The coder who doesn't, > may be > presented with a solution that performs worse than the tree-based > containers, and is better off sticking with the O(Log N) solution. > > Imho, the committee should do absolutely nothing to penalize the > coder > who has carefully tuned his hash function and loading, either in > memory > consumption nor speed. Of course if hash container writers would > like > to add safeguards which may also add such overhead, I see little > rationale for the committee to object to that either. > > Doubling the per element storage overhead for a perfect > distribution > with a loading of 1 is a serious hit in the memory consumption > department, and may well lead to a performance hit due to more L2 > cache > misses. Adding bidirectional iteration, again at the cost of > doubling > the per element overhead in a well tuned application makes little > sense > to me. The container is unordered. When you iterate in the > forward > direction, you access the elements in a generally unpredictable, > unordered order. What motivation is there (motivation high enough > to > double per element overhead), to iterate in the reverse of the > generally unpredictable, unordered order? > > Again, I have no wish for the committee to outlaw such hash > containers. > But I strongly feel that neither should they outlaw the more > traditional hash container design which favors uncompromising > performance when everything is tuned just right. > What strikes about the resolution is that it doesn't seem to address Bill Wade's concern: in a minimum overhead "classic" hash table implementation (one pointer per element + one pointer per bucket), iteration is not going to be amortized constant under low load conditions. This is in very strong disagreement with that the std requires about forward iterators. I think this cannot be just swept under the rug: if the committee is going to accept it, at least it should be noted somewhere. The implementation I adopted (2 pointers per node + 2 pointers per bucket) has O(1) iteration, insert() and erase(), whatever the load conditions (provided the hash function behaves, of course.) I agree with you bidirectional iteration is of little value, and my main motivation was to achieve O(1). So, I'll be happy to go for a lighter implementation if these issues can be solved in another way --or if there's consensum that costly iteration under low load conditions is acceptable. PS. The worst of all implementations seems to be Dinkum's, where iteration is O(1) but insertion will degrade to O(bucket_count()^2) when a previous rehashing is issued, as Wade points out. It also puzzled me that the comittee NADed the issue without at least a comment on this. Looking fwd to your comments, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] [multi_index][hash][rfc] Hashed indices preview +Boost.Hash
by JOAQUIN LOPEZ MU?Z 20 Feb '05

20 Feb '05

Hi John, thanks for your comments! ----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Sábado, Febrero 19, 2005 6:02 pm Asunto: Re: [boost] [multi_index][hash][rfc] Hashed indices preview +Boost.Hash [...] > > > 1.4. Usual implementations use one pointer per bucket, whereas > > Boost.MultiIndex has two pointers per bucket. This addresses > potential> performance problems of insert() and erase() under low > load conditions, > > as discussed in > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf > > issue 6.14. Is this convenient? > > Well it's not unreasonable, you need what you need. BTW, have you read the committee's resolution to this issue? It doesn't make any sense to me (Bill Wade's concern, OTOH, seems very rasonable.) > > > 6. Yet, this hasn't undergone any formal review, so some of you > might> (with reason) object to its being commited to the CVS. From > our point > > of view, we have three valid alternatives: > > * Boost members agree to have it in CVS without more ado. > > * As this is used by Boost.MultiIndex, Boost.Hash is suitable for > > fasttrack review. > > * This is untolerable and the library should be push_back()'ed to > > the review queue. Meanwhile, Boost.Hash should live as an impl > > detail of Boost.MultiIndex. > > I don't see how you can place it in a detail namespace if users > are going to > be expected to (possibly) provide their own specialisations of the > hash > function object. > > I've no objection to either a fast track review, or just adding to > cvs, I think Daniel is going to ask for a fasttrack review, and Thorsten volunteered to manage it. In the meantime, I'll commit my update and Boost.Hash code only, and wait for the outcome of Daniel's review --it'll be his responsabiity to upload docs, test, etc. if the lib is accepted. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

BOOST_NO_RTTI?
by Douglas Gregor 20 Feb '05

20 Feb '05

We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS. http://lists.boost.org/MailArchives/boost-users/msg09240.php I'll plan to add it unless there is violent disagreement. Doug

6 10

Two more patches
by Julio M. Merino Vidal 20 Feb '05

20 Feb '05

Hi again, I've attached two more patches (mostly nitpicking): - patch.diff fixes a typo in the Jamfile usage message (teh -> the). While solving this, I also splitted several long lines (over 80 cols) on several ones. Looks nicer, IMHO. This patch also fixes the indentation of a message in the python.jam file. I.e., PYTHON_INCLUDES explanation appears incorrectly indented WRT PYTHON_LIB_PATH (lacks some spaces). I also indented the second line of each message two more characters to match the PYTHON_VERSION message that appears at the very beginning (indented farther than the dash). I.e.: PYTHON_LIB_PATH - blahblahblah blahblah rather than: PYTHON_LIB_PATH - blahblahblah blahblah - patch2.diff fixes two typos in the web pages. First of all, in the filesystem's FAQ, a question ends with a dot, while there should be a question mark in there. (Just as in my previous message, I've added a blank line at the end of the file.) Then, in the mailing lists information page, there is a paragraph that does not end with a dot. I've added it and reformatted the affected lines to fit on screen. Hope they are correct and can be applied. Kind regards, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

1 0

Biconnected components patch
by Janusz Piwowarski 20 Feb '05

20 Feb '05

Hello, Because of recursion problem, i rewrote biconnected components algorithm using DFSVisitor. It needs one additional property map only. Patch is attached. Regards, Janusz

2 1

Confused CVS lock?
by Mark Deric 19 Feb '05

19 Feb '05

This may not be the right forum to surface this admin issue, so please redirect me if it's appropriate. I was just updating my boost cvs sandbox: [mark@laguna06 boost_current_cvs]$ cat CVS/Root :pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost [mark@laguna06 boost_current_cvs]$ cvs -z3 -q up -d -P and have gotten cvs update: [18:42:34] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/tmpw2001-paper ... cvs update: [19:24:11] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/tmpw2001-paper I'm not used to a cvs lock blocking for 40 minutes unless it's toasted. Can anyone help? Regards, Mark

2 1

[multi_index][hash][rfc] Hashed indices preview + Boost.Hash
by Joaquín Mª López Muñoz 19 Feb '05

19 Feb '05

Hello all, You can find a preview version of Boost.MultiIndex including hashed indices plus Daniel James' Boost.Hash library at the Sandbox Files area: multi_index_140205_plus_hash_part_1.zip multi_index_140205_plus_hash_part_2.zip (split in two for maximum size reasons.) There are a number of things we'd like to ask you feedback about: 1. Hashed indices are modeled according to the latest TR1 draft, with some significant diversions: 1.1. erase() does not throw ever, even it the user-provided Hash object throws. This is imposed by the general framework of Boost.MultiIndex. This goodie does not come for free: if the Hash object throws, erase() decays to a linear search. Not that there's any alternative, but I'd like to point it out. 1.2. insert() has strong exception safety (TR1 only requires basic.) Again, the way Boost.MultiIndex is designed forces this. 1.3. hash indices iterators are bidirectional. 1.4. Usual implementations use one pointer per bucket, whereas Boost.MultiIndex has two pointers per bucket. This addresses potential performance problems of insert() and erase() under low load conditions, as discussed in http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf issue 6.14. Is this convenient? 2. The material is complete except for a section in the tutorial and possibly one more example (example 8 already exercises hashed indices.) Tests fully sport hashed indices. The reference is also updated. 3. All in all, I'd greatly appreciate your comments on this: suitability, documentation, performance, etc. I plan to commit this to the CVS if nobody objects in a reasonable amount of time (a couple of weeks.) I'm open to all kind of suggestions --I'm eager to recieve them, as it happens :) 4. As for Boost.Hash, this library by Daniel James' implements the ideas for std::tr1::hash (albeit in boost namespace) proposed by Peter Dimov in the aforementioned paper, issue 6.18. The idea is to provide a general purpose hash<> utility for use by * Boost.MultiIndex * TR1-based unordered containers (Daniel is working on this.) * Eventually, wrapping by Boost.TR1. 5. The library comes fully documented and tested, and in our view well prepared for uploading to the CVS. 6. Yet, this hasn't undergone any formal review, so some of you might (with reason) object to its being commited to the CVS. From our point of view, we have three valid alternatives: * Boost members agree to have it in CVS without more ado. * As this is used by Boost.MultiIndex, Boost.Hash is suitable for fasttrack review. * This is untolerable and the library should be push_back()'ed to the review queue. Meanwhile, Boost.Hash should live as an impl detail of Boost.MultiIndex. We hope you find the material useful and look forward to knowing your opinions about the issues brought forward. Best, Joaquín M López Muñoz Daniel James

2 1

Profiling Library suggestion
by christopher diggins 19 Feb '05

19 Feb '05

I was searching around boost for mention of a profiling library. A fellow by the name of Carl Daniels posted something about an invasive profiling library. I was wondering in anyone knows what happened to that project? Profiling seems lacking at Boost, is anyone else interested in such a thing? Would a trivial policy driven RAII type be sufficient to garner interest as a mini-library? e.g. struct ProfilerDefaultPolicy { OnElapsed(int msec) { cout << "time elapsed (msec): " << msec << endl; } }; template<typename Policy_T = ProfilerDefaultPolicy> class Profiler { public: Profiler() { mnStart = GetTickCount(); }; ~Profiler() { Policy_T::OnElapsed(GetMSecElapsed()); }; int GetMSecElapsed() { return GetTickCount() - mnStart; }; int GetTickCount() { return int(double(clock()) * 1000 / CLOCKS_PER_SEC); }; private: int mnStart; }; usage: void MyRoutine() { Profiler<> p; // do stuff } Pretty trivial (and probably not boost-worthy), but I find it very useful. Does anyone want to take this and run with it (i.e. boostify it)? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

14 67

Broken links to CVS information
by Julio M. Merino Vidal 19 Feb '05

19 Feb '05

Hi! first of all, I should say hi to everybody, since I'm new to the list. I hope this is the correct mailing list to send a patch against the website (according to the page about bug reporting, it should be). During the last past few days, I've been reading about Boost at the website because I'm interested in using it in one of my projects. I must say that the website is great. It has lots of information and is well organized. Anyway, while doing so, I've came across some broken links to the CVS access information. (As well as some typos, but I have to re-find them...) They point to the obsolete (according to the logs) download.html file, while they should be pointing to getting_started.html. I've attached a patch which corrects this. BTW, vim warned me saying that the files I changed in the patch do not have a newline at the end. It added one automatically, but I've removed that chunk from the patch. Is this behavior expected? IMHO, the newline should be there (otherwise, cat <file> looks ugly). Kind regards, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

3 3

New Logging Library
by John Eddy 19 Feb '05

19 Feb '05

I have continued working on a logging library as a possible contender for a new Boost library. I have made sweeping changes inspired by comments and requests from a number of people (all very helpful). Here are some of the properties of the library as it is now. All components are completely independent of one another and highly parameterized for flexibility. The primary components are: -Entries which can be anything at all (built-in or user-defined types). There are a number of custom entries that I have created that support for example ostream like formatting. -Logs which actually go about the job of storing/processing/whatevering entries. I have created a few logs for writing to files, ostreams, storing entries in a list, etc. -Log managers are intermediaries between users and logs. They can do whatever they wish prior to passing entries on to logs. I have implemented a few managers so far. 1 that does virtually nothing. 1 that discriminates based on logging levels (only entries of appropriate levels get logged) and one that discriminates on levels and supplies a callback mechanism for whatever levels desired. Many managers can be attached to the same log. -Level Policies are classes supplied to level log managers indicating what the different allowable levels are. The documentation is still in very rough shape but the code in its current state is available for simple download from www.eng.buffalo.edu/~johneddy. It is not well Boost-ified yet but the directory structure is in place and some example files are available. Everything is implemented in header files at this point so no library need be built. John

5 12

Constructor-proxy: Template parameter deduction, a question for template masters
by ION_G_M 19 Feb '05

19 Feb '05

Hello to all, while developing Boost Shmem, I wanted to create a constructor proxy to emulate c++ dynamic object allocation syntax when creating shared memory objects using a proxy object in the following way: T * ptr = shmem_segment.create<T>("ObjectName")[size] /*proxy returned here, calls operator() of the object*/ (arg1, arg2, ...argN); Shared memory is allocated and the object is constructed. I want the arguments to be deduced automatically in the proxy object function call to preserve this syntax. I also want to avoid _all_ parameter copying. I mean, if I can deduce that an argument can be passed by value or by referenced using this syntax, great. But, between copying _all_ arguments and passing a reference in _all_, I prefer the second. Trying to find a correct proxy for this, I had many problems when passing temporary arguments and hardcoded constants to the proxy. Right now I am using some ugly casts to avoid the copies, but this has some side-effects. I will explain the problem in the following code: #include <new> //Object to be constructed struct Ctor2Arg { Ctor2Arg(const int &const_ref, int &non_const_ref){} }; //"Clean" proxy template <class T> struct constructor_proxy_t { template<class T0, class T1> void operator()(T0 & t0, T1 & t1) const { char m_mem[sizeof(T)]; //Call constructor and destructor T *ptr = new(m_mem)T(t0, t1); ptr->~T(); } }; //Ugly cast proxy template <class T> struct ugly_constructor_proxy_t { template<class T0, class T1> void operator()(const T0 & t0, const T1 & t1) const { char m_mem[sizeof(T)]; //Convert all refs to non-const refs T0 & t0ref = const_cast<T0 &>(t0); T1 & t1ref = const_cast<T1 &>(t1); //Call constructor and destructor, non-const //refs can be converted to const refs T *ptr = new(m_mem)T(t0ref, t1ref); ptr->~T(); } }; //Main function int main() { //Construct normal and ugly proxies constructor_proxy_t<Ctor2Arg> proxy; ugly_constructor_proxy_t<Ctor2Arg> ugly_proxy; //One const int and one non-const int const int dummy_const = 0; int dummy_non_const = 0; //This is ok, calls: //constructor_proxy_t<Ctor2Arg>::operator() //<int const ,int>(const int & t0=0, int & t1=0) proxy(dummy_const, dummy_non_const); //Both of these calls do not compile in VC7.1 or gcc 3.4.3, //tries to call constructor_proxy_t<Ctor2Arg>::operator() //<int, int>(int & t0=5, int & t1=0) // // gcc 3.4.3 error // //error: no match for call to // `(constructor_proxy_t<Ctor2Arg>) (int, int&)' //candidates are: // void constructor_proxy_t<T>::operator()(T0&, T1&) // [with T0 = int, T1= int, T = Ctor2Arg] // //Obviously, compilers are right, but //it wouldn't be more logical to call //<int const, int> specialization since a //temporary is a constant object? // proxy(dummy_non_const+5, dummy_non_const); // proxy(dummy_const+5, dummy_non_const); //This is ok, calls: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=0, const int & t1=0) ugly_proxy(dummy_const, dummy_non_const); //These are ok, call: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=5, const int & t1=0) ugly_proxy(dummy_non_const+5, dummy_non_const); ugly_proxy(dummy_const+5, dummy_non_const); //This compiles but it should not, since //I am passing a const object as second parameter //so Ctor2Arg obj(dummy_const, dummy_const) //does not compile. This calls: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=0, const int & t1=0) ugly_proxy(dummy_const, dummy_const); return 0; } My question is, has anyone a better way to write the proxy object without ugly casts, no side-effects (I mean, the proxy call should compile only if the constructor compiles), preserving a clean calling syntax, and _no_ object copies at all? And the second question is: when a temporary is passed to a template, why non-const argument is deduced in the function call? Thank you, regards, /Ion

3 2

singleton report (lifetimes)
by Jason Hise 19 Feb '05

19 Feb '05

Just thought I would release a progress report on the singleton. I have added a new lifetime policy called static_lifetime, which derives from the longevity lifetime and just hides the longevity part from client code, setting it to zero. The result: singletons using the static_lifetime policy are guaranteed to be destroyed in reverse order of creation, if they are created. I am thinking that this should be the default lifetime for the singleton, however I am open to suggestions. Here is a brief summary of each lifetime in the library. If there are any ideas for other lifetimes I would love to hear them. dependency_lifetime - Uses pointers to the singleton as reference counted dependencies. The singleton, if created, is destroyed upon the destruction of the last pointer. A static or global pointer must exist to ensure that the singleton doesn't get destroyed and recreated as the program executes. Singletons can own dependencies to other singletons to ensure proper order of creation and destruction. If a circular reference exists, the singletons owning pointers to each other will never be destroyed. This was my former choice for the default policy. longevity_lifetime - Upon first creation of a singleton using this policy, the singleton instance is registered with a hidden singleton, the longevity_registry. The longevity_registry has a static pointer to itself in its constructor, ensuring it lives at least until main exits. Upon destruction, it destroys the registered singletons in order. Singletons with lower longevities are destroyed first, and singletons with the same longevity are destroyed in reverse order of creation. static_lifetime - Deriving from the longevity_lifetime, this just hides the longevity template parameter and uses zero. As a result, singletons using this policy are destroyed in reverse order of creation, and are destroyed before any longevity based singletons using a longevity greater than one. As the longevity is an unsigned int, this means most of them. This is my current choice for a default. leaky_lifetime - This never destroys the singleton instance. Because of the extensive framework that it provides in terms of member functions and classes, all of the other lifetimes derive from it. This way the other lifetimes can add the specialized destruction behavior without duplicating all the little details, like creation behavior and member functions of the pointer class. The leaky lifetime is used internally by a hidden singleton used in the multiton implementation. This singleton stores multiton instance holders in a map (ideally this should be an assoc_vector if one is ever added to boost). It can never be destroyed because the singletons it stores instance holders to could potentially be destroyed later, or even be recreated by other singletons in the process of being destroyed. Fortunately the map only needs to be destroyed if it needs to free the memory, and this memory which will be automatically cleaned up by the OS anyway. I would like to point out that the method of creation is the same regardless of the lifetime used. An enumerated trait of each lifetime controls when automatic creation can occur. This can be set to create the singleton upon creation of a pointer, upon dereferencing a pointer, both, or neither. If this is set to not automatically create the singleton at all, client code can explicitly call a create member function from any singleton pointer. The leaky_lifetime implements all of these details so that the other lifetimes which derive from it do not have to worry about it. Phoenix re-creation ability works automatically for all of these. To achieve a non-phoenix lifetime, a one_time_creator can be specified which uses a real creator the first time, and a creator designed to fail the second time. Numerous failure creators are provided: null_creator - create simply returns null throw_creator - create throws an exception (which can optionally be specified) assert_creator - causes a boost assertion to fail, and then uses some other failure creator (defaults to throw_creator) if execution gets past the assertion The real creators provided include: create_using_new - client code can customize with a boolean trait whether to make it use no throw new create_using_malloc - client code can make this throw or no throw as well create_statically - uses a static aligned_storage buffer to hold the instance, cannot be used with a multiton create_using_std_allocator - allocates memory with a standard allocator (which can be customized) The one_time_creator can be chained to use a different creator for the first, second, and third creations, ad infinitum. It makes sure to destroy each instance with the internal creator used to create it. I am diligently working on the html documentation, which is going to be quite extensive. It seems like the more documentation I write, the more ideas I get for improving the library. When I get the documentation into a coherent state I will upload it. However, I have made so many changes now that I think an outside perspective would be a good thing before I start setting class and function names in stone. Thus, an up to date stable version has been uploaded to the sandbox. What would be really helpful is if someone could try to write a test program in a multi threaded context. My background in threading is very shaky, and I want to be sure that I am using the locking policy the right way. Is anyone willing to give this a try? -Jason

1 0

[Reminder] Mailing list and lists.boost.org outage Saturday
by Douglas Gregor 19 Feb '05

19 Feb '05

This is a reminder that the Boost mailing lists and lists.boost.org will go down at 12:00pm Saturday Eastern Standard Time. We expect that all will be running again by 8pm at the absolute latest. Doug

1 0

assert
by Jason Hise 19 Feb '05

19 Feb '05

My version of assert.hpp has the line: #include <assert.h> Shouldn't this be: #include <cassert> ? -Jason

6 6

[bug]: optional<T> fails on self-assignment
by Joe Gottman 18 Feb '05

18 Feb '05

I just discovered that optional<T> is not safe under self-assignment. Consider the following code fragment: boost::optional<long> x(1); //At this point x is initialized and *x == 1 x = x; //x should be unchanged, but instead x is now uninitialized Optional's assignment operator looks like optional& operator= ( optional const& rhs ) { this->assign( rhs ) ; return *this ; } and assign is defined by void assign ( argument_type val ) { destroy(); construct(val); } Thus, if (this == &rhs) in operator=(), any value held by rhs will be destroyed. I can see two possible fixes for this. the first is to put an "if (this != &rhs) " around the call to assign in operator=(). This is simplest, but it slows the code down in order to protect against a very rare situation. The other is to rewrite assign as follows: void assign(argument_type val) { if (m_initialized) { get() = val; // call assignment operator } else { construct(val); //call copy constructor } return *this; } This makes optional self-assignment safe. It has the added advantage that is T's assignment operator has the strong exception safety guarantee, so does optional<T>'s assignment operator. It has the disadvantage of making optional depend on both assignment operator and copy constructor to copy, but very few classes have a copy constructor but don't have an assignment operator. Joe Gottman

7 31

New profiling library update
by christopher diggins 18 Feb '05

18 Feb '05

I have updated the profiling library and written a few tests. I still need to rewrite the documentation. the latest version is at http://www.ootl.org/profiler/toc.htm . Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

Compile-time conditional function invocation
by Jeff Mirwaisi 18 Feb '05

18 Feb '05

Below I have outlined my need and implementation for a compile-time conditional function invocation utility. I thought it might be generally useful to others using simmilar metaprogramming techniques. If suitable solutions can be found for some of the outstanding issues perhaps it will prove suitable for inclusion in boost. The following quick documentation and a snapshot of the implementation can be found at http://dump.qxxy.com/execute_if/ and (intermitantly) http://66.1.253.185:8080/src/execute_if/index.html Any feedback would be appreciated. Thanks Jeff Mirwaisi Introduction The following is a simple compile-time conditional function invocation and binding utility type. Generic code often needs to handle a subset, of all the types, in a slightly different way than the rest. template <typename T> void f(T t) { t.a(); t.b(); ... if ( has_member_function_c<T>::value ) t.c(); } This solution obviously will not work if type T has no member function c. The compiler expects all the types used with the template function f to have a member function c even though its clear the conditional expression is either true or false at compile time. One possible workaround for this situation is to use SFINAE and enable_if to overload template function f for types which have a member function c and those that do not. template <typename T> void f(T t, typename enable_if<has_member_function_c<>,T>::type* SFINAE = 0) { t.a(); t.b(); ... t.c(); } template <typename T> void f(T t, typename enable_if<not<has_member_function_c<T> >,T>::type* SFINAE = 0) { t.a(); t.b(); ... } This solution works! Unfortunately it forces us to repeat the majority of the implementation of the two template function overloads f, and it does not scale. If we add a second conditional invocation, the number of overloads jump to four, the same is true of conditional callers, e.g. a second group of two template functions overloads g if theres a single conditional invocation, four if there are two conditional calls etc. To combat this overload explosion we could isolate the conditional call to member function c with a helper type. template <bool> struct call_member_function_c { static inline void invoke(T& t) {t.c();} }; template <> struct call_member_function_c<false> { static inline void invoke(T& t) {} }; template <typename T> void f(T t) { t.a(); t.b(); call_member_function_c< has_member_function_c<T> >::invoke(t); }; This solution improves on the previous one, it scales well as we add conditional member function invocations (call_member_function_d,call_member_function_e,...) and as we increase the number of callers(f,g,h,...). But it has introduced an explicit no-op function for each call_member_function_X helper type, and a partial specialization for each helper type to select whether to generate a call or a no-op. This "helper" type can be formalized and we can provide a generic no-op implementing replacement for all "helpers" which reduces our problem to the simplest solution allowed by C++. Target Holders Unfortunately the limitations of the current language wont allow us to create a generic "helper" type which can be loaded with different template function targets. Instead the user is expected to provide a minimal holder type which delegates to the target template function. Note that the following example is also a late template argument binding function object. This allows the user to either invoke the conditionally executed target immediately or produce a function object which can be stored and called at a later point. template <typename T> void template_fn_target(T) {} struct template_fn_target_holder { typedef void result_type; template <typename Arg> inline result_type operator()(Arg arg) {return template_fn_target(arg);} template <typename Arg> static inline result_type invoke(Arg arg) {return template_fn_target(arg);} }; The target holder type provides the result type of the operation to the user, the function object usage expects a function call overload that can handle the arguments specified, if the call is to be made instantly than we can simplify the use by calling a static member function of the target holder type named invoke. execute_if template <typename Condition > struct execute_if { template< typename TargetHolder > static inline typename TargetHolder::result_type invoke( arg1,...,argN ); template< typename TargetHolder > static inline TargetHolder bind(); }; When the condition value is true the subsequent invoke or bind operation are performed on the target type, if the value is false a no-op invoke or bind are generated. execute_if_c template < bool > struct execute_if_c { template< typename TargetHolder > static inline typename TargetHolder::result_type invoke( arg1,...,argN ); template< typename TargetHolder > static inline TargetHolder bind(); }; The execute_if_c variation on the above execute_if type provides a less generic version of enable_if which uses a boolean value as the condition upon which to select either the specified target or a no-op. execute_if_else template <typename Condition > struct execute_if_else { template< typename TargetHolderA,typename TargetHolderB > static inline typename TargetHolder?::result_type invoke( arg1,...,argN ); template< typename TargetHolderA,typename TargetHolderB > static inline TargetHolder? bind(); }; When the condition value is true the subsequent invoke or bind operation are performed on target holder A, if the value is false target holder B will be used execute_if_else_c template < bool > struct execute_if_else_c { template< typename TargetHolderA,typename TargetHolderB > static inline typename TargetHolder? ::result_type invoke( arg1,...,argN ); template< typename TargetHolderA,typename TargetHolderB > static inline TargetHolder? bind(); }; The execute_if_else_c variation on the above execute_if_else type provides a less generic version of enable_if which uses a boolean value as the condition upon which to select either target holder A or target holder B. To-Do * Currently manually written nullary,unary,and binary execute_if and proxy functions, needs to be rewritten to use the boost preprocessor lib * Possible move of the return type template parameter into the execute_ifxxx template parameter list (out of the bind and invoke template functions) * Investigate using the preprocessor to automatically generate the template function holder types, and other techniques to reduce the users responsibility * Document the lack of a means of representing a template function in the c++ type system, no function equivalent of template template classes * The current code also implements a set of invoke_fn and bind_fn overloads which operate on function references and function object references, we must determine wether these should be provided at all, and if so they should probably be documented

2 1

gui library
by Matthew Johnson 18 Feb '05

18 Feb '05

I spent some time reading the archives regarding the gui project that was started towards the end of last year. Is that project still underway? What is the best way of keeping up with the status of it? Thanks, Matthew

3 2

New article on BOOST_FOREACH
by Eric Niebler 18 Feb '05

18 Feb '05

For anybody interested in peeking under the hood of BOOST_FOREACH, there is a new article about it at The C++ Source (http://www.artima.com/cppsource/index.jsp) It focuses mainly on the conditional operator and how to use it to write macrco's that do not reevaluate their arguments. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

program options documentation
by Rutger ter Borg 18 Feb '05

18 Feb '05

Hi, I noticed that the documentation of the Boost.Program_options library has a small inconsistency regarding the add_options method. In the tutorial section and in the Options Descriptions Component subsection of the Library Overview, add_options is documented in a form that is probably meant as the correct one: desc.add_options() ("compression", po::value<int>(), "set compression level"); while on the other hand, under Library Overview/Options Description Component/Syntactic information it is written as desc.add_options() ("compression", "compression level", value<string>()); , i.e., the 2nd and 3rd arguments are exemplified in a different (likely wrong) order. Best regards, Rutger

2 1

Wave C++ Review Begins Today - February 7, 2005
by Tom Brinkman 18 Feb '05

18 Feb '05

The Wave C++ preprocessor library review begins today February 7, 2005. The library author is Hartmut Kaiser <hartmutkaiser(a)t-online.de> The review manager is Tom Brinkman <reportbase(a)yahoo.com> Download at http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It is not a monolitic application, it's rather a modular library, which exposes mainly a context object and an iterator interface. The context object helps to configure the actual preprocessing process (as search path's, predefined macros, etc.). The exposed iterators are generated by this context object too. Iterating over the sequence defined by the two iterators will return the preprocessed tokens, which are to be built on the fly from the given input stream. The C++ preprocessor iterator itself is fed by a C++ lexer iterator, which implements an abstract interface. The C++ lexers packaged with the Wave library may be used standalone, too, and are not tied to the C++ preprocessor iterator at all. The flexible interface exposed by the library makes it usable in a variety of applications ranging from simple lexing (tokenising) a C99/C++ input stream to complex preprocessing with fine control over the details of the macro expansion process. For instance it's very simple to inject your own #pragma handling into the preprocessing, allowing to expand it in virtually unlimited ways. The Wave C++ preprocessor library is known to be compilable on VC7.1, Intel7.1 and 8.0, gcc 3.2.x and 3.3.x. Work is currently underway to make it usable with VC6.5 as well. The library contains samples, which show different ways of it's usage. A full blown preprocessing command line oriented driver application is included in the Boost tools section as well. The review candidate version of Wave is accessible here: http://spirit.sourceforge.net/dl_more/wave-1.1.12.zip additionally it is included in the Boost-sandbox CVS. If you're interested in what's new or changed since the last releases, please refer to the enclosed documentation or the changelog file contained inside the archive. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

15 40

A library: out-of-core containers and algorithms
by Roman Dementiev 18 Feb '05

18 Feb '05

Hello, I am developing a library called Stxxl. It is an implementation of STL for external memory (out-of-core) computations, i.e. Stxxl implements containers and algorithms that can process huge volumes of data that only fit on disks. Currently I have implemented vector, stack, and priority_queue. External memory map, list, and queue are coming soon. The containers take only specified (given) fixed amount of main memory, but can contain more elements than can fit into the main memory. The containers are compatible with STL algorithms, an example: #include <stxxl> // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::fill(HugeVector.begin(), HugeVector.end(), 0.0); STL algorithms that rely on Output, Input, Forward and Bidirectional iterators will work I/O efficiently with Stxxl containers. For the RandomAccessIterator algorithms (sortting) I have implemented specialized I/O efficient implementations: // ten billion doubles stxxl::vector<double> HugeVector(10ULL * 1000000000ULL); std::generate(HugeVector.begin(), HugeVector.end(), MyRandom()); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); or another example (sort a file): stxxl::file myfile("../myfile.dat",stxxl::file::RDWR); stxxl::vector<double> HugeVector(&myfile); // sort the vector using only 512 MB of main memory stxxl::sort(HugeVector.begin(), HugeVector.end(), 128*1024*1024); More details about the Stxxl library: http://i10www.ira.uka.de/dementiev/stxxl.shtml Would such a library be interesting for Boost users? Does it fit here? Is it worth to boostify it? I would be very glad to know your opinion. With best regards, Roman

9 22

[inspection]
by Jonathan Turkanis 17 Feb '05

17 Feb '05

Hi, A high percentage of the html documents in the iostreams library are listed by the inspection tool as unlinked. These documents are not really unlinked, however, and I am having trouble figuring out what is triggering the erroneous report. Among the documents listed as unlinked are menu.html and home.html, which are the entry points into the iostreams documentation. Any help would be appreciated. Jonathan

4 7

inherited operators
by Jason Hise 17 Feb '05

17 Feb '05

Sometimes I like to play around with obscure code, just to see what it does. The following really surprised me: #include <iostream> struct A { public: bool operator == ( const A & rhs ) { std::cout << "A\n"; return true; } }; struct B { public: bool operator == ( const B & rhs ) { std::cout << "B\n"; return false; } }; struct C : public A, public B { }; int main ( ) { C c1, c2; if ( c1 == c2 ) std::cout << "Equal\n"; return 0; } Compiled on MSVC 7.1, this outputs: A Equal I would have expected this code not to compile at all, because the == overload seems ambiguous. Is this result standards conforming? If not, what would the standards conforming result be? Does this fall into the realm of undefined behavior? -Jason

3 3

Re: [boost] Re: [indirect container] RFC on naming of libraryandclasses
by JOAQUIN LOPEZ MU?Z 17 Feb '05

17 Feb '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses [...] > | If indirection is not really the unifying theme, perhaps you > should use the > name > | Boost.ManagedContainer, which I think was suggested at some point. > | ('ManagingContainer' might be more correct, but doesn't sound good.) > > Managed container is a good name. To recap, I think these are good > condidates: > Boost. Managed Container > Boost. Managed Pointer Container > Boost. Pointer Container > Boost. Clonable Container > Boost. Clonable Pointer Container > Boost. Cloned Container > > My personal favourite would be Boost.Cloned Container > with class names like this: > > cloned_vector<T> > cloned_map<Key,T> > > When I think about it, I see cloning as the most central concept; > in fact, the > only new policy of the containers is the CloneAllocator. > IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones. As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!) So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds. To sum it up, I vote for "pointer container", "clone container" being my close-second choice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[indirect container] RFC on naming of library and classes
by Thorsten Ottosen 17 Feb '05

17 Feb '05

Dear all, I will soon start to write some more documentation for the indirect container library (formerly called the smart container library). Before I start on that I would like to get a vote on the preferred naming of 1. the library itself 2. library classes Ad 1: library name: -------------------- Boost.Indirect Cotainer was suggested by Joaquin. It sounds reasonable to me. I don't have any alternatives, but suggestions are welcome. Ad 2: library classes: --------------------- The library currently consists of the following major classes in namespace boost: ptr_array ptr_vector ptr_list ptr_deque ptr_set ptr_multiset ptr_map ptr_multimap ptr_sequence_adapter ptr_set_adapter ptr_multiset_adapter ptr_map_adapter ptr_multimap_adapter Should these names persist? Or should we go for something like indirect_array, indirect_vector etc? br -Thorsten

4 18

Re: bald singleton pointers
by Dave Handley 17 Feb '05

17 Feb '05

Jason Hise wrote: > > I would like to get general feedback on a feature that has been > requested. Some background: > > Right now, my singleton pointer classes serve a variety of purposes. In > the first place, they are the access mechanism for a singleton. Any > pointer constructed immediately points to the singleton instance (or > possibly null if the instance hasn't been created yet). If the > singleton uses instant_creation, the first pointer created creates the > singleton instance. When a member is accessed through a singleton > pointer, an intermediate pointer type performs locking, and if > lazy_creation is set it may also create the singleton instance. > Regardless of the lifetime mechanism used, when the singleton instance > gets destroyed all pointers instantly reflect this by becoming null. > > It has been suggested that I provide a mechanism to get a bald pointer > to the instance, such as an unsafe_ptr member function of either the > pointer class or the singleton itself. I feel that such a mechanism > would be very dangerous, because the bald pointer could not perform lazy > creation, it would not lock the operations, and it would not reflect > when the singleton is destroyed. > > Are there instances in which allowing bald pointers to exist is > necessary and/or useful? > The only instance that I can think of where you may want to do this is in a multi-threaded environment. And even then only in a very specific set of circumstances. Specifically, you may want to do this when you don't want the overhead of a lock, but, for some other reason, you can absolutely guarantee that concurrent access to the object (or parts of the object you are accessing) is valid. If I'm honest though, I'm having some difficulty convincing myself that something like this would actually genuinely be useful. Perhaps if you could get a "bald pointer" through a protected member, that was therefore only accessible to derived classes (hence the singletons themselves). This could be useful to build into a static access function that provided a safe pointer, but perhaps without the overhead of a lock? Personally, I would be quite reluctant to provide such a feature... Dave Handley

9 20

GMane Outage
by David Abrahams 17 Feb '05

17 Feb '05

GMane was apparently down for part of this morning, and it looks as though it may have dropped some Boost messages, such as http://lists.boost.org/MailArchives/boost/msg79129.php. If you care what you missed, you might want to go back and re-read. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Entire boost 1.32.0 source-code online
by christopher diggins 17 Feb '05

17 Feb '05

I have pretty-printed the entire source-code for boost 1.32.0 in html (along with my current version Jonathan Turkanis's BIL library) and placed it on the OOTL web site. The table of contents is at http://www.ootl.org/boost/toc.htm . The html formatted version is mirrored with the original source. For instance : http://www.ootl.org/boost/any.hpp.htm is a formatted html version while the raw text version is at http://www.ootl.org/boost/any.hpp . The formatting program used was built using the YARD parser version 2.0 beta ( http://www.ootl.org/yard/ ) which I mentioned previously on this list. The source for the formatter is at http://www.ootl.org/yard/toc.htm . Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org PS. Brian, I am still working on the next profiler release and test suite.

1 0

Dynamic Exception Handlers
by David Abrahams 17 Feb '05

17 Feb '05

Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python? http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162 Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost.Test doc bug.
by Hubert Holin 17 Feb '05

17 Feb '05

Somewhere in the E.U., le 17/02/2005 Bonjour It looks as though the Boost.Test doc has a slight sync issue. The BOOST_CHECK_PREDICATE macro is described (in file boost/libs/test/doc/components/test_tools/reference/index.html) as having to be used thus: 8>< ------------------------------------------- ><8 int test.cpp( int, char* [] ) { int i = 17; BOOST_CHECK_PREDICATE( std::not_equal_to<int>(), 2, (i,17) ); // ^^^^^^^^^^ return 0; } 8>< ------------------------------------------- ><8 whereas Boost.Test's test uses (in file boost/libs/test/test/test_tools_test.cpp) the following form: 8>< ------------------------------------------- ><8 using std::not_equal_to; CHECK_TOOL_USAGE( BOOST_CHECK_PREDICATE( not_equal_to<int>(), (i)(17) ), // ^^^^^^^^^ output.is_equal( CHECK_PATTERN( "error in " TEST_CASE_NAME ": test not_equal_to<int>()( i, 17 ) failed for ( 17, 17 )\n", 2 ) ) 8>< ------------------------------------------- ><8 Of course the later compiles while the former does not. Merci Hubert Holin

2 1

multi_index_container issue
by David Gruener 17 Feb '05

17 Feb '05

Hello, i just started using the boost::multi_index_container and ran into some trouble. I'm using boost version 1.32. Well, i tried a slightly modified version of Example 6 ("complex searches and foreign keys"). This is the code: -------------------------------------------------------------------------- #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/mem_fun.hpp> #include <string> using namespace std; using namespace boost; using namespace boost::multi_index; template<class KeyExtractor1,class KeyExtractor2> struct key_from_key { public: typedef typename KeyExtractor1::result_type result_type; key_from_key( const KeyExtractor1& key1_=KeyExtractor1(), const KeyExtractor2& key2_=KeyExtractor2()): key1(key1_),key2(key2_) {} template<typename Arg> result_type operator()(Arg& arg)const { return key1(key2(arg)); } private: KeyExtractor1 key1; KeyExtractor2 key2; }; struct person { string get_name() const { return "GM"; } // XXX }; struct car_manufacturer : public person // XXX { }; struct car_model { string model; car_manufacturer* manufacturer; int price; }; multi_index_container< car_model, indexed_by< ordered_unique< key_from_key< const_mem_fun<person,std::string,&person::get_name>, member<car_model,car_manufacturer*,&car_model::manufacturer> > > > > mic; -------------------------------------------------------------------------- As one might see, the change i made is that the key get_name() of the car_manufacturer now comes from a base class called person. However, this code wont compile because the compiler argues that there is no '*' operator for car_manufactuerer. I found out that the problem is the handling with the so called chained pointers in the mem_fun structs. template<typename ChainedPtr> Type operator()(const ChainedPtr& x)const // [1] { return operator()(*x); } Type operator()(const Class& x)const // [2] { return (x.*PtrToMemberFunction)(); } In the example the compiler calls [1] for car_manufacturer*, which seems right. After that, it can chose (among other methods) between [1] and [2] (Class = person) with argument type car_manufacturer and choses the better matching [1] with the followed error. However, maybe things could be done better here. The mem_fun structs could be smart enogh to deal with classes derived from template argument Class. That means [2] should be called in the case of operator() with a "Class"-derived argument. I dont know much about metaprogramming, but the following diff for const_mem_fun (as an example) of file mem_fun.hpp seems to work with a compiler supporting full template specialisation at class scope. Unfortunately gcc up to 3.4 doesn't seem to support this, while icc 8.0 does. I'm pretty sure there is a better sollution than mine, assumed that a "problem" even exists, which is my question to you. :] ------------------------------------------------------------------------------- *************** *** 12,17 **** --- 12,18 ---- #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/mpl/if.hpp> #include <boost/type_traits/remove_reference.hpp> + #include <boost/type_traits/is_base_and_derived.hpp> namespace boost{ *************** *** 45,54 **** { typedef typename remove_reference<Type>::type result_type; ! template<typename ChainedPtr> ! Type operator()(const ChainedPtr& x)const { ! return operator()(*x); } Type operator()(const Class& x)const --- 46,58 ---- { typedef typename remove_reference<Type>::type result_type; ! template<typename MaybeChainedPtr> ! Type operator()(const MaybeChainedPtr& x)const { ! return dispatch_cptr< typename mpl::if_< ! is_base_and_derived<Class, MaybeChainedPtr>, ! Class, ! MaybeChainedPtr>::type > (x); } Type operator()(const Class& x)const *************** *** 65,70 **** --- 69,87 ---- { return operator()(x.get()); } + + private: + template<typename MaybeChainedPtr> + Type dispatch_cptr(const MaybeChainedPtr& x)const + { + return operator()(*x); + } + + template<> + Type dispatch_cptr<Class>(const Class& x)const + { + return operator()(x); + } }; ------------------------------------------------------------------------------ Would some type handling like this make sense? If not, whats the best way to use dervied member function of a (pointer)member of the container type as key? If yes, are there similar issues in other extractors like member extractor? --David

2 1

wave works on simple_fun fails in pp_enum_params
by Larry Evans 17 Feb '05

17 Feb '05

I got wave to work on this: <----------------- #define DOUBLE(X) X,X #pragma wave trace(enable) DOUBLE(aaa) #pragma wave trace(disable) >----------------- but it tops out the cpu and finally aborts when BOOST_PP_ENUM_PARAMS is used. Heres the output from make: <----------------- cd /home/evansl/prog_dev/boost-release/boost_1_32_0/wave/wave/tools/wave/build/ make wave cat pp_enum_params.cpp #include <boost/preprocessor/repetition/enum_params.hpp> #pragma wave trace(enable) BOOST_PP_ENUM_PARAMS(3, class T) #pragma wave trace(disable) date Wed Feb 16 19:19:41 MST 2005 wave --traceto pp_enum_params.trace.out --output pp_enum_params.pp.out -S /usr/include/c++/3.3 -S /usr/include/c++/3.3/i486-linux -S /usr/include -S /home/evansl/prog_dev/boost-release/boost_1_32_0 pp_enum_params.cpp make: *** [wave] Killed Compilation exited abnormally with code 2 at Wed Feb 16 19:23:55 >----------------- Has anyone had success on non-trivial cases?

2 1

singleton template template parameters
by Jason Hise 16 Feb '05

16 Feb '05

In my singleton code, I have been using a template template parameter in my lifetimes for the creator[1], so that client code does not need to duplicate writing the type when specifying the creation policy. The drawback to this is that the creators which provide additional policies need to use a nested struct to avoid breaking the template signature that creators are required to have. A perfect example is the bool_creator[2]: template < bool Value > struct bool_creator{ template < typename Type > class creator { // pass Value to Type's ctor in create method }; }; If I wanted to be consistent, I would be tempted to do the same with my lifetime policies, separating the Type template parameter from the rest and having the singleton use a template template parameter for the lifetime. However, I suspect this would just make client code really ugly when it tried to specify the lifetime it wanted to use. In addition, I am willing to bet that a lot of compilers choke on template template parameters. As an alternative, I am thinking of switching the creator policy to a non template template policy. Although this would make client code have to plug the name of their class into the base singleton template yet a third time, I am thinking that in the end it would be more portable and cleaner. Thoughts? -Jason [1] Yes, I made the name change from allocator to creator in my code. The change has not yet been uploaded though, so keep in mind that creators in this message refer to allocators in the current online code, and bool_creator is really bool_alloc at the moment. [2] I'm thinking of dropping bool_creator from the library. Instead of providing it directly, I'll develop it in the documentation as an example custom creator and go on to show how it can be used to implement a zombie singleton. Of course, if you think it should stay in the library let me know, I can be persuaded to keep it.

2 3

problem with boost::variant and borland
by Robert Ramey 16 Feb '05

16 Feb '05

I have a program which consists on one line: #include <boost/variant.hpp> If I try to compile this using the main CVS tree, I get the following with borland 5.51 and 5.64 compilers: Error E2401 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Invalid template argument list Error E2041 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Incorrect use of default Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Declaration terminated incorrectly Error E2394 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too few arguments passed to template 'substitute<T,Dest,Source,Arity>' Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Declaration terminated incorrectly Error E2228 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too many error or warning messages What can be done to fix this? Robert Ramey

2 2

[repost][multi_index][hash][rfc] Hashed indices preview + Boost.Hash
by Joaquín Mª López Muñoz 16 Feb '05

16 Feb '05

Allow me to repost this message from a couple of days ago, since nobody responded :( In another situation, I could proceed according to my own judgement, but point (6), in particular, necessitates a public discussion, IMHO. Thank you, Hello all, You can find a preview version of Boost.MultiIndex including hashed indices plus Daniel James' Boost.Hash library at the Sandbox Files area: multi_index_140205_plus_hash_part_1.zip multi_index_140205_plus_hash_part_2.zip (split in two for maximum size reasons.) There are a number of things we'd like to ask you feedback about: 1. Hashed indices are modeled according to the latest TR1 draft, with some significant diversions: 1.1. erase() does not throw ever, even it the user-provided Hash object throws. This is imposed by the general framework of Boost.MultiIndex. This goodie does not come for free: if the Hash object throws, erase() decays to a linear search. Not that there's any alternative, but I'd like to point it out. 1.2. insert() has strong exception safety (TR1 only requires basic.) Again, the way Boost.MultiIndex is designed forces this. 1.3. hash indices iterators are bidirectional. 1.4. Usual implementations use one pointer per bucket, whereas Boost.MultiIndex has two pointers per bucket. This addresses potential performance problems of insert() and erase() under low load conditions, as discussed in http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf issue 6.14. Is this convenient? 2. The material is complete except for a section in the tutorial and possibly one more example (example 8 already exercises hashed indices.) Tests fully sport hashed indices. The reference is also updated. 3. All in all, I'd greatly appreciate your comments on this: suitability, documentation, performance, etc. I plan to commit this to the CVS if nobody objects in a reasonable amount of time (a couple of weeks.) I'm open to all kind of suggestions --I'm eager to recieve them, as it happens :) 4. As for Boost.Hash, this library by Daniel James' implements the ideas for std::tr1::hash (albeit in boost namespace) proposed by Peter Dimov in the aforementioned paper, issue 6.18. The idea is to provide a general purpose hash<> utility for use by * Boost.MultiIndex * TR1-based unordered containers (Daniel is working on this.) * Eventually, wrapping by Boost.TR1. 5. The library comes fully documented and tested, and in our view well prepared for uploading to the CVS. 6. Yet, this hasn't undergone any formal review, so some of you might (with reason) object to its being commited to the CVS. From our point of view, we have three valid alternatives: * Boost members agree to have it in CVS without more ado. * As this is used by Boost.MultiIndex, Boost.Hash is suitable for fasttrack review. * This is untolerable and the library should be push_back()'ed to the review queue. Meanwhile, Boost.Hash should live as an impl detail of Boost.MultiIndex. We hope you find the material useful and look forward to knowing your opinions about the issues brought forward. Best, Joaquín M López Muñoz Daniel James

4 4

[boost] [Important] Mailing list downtime this Saturday, February 19
by Doug Gregor 16 Feb '05

16 Feb '05

The Open Systems Lab, which hosts most of the Boost mailing lists, will be migrating to new hardware this Saturday. The outage will be this Saturday, February 19 starting at noon Eastern Standard Time and should not last more than 8 hours. lists.boost.org will be unavailable during the outage as will the mailing lists themselves. Thanks, Doug Gregor

1 0

RE: [boost] Re: Re: Profiling Library suggestion
by Brian Braatz 16 Feb '05

16 Feb '05

Christopher, Just wanted to send out a note so you know I have not lost interest in the profile library. I was fairly active in this conversation up until the weekend. My main computer died and had to be reinstalled. I am back running again (and back on mail). I am re-arranging the project I am working on so that I can spend the next 5 days to actually use your library as is to profile a million line application. I will keep you posted as to my progress. (considering the structure of the application, the "hard part" here is going to be adding the library in after the fact). This should be a fairly useful experience. Thank you for staying with this library and responding to all of the suggestions from myself and others. Brian

2 1

void * with boost::python
by Preston A. Elder 16 Feb '05

16 Feb '05

I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg: std::string str("This is a test"); hexdump(str.data(), str.length()); std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t)); I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it). Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class). Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures. Also, on another note, is there somewhere that has all of boost already pythonized? I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 8

Wave review
by Joel de Guzman 16 Feb '05

16 Feb '05

Hi Hartmut, I wanted to try out the examples. I encountered some problems: + Read the quikstart to get me started immediately. "Do not instantiate the main, preprocessing iterators yourself." --> not enough context here. "main" is undefined at this point. + when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good. + Now, I'm able to build the samples using bjam V2. A little hickup: bjam complains: error: Unable to find file or target named error: '/boost/program_options//boost_program_options' error: referred from project at error: 'cpp_tokens/build' Looking at program_options, it seems that the library name is program_options (without the boost_ prefix). + Got this fixed and. Now got into a link error: gcc.link ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.exe ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\release\ cpp_main.o(.text+0x50):cpp_ ain.cpp: multiple definition of `_main' ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.o(.text+0x7eb0):ins ect.cpp: first defined here Any clues? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 12

Const-incorrect constructor inprogram_options::basic_command_line_parser?
by Lars Iversen 16 Feb '05

16 Feb '05

I assume that the constructor for program_options::basic_command_line_parser (and function program_options::parse_command_line) in boost/boost/boost/program_options/parsers.hpp revision 1.11 could accept pointers to const char instead of non-const pointers?! Regards, Lars

3 3

Smart mutex pointer?
by Raz 15 Feb '05

15 Feb '05

Why doesn't Boost have any smart pointers that automatically lock a class when a member is used? The code isn't that hard. #include <iostream> struct Dummy { int a; } class Lock { private: Dummy &_d; public: Lock( Dummy &d ) : _d(d) { std::cout << "Locked." << std::endl; } ~Lock( void ) { std::cout << "Unlocked." << std::endl; } Dummy *operator->( void ) { return &_d; } }; class Ref { private: Dummy &_d; public: Ref( Dummy &d ) : _d(d) { } Lock operator->(void) { return Lock(_d); } }; int main( void ) { Dummy d; Ref x(d); x->a = 1; std::cout << x->a << std::endl; } I get: Locked Unlocked Locked 1 Unlocked on my system (g++ 3.3.3 and g++ 3.4.0). Has there been any reason not to do this? -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 5

overloads-20050207.tar.gz
by Alexander Nasonov 15 Feb '05

15 Feb '05

https://sourceforge.net/project/shownotes.php?release_id=303009 This package has been tested on gcc 3.4 and linux-intel 8.0. Two kinds of overload sets are currently implemented: natural sets and range sets, that is, overloads::set<X> and overloads::set<X, mpl::range_c<int,1,3> > where X is (I call its concept OverloadsHolder, feel free to suggest better name): struct X { void operator()(overloads::id<1>, int, char) const; // void(int,char) bool operator()(overloads::id<2>, long) const; // bool(long) }; mpl::end for natural set is not constant time but fast. The following MPL algorithms work: - has_key - order - find - size - empty - equal

4 33

Re: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts)
by JOAQUIN LOPEZ MU?Z 15 Feb '05

15 Feb '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Martes, Febrero 15, 2005 8:41 pm Asunto: std::map per-node overhead (Was: [boost] Re: shared_ptr doubts) > David Abrahams wrote: > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > >> On Feb 15, 2005, at 9:49 AM, David Abrahams wrote: > >> > >>> You don't need any storage for rebalancing. Typical map nodes > have>>> 3 pointers: parent, left child, and right child. > >> > >> If it is a red-black tree, you need to store the color of each > node.>> This information requires 1 bit, which can easily be > padded to a > >> word. > > > > Oh, I didn't understand that he meant color info. I guess that is > > only for rebalancing, isn't it? > > > > /me crawls back under rock > > > >> If it is a AVL tree, each node needs to store its tilt. This > >> information requires 2 bits. > >> > >> Or is there a new technique I'm about to learn about? :-) > > > > /me burrows several inches down into dirt under rock > > You could have pretended that you had in mind an implementation > where > pointers are always even and one of the least-significant bits is > used as a > color bit. ;-) > > Are there std::maps that store a next and previous pointer to > optimize > traversal at the expense of per-node overhead? > > (Of course my original point was that most people don't care about > the > per-node overhead and those that do just use a different data > structure.) I'm pretty certain no commercial STL implementation exists that does this, precisely because of the overhead. Users might not care, but implementors surely do. Incidentally, a multi_index_container with an ordered index and a sequenced index pretty much mimics the kind of data structure you've got in mind. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo.

1 0

Re: [boost] Re: Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >>>> I wanted to create a very simple AutoPtr that was essentially the >>>> same as the STL auto_ptr (and backwards compatible with it). >>> >>> Unfortunately, you haven't (see below). Furthermore, auto_ptr is >>> widely recognized as unsafe because it is too easy to transfer >>> ownership unintentionally. >> >> Of course you can unintentionally transfer ownership if you don't >> know what you're doing. ;) > > The problem is that the code which transfers ownership appears innocuous on the > surface, because auto_ptr allows transfer of ownership with the same syntax > ordinarily used for copying: > > void f() > { > auto_ptr<int> ptr(new int); > auto_ptr<int> ptr2(ptr); // ptr is now empty. > } Why would anyone in their right mind do that? >> I believe that's why you're not supposed to pass an auto_ptr to a >> function -- instead you pass the pointer itself with .get(). You >> can't stop everyone from shooting themselves in the foot. > > Declaring a function to take an argument of type auto_ptr<...> is one way to > signal that ownership is being transfered to the function. It also ensures that > the managed object will be deleted, unless the function takes explicit steps to > cause a leak. Passing raw pointers defeats this system. Yes, this is true if you're calling a function that you wrote and compiled yourself, but if you're calling a 3rd party API that you didn't compile yourself, that can be dangerous (or so I've been told). >> How? If you pass a pointer to a function, you shouldn't be deleting >> it inside that function anyways (so pass it with .get()), > > What if you want to transfer ownership to the function, as is often the case? Then pass ptr.release() to the function. >> and if you >> return a pointer from a function, you can save it in a new AutoPtr so >> it will get deleted automatically... > > This depends on the calling code to do the right thing. If you return an > auto_ptr, the managed object will be freed even if the calling code choses to > ignore the return value. I agree, if it's your own code, return an auto_ptr, but if you're an API, you must return a raw pointer. >> I don't set my pointer to NULL when I release() it, I just set >> m_Owner = false. > > This behavior is not compatible with std::auto_ptr. I could change it to set the pointer to NULL, but this is what Microsoft's auto_ptr does, and it looked safer. > move_ptr has the same overhead as auto_ptr. Thanks, when I get some time I'll take a look at those. As you might infer from some of my comments, I'm dealing mostly with API component code myself, which integrates some older sub components, so I have no choice but to pass raw pointers most of the time. Chris Just __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Re: Re: Re: Re: Re: Querying the Interest in a new AutoPtr class
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >> I'm not an expert with compilers so I'll tell you how it was >> explained to me. Different compilers could take the same C++ code >> and compile it into different machine code, causing function pointers >> to shift. When you pass an object that was compiled on one machine >> to a function that was compiled on another machine, you can't be sure >> that the object will be deleted properly. > > I guess you're talking about passing objects between modules compiled with > compilers having incompatible ABIs. In general this is a recipe for disaster. If > you restrict yourself to a C language interface you often have more flexibility, > but in that case you can't use smart pointers. > > Is this what you mean? Yes, that's exactly what I mean, and probably explained a little better too. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

find the subexpression that matched
by Lorenzo Bettini 15 Feb '05

15 Feb '05

Hi is there an immediate way to access the sub-expression that matched instead of checking each "what" as in the following? for (unsigned int i = 1; i < what.size(); ++i) { if (what[i].matched) { thanks in advance Lorenzo

4 9

[iostreams] Link errors on msvc-stlport with dynamic runtime
by Jonathan Turkanis 15 Feb '05

15 Feb '05

Hi, Three iostreams tests are failing with the toolset msvc-stlport. All the unresolved symbols are specializations of standard library function templates. In the first case, the template argument is a user-defined type, but in all the other cases the template arguments are built-in types or standard library classes. The middle two look a bit suspicious, since debug and non-debug stuff is mixed together. I don't know anything about what functions STLPort defines in DLLs, so any help would be appreciated. Jonathan ---------------- Unresolved symbols (abbreviated): code_converter_test.cpp 1. __declspec(dllimport) public: __thiscall locale(locale const&, stateless_null_padded_codecvt*) 2. __declspec(dllimport) basic_string<unsigned short>::insert( struct _STL::_DBG_iter<class _STL::_Nondebug_string<unsigned short> >, unsigned short const*, unsigned short const*) newline_filter_test.cpp 3. __declspec(dllimport) basic_string<char>::insert( struct _STL::_DBG_iter<_STL::_Nondebug_string<char> >, char const*, char const*) wide_stream_test.cpp 4. __declspec(dllimport) basic_string<unsigned short>::basic_string( basic_string<unsigned short>::_DBG_iter<class _STL::__vector<unsigned short> >, basic_string<unsigned short>::_DBG_iter<class _STL::__vector<unsigned short> )

3 6

Re: [boost] Re: Re: Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 15 Feb '05

15 Feb '05

Jonathan Turkanis wrote: >>> Declaring a function to take an argument of type auto_ptr<...> is >>> one way to signal that ownership is being transfered to the >>> function. It also ensures that the managed object will be deleted, >>> unless the function takes explicit steps to cause a leak. Passing >>> raw pointers defeats this system. >> >> Yes, this is true if you're calling a function that you wrote and >> compiled yourself, but if you're calling a 3rd party API that you >> didn't compile yourself, that can be dangerous (or so I've been told). > > Dangeous how? Actually the opposite is true: if you declare such a function to > take a raw pointer, I'm not an expert with compilers so I'll tell you how it was explained to me. Different compilers could take the same C++ code and compile it into different machine code, causing function pointers to shift. When you pass an object that was compiled on one machine to a function that was compiled on another machine, you can't be sure that the object will be deleted properly. > callers might think they still own the pointer after calling > the function, or the function might not clean up the resource properly. That's what documentation is for. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

wave use to clarify PP usage
by Larry Evans 14 Feb '05

14 Feb '05

Does anyone have a tool that would clarify what's happening with some PP macros in, for example: boost/spirit/fusion/sequence/tuple.hpp For example, could wave be used to sort-of trace through the macro expansions to make the code easier to understand. For instance, I'm guessing that: BOOST_PP_REPEAT_FROM_TO( 2, FUSION_MAX_TUPLE_SIZE, FUSION_TUPLE_CONSTRUCTOR, _) does for 2 to FUSION_MAX_TUPLE_SIZE what: explicit tuple(typename detail::call_param<T0>::type _0) : base_type(_0) {} Does for a 1 argument CTOR. I could run it through cpp, but if there are several nested macro calls, it probably wouldn't help much in understand what's going on. TIA.

3 2

Re: [iostreams] Link errors on msvc-stlport with dynamic runtime
by François Dumont 14 Feb '05

14 Feb '05

This is a MSVC6 bug. When you export a class from a dll the linker try to find all class methods within the import library and of course fails for the template methods. Latest STLport library, the 5.0 beta you can get from CVS using STLPORT_5_0 branch, has a workaround for the std::locale and std::basic_string classes so your library should build fine with this version. Moreover it would be very usefull if boost was using the STLport 5.0 beta library for its unit tests with some platform/compilers. If you are interesting don't hesitate to contact me for information on STLport new features and modifications. Bests > > Message: 10 > Date: Sun, 13 Feb 2005 23:18:19 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] Re: [iostreams] Link errors on msvc-stlport with > dynamic runtime > To: boost(a)lists.boost.org > Message-ID: <cupj7f$j2b$1(a)sea.gmane.org> > > I have had the exact same problem when building the serialization library > and have found no way around it. I tried definine the template > instantiation in a separate module but it collided with some msvc problem. > > Robert Ramey > > Jonathan Turkanis wrote: > >> >> 1. __declspec(dllimport) public: __thiscall >> locale(locale const&, stateless_null_padded_codecvt*) >>

1 0

Profiling library design change proposal
by christopher diggins 14 Feb '05

14 Feb '05

Preston brought up a good point earlier about the complexity of having the profile_manager being entirely static. What if instead we created profile_manager variables and passed them to the profiler (if desired) something like: profile_manager pm1("profile-group-1", &cerr /* log to cerr */, false /* don't collect stats */, ...); profile_manager pm2("profile-group-2", null /* don't log */, true /* do collect stats */, ...) ; { profiler p("profileA", pm1); ... } { profiler p("profileB", pm1); ... } { profiler p("profileC", pm2); ... } { profiler p("profileD", pm2); ... } pm1.GenerateReport(cout); pm2.GenerateReport(cout); The profiler would still recieve a profiler_manager type as a type parameter: typedef basic_profiler<profile_manager> profiler; And the profile_manager would also still have its type parameters: typedef basic_profile_manager<string, high_resolution_timer, default_stats_policy, default_logging_policy> profile_manager; Any comments or suggestions? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

boost::rtl / rel where can I get some more infos
by Vinzenz Feenstra 14 Feb '05

14 Feb '05

Hi Arkadiy a friend told me about boost::rtl/rel, so I was wondering where I can get some more infos about it, it sounds quite interessting. BR Vinzenz

5 18

serialization - questionable basic_xml_oarchive dtor
by Sergey Skorniakov 14 Feb '05

14 Feb '05

Hello, All! I think that basic_xml_oarchive destructor can be more safe if uncaught_exception examination will be added, because put sometimes can throw exceptions: template<class Archive> basic_xml_oarchive<Archive>::~basic_xml_oarchive(){ if(!header) return; if (!std::uncaught_exception()) this->This()->put("</boost_serialization>\n"); } With best regards, Sergey.

2 2

[shared_ptr] Optimization suggestion
by Don G 14 Feb '05

14 Feb '05

Hi All, For my own work in the thread-safe smart pointer arena, I have used a technique to reduce the number of mutex objects from one per object, yet minimize induced contention. The basic idea is a static pool of mutexes indexed by hashed pointers. Or in pseudo code: mutex & get_object_mutex (const void * p) // see below { const size_t pool_size = 127; static mutex pool[mutex_pool_size]; unsigned long ul = reinterpret_cast<unsigned long>(p); unsigned long hash = ...; // munge ul in some clever way return pool[ hash % pool_size ]; } class foo { public: void bar () { #ifdef BOOST_HAS_THREADS mutex::scoped_lock guard(get_object_mutex(this)); #endif // ... do something ... } }; This is a tad simplified. For example, I used my Singleton template to manage the pool, but the idea is the same. Instead of allocating one mutex per object that might need one, allocate a pool of them and hash the object's pointer so that all references to the same object use the same mutex. Has anyone considered using this technique in shared_count? The extra contention could be controlled by the sizeof the pool, and it would be a big savings where lots of objects are used. It would also be better than the lightweight_mutex used on some platforms (such as Windows) to achieve similar savings. At least that would be so if the mutex used where a CRITICAL_SECTION and not a kernel mutex. Best, Don ===== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

singleton allocators
by Jason Hise 14 Feb '05

14 Feb '05

In my code, I use the term allocator for policies that mirror the Loki singleton creator policies. For example, my dynamic_allocator class maps almost directly to Alexandrescu's CreateUsingNew policy. It has been suggested that allocator is a misleading term, because users will think that such classes were meant to work with the allocator policy used in the standard containers. Is the term allocator really that misleading? Should I make the massive change in my code to refer to these classes as creators? -Jason

2 1

[iterators] request for utility iterator
by Thorsten Ottosen 14 Feb '05

14 Feb '05

Hi all, I often want to iterate over just the values of a map or perhaps just the keys of a map. Therefore I would like to see the following iterator adapters in the iterator library: template< class Map > struct map_key_iterator; template< class Map > struct map_value_iterator; template< class Map > struct map_const_value_iterator; I have outlined an implementation in the attached file, but basically it just a wrapper around transform_iterator<typename Map::iterator>. Comments? br Thorsten begin 666 map_value_iterator.cpp M(VEN8VQU9&4@/&)O;W-T+VET97)A=&]R+W1R86YS9F]R;5]I=&5R871O<BYH M<' ^#0H-"G1E;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T('-E;&5C=%]F M:7)S= T*>PT*(" @('1Y<&5D968@='EP96YA;64(a)36%P.CIK97E?='EP928@ M<F5S=6QT7W1Y<&4[#0H@(" @#0H@(" @<F5S=6QT7W1Y<&4@;W!E<F%T;W(H M*2@@8V]N<W0@='EP96YA;64(a)36%P.CIV86QU95]T>7!E)B!R("D@8V]N<W0- M"B @("![#0H@(" @(" @(')E='5R;B!R+F9I<G-T.PT*(" @('T-"GT[#0H- M"G1E;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T('-E;&5C=%]S96-O;F0- M"GL-"B @("!T>7!E9&5F('1Y<&5N86UE($UA<#HZ;6%P<&5D7W1Y<&4F(')E M<W5L=%]T>7!E.PT*(" @( T*(" @(')E<W5L=%]T>7!E(&]P97)A=&]R*"DH M(&-O;G-T('1Y<&5N86UE($UA<#HZ=F%L=65?='EP928@PT*(" @(" @("!R971U<FX@<BYS96-O;F0[#0H@(" @?0T*?3L-"@T* M=&5M<&QA=&4\(&-L87-S($UA<" ^#0IS=')U8W0@;6%P7VME>5]I=&5R871O MPT*<')I=F%T93H-"B @("!T>7!E9&5F(&)O;W-T.CIT<F%N<V9O<FU?:71E M<F%T;W(\('-E;&5C=%]F:7)S=#Q-87 ^+" -"B @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @('1Y<&5N86UE($UA<#HZ8V]N<W1?:71E M<F%T;W(@/@T*(" @(" @("!B87-E.PT*(" @( T*(" @('1Y<&5D968@='EP M96YA;64(a)36%P.CIC;VYS=%]I=&5R871O<B!I=&5R871O<CL-"G!U8FQI8SH- M"B @("!M87!?:V5Y7VET97)A=&]R*"D@.B!B87-E*"D-"B @("![('T-"@T* M(" @(&UA<%]K97E?:71E<F%T;W(H(&ET97)A=&]R('@@*2 Z(&)A<V4H>"D- M"B @("![('T-"@T*(" @(&UA<%]K97E?:71E<F%T;W(F(&]P97)A=&]R/2@@ M:71E<F%T;W(@PT*(" @(" @("!B87-E.CIO<&5R871O<CTH M<BD[#0H@(" @(" @(')E='5R;B J=&AI<SL-"B @("!]#0I].PT*#0H-"G1E M;7!L871E/"!C;&%S<R!-87 @/@T*<W1R=6-T(&UA<%]V86QU95]I=&5R871O M7!E;F%M92!-87 Z.FET97)A=&]R(#X-"GL-"G!R M:79A=&4Z#0H@(" @='EP961E9B!B;V]S=#HZ=')A;G-F;W)M7VET97)A=&]R M/"!S96QE8W1?<V5C;VYD/$UA<#XL( T*(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @='EP96YA;64(a)36%P.CII=&5R871O7!E;F%M92!-87 Z.FET97)A M=&]R(&ET97)A=&]R.PT*(" @( T*<'5B;&EC.@T*(" @(&UA<%]V86QU95]I M=&5R871O<B@I(#H@8F%S92@I#0H@(" @>R!]#0H-"B @("!M87!?=F%L=65? M:71E<F%T;W(H(&ET97)A=&]R('@@*2 Z(&)A<V4H>"D-"B @("![('T@(" @ M#0H-"B @("!M87!?=F%L=65?:71E<F%T;W(F(&]P97)A=&]R/2@@:71E<F%T M;W(@PT*(" @(" @("!B87-E.CIO<&5R871O<CTH<BD[#0H@ M(" @(" @(')E='5R;B J=&AI<SL-"B @("!]#0H-"GT[#0H-"@T*=&5M<&QA M=&4\(&-L87-S($UA<" ^#0IS=')U8W0@;6%P7V-O;G-T7W9A;'5E7VET97)A M=&]R(#H@#0H@(" @<'5B;&EC(&)O;W-T.CIT<F%N<V9O<FU?:71E<F%T;W(\ M('-E;&5C=%]S96-O;F0\36%P/BP@#0H@(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @('1Y<&5N86UE($UA<#HZ8V]N<W1?:71E<F%T;W(@ M/@T*>PT*<')I=F%T93H-"B @("!T>7!E9&5F(&)O;W-T.CIT<F%N<V9O<FU? M:71E<F%T;W(\('-E;&5C=%]S96-O;F0\36%P/BP@#0H@(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @("!T>7!E;F%M92!-87 Z.F-O;G-T M7VET97)A=&]R(#X-"B @(" @(" @8F%S93L-"B @("!T>7!E9&5F('1Y<&5N M86UE($UA<#HZ8V]N<W1?:71E<F%T;W(@:71E<F%T;W([#0IP=6)L:6,Z#0H@ M(" @;6%P7V-O;G-T7W9A;'5E7VET97)A=&]R*"D@.B!B87-E*"D-"B @("![ M('T-"@T*(" @(&UA<%]C;VYS=%]V86QU95]I=&5R871O<B@@:71E<F%T;W(@ M>" I(#H@8F%S92AX*0T*(" @('L@?0T*#0H@(" @;6%P7V-O;G-T7W9A;'5E M7VET97)A=&]R)B!O<&5R871O<CTH(&ET97)A=&]R('(@*0T*(" @('L-"B @ M(" @(" @8F%S93HZ;W!E<F%T;W(]*'(I.PT*(" @(" @("!R971U<FX@*G1H M:7,[#0H@(" @?0T*?3L-"@T*(VEN8VQU9&4@/&UA<#X-"@T*:6YT(&UA:6XH M*0T*>PT*(" @('1Y<&5D968@<W1D.CIM87 \:6YT+&EN=#X@;6%P.PT*#0H@ M(" @;6%P(&T[#0H@(" @;6%P7VME>5]I=&5R871O<CQM87 ^(&ME>5]B96=I M;B ](&TN8F5G:6XH*3L-"B @("!M87!?=F%L=65?:71E<F%T;W(\;6%P/B!V M86QU95]B96=I;B ](&TN8F5G:6XH*3L-"B @("!M87!?8V]N<W1?=F%L=65? M:71E<F%T;W(\;6%P/B!V86QU95]E;F0@/2!M+F5N9"@I.PT*(" @(" @(" - M"B @("!K97E?8F5G:6XK*SL-"B @("!V86QU95]B96=I;BLK.PT*(" @('9A 3;'5E7V5N9"TM.PT*?0T*#0H-"@`` ` end

1 0

Re: [boost] Re: Re: Querying the Interest in a new AutoPtr class?
by Chris Just 13 Feb '05

13 Feb '05

Jonathan Turkanis wrote: >> I wanted to create a very simple AutoPtr that was essentially the same >> as the STL auto_ptr (and backwards compatible with it). > > Unfortunately, you haven't (see below). Furthermore, auto_ptr is widely > recognized as unsafe because it is too easy to transfer ownership > unintentionally. Of course you can unintentionally transfer ownership if you don't know what you're doing. ;) I believe that's why you're not supposed to pass an auto_ptr to a function -- instead you pass the pointer itself with .get(). You can't stop everyone from shooting themselves in the foot. >>> I only looked very briefly, but I don't see how your auto_ptr can be >>> returned from functions. Also, why do you need the m_Owner variable? >> >> Correct me if I'm wrong, but wasn't there a specific reason why the >> STL auto_ptr was made so it couldn't be passed to or returned from a >> function? > > This was true of the initial version. The standard version, which is version 3, > implements a flavor of move semantics (and it doesn't quite work). I'm using the version that comes with Visual C++ 6.0, whatever version that is. >> Anyways, if you want to pass or return the pointer to/from a >> function, just use the .get() or .release() functions. > > But this subverts the resource management system. How? If you pass a pointer to a function, you shouldn't be deleting it inside that function anyways (so pass it with .get()), and if you return a pointer from a function, you can save it in a new AutoPtr so it will get deleted automatically... >> I need the m_Owner variable to tell me if I own the pointer before I >> delete it. > > For auto_ptr, checking that the stored pointer is non-null should be sufficient. I don't set my pointer to NULL when I release() it, I just set m_Owner = false. I've also run some speed comparisons between auto_ptr and AutoPtr and (on Windows at least) they appear to be virtually the same speed when doing the same operations. I'm wondering what the speed comparisons would be between auto_ptr and some of the other smart pointers that you mentioned? Chris Just __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

3 3

[filesystem] Major changes before standardization
by Beman Dawes 13 Feb '05

13 Feb '05

I'm currently working on a major revision of the Boost filesystem library aimed at getting it ready to be proposed to the C++ committee for the next Library TR. The critical technical change required is internationalization. The plan is to provide a templated basic_path class, with typedefs for path and wpath. In other words, an approach very similar to the current std::basic_string, std::string, and std::wstring. Doing this adds a certain amount of complexity compared to the current path class. For example, a path_traits class has to be introduced to give basic_paths on user defined types a way to import the conversions, delimiters, and other traits. To offset the added complexity, I'd like to reduce some of the complexities in the current design: * Eliminate the distinction between native and generic grammars; either would be permitted in all contexts. As well as simplifying the class interface a bit, this will also eliminate a source of user confusion. * Move the name error checking from the basic_path class into stand alone functions. Although the current error checking could be further improved by Peter Dimov's suggested change allowing failure to be treated as either a warning or a hard error, moving it out of the class simplifies the interface, allows full path (rather than name-by-name) error checks, and eases internationalization. The primary downside of these changes will be that users who want path portability checks will have to code calls to checking functions that are currently being called automatically. The internationalization of the library is a big enough change that we will probably want to have at least a mini-review once the changes are complete. Comments? --Beman

12 55

Strange gcc 3.2.2-5.8 behavior
by John Eddy 13 Feb '05

13 Feb '05

The following bit of code gives me an undefined symbol (l1) when using gcc 3.2.2-5.8. Is there something wrong with the code or is there a bug in the compiler or a setting I don't know about, etc? struct S { static const short l1 = 10; }; void go(const short& l) {}; // causes undefined symbol l1 int main(int argc, char* argv[]) { go(S::l1); return 0; } If I do normal, non-in-class-initialization, the problem doesn't appear nor does it appear if I accept the short by value in go. Thanks, John

4 6

Re: [boost] Re: Querying the Interest in a new AutoPtr class?
by Chris Just 13 Feb '05

13 Feb '05

Jonathan Turkanis wrote: > There is a policy-based pointer, based on the Loki SmartPtr, coming up for > review soon which can emulate an auto_ptr and allows deletion policy to be > specified as part of the 'storage policy'. I don't know much about the Loki SmartPtr, but it sounds like it might be a little hard to use if you need to setup policies... I wanted to create a very simple AutoPtr that was essentially the same as the STL auto_ptr (and backwards compatible with it). > I only looked very briefly, but I don't see how your auto_ptr can be returned > from functions. Also, why do you need the m_Owner variable? Correct me if I'm wrong, but wasn't there a specific reason why the STL auto_ptr was made so it couldn't be passed to or returned from a function? I don't have my Stroustrup book with me to check. Anyways, if you want to pass or return the pointer to/from a function, just use the .get() or .release() functions. I need the m_Owner variable to tell me if I own the pointer before I delete it. Chris Just __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

2 1

Wave review ends February 19, 2005
by Tom Brinkman 13 Feb '05

13 Feb '05

The boost::wave review ends in six days, February 19, 2005. Please get your review in by then. If you need more time, please contact me personally. Review Manager, Tom Brinkman __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

BOOST_PP_SEQ_FOR_EACH_I
by Arkadiy Vertleyb 13 Feb '05

13 Feb '05

Hi all, I don't think that reentrancy mechanism is working for this macro. Is it supposed to? The following example illustrates my problem (I tried both automatic and manual methods): #include <boost/preprocessor/seq/for_each_i.hpp> #define seq\ ((1)(2)(3))\ ((4)(5)(6))\ ((7)(8)(9)) #define MACRO(r, data, i, elem)\ BOOST_PP_SEQ_FOR_EACH_I(MACRO2, ~, elem) #define MACRO1(r, data, i, elem)\ BOOST_PP_SEQ_FOR_EACH_I_R(r, MACRO2, ~, elem) #define MACRO2(r, data, i, elem)\ elem BOOST_PP_SEQ_FOR_EACH_I(MACRO, ~, seq) BOOST_PP_SEQ_FOR_EACH_I(MACRO1, ~, seq) Both preprocessors I tried, VC71 and GCC 3.4.2, produce the same result: BOOST_PP_SEQ_FOR_EACH_I(MACRO2, ~, (1)(2)(3) ) BOOST_PP_SEQ_FOR_EACH_I(MACRO2, ~, (4)(5)(6) ) BOOST_PP_SEQ_FOR_EACH_I(MACRO2, ~, (7)(8)(9) ) BOOST_PP_SEQ_FOR_EACH_I_M(3, (MACRO2, ~, (1)(2)(3) (nil), 0)) BOOST_PP_SEQ_FOR_EACH_I_M(4, (MACRO2, ~, (2)(3) (nil), 1)) BOOST_PP_SEQ_FOR_EACH_I_M(5, (MACRO2, ~, (3) (nil), 2)) BOOST_PP_SEQ_FOR_EACH_I_M(4, (MACRO2, ~, (4)(5)(6) (nil), 0)) BOOST_PP_SEQ_FOR_EACH_I_M(5, (MACRO2, ~, (5)(6) (nil), 1)) BOOST_PP_SEQ_FOR_EACH_I_M(6, (MACRO2, ~, (6) (nil), 2)) BOOST_PP_SEQ_FOR_EACH_I_M(5, (MACRO2, ~, (7)(8)(9) (nil), 0)) BOOST_PP_SEQ_FOR_EACH_I_M(6, (MACRO2, ~, (8)(9) (nil), 1)) BOOST_PP_SEQ_FOR_EACH_I_M(7, (MACRO2, ~, (9) (nil), 2)) Which, I think, indicates that reentrancy is not working. Am I missing something? Regards, Arkadiy

2 4

Querying the Interest in a new AutoPtr class?
by Chris Just 13 Feb '05

13 Feb '05

Hi all, I was wondering what the interest level is for a new auto pointer? I know you've got a few different ones already, but I believe this one has some features that make it quite unique. I based my AutoPtr from the STL auto_ptr and added some additional operator overloads to make it easier to use. The biggest feature however, is that you can specify a custom deletion function object. The custom deletion function object allows you to delete in ways other than just 'delete ptr;' For example, you can delete like this: delete [] ptr; ptr->Delete(); // Delete() calls: delete this; free( ptr ); If you want to take a look at it, it's available at: http://groups.yahoo.com/group/boost/files/AutoPtr/ I'd like to hear your suggestions. Chris Just __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

3 2

thread safety in boost intrusive and shared pointers
by Puneet Jain 13 Feb '05

13 Feb '05

I am a new user of boost pointers and was wondering about the thread safety in boost shared and intrusive pointers. After reading some eariler posts and the current documentation, I am little confused. As per current documentation shared pointers thread safety in shared pointers is on the lines of STL and thus they are not thread safe for writing. But I am pretty sure I read in one of the posts that shared pointer is thread safe for all operations. Also, looking at the operator= and swap, it seems there could be some thread safety issues. Also, I have my own counted_base which I use in intrusive pointer. If my understanding is correct, to ensure thread safety, if I ensure add_ref and release_ref operations are atomic, I am pretty much covering all the bases. Thanks, Pete

2 1

[date_time] errors in compiler_config.hpp
by Martin Wille 13 Feb '05

13 Feb '05

Hi, there are several missing logical operators around line 17 of date_time/compiler_config.hpp Regards, m

2 1

Boost filesystem and windows drives
by jrg＠dsl.pipex.com 13 Feb '05

13 Feb '05

Boost filesystem paths checked using filsystem::windows_name cannot contain a colon (":"). But the standard way to specify a particular drive in Windows is to use a colon (e.g. "C:\Windows"). Shouldn't colons be allowed for specifying a drive in Windows? Thanks, James

2 1

[config] How to test for GCC <= 4.0
by Jonathan Turkanis 12 Feb '05

12 Feb '05

Hi, I have a workaround which I want to apply to all known versions of GCC but not to future versions unless I later determine that it is necessary. Currently I have something like this: #if !defined(BOOST_INTEL) && ( BOOST_WORKAROUND(__GNUC__, <= 3) || \ BOOST_WORKAROUND(__GNUC__, == 4) && \ BOOST_WORKAROUND(__GNUC_MINOR__, BOOST_TESTED_AT(0)) ) \ /**/ ... #endif but I can see from the regression reports that GCC 4.0 is not picking up the workaround code. What am I doing wrong? Jonathan .

2 3

Singleton Library Ready for Review
by Jason Hise 12 Feb '05

12 Feb '05

Recent changes: * The dependency lifetime now works by using the pointers themselves as dependencies, and using lazy creation to determine whether creation of the pointer or dereferencing of the pointer creates the instance. Using the pointer instead of a separate dependency class allows the lifetime to achieve a consistent interface with the other lifetime policies. * All lifetime policies now work uniformly for Singletons, Multitons, and potentially any Somethingtons that an end user might choose to implement (HashedMultiton, TwoKeyedMultiton, etc...). The only caveat is that the Multiton instance holder (a singleton used in the implementation of the multiton), must use a leaky lifetime. If any other type of lifetime is used, combining the longevity lifetime policy with the multiton ends up being disastrous. If the OS cleans up leaked memory when the program exits, this should not be a problem. Even so, I would like to find a better solution if possible. Because I have no experience with multi threading, I need someone to verify that I am locking in all of the right places, and that any singleton/multiton operations that need to be thread safe actually are thread safe. A sample test program is provided below, whose lifetime policies can be easily edited to verify order of creation and destruction in all circumstances. I am fairly confident that my singleton library is now complete. What are the next steps to take in adding it to Boost? -Jason // Sample Program #include <sstream> #include <fstream> #include "../Include/StaticAllocator.h" #include "../Include/MallocAllocator.h" #include "../Include/LongevityLifetime.h" #include "../Include/Singleton.h" #include "../Include/Multiton.h" using namespace boost::singleton; using std::stringstream; using std::ofstream; class TestLog : public Singleton < TestLog, LongevityLifetime < TestLog, 10 > > { private: ofstream out; protected: TestLog ( ) : out ( "log.dat" ) { out << "Test log created.\n"; } ~ TestLog ( ) { out << "Test log destroyed.\n"; out.close ( ); } public: void Write ( const char * msg ) { out << msg; } }; class A : public Multiton < int, A, LongevityLifetime < A, 5 > > { private: TestLog :: Pointer log; protected: A ( ) { log->Write ( "A created.\n" ); } ~ A ( ) { log->Write ( "A destroyed.\n" ); } }; // lifetime longevity higher than A, to verify that even though A is created first, it is still destroyed after B class B : public Singleton < B, LongevityLifetime < B, 7 > > { private: TestLog :: Pointer log; A :: Pointer a1; A :: Pointer a2; A :: Pointer a3; protected: B ( ) : a1 ( 0 ), a2 ( 1 ), a3 ( 1 ) { log->Write ( "B created.\n" ); } ~ B ( ) { log->Write ( "B destroyed.\n" ); } public: void foo ( ) { log->Write ( "foo called.\n" ); } }; int main ( ) { B::Pointer ptr; ptr->foo ( ); }

5 16

CVS has a stale lock
by Carlo Wood 12 Feb '05

12 Feb '05

This is majorly annoying, can this be fixed ASAP please? cvs checkout: Updating boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:46:22] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:46:52] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:47:22] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:47:52] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:48:22] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:48:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:49:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:49:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:50:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:50:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:51:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:51:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:52:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:52:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:53:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:53:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:54:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:54:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:55:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:55:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:56:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:56:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:57:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:57:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:58:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:58:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:59:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [04:59:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:00:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:00:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:01:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:01:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:02:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:02:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:03:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:03:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:04:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:04:53] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:05:23] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:05:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:06:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:06:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:07:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:07:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:08:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:08:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:09:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:09:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:10:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:10:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:11:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:11:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:12:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:12:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:13:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:13:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:14:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:14:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:15:24] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib cvs checkout: [05:15:54] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v1/example/sublib_use/sublib etc -- Carlo Wood <carlo(a)alinoe.com>

2 1

unit-test always seg-faulting
by amerio 12 Feb '05

12 Feb '05

Hello, We are trying to use boost unit test framework for our unit tests. It works fine, except it will always seg fault when quitting. Even the smallest simplest empty test will seg fault. Compiler is gcc 2.95.4, on a Woody Debian. Compiling with -g -pg -pthread Linking with -g -pg -lboost_thread-gcc-mt -lboost_unit_test_framework-gcc-1_32 unit_test.cpp is only : #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include <iostream> BOOST_AUTO_UNIT_TEST(autofct) { std::cout <<"ok" << std::endl; } Seg fault is when calling dispose(), in shared_count::release() (line 147) Thanks for your help.

2 1

Unordered associative containers and swap's exception safety
by Daniel James 12 Feb '05

12 Feb '05

Hello everyone, I've got an exception safety problem implementing the hash containers. The draft standard says (from 6.3.1.1): 'For unordered associative containers, no swap function throws an exception unless that exception is thrown by the copy constructor or copy assignment operator of the container's Hash or [equality] Pred object (if any).' This is a problem, because for the container to be valid, its hash buckets, equality predicate and hash function need to consistent. Since both the hash and predicate can throw, this is impossible (or hard?) to achieve. If swapping/copying the first one succeeds, and the second one throws they won't match. Any ideas on what I should do? I don't think this can cause any major problems, like memory leaks or access to unowned memory, but it can cause unpredictable behaviour - since equal keys can end up in different buckets. Basically the invariant ends up totally broken. The only solution that I've come up with, is to store the two function objects in a seperate structure, allocated on the heap, so that only pointers have to be swapped. But this seems unfortunate since most function objects won't throw. This problem also applies to the copy assignment operator. Daniel

3 3

RE: [boost] new version of profiling library
by Brian Braatz 12 Feb '05

12 Feb '05

I will not be able to deeply look at this til tomorrow. But my initial reaction is THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Friday, February 11, 2005 4:36 PM > To: Boost mailing list > Subject: [boost] new version of profiling library > > The profiling library has been updated in a big way. > The new files are at: > > http://www.cdiggins.com/profiler/v2/profiler.hpp > http://www.cdiggins.com/profiler/v2/profile_manager.hpp > http://www.cdiggins.com/profiler/v2/high_resolution_timer.hpp > > and as a special treat for Brian there is: > > http://www.cdiggins.com/profiler/v2/custom_profile_manager.hpp > > This last version shows one possible way of using the current library to > associate meta-data with profiles. Instead of using a multi-index > internally, I push the data into a multi-index to generate a custom > report. > I am not super happy with this version, it is more complicated than I > would > like, but it does work. > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

new version of profiling library
by christopher diggins 12 Feb '05

12 Feb '05

The profiling library has been updated in a big way. The new files are at: http://www.cdiggins.com/profiler/v2/profiler.hpp http://www.cdiggins.com/profiler/v2/profile_manager.hpp http://www.cdiggins.com/profiler/v2/high_resolution_timer.hpp and as a special treat for Brian there is: http://www.cdiggins.com/profiler/v2/custom_profile_manager.hpp This last version shows one possible way of using the current library to associate meta-data with profiles. Instead of using a multi-index internally, I push the data into a multi-index to generate a custom report. I am not super happy with this version, it is more complicated than I would like, but it does work. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

Proposal for an extension of the boost::signals::connection interface
by Frantz Maerten 11 Feb '05

11 Feb '05

I took a look at libsidc++ and found very interresting the way of blocking/unblocking connections. I added some small modifications in boost::signals lib in order to have this functionality (2 patches in attachment to apply at the parent of the boost_1_32_0 distrib). Only the interface of connection has changed (3 new methods), and I added a boolean flag in basic_connection struct. Also, a functor is_callable was added in the file connection.hpp, in replacement of the is_disconnected functor (used in the class slot_call_iterator). So, my questions are: 1) is it interresting/useful to incorporate it (for me, yes of course)? 2) is it a safe implementation? You can test it like that: \code void fct1(int) ; void fct2(int) ; MySignal sig ; boost::signals::connection conn = sig.connect(&fct1) ; sig(10) ; // call fct1 and fct2 conn.block() ; sig(20) ; // call only fct2 conn.unblock() ; sig(30) ; // call fct1 and fct2 \endcode --Frantz

1 0

RE: [boost] [Signals] Named slot group usage?
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Friday, February 11, 2005 12:40 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Signals] Named slot group usage? > > On Feb 11, 2005, at 3:21 PM, Brian Braatz wrote: > > What about allowing the internal type to be policy\traited? > > > > i.e. I can use a vector instead of a map<> > > That gets really messy, really quick, and I only really know how to > give sane semantics for list<> and map<>. > I'm against policies except in very extreme circumstances. > > > and is it possible to allow for meta-data while you're at it? > > Worry not, we'll find a way to get meta-data into slots :) > > Doug > [Brian Braatz] (Imagine an entire football stadium standing up and cheering!) OR (just me :) )

1 0

Re: [boost] Unordered associative containers and swap's exceptionsafety
by JOAQUIN LOPEZ MU?Z 11 Feb '05

11 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Viernes, Febrero 11, 2005 10:45 am Asunto: [boost] Unordered associative containers and swap's exception safety > Hello everyone, > > I've got an exception safety problem implementing the hash > containers. > The draft standard says (from 6.3.1.1): > > 'For unordered associative containers, no swap function throws an > exception unless that exception is thrown by the copy constructor > or > copy assignment operator of the container's Hash or [equality] > Pred > object (if any).' > > This is a problem, because for the container to be valid, its hash > buckets, equality predicate and hash function need to consistent. > Since > both the hash and predicate can throw, this is impossible (or > hard?) to > achieve. If swapping/copying the first one succeeds, and the > second one > throws they won't match. Any ideas on what I should do? Hi Daniel. I think little can be done here without penalizing the normal users (i.e. those providing notrow Hash and Pred objects.) The solution you propose is probably the only way out, but it incurs an extra indirection each time one of the objects is accessed. FWIW, all implementations I've seen simply assume swapping of these objects won't throw --and this is the case also for other STL containers, where a simple recovery strategy would be nonetheless possible. Having a nonthrowing swap, then it is trivial to have exception-safe strong assignment. I think this has received attention at comp.std.c++, but without any definitive conclusion AFAIK. So my advice is to just assumme Hash and Pred objects won't throw when being swapped through std::swap and be happy. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Signals] Named slot group usage?
by Douglas Gregor 11 Feb '05

11 Feb '05

I'm trying to determine how widely used named slot groups are in the Signals library. I would appreciate it if I could get some feedback on if they're used, how they're used, etc. In particular: (1) Do you use named slot groups? (2) Did the FIFO ordering guarantees in 1.32.0 and the ability to add to the front or back of the slot list alleviate the need for named slot groups? (3) If performance of connection/disconnection of named slot groups were to get worse (e.g., linear in the number of slots), would it seriously impact the performance of your application? Responses should probably come to me, personally, unless they would be of interest to the group. Background: Signals performance is sub-par, and much of the problem can be traced back to support for named slot groups. I'm trying to determine the best way to proceed. Thanks, Doug

6 7

Re: What about Multi-Index? \ RE: [boost] Latest version of theprofiler
by JOAQUIN LOPEZ MU?Z 11 Feb '05

11 Feb '05

----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Viernes, Febrero 11, 2005 5:07 pm Asunto: What about Multi-Index? \ RE: [boost] Latest version of the profiler > (Responding to my own post again. I guess I am one of those guys who > could sit in a closet and carry on a conversation with himself) :) > > (Joaquin: ARE YOU OUT THERE?- Your thoughts appreciated) Hi Brian, here I am :) I'm afraid I haven't been following this thread close enough to emit an informed opinion. Please allow me some hours to catch up and I'll be back to you. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > What if instead of a map, you used Boost.MultiIndex container?. Then > exposed the configuration of that to the users of the profiler. >

1 0

[logo]
by Jonathan Turkanis 11 Feb '05

11 Feb '05

Hi, Please forgive me if this is off topic here ... Can someone recommend a free SVG editor other than Inkscape? I downloaded it yesterday and it quickly used up all the available device contexts, forcing me to shut down my system. Jonathan

2 1