March 2005 - Boost - lists.boost.org

Re: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

Hi Jonathan! ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Viernes, Marzo 4, 2005 0:08 am Asunto: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > JOAQUIN LOPEZ MU?Z wrote: [...] > > The macros I'm using are: > > > BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS > > BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS > > These would be okay with me. But sometimes I use a macro for > specifying the type > of derivation, and > > struct derived_class > : BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS base_class > { }; > > seems a bit long. Yep it is long, but BOOST_PRIVATE covers too much semantic scape: what if in the future a similar workaround is needed to make up for another, unrelated defficiency? This is not hypothetical, in fact I'm already using BOOST_MULTI_INDEX_PRIVATE_IF_USING_DECL_FOR_TEMPL_FUNCTIONS that does the same thing (turning private into public) in some compilers that do not support in-class using declarations for template functions. Admittedly, it'd be nicer if we can come up with a shorter, yet descriptive name. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: OT: Jonathan, weren't you going to promote a scopeguard impl to boost/detail? I'm waiting for that so that I can reduce my own codebase :)

2 1

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

[I'm reposting this because I misspelled 'config' in the subject line] Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 1

[config] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost][repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 0

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 03 Mar '05

03 Mar '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Marzo 3, 2005 9:49 pm Asunto: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Hi, > > <boost/shared_ptr.hpp> contains the following in the public > section of the class > definition (reformatted): > > // Tasteless as this may seem, making all members public > // allows member templates to work in the absence of member > // template friends. (Matthew Langston) > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > private: > > template<class Y> friend class shared_ptr; > template<class Y> friend class weak_ptr; > > > #endif > > T * px; // contained pointer > detail::shared_count pn; // reference counter > > This has become a pretty common technique, I believe. I certainly > use it a lot, > at any rate. FWIW, I've also been forced to use a similar workaround. > > I'd like to suggest two macros which would allow code like the > above to be > simplified as follows: > > BOOST_PRIVATE: > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > T * px; // contained pointer > detail::shared_count pn; // reference counter > BOOST_PRIVATE seems a little to uninformative a name to me. The macros I'm using are: BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS (well, I'm using lib-specific variations of these names, but you get the idea.) As for your proposal, I like it: there are at least three libraries that would benefit from it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

03 Mar '05

On Thu, 2005-03-03 at 13:54 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > > > > So anything less than CORBA should not be considered? For RPC, Yes. > > My experience with CORBA is that you _do_ pay for things you don't need. Try > building a simple server/client app with my RPC library, and then build it with > ACE TAO, and I wonder which method you'll find to be simpler/easier/faster... Here is an example CORBA client. And it doen not matter which ORB you use. #include <iostream> #include "echoC.hpp" // generated from the idl file int main ( int ArgV , char * ArgV ) { try { // _var types are smart ptrs to ref counted objects. CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO"); // get IOR from a file so we can talk to server CORBA::Object_var Factory_Object = Orb->string_to_object ( ArgV [ 1 ] ); // This is a CORBA safe downcast My::Echo_Factory_var Factory = My::Echo_Factory::_narrow ( Factory_Object.in( ) ); My::Echo_Server_var EchoServer = Factory->get_server ( ArgV [ 2 ] ); CORBA::String_var Echoed = EchoServer-> ( "Hello World" ); } catch ( CORBA::Exception & E ) { std::cerr << "CORBA exception raised!" << std::endl; } } I don't think 5 lines of code is exactly heavyweight. I could of done it in 3 lines if I did not use a factory, but that would have been unrealistic. I won't show the server but it 2 classes the factory publicly inherits from Echo_Factory and implements a single function get_server. Likewise like for EchoServer. > Which code is less invasive, more intuitive, and more proportional to the task? > And oh I forgot, don't forget to first build all of ACE and TAO, and then link > the whole shebang to your own 5 lines of code. To me it feels like I'm getting > far, far more than I asked for. But that's just me :-) ACE is nothing to do with CORBA. It just happens to be what TAO uses internally. Building Open source or installing per build libs has nothing to do with how easy it is to use. Your comparing apples and carrots. >If you need scaleability, then obviously CORBA is one of the few >options you have. But if you don't need scaleability, or naming >services, or whatever, what's wrong with using something much simpler? Because when you app grows you will have to re-write it. More likely, is that won't happen and people will re-invent the again. Take a look at the development of SOAP :-(. /ikh

2 1

regexes matching empty strings
by Michael Goldshteyn 03 Mar '05

03 Mar '05

Why can I not construct a regex of the form: "|abc" (throws exception based on REG_EMPTY) for use with regex_match, if I want to match either "abc" or the empty string "". I understand thatn in a regex_search the empty string would always match (per Perl like semantics), and abc would never be considered. But, I want to use this with regex_match, where the empty string would have to match the entire string being searched. Work arounds such as "(?:)|abc" and "^$|abc" seem to get around this deficiency, but I am wondering why it is there in the first place. Thanks, Michael Goldshteyn

2 3

One more test message. Please delete it
by Pavel Chikulaev 03 Mar '05

03 Mar '05

Ok?

1 0

Running regression tests
by Jody Hagins 03 Mar '05

03 Mar '05

Trying to run the regression tests for BCB6/Windows, using current CVS head... set BOOST_ROOT=C:\boost set TOOLS=borland I can run bjam stage and everything that is supposed to build, builds (serialization, and wave do not build). However, when I follow the directions, I have problems. Can someone please help?!? I tried cd up into boost root, and it seemed to work better, but links in the html files wanted to access directories ".." so that failed too. What am I doing wrong? Thanks! C:\boost>cd status C:\boost\status>bjam --dump-tests test >bjam.log 2>&1 C:\boost\status>echo %BOOST_ROOT% C:\boost C:\boost\status>echo %TOOLS% borland C:\boost\status>process_jam_log < bjam.log Usage: bjam [bjam-args] | process_jam_log [--echo] [--create-directories] [locat e-root] locate-root - the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. create-directories - if the directory for xml file doesn't exists - creates it. usually used for processing logfile on different machine boost_root: C:/boost/status/.. locate_root: C:/boost/status/.. no errors detected C:\boost\status>compiler_status %BOOST_ROOT% cs-win32.html **** exception(205): std::exception: boost::filesystem::directory_iterator const ructor: "C:\boost\status\bin": The system cannot find the path specified. ******** errors detected; see standard output for details ******** C:\boost\status>compiler_status Usage: compiler_status [options...] boost-root status-file [links-file] boost-root is the path to the boost tree root directory. status-file and links-file are paths to the output files. Must be run from directory containing Jamfile options: --compiler name Run for named compiler only --ignore-pass Do not report tests which pass all compilers --no-warn Warnings not reported if test passes --locate-root path Path to ALL_LOCATE_TARGET for bjam; default boost-root. --comment path Path to file containing HTML to be copied into status-file. --notes path Path to file containing HTML to be copied into status-file. --notes-map path Path to file of toolset/test,n lines, where n is number of note bookmark in --notes file. --jamfile path Path to Jamfile. By default "Jamfile". Example: compiler_status --compiler gcc /boost-root cs.html cs-links.html Note: Only the leaf of the links-file path and --notes file string are used in status-file HTML links. Thus for browsing, status-file, links-file, and --notes file must all be in the same directory. **** error return code: 1 ******** errors detected; see standard output for details ******** C:\boost\status>

3 10

Test. Please delete this thread
by Pavel Chikulaev 03 Mar '05

03 Mar '05

I just couldn't have get access to developers list

1 0

Preview of the Function Types library (function_traits replacement)
by Tobias Schwinger 03 Mar '05

03 Mar '05

Dear Boosters, a preview of the Function Types library is available, now. [ Online documentation: http://tinyurl.com/4fw9n ] [ Downloadable archive: http://tinyurl.com/6u77y ] It is the third (nearly) complete rewrite and the design finally feels right for me. However, I am very curious to hear any of your opinions about it ! So, if you have been hoping for the retirement of function_traits, please take a few minutes to find out if this would suit your needs. Regards, Tobias

3 19

patch against boost threads library
by Ulrich Eckhardt 03 Mar '05

03 Mar '05

Short notes: * thread_exception::message() is broken beyond repair, as it returns a pointer to local storage (via std::string::c_str()) * any program using it is broken, too. * it is unused by boost itself(!) which is why it can be removed * it is the only reason why a helper-function 'system_message()' is needed, which can then be removed, too. * system_message() is the only reason several headers and a hack for strerror() were needed, which can then also be removed. * system_message() requires a char-based API on win32, which is not available under MS Windows CE, strerror() is also not available there, making two more reasons to remove it. cheers Uli

3 4

[range] BOOST_RANGE_DEDUCED_TYPENAME
by Jody Hagins 03 Mar '05

03 Mar '05

In range/config.hpp, I see this code... #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) #define BOOST_RANGE_DEDUCED_TYPENAME #else #define BOOST_RANGE_DEDUCED_TYPENAME BOOST_DEDUCED_TYPENAME #endif Why is there a special version of this? It is only defined to empty, or BOOST_DEDUCED_TYPENAME. What is wrong with simply using BOOST_DEDUCED_TYPENAME? If there is a problem with the "stock" one? If so, shouldn't that be changed instead?

3 2

Preprocessor warning from BOOST_PP_SEQ_ELEM
by Edward Bishop 03 Mar '05

03 Mar '05

Hi All, When I run the following code through the preprocessor, it emits the correct output: alpha is simple; beta is simple; gamma is complex and color is red; delta is simple; epsilon is complex ; but it also emits the folowing warning (several times): macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given My question is, how can I eliminate the warning. Thanks in advance for any comments/advice. # include <boost/preprocessor/library.hpp> #define IS_SIMPLE(t) BOOST_PP_NOT_EQUAL(3, BOOST_PP_SEQ_SIZE(t)) #define PROPERTIES(t) BOOST_PP_SEQ_ELEM(2,t) #define HAS_COLOR(t) BOOST_PP_EQUAL(2, BOOST_PP_SEQ_ELEM(0, \ PROPERTIES(t))) #define COLOR(t) BOOST_PP_SEQ_ELEM(1, PROPERTIES(t)) #define FSIMPLE(a, s, i, t) \ BOOST_PP_SEQ_ELEM(0,t) is simple; #define FCOMPLEX(a, s, i, t) \ BOOST_PP_SEQ_ELEM(0,t) is complex \ BOOST_PP_IF(HAS_COLOR(t), and color is COLOR(t) , ); #define FCHOICE(a, s, i, t) \ BOOST_PP_IF(IS_SIMPLE(t), \ FSIMPLE(a, s, i, t), \ FCOMPLEX(a, s, i, t)) #define T(s)\ BOOST_PP_SEQ_FOR_EACH_I(FCHOICE, s, s) \ T ( // ID Frequency Properties ( (alpha) (16) ) ( (beta) (3) ) ( (gamma) (13) ((2) (red)) ) ( (delta) (5) ) ( (epsilon) (13) ((4) (heavy)) ) )

3 7

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

03 Mar '05

First, I appologize for messing up the threading, but I get the digest and so can't respond directly. >Have you ever had a look at other FSM libraries? I think boost::fsm >is less messy than any other library I've seen. Unfortunately, no. My response is based on the fact that 1) I generally think I know what fsm are about, 2) I'm comfortable seeing complex template stuff, yet 3) sample code for simple state machines just didn't click for me. I feel like I'm in the target audience of the library, so I'm looking deeper to see if I can figure out why. >> // I guess there's no way to avoid declaring >> // these ahead of time?? >> class Machine, State1, State2, Event1, Event2; >Actually there is, but I found out about this only recently (Peter > Dimov mentioned this in an unrelated post) and haven't changed the > docs because I feared that this does not work on all compilers: > >Instead of > >struct Greeting; >struct Machine : fsm::state_machine< Machine, Greeting > {}; > >you can write: > >struct Machine : fsm::state_machine< Machine, struct Greeting > {}; Ok, good to know. I'd like to hash out what the "ideal world" would look like and compromise from there, if you know what I mean. >> 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 >You consider this more readable? Sorry, I have to disagree. For entry > and exit actions and extended state variables I consider my approach > superior, for reaction definition, your approach seems about > equivalent. I think this is how my example would look using the current library, right? struct State1 : simple_state< State1, Machine, custom_reaction< Event1 >, transition< Event1, struct State2 > > { int i; State1() : i(0) { cout << "Entering State1."; } ~State1() { cout << "Exiting State1."; } result react( const Event1 & ) { i++; } }; That's actually not so bad. I've defined both a reaction and a transition on the same event; not sure if you're supposed to do that. Now I'm wondering if there's a way with mpl to determine if a class has a function with a certain signature. Can you eliminate the need for "custom_reaction< Event1 >" and just test whether or not the class implements "result react( const Event1 & )" ? If you could somehow hide the CRT mechanism, and specify children instead of parents, maybe you could boil down to something like so: DEFINE_STATE(State1, transition< Event1, struct State2 >) { int i; State1() : i(0) { cout << "Entering State1."; } ~State1() { cout << "Exiting State1."; } result react( const Event1 & ) { i++; } }; And I think that's about as obvious as you can make it. But that may just be wishful thinking. >I don't understand, you do define states top-down in boost::fsm. Maybe I'm confused, but as best as I can tell, you specify parents instead of specifying children. So, if StateX has StateY and StateZ as inner states, instead of saying StateX : StateY + StateZ, you say StateY -> StateX; StateZ -> StateX. >> 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 >One sure can but that would duplicate mpl::list<> functionality to a > certain degree. For "real-world" uses, this seems unimportant. However, for the tutorial and basic examples, I think it would be a good idea if you can silently ignore mpl. Of course those examples should compile and work... I don't have a feel for whether I'm asking for a mountain or a molehill here, so I'll let it be. >Given that the approach you outlined above really works, I think you > can use lambda for transitions without changing a single line of > boost::fsm, you simply define your own reaction that accepts > typeofed lambda expressions instead of function pointers for > transition actions. I'm not so sure whether the same is possible > with entry/exit actions but I'm inclined to think that it > is (that would require deriving your own state class template from > simple_state). I think it would be nice to have a mechanism that accepts lambdas, though I'll concede it is better to avoid it for "average joe" programmer. But since fsm is compile time, an advanced user might use another library/technique to programmatically generate the code she wants as a lambda type. It's always seemed that lambda had great potential as a compile time code generator, and fsm is a place where one might concievably stick it. >Most people get used to the syntax >of boost::fsm quite quickly. Also, I've received feedback that people > really like the fact that they can easily put the bodies of complex > actions in cpp files, I *guess* that would be a little more > difficult with your approach. Now I'm thinking that maybe a macro or two added to what you've got, just to hide some of the machinery, is all that it would take to get what I'm looking for. I'll grant you that I'm struggling to come up with what I think is "ideal." My main goal is boost::fsm using code should be reasonably "guessable" by an educated reader in short order. Basically, my coworkers should be able to look at my code and mostly be able to guess what was going on. [snip] > I'd say it takes one day tops of playing around with boost::fsm to > learn this. My concern is intimidating potential new users more than necessary. Like I said initially, I might have missed a ton of discussion about this from before. If you can point me to a thread where interface issues were hashed out in great detail already, I'll take a look. > I did consider using named template parameters, but > rejected it because it would add to the amount of text you have to > write and would offer a benefit only for beginners. Me, I would probably cater a little more to the beginners, since I think getting more people to use FSM than previously would have to be a good thing. >> tutorial just made my head spin, especially trying to figure out >> how states and machines get tied together (this is still unclear to >> me). > I guess you mean how the implementation ties them toghether? As a > user, why do you need to know that? When I first looked at the sample code, I was hunting high and low, thinking to myself, "Where on earth does it specify which states belong to which?" >As I already mentioned in another post: Targetting every C++ > developer would require an *additional* document at least as thick > as the current tutorial. I think it is reasonable to expect previous > exposure to FSMs. Yes, I do not suggest writing your own guide to FSMs. >> In general, I would drop all mention of UML except for some >> appendix somewhere (and the reference manual too). > >Why? I think it's a distraction. Sure, it's great that you've got this nice correspondance with UML, but 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. >> "Getting Started" and >> "Target Audience" should be in a differenct document, and > >Please make a suggestion. Probably just in index.html. >> "How to read this tutorial" should be removed. > >Why? To me, is unnecessary verbiage. It doesn't say anything important. Perhaps you need better headings in the TOC. The ToC is currently broken up by the name of the example; perhaps rather than "StopWatch," say "Simple Finite State Machines - A StopWatch example." >> In general, all of your "remarks" and "comments" need to be in the >> code! > >You're the second person to request that. I personally think it is > better to not clutter code with too many comments. If people think > it is better to have all comments in the code, I'll sure change it. Having it in the code, both in the tutorial and in the example files, would help a lot, IMO. Especially the example files. If you could give me a better overview of the process and hold my hand better about which template parameters are which, I think I would have been much less confused. >> 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. > >Why? Well, maybe this isn't the norm, but I was taught FSMs using alphabets-as-events. One of the first things *I* would do with the library is try and implement some examples out of my old college text. I figured most people were taught this way, and so having an example with that would help connect with something familiar. >You mean the mapping between the pressed key and the generated event? > Why? I think it's probably a common thing to want to test your state machine by triggering events from the keyboard in a console app. >> I'm confused about why entering/exiting states causes construction/ >> destruction. It's taken as a given, > >It is not: http://tinyurl.com/5mjra (State-local storage) That's explaining why you offer state-local storage, which I have no qualms with. It doesn't explain why you use the constructor/destructor mechanism, it's just stated that's the way it is. >> but I would tend to assume that >> state-local-storage is maintained throughout unless I explicitly >> reset it. > >Why? Ok, I think I figured something out since I wrote this. You're relying on nesting states to maint data. I think this needs to be explained in big neon signs. I don't think of exiting a state as destroying it, just that it's no longer "active" or whatever. Your model is like a window manager that closes a window every time a different window gets the focus and reopens the first window upon return. Of course, having lost all data imbetween. Maybe hoisting your data up to an enclosing space is a good idea, but I'm not used to working with nested states, so I don't really think that way. I'm willing to be convinced, although I'm suspicious. >> 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. > >I don't know what accept states are. UML doesn't have them. Now, I'm in no way an academic, so I'm relying on Wikipedia to tell me what's "normal." Since it's in line with my old textbook, I guess it's reasonably standard. Wikipedia tells me that there "acceptor" and "transducer" finite state machines. I've not worked with the "transducer" variety before; my text deals with them only in the exercises. At any rate, with an "acceptor" FSM, if after processing all input you are in an "accept" state, the input was legal, the operation was successful, whatever. Otherwise there was an error. Not that everybody will use them, but it would be nice to be able to mark states as accept-states and ask the machine if the current state is an accept-state. I would certainly recommend adding http://en.wikipedia.org/wiki/Finite_state_machine to your list of links about FSMs. Cheers- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

3 3

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