- Boost - lists.boost.org

Re: [boost] [SoC] Specialized containers with Boost.MultiIndex
by JOAQUIN LOPEZ MU?Z 02 May '06

02 May '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Lunes, Mayo 1, 2006 6:59 am Asunto: Re: [boost] [SoC] Specialized containers with Boost.MultiIndex > I am finishing my application to the (M)ulti (I)ndex (S)pecialized > (C)ontainers (from now on MISC, do you like it?) for the SoC. > I am constructing a quickbook with a formal proposal, interface > design, project plan and personal information. I want to share it with > the list. I will really appreciate some feedback before sending the > application, specially from Joaquin. Can i post it here when it is > mature enough? Sure, I'm eager to read it. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

[fusion] How does is_pointer< Sequence > work?
by Andreas Huber 02 May '06

02 May '06

Hi Joel & Dan Going through the fusion quick start, I'm wondering how the expression ... for_each(filter_if<boost::is_pointer<Sequence> >(seq), print_xml()); ... could ever work? Shouldn't that rather read similar to ... for_each(filter_if<boost::is_pointer<_> >(seq), print_xml()); ... so that the _ placeholder can be replaced with the individual types in the sequence? Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

4 3

Re: [boost] [Boost Review] Do property_tree and program_options overlap?"
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Lunes, Mayo 1, 2006 6:43 pm Asunto: Re: [boost] [Boost Review] Do property_tree and program_options overlap?" > "bwood" <brass(a)mailvault.com> wrote in message > > I read those and was sympathetic to the terminology > > arguments you made. L?pez Mu?oz believes it is too late > > to make those sort of changes. I disagree with him on that, > > but it isn't clear enough yet to me what would be better > > terminology. I didn't follow the other matter you raised > > in those posts. > > My point was that we need another level of indirection an in-Order > indexing > (along with different orders for the same data). > Hello Gennadiy, It'd be great if you can resume that discussion of ours where we left: http://lists.boost.org/Archives/boost/2006/04/103441.php This last response I sent on Apr 20th, after some inactivity days, so maybe you just didn't notice it. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[SoC][Act]Concurrency library
by Matt Calabrese 01 May '06

01 May '06

For the past month or so I've been working on a concurrency library which brings active types, atomic types, and parallel loop constructs and algorithms to C++. I am familiar with some of the concurrency projects already underway, though I'm sure my library would be able to coexist. I plan on proposing through SoC sometime later this week. Over the past two days I've also begun writing up some documentation using QuickBook to give a general idea as to the design of the library. Though I do have a lot of features already implemented, there is still a very large amount of work to be done prior to completion. Some feedback before I make the formal proposal would be nice, and it'd also be great to see if anyone is interested. Keep in mind that the documentation is only a rough outing and so there are a few unconnected links, but I do include a brief introduction and some basic usage examples including code snippets. The library is reference to as Surge.Act as that is the namespace I use for my personal libraries, though it will of course be changed to Boost.Act if it were to be accepted. http://members.gamedev.net/Rivorus/surge/html/index.html For those familiar with the concept of futures and are confused as to why they are not mentioned, I will be adding all of that information to the rationale over the upcoming few days. I also apologize for not having better code examples. -- -Matt Calabrese

4 7

Re: [boost] [Boost Review] Do property_tree and program_options overlap?"
by bwood 01 May '06

01 May '06

Gennadiy Rozental wrote: >> You've been touting multi_index here as well. > >Not at all. If you follow my recent concern with multi_index design I >actually believe it's lacking. I read those and was sympathetic to the terminology arguments you made. L?pez Mu?oz believes it is too late to make those sort of changes. I disagree with him on that, but it isn't clear enough yet to me what would be better terminology. I didn't follow the other matter you raised in those posts. Please correct me if I'm wrong, but it seems B.MI's serialization forces you to receive a B.MI instance with the same number of indices as was sent. While on one level it is impressive that B.MI preserves the relative order of equal elements, it has a cost. If you have a B.MI with 3 indices in a server and only need one or two indices in a client, you have some work to do. In order to accomplish this I think you would have to receive a B.MI with the same indices as was sent and then write code that copies the contents of that B.MI to either a simpler B.MI or an STL container. Does the preservation of the relative order of elements matter more than this sort of flexibility? Brian www.webEbenezer.net

2 1

The fate of Boost.Logging ?
by Zrubavel Zodikovich 01 May '06

01 May '06

Hi, Are there any life signs coming from Boost.Logging library which was withdrawn from review last November ?

3 2

[filesystem] Some questions about string use
by Ion Gaztañaga 01 May '06

01 May '06

Hi to all, While revising a bit the boost::filesystem error/exception use for looking a model for interprocess library and after reading the N1934 "Filesystem Library Proposal for TR2 (Revision 2)" I'm a bit concerned about the heavy use of std::string/string_type in the library. The following functions return some kind of path as value type: // observers const string_type string() const; const string_type file_string() const; const string_type directory_string() const; const external_string_type external_file_string() const; const external_string_type external_directory_string() const; string_type root_name() const; string_type root_directory() const; basic_path root_path() const; basic_path relative_path() const; string_type leaf() const; basic_path branch_path() const; I know that syntactically this is nicer and we can have RVO: string_type str = path.string(); But when iterating through directories I find that that returning a temporary object that must allocate/copy/deallocate hurts my performance paranoia. Even with move semantics we have a an overhead: std::vector<std::path> paths; //fill with paths std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ std::path::string_type str = it->root_name();//temporary created str += "append some data"; std::cout << str; } Couldn't be better (although uglier) to take a reference to a string that will be filled? void fill_root_name(string_type &root_name) const; ... //////////////////////////////////////////////////////////////////// std::vector<std::path> paths; //fill with paths std::path::string_type root_name; root_name.reserve(PATH_LENGTH); std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ it->fill_root_name(root_name); str += "append some data"; std::cout << str; } This way we only allocate memory if we don't have enough place in our string. We can also reserve it beforehand to speed up code. Apart from this I see that path::iterator has a string member. dereference will return a reference to that member but an iterator is supposed to be a "lightweight" pointer-like abstraction, which is value-copied between functions. A string member, in my opinion, converts an iterator in a heavy class (that depends on the string length, but an small string optimization of 16 bytes is not going to help much). Now that filesystem is proposed for the standard I would like to ask boosters (and Beman, of course) if they find these performance concerns serious enough. Regards, Ion

10 29

Re: [boost] [SoC] Specialized containers with Boost.MultiIndex
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Sábado, Abril 29, 2006 4:54 am Asunto: Re: [boost] [SoC] Specialized containers with Boost.MultiIndex > Hi, all, especially Joaquin... > > I am planning to submit an application to SoC. I will love to make > realthe specialized containers you mention and try to include some > useful others. [...] > Is the list the place to talk this about of? Hello Matías, good to know a Spanish-speaking fellow, we're only a handful round here. The way SoC is organized, I think the procedure involves your sending an application thru SoC online tool starting May 1st. Yours, along with all other applications related to Boost, will then be routed by Google to Boost mentors, which will do then the selection and P2P discussion with applicants. In your case, since you're interested in the B.MI proposal, I understand it's gonna be I who will be evaluating your application. I don't really know what the application format and required information are (that depends on the SoC online tool, I guess) but I can tell you what I'd like to see in those submissions under my evaluation responsibility: * As much CV data as possible, academic performance, programming-related courses, etc. * Programming experience: University assignments, open source projects, freelance activities, whatever. If you can point to some code of yours, so much the better. * As per the concrete proposal, expand on the idea described on the Boost wiki along the following directions: * A detailed description of your activity, specially if you plan to add some extra bonuses to the original idea (some other specialized container, for instance). Do not make a wishlist, but rather provide a realistic statement of goals you feel confident to achieve within the time schedule imposed by SoC. * Environmental details: IDEs you'll be using, how you'll do the docs, etc. * A roadmap of the project, or some approximation to it. In general, take into account there can be other applicants for the same project, so not only must you be convincing the mentors you're fit for the project, you must make it it clear you're the fittest :) Good luck with your application, I'll be seeing you around during these weeks, come back here if you have tecnhical doubts while designing your application. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[soc] mentoring acceptance pending
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

Hello, I applied for mentorship for Boost yesterday, my application is listed as acceptance pending. Does approval depend on Google, or on the Booster who has taking on administrative responsibilities (looks like Jeff from his recent SoC activity)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [Boost Review] Do property_tree and program_optionsoverlap?"
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

Hello Brian, ----- Mensaje original ----- De: bwood <brass(a)mailvault.com> Fecha: Lunes, Mayo 1, 2006 0:45 am Asunto: Re: [boost] [Boost Review] Do property_tree and program_optionsoverlap?" [...] > Please correct me if I'm wrong, but it seems B.MI's > serialization forces you to receive a B.MI instance with the > same number of indices as was sent. Correct. In fact, you're required to use the very same type (i.e. container definition) on loading that you used on saving. > While on one level it is > impressive that B.MI preserves the relative order of equal > elements, it has a cost. If you have a B.MI with 3 indices > in a server and only need one or two indices in a > client, you have some work to do. In order to accomplish > this I think you would have to receive a B.MI with the same > indices as was sent and then write code that copies the > contents of that B.MI to either a simpler B.MI or an STL > container. Does the preservation of the relative order of > elements matter more than this sort of flexibility? Well, my approach to B.MI serialization looks to me a natural one, in which if one saved a T then it is a T that it must be loaded. AFAIK there's no scenario (excepting this discussion) where loading Qs from saved Ts is ever considered. Now, I'm not denying the potential usefulness of a serialization approach like you propose: it is just that I don't have any feedback about how B.MI serialization capabilities are being used to make an educated decision, and what I settled for has at least the benefit of consistency with other serialization implementations. In the meantime, it is easy to have less stringent serialization of B.MI containers by simply saving their elements according to its first index (similarly to what your own middleware service does), which can be implemented without built-in support from B.MI itself. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0