- Boost - lists.boost.org

bgl subgraphs
by Brian Makin 13 Oct '06

13 Oct '06

With respect to boost graph library. Is anyone using subgraphs? What are they being used for? Is there functionality which is needed wrt subgraphs? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Boost super_string
by shams 13 Oct '06

13 Oct '06

Hi, Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff. Has there been any interest in this as-of lately? Is there possibilility that it will be get included in Boost? It sure will attract the attention of c++ novices. Also Jeff: Are most of the interfaces for string_algo implemented in your super_string library from RC_1.34? Thanks Shams

6 18

[multi_index] Relationship Table
by Joe Gottman 13 Oct '06

13 Oct '06

One pattern that seems to come up pretty often is the relationship table. Suppose I have 2 classes, Employee and Skill. An Employee can have any number of Skills, and a Skill can be possessed by any number of Employees. But an Employee can have a given Skill only once. The user would need to be able to search for which Skills a given Employee has, and which Employees have a given Skill. What is the best way of using a multi_index_container to model this use case? Suppose, in addition, that every Employee who has a Skill has a numerical rating at that Skill. How would you do a multi_index_container in that case? Joe Gottman

2 1

[type-traits] much dead code in integral_constant.hpp
by Ronald Garcia 13 Oct '06

13 Oct '06

Howdy, A large amount of code in boost/type_traits/integral_constant.hpp appears to be #if'ed out. Can that code be safely removed from the file or is it a work in progress? Thanks, ron

3 2

Re: [boost] Geometry/Vector Lib
by brangdon＠cix.compulink.co.uk 13 Oct '06

13 Oct '06

In-Reply-To: <4528E0F8.1070503(a)yar.nu> macke(a)yar.nu (Marcus Lindblom) wrote (abridged): > The point I'm trying to make is that there is as almost much opinion on > member-access on vectors as there are on code indent size. So, whatever > we make ought to support everything, if we want it to be acceptable to > a large audience? And I was making the more-or-less opposite point, that the interface doesn't matter too much as long as it doesn't expose the representation. The core question is whether encapsulation matters for a class like this. With emphasis on the "like this" - I'm sure we all love encapsulation normally, and the issue is whether this is one of the rare exceptions. If we support the v.x syntax we can't store vectors in polar representation, or add checks or instrumentation to accesses, or have values that are calculated on demand, or use any number of other techniques which rely on information hiding. Does it matter in this case? It's ultimately a judgement call, and I don't think my own opinion should carry any special weight, so I will try to stop posting about it after this and let you get on with it. -- Dave Harris, Nottingham, UK.

2 1

GIL Review - Extended to October 25
by Tom Brinkman 13 Oct '06

13 Oct '06

As review manager of the GIL library, I believe that there is sufficient interest to warrent extending the formal review period by another 10 days, until October 25. Of course, I will accept reviews after that date as well. GIL is an Adobe sponsered graphics library and part of the ASL (Adobe Source LIbraries). Its being developed by some very talented graphics developers at Adobe and clearly deserves much more attention than it has received so far. Please, please get your reviews in. I need alot more feedback. Tom Brinkman Review Manager

1 0

Re: [boost] [mpl] BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS Problems
by Jared McIntyre 13 Oct '06

13 Oct '06

I just realized I misunderstood the documentation. Assuming Visual Studio can support more than 50 parameters, how would one go about building out the source so that they could use an mpl::map with more than 50 parameters? I actually have a needs for several hundred, but have a feeling I will be splitting those up into multiple maps (or some other technique). Even with splitting it up, I'd like to try to increase the number in each if possible. Jared >I have an extremely large mpl::map who's size doesn't fit in the pre >defined map files. I'm trying to get mpl to >process the map without using the preprocessed file. I've added a >BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS define to the >atdafx and a BOOST_MPL_LIMIT_MAP_SIZE where map is defined. It >continues to want to use the file associated with >BOOST_MPL_LIMIT_MAP_SIZE. BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS is >definitely being defined before any mpl header >files are loaded. Any thoughts? This is Boost 1.33.0 if that makes >any difference. The attempt to load the file is on >line 36 of map.hpp. > >Jared

1 0

[range/iterator] operator[] forwarding
by Shunsuke Sogame 12 Oct '06

12 Oct '06

Hi gurus, under RC_1_34, #include <boost/range.hpp> #include <boost/iterator/counting_iterator.hpp> int main() { boost::make_iterator_range( boost::make_counting_iterator(0), boost::make_counting_iterator(5) )[2]; } VC++7.1 and GCC3.4 says a warning something like "returning address of local variable or temporary". counting_iterator is implemented by iterator_facade, whose operator[] returns *value*. In fact, the result type of iterator_facade's operator[] seems unspecified. Is it possible to do forwarding of iterator's operator[], which is tried by iterator_range? -- Shunsuke Sogame

4 9

GIL Review: Use of concept syntax for documentation
by Lubomir Bourdev 12 Oct '06

12 Oct '06

GIL's way of documenting concepts has been a hot topic for discussion, so let me share our thoughts on it. Our current documentation is in this form because we believe it is more intuitive and we hope some related version of it will make it into the standard. As part of ASL we have no requirement to use the old style. Given the size of the library, we feel it will be too much wasted work to change the design just for the boost review, in case the library does not make it into boost. That said, if there is a strong consensus that as a condition for acceptance GIL must switch to the old-style concept documentation, we will change it. We prefer the opposite - to update the GIL documentation to comply with the very latest draft of the proposal. Lubomir

2 1

GIL - Generic Image Library Review - Begins October 5
by Tom Brinkman 12 Oct '06

12 Oct '06

With the last finishing touches completed, i'm excited to be able to announce that the review of Generic Image Library (GIL) will begin October 5, in three days. Please download the library at: http://opensource.adobe.com/gil.<http://opensource.adobe.com/gil> This site has a great deal of background information about the library, so be shur to check it out. A quick summary follows: The Generic Image Library (GIL) is a C++ library that abstracts the image representation from operations on images. It allows for writing the image processing algorithm once and having it work for images in any color space, channel depth and pixel organization, or even synthetic images, without compromising the performance. GIL has an extension mechanism that allows for adding extra functionality. Two extensions are currently provided – one for image I/O and one for handling images whose properties are specified at run-time. A 55 minute Breeze presentation describing is available at: http://opensource.adobe.com/gil/presentation/index.htm A tutorial is available at: http://opensource.adobe.com/gil/gil_tutorial.pdf A design guide is availage at: http://opensource.adobe.com/gil/gil_design_guide.pdf Tom Brinkman Review Manager

13 54