- Boost - lists.boost.org

[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

New Code Of Summer project
by Carlo Wood 01 May '06

01 May '06

Hi, I just subbed. Before, I was only on boost-users, where there was a single mail about Code of Summer 2006. That mail said that if you had a new idea for a project, then you could add it to the wiki. I've added it to the wiki now, but I suppose it has to be approved too more or less. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… -- Carlo Wood <carlo(a)alinoe.com>

3 5

Including thread.hpp causes coredump on AIX
by Chris Grayson 30 Apr '06

30 Apr '06

#include <iostream> #include "Class1.h" #include <boost/thread/thread.hpp> main () { std::cout << "starting main()" << std::endl; Class1 c; c.noop(); std::cout << "exiting main() normally" << std::endl; } #include <iostream> #include "Class1.h" #include <boost/thread/thread.hpp> void Class1::noop () { std::cout << "entering Class1::noop()" << std::endl; try { std::cout << "..throwing exception" << std::endl; throw (2.1); } catch (...) { std::cout << "..caught exception in Class1.noop()" << std::endl; } std::cout << "..leaving Class1.noop()" << std::endl; return; } class Class1 { public: void noop(); };

2 2

[Boost Review] Property Tree Library
by Thorsten Ottosen 30 Apr '06

30 Apr '06

Dear All, I have the great pleasure to announce that the formal boost-review of Marcin Kalicinski Property Tree Library begins now (the 18th of April) and runs through the 27th of April. Introduction ------------ This fairly high-level library consists of the following facilities: 1. a generic recursive property-tree data-structure 2. generic conversions to/from this data-structure from/to a. xml-files b. ini-flies c. json-files d. windows registry files As an example of how powerful the library is, consider this tutorial: - http://kaalus.atspace.com/ptree/doc/index.html#five_minute_tutorial The library may be downloaded from - the boost file vault http://boost-consulting.com/vault/ (property_tree_rev5.zip) - tinyurl: http://tinyurl.com/fkt7r - boost sandbox: http://www.boost.org/more/mailing_lists.htm#sandbox (look in boost/property_tree and libs/property_tree) The documentation may be viewed online at - http://kaalus.atspace.com/ptree/doc/index.html If your find the above interesting, please consider submitting a review to the boost developer mailing list: - http://www.boost.org/more/mailing_lists.htm#main You might end up using several hours on a review, but the end result could be a superb library that will save you weeks of work. Notes for reviewers ------------------- When writing your review, you may wish to consider the following questions: * 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. In particular, consider if you can answer the following questions: - was the library suitable for your daily xml-tasks? If not, what was missing? - was the library's performance good enough? If not, can you suggest improvements? - was the library's design flexible enough? If not, how would you suggest it should be redesigned to broaden its scope of use? best regards Thorsten Ottosen, Review Manager

29 208

Re: [boost] [Boost-users] portable uuid generator
by Tim Blechmann 30 Apr '06

30 Apr '06

hi andy, to use your guid library with gcc-4.1, i had to change it according to the attached patch ... cheers ... tim -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

1 0

[Boost Review] Property tree review
by Jeff Hardy 30 Apr '06

30 Apr '06

I'm going to vote YES on inclusion of the Property Tree library. It has its faults, but I think it's useful enough right now to be part of Boost. * What is your evaluation of the design? The most valuable parts of the library are the parsers and the path functions. I agree with what others have mentioned: the paths should be seperate from the tree. I would be using it to parse various file formats into a tree, and then use my own path language on top of that. For me, then, the parsers are the most important part of this library. Having a (mostly) common structure is very nice. The reading and writing interface is as simple as possible; navigating the tree is also resonably simple. * What is your evaluation of the implementation? I didn't inspect the implementation closely, but I did notice some things during use. I don't like how XML attributes are stored. It should at least be an option to treat <x y="1" z="2" /> and <x> <y>1</y> <z>2</z> </x> as the same structure, without the "<xmlattrs>" node. If there's a confilict between an attribute name and a child element name, then reading/writing should fail. The ability to preserve comments in a file would be very nice. * What is your evaluation of the documentation? A bit sparse. The reference was mostly what I used, but more examples in the docs is always a good idea. A better "mission statement" about what the library is for would help as well; right now, it's not very clear what the author thinks the library is trying to do. The tree descriptions used in the descriptions of the parsers are not very clear; specifying what is in child.second.data() and what is in child.first should be explicit. An example of directly manipulating the tree (without using get()/put()) would be useful as well. * What is your evaluation of the potential usefulness of the library? As a general XML parser, it's not very useful (no namespaces, etc.); as a generic tree, it's not very useful (not general enough). As a utility for parsing various file formats into similar data structures (and writing them back), it's useful. Loading program configuration seems to be the primary goal, and it does that well enough. Trying to get the library to do other things might be stretching it too far. * Did you try to use the library? With what compiler? Did you have any problems? Yes, with MSVC 8. I had no problems beyond my own reading incomprehension. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I adapted the backend of my own configuration system (which previously used TinyXML) to use property trees. However, I didn't use the get*() functions, since I have my own path system already built. * Are you knowledgeable about the problem domain? Resonably. I plan on using the library whether it is accepted into Boost or not, and I'd like to thank Marcin for his work. -Jeff Hardy

8 14

[SoC] new bcp
by Felipe Magno de Almeida 30 Apr '06

30 Apr '06

Hi, I would like to propose creating a new bcp tool. Using the BGL and Wave for handling better the dependencies. Would it have any chance of getting accepted? How much people need this? Thanks, -- Felipe Magno de Almeida

6 6