- Boost - lists.boost.org

Boost.Python broken in latest CVS
by Ralf W. Grosse-Kunstleve 24 Apr '06

24 Apr '06

Boost.Python doesn't compile anymore after a cvs update (a few minutes ago). The gcc 3.4.2 error is attached. I haven't done any digging yet. It looks like property_map.hpp has not changed recently. The error must be deeper down. I'd be grateful for any clues. Cheers, Ralf g++ -o boost/libs/python/src/object/inheritance.o -c -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-math -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.3_cci_x86_64/include/python2.4 /net/legless/scratch1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp In file included from /net/legless/scratch1/rwgk/hot/boost/boost/graph/graph_concepts.hpp:16, from /net/legless/scratch1/rwgk/hot/boost/boost/graph/breadth_first_search.hpp:21, from /net/legless/scratch1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp:7: /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp: In member function `void boost::LvaluePropertyMapConcept<PMap, Key>::constraints()': /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:243: error: expected nested-name-specifier before "require_same" /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:243: error: expected init-declarator before '<' token /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:243: error: expected `,' or `;' before '<' token /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp: In member function `void boost::Mutable_LvaluePropertyMapConcept<PMap, Key>::constraints()': /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:276: error: expected nested-name-specifier before "require_same" /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:276: error: expected init-declarator before '<' token /net/legless/scratch1/rwgk/hot/boost/boost/property_map.hpp:276: error: expected `,' or `;' before '<' token /net/legless/scratch1/rwgk/hot/boost/boost/concept_check.hpp: In function `void* boost::concept_checking::failed() [with Model = boost::IncidenceGraphConcept<boost::reverse_graph<boost::<unnamed>::cast_graph, const boost::<unnamed>::cast_graph&> >]': /net/legless/scratch1/rwgk/hot/boost/boost/concept_check.hpp:55: instantiated from `boost::concept_check<void (*)(boost::IncidenceGraphConcept<boost::reverse_graph<boost::<unnamed>::cast_graph, const boost::<unnamed>::cast_graph&> >)>' /net/legless/scratch1/rwgk/hot/boost/boost/concept_check.hpp:115: instantiated from `void boost::function_requires() [with Model = boost::IncidenceGraphConcept<boost::reverse_graph<boost::<unnamed>::cast_graph, const boost::<unnamed>::cast_graph&> >]' /net/legless/scratch1/rwgk/hot/boost/boost/graph/breadth_first_search.hpp:55: (... rest of the error omitted ...) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [boost] [Boost Review] Property Tree Library
by Trent Nelson 24 Apr '06

24 Apr '06

> - was the library's design flexible enough? If not, how would you > suggest it should be redesigned to broaden its scope of use? Very promising looking library. I think we've all had to roll some sort of config parser in the past, so there is a lot of potential for this to gain widespread adoption if its functionality exceeds home-grown versions. Two things that I had to roll into my config system: a) ability to include other files b) inline variable expansion, e.g. site.root = c:\dev site.home = ${site.root}\home The former is important for me as I'll often have a lot of common configuration files shared between products, but I don't want client code having to care about opening half a dozen conf files to find a particular setting. Instead, client code opens '<productname>.conf', and that file happens to 'include(...)' all the other config files necessary, The latter is very Java-.properties-esque, but I don't see any reason why it couldn't be used here. It's extremely flexible, especially if you leave evaluation of inline properties to the very last minute, such that you can consult the entire property tree for the corresponding value (rather than expanding the value as soon as you come into contact with it, restricting you to reference values that have been defined before your reference occurs). What are your thoughts on this being included in your library? Anyone else need to do this type of stuff, or would find this useful? Trent. -- http://www.onresolve.com

11 24

Re: [boost] build system (was Summer of Code 2006)
by Reece Dunn 24 Apr '06

24 Apr '06

Rene Rivera wrote: > David Abrahams wrote: > > Rune Sune <rune.sune(a)yahoo.com> writes: > >> --- David Abrahams <dave(a)boost-consulting.com> wrote: > > >> That is, it is unnecessary high from the end-users viewpoint. If the > >> newbie only had the usual interface towards the development project, > >> i.e. make- or dsp-files, he could focus on his key problems instead > >> of having to grasp all of BB. > > > > The user doesn't have to grasp all of BB. We just need improved > > getting started directions, which I am writing. Only a very small > > amount of grasping is required. > > > > If you want make- or dsp- files (note that dsp files are platform > > *and* compiler-specific), figure out a way to generate them from > > within Boost.Build, and we'll include them. > > Which is what the second SoC Boost.Build project I'm willing to mentor > is about. FWIW, I started a BBv2/Microsoft solution/project setting guide on the BBv2 Wiki (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_…, orhttp://tinyurl.com/fw5vv) This may be a useful starting point for anyone working on this project. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

A garbage collector for C++
by Brittany Foo 24 Apr '06

24 Apr '06

Hi,All! Here's an article you might be interested in: http://groups.google.com/group/comp.lang.c++/browse_thread/thread/95007ffdf… --Brittany --------------------------------- 想成为冯小刚、陈凯歌、张纪中三大导演的主角吗？

1 0

[ANN] New documentation style sheet
by Eric Niebler 24 Apr '06

24 Apr '06

The good folks at boost-docs have been working on improving the look-and-feel of Boost's documentation. This work is based largely on Rene Rivera's website redesign. The change went in to both HEAD and the release branch a few days ago. The biggest change is a smaller font. We've also improved readability by eliminating colored backgrounds, and improved the presentation of many elements of the Doxygen-generated reference sections. Please take a moment to have a look at the new docs: http://tinyurl.com/4b9gc. Compare to the style of the 1.33.1 docs here: http://tinyurl.com/rujfh. (I notice that there is some strangeness at the bottom of the libraries.html file the above link takes you to. There should be an alphabetized lists of libraries, and instead there is a fragment of the Boost.Concept_check documentation. That's clearly a bug, but it's not related to the style change.) Report any problems with the new style to boost-docs(a)lists.sourceforge.net. Thanks, -- Eric Niebler Boost Consulting www.boost-consulting.com

17 41

Re: [boost] boost::bimap [was Re: Do really property_tree andprogram_options overlap? ]
by JOAQUIN LOPEZ MU?Z 24 Apr '06

24 Apr '06

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Abril 23, 2006 4:16 pm Asunto: Re: [boost] boost::bimap [was Re: Do really property_tree andprogram_options overlap? ] > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > > I'm afraid I don't have the time to pursue this, as the > > current roadmap for core features of B.MI is taking > > all the spare time I can dedicate to the library. For this > > reason, I would love to see some volunteer jumping in > > who can develop this and other singular containers using > > B.MI (a cache container comes to mind) and then propose > > the results here either as a stand alone library of as > > part of B.MI --I'd prefer the former so as to keep the size > > of B.MI bounded. > > > > If there's such a volunteer I can provide her with some > > help/mentoring. I also wonder whether this is a task > > suitable to be proposed for Google Summer of Code. > > Great! Do you have time to add it to the Wiki page? ;-) I've just done so, please take a look at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2006 (bottom of the page) and please comment on whether you find it informative/appealing enough. I've only included those ideas related to B.MI (Thorsten has proposed additional items in other post) because it is the only task I feel confident enough to mentor. Who's the spokesperson for Boost at SOC? You, Dave? Have we already applied for mentorship? Also, I'm a little dissapointed by the low number of proposals gathered so far. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: [boost] [Boost Review] Property Tree Library
by Ames Andreas 24 Apr '06

24 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jorge Lodos > Sent: Friday, April 21, 2006 2:55 PM > Subject: Re: [boost] [Boost Review] Property Tree Library > > What I think PT must have that serialization library is not > meant to is: > > 1. The ability to load/save properties independently, not as a whole. > 2. A documented (for library extensibility) parser interface > allowing parser > developers to accomplish (1). > > At least 3 storages requiring (1) come to mind: windows > registry, ISA Server > storage and IIS metabase. > I would put these requisites as conditions for acceptance. And 3. The ondisk representation should be manually editable (i.e. by human beings) Given some posts I've seen, this seems not necessarily to be a primary goal of serialization while I'd count that a must-have for some config formats (e.g. XML representation should have a DTD, schema or something etc.). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com

4 3

Re: [boost] [Boost Review] Property Tree Library
by Tom Brinkman 24 Apr '06

24 Apr '06

I took another look at the library this morning and I agree with Jeff Garland that this library has potential. Howewver, it is hard to get my head around this library becouse it contains two very different things: 1) a recursive property-tree container and 2) six parsers to populate this container. I'm not a low-level container author so I cant speak to the merits pro/con of this implementation of a recursive property-tree. Nevertheless, I would like the review to focus on this, without regard to the parser grammers. I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time. If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.

6 7

[Boost Review] Property Tree Library
by Tom Brinkman 24 Apr '06

24 Apr '06

I'm voting NO on "property tree". I'm not persuaded that this library should be added to boost. Here is my review: * What is your evaluation of the design? Interesting. The "Property Tree" library attempts to meet a real need that I have had. The design appears to be appears to be adequate at first, but the more time I spent with working through the examples, the less I liked it. * What is your evaluation of the implementation? I think the implementation is pretty good. Overall, the author(s) have utilized modern c++ and established boost's "best-practices", including using boost::spirit for the "xml" parser. I'm not sure why he didn't use boost::spirit or boost::xpressive for the other parsers though. * What is your evaluation of the documentation? Inadequate, at least compared to the better documented boost libraries. More work is need here. * What is your evaluation of the potential usefulness of the library? Each individual part of the library is very useful. * Did you try to use the library? With what compiler? Did you have any problems? gcc. No problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I studied documentation and the source code for a couple of hours. There is variety of interesting stuff hidden in this library. I ran the examples and created a couple of my own. * Are you knowledgeable about the problem domain? Yes * Do you think the library should be accepted as a Boost library? No I'm voting NO on "property tree". I'm not persuaded that this library should be added to boost. It should be broken up into seperate boost::spirit or boost::xpressive grammers and submitted seperately. Grouping all this stuff under the "property tree" library is convenient, but not up to the standards of a boost library.

4 3

interest in an automatic dereferencing mechanism?
by sm garth 24 Apr '06

24 Apr '06

I'm working on a small library that performs compile-time, inline dereferencing that may prove useful for writing more generic algorithms. For example, a function that searches a sequence of iterators for an integer could be designed that would treat an int***[] just as if it were an int[] array. Is this something that might belong in the Boost framework? --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

2 1