April 2006 - Boost - lists.preview.boost.org

Re: [boost] [SoC] Payment handling?
by Matt Doyle 26 Apr '06

26 Apr '06

Boost could refuse payment, or request that the payment be donated in Boost's name to some university. Just a thought. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, April 25, 2006 10:54 AM > To: boost(a)lists.boost.org > Subject: [boost] [SoC] Payment handling? > > I know this is a controversial question, but is one that > needs to be addressed I'm afraid... > > IIUC, the mentoring organization for Google's Summer of Code > 2006, Boost in our case, will get paid 500 bucks per mentored student. > How will that be administered? We have no precedent for > anything like that AFAICT > > Of course the basic idea would be that the _specific_ actual > mentor within boost gets the money, but will such an > individual be properly identifiied? > What if there is more than one per student? Or that will just > not be allowed in order to simplify this matter? > > How will Google address the recipient of such a payment? Via > boost-consulting and Dave does the final dispatch? > > > -- > > Fernando Cacciola > SciSoft > http://fcacciola.50webs.com/ > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by McAfee GroupShield {X3BTB534}

6 6

[property tree][review]
by John Maddock 26 Apr '06

26 Apr '06

OK, here's my review of the property tree library, actually quite a difficult review to write given all the hyperbole that's gone before. Still that's better than not having anyone interested ! :-) First of all I do not believe that the potential uses of this library are so similar to the serialisation or program options library that it should be excluded on those grounds. Secondly the library looks mature and usable enough that I would consider using it to manage program configuration. However, I do have problems with the conceptual scope of the library as described in the docs, more on this later but it's not the generic tree that the docs give the impression of it being on first view. I also have problems with the interface: that it's needlessly idiosyncratic in places. Not so much as to render it unusable at all, but I believe better can be done. OK down to nut's and bolts, first off the interface: 1) As others have commented, there are too many member functions IMO. I don't believe that changing to non-members offers any benefit in this case (and may actually be harmful due to ADL). Let's start with child access, I can't believe you're not using operator[] here. Yes I know it's cute, but it does work well for std::map. How about: mymap b; b[a][b][c] = 2; // assigns value 2 to node at a/b/c The way I'm figuring this would work is: * Accessing a child node with operator[] always succeeds but may point to a "ghost" node that doesn't actually exist. * Assignment to a node always succeeds, the node gets created if required. * Reading from a node throws if the node doesn't exist yet, or if the conversion can't be performed. * If you read a Boost::optional then it shouldn't throw, and no need for a special member function. I'm assuming that operator [] returns another "property map" by value BTW. You could have a single function that returns the node from a path of some kind as well, but *please* make the separator parameter the second argument with a default parameter. BTW, you can do much the same thing with the / operator (as has already been suggested), boost::filesystem makes this work rather well, and I guess I'd be just as happy with: property-map m = mymap / "he" / "she" / "it"; or int val = (mymap / "he" / "she" / "it").get<int>(); And finally if a property-tree is usable in boolean contexts you can detect whether a node actually exists already, or is a "ghost" node with nothing in it: tree-type a; // read in some data.... tree-type b = a["ha"]["ha"]; if(b) { // do something... } Reading data I'm inclined to suggest an unreasonably "cute" interface here: just provide a template conversion operator so that: int i = mymap["fee"]["far"]["thumb"]; does what you would expect and throws if the node/value doesn't exist or the conversion to int can't be done. boost::optional opt = mymap["fee"]["far"]["thumb"]; would never throw, and int i = mymap["fee"]["far"]["thumb"].get(3); returns 3 if there is no data. A step to far? Maybe, and I would be perfectly happy with a single get() function that did all the getting, again not throwing if the type being fetched is a boost::optional, and with a single argument overload version for data with default values. Setting data: You must know what's coming... what's wrong with operator = ? OK you may need a member function to deal with std::locale, but you know what, I bet 99.999% of programmers would be completely happy with just the default (or the locale could be a property of the property-tree as a whole - just add one imbue() member function and use it's locale everywhere). Of course if the argument to operator= is another property tree, then it copies the tree to that node rather than setting the data. The comments so far relate to any kind of hierarchical "tree like" associative storage, but now for the real guts of the issue for me (and I think why this library has attracted so much comment). What is this library trying to be? Yes, I've seen you're posts, and I believe I do understand what it's for :-) But that's not the point, the docs and actually the interface are at odds with what it's for. There is definitely a place in boost for a generic tree container. But this isn't one as you have said many times I believe, but to look at the interface it's kind of pretending to be one :-) So what is this library? I believe it's an interface to a hierarchical database, in fact I believe it need not be an in memory container at all. I certainly wouldn't try and read (and then write back!!!) the entire windows registry, or any large part of it, with this library. And yet, why shouldn't it be able to provide a view onto large data sets that form some kind of hierarchy? I'm thinking out loud here, but what would happen if your read/write functions were replaced by some kind of opaque data access API, that the tree used internally to access data from it's actual source. Possibly this is a step too far, but it may be food for thought anyway. I guess what I'm saying is either lets have: * A generic tree data structure with serialisation to various formats (not necessarily using boost.serialisation depending on practicalities). * A wrapper around external hierarchical databases, that doesn't necessarily load data into memory. Conclusions: I believe we need a library like this in Boost. And I believe this one is - in spite of what I've said above - perfectly usable. However, I believe a better interface is possible. So, I'm going to vote weakly "no": for the review manager that means this is not an "over-my-dead-body" vote, it's a "can-do-better on the interface, but let it through if there's a consensus for it". Whew. Regards, John Maddock.

8 9

[property_tree] Review
by Daniel Wesslén 25 Apr '06

25 Apr '06

> * Are you knowledgeable about the problem domain? Yes. Most of my applications use either a simple XML library or a PersistentValue template, mapping values to entries in a ini-like configuration file, these values are edited both by hand and through user action in the application - precisely the problem this library is intended to solve. My XML library has an interface very much like that of ptree and is used in the same way. I have been very interested in this library since Marcin first mentioned it in this list, and read through the documentation and part of the implementation back then. > * What is your evaluation of the design? The interface is "good enough" but could be better. I believe separating the path handling will be a big step. Some have suggested making functions nonmembers, but I don't see that as an improvement. Getting and setting the contents of the tree is /the/ use of the tree. If we don't use member functions for that, then what do we use them for at all? Regarding the parsers, the metadata for XML and Windows registry could be better handled. These formats both have two ways of storing data under a node, in property_tree represented by the <xmlattr> and \values subtrees. Couldn't these be handled in the same way? Both to make things (paths especially) more format-agnostic, and so that the next format with a similar facility doesn't invent a third way to handle the same thing. > * What is your evaluation of the implementation? I didn't look at it much this time. > * What is your evaluation of the documentation? Others have mentioned it needs work, especially in the rationale. Given the confusion at the start of the review period this is clearly the case. > * What is your evaluation of the potential usefulness > of the library? Very useful for those of us who prefer to store data this way. I use the one or both of the two previously mentioned components in essentially all my nontrivial applications. > * Did you try to use the library? With what compiler? > Did you have any problems? I replaced a home-brewn name-value map template used for storing application settings. Installing the library and glancing at the documentation included, the whole thing took 15-20 minutes. A significant portion of that time was spent renaming the parameters. There were no problems. I used Visual C++ 7.1. The original class was non-hierarchical and stored the values in a ini-like format. With some tweaks to the parameter names and a switch to ptree's JSON parser, the conceptual hierarchy was made explicit, making some (unfrequent but necessary) hand-editing very slick compared to the previous format where it was trivial but tedious. > * How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? A glance of the documentation prior to the test mentioned above, followed by a quick reading after. I have read the documentation of a previous version in-depth, and then made a quick reading of the implementation (which needed changes but seems to have matured since then.) > - was the library suitable for your daily xml-tasks? If not, what was > missing? No. I tend to use namespaces and XInclude, which the supplied XML parser does not support. > - was the library's performance good enough? If not, can you suggest > improvements? I didn't use the library for anything performance-critical. > - was the library's design flexible enough? If not, how would you > suggest it should be redesigned to broaden its scope of use? It was "flexible enough", but I would prefer if it were more flexible. In particular, I definitely think path handling should be separated out from the accessor functions, but I believe this is already in progress(?) That way those of us who prefer more XPath-like path handling could implement that as a new path-parser. I find Ryan Gallagher's recent suggestion about separating path handling into its own concept very interesting but am unsure if it may be complicating things too much. It would certainly make accessing the tree very flexible, something I can only consider a good thing. The library implements a single container type, with parsers for many different formats. Some of these formats have conflicting natural (or perhaps "traditional") ways of referring to the contained data. Allowing users to refer to the data in this natural way is important as I expect it will be far more common to use subsets of the library as "a simple XML parser" / "a JSON parser" / "a INI parser", etc. than to be format-agnositc (especially since some formats store metadata in the tree, which will not make sense in other formats.) > 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. > This is a hard question. The library is good enough, and I would like to see it in Boost. It seems to me it can become significantly better though. This library has generated a very active discussion, and suggestions are still coming in for how to make it better. How many / how big changes are allowed to a library once it has been accepted? I wouldn't want potential improvements to be ruled out on the grounds that it has been accepted in its current form. Eventually: Yes. At the moment: I leave it to the review manager to decide if the library will need a second review before acceptance, but if I have to say something it would be a "weak no." I will be using this library even if it gets rejected. -- Daniel Wesslén

2 1

Re: [boost] [SoC] Payment handling?
by Matt Doyle 25 Apr '06

25 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, April 25, 2006 11:52 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [SoC] Payment handling? > > Thorsten Ottosen wrote: > > Felipe Magno de Almeida wrote: > >> On 4/25/06, Fernando Cacciola > <fernando_cacciola(a)hotmail.com> wrote: > >> > >>> Matt Doyle wrote: > >>> > >>>> Boost could refuse payment, > >>> > >>> Donating seems better to me. > >> > >> > >> IMO, it should go to the mentor. As is the intent of google. > > > > Agreed. The mentor puts some extra effort into this and the > money is > > well-deserved. > > > Me too.. this is what I initally said. > I was comparing donating to letting Google keep it. > > Still, deciding what's the best to do is half the issue here. > How to do is is also important, specially because of the > responsability put on those willing to administer the payments. > As I said, unless I got it wrong, Google will pay "Boost", > not each individual mentor. > > Fernando Cacciola I'm not disagreeing that the mentor deserves it. What I was thinking about was more, how could Google possibly pay Boost? Boost is not an entity. The only other option I can see is to name an individual (or an entity) to accept it for Boost. Or, just donate it... > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by McAfee GroupShield {X3BTB534}

1 0

boost::any operations
by Jorge Lodos 25 Apr '06

25 Apr '06

Hi The following is a partial solution for boost::any operations, including operator==. Adding the operator ValueType& as follows: template <typename ValueType> operator typename ValueType&() const { if (empty() || type() != typeid(ValueType)) boost::throw_exception(bad_any_cast()); return static_cast<any::holder<ValueType> *>(content)->held; } This is different from any_cast in that it returns a reference, instead of a copy. Note also that this will never be used implicitely, you have to call operator ValueType&() explicitely. Operations with values can be added as: template <typename ValueType> bool operator==(const ValueType& rhs) { return rhs == this->operator ValueType&(); } Or template <typename ValueType> any& operator+=(const ValueType& rhs) { this->operator ValueType&() += rhs; return *this; } All operators could be added this way. While this won't break existing code and allows for any object operations, it still has the following drawbacks: 1. No type conversion is performed, (due to template argument deduction). Thus a float can be compared or added to another float, but not to a long, for instance. 2. No operations between any objects can be performed, only between an any and a concret object. 3. The order matters. 0 == any(0) won't compile, while any(0) == 0 will do. 4. It is easy to forget that all operations may throw. If you have any idea of how to overcome (or improve) any of these please let me know. By the way, I'm testing with VC 8.0 and the program compiles and behaves identically calling operator ValueType&() or operator ValueType() with the above declaration. Is that correct? Cheers Jorge

3 6

[SoC] Payment handling?
by Fernando Cacciola 25 Apr '06

25 Apr '06

I know this is a controversial question, but is one that needs to be addressed I'm afraid... IIUC, the mentoring organization for Google's Summer of Code 2006, Boost in our case, will get paid 500 bucks per mentored student. How will that be administered? We have no precedent for anything like that AFAICT Of course the basic idea would be that the _specific_ actual mentor within boost gets the money, but will such an individual be properly identifiied? What if there is more than one per student? Or that will just not be allowed in order to simplify this matter? How will Google address the recipient of such a payment? Via boost-consulting and Dave does the final dispatch? -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/

1 0

[math] RFC: comparison function objects
by Alberto Ganesh Barbati 25 Apr '06

25 Apr '06

Hi Everybody, in a discussion on comp.std.c++ it was proposed to include into boost some facility to "fuzzy" or, in other words, to "properly" compare floating point numbers. Something like this, for example: template <typename T> struct compare_absolute_error : std::binary_function<T, T, bool> { T eps; compare_absolute_error(T eps_) : eps(eps_) {} bool operator()(T x, T y) const { return abs(x - y) < eps; } }; This kind of operators occurs frequently in algorithms and are sometimes error-prone to write, so having a ready-made and well tested component can certainly be an advantage. Of course, we could (and should) provide a bunch of different comparison algorithms: absolute and relative in the first place, but there may be others. I believe it might be a little but useful addition to the math library. Main questions are: 1) Is there interest for this? 2) What are the comparison algorithms to include? Thanks for your comments. Ganesh

6 19

[program_options] add options programmatically
by Chris Weed 25 Apr '06

25 Apr '06

Hi, Is it possible to add options to the variables_map, programmatically, instead of using the 3 parsers? I don't see a way to do this in the documentation. Chris

1 0

[Boost-bugs] [ boost-Bugs-1476219 ] iterator/zip_iterator.hpp - multiple definition tuple_equal
by SourceForge.net 25 Apr '06

25 Apr '06

Bugs item #1476219, was opened at 2006-04-25 11:08 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=1476219&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: iterator Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Polivka (bpolivka) Assigned to: David Abrahams (david_abrahams) Summary: iterator/zip_iterator.hpp - multiple definition tuple_equal Initial Comment: Hi, In iterator/zip_iterator.hpp: bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } is not declared as inline, leading to multiple definition link errors if zip_iterator.hpp is included in more than one translation unit. Thanks, Brett Polivka ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1476219&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[typeof] problem with PCH in VC7.1, 8.0
by Arkadiy Vertleyb 25 Apr '06

25 Apr '06

Fixed (by using different kind of unnamed namespace) in both CVS HEAD and RC_1_34_0. Regards, Arkadiy

1 0