December 2010 - Boost - lists.preview.boost.org

[Bug Sprint] Final report for the (late 2010) Bug Sprint
by Marshall Clow 23 Dec '10

23 Dec '10

Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ] There were 25 changes to the trac database yesterday - not counting all the spam. [ I'd like to say "25 tickets were changed", but some tickets were changed more than once. ] In this sprint, we looked at (and modified) a couple hundred tickets, resulting in a net drop of 16 tickets from the start of the Bug Sprint. General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 December 5: 934 (ouch, again!) December 5: 930 Activities on the trac system yesterday: New tickets 4 Tickets closed 5 Tickets reopened 1 Tickets changed 15 [ Some other changes happened after midnight; hence the difference between the deltas and the total # of tickets ] marshall 8 rleigh@ 3 jwellico 2 andysem 2 altsysreq@ 2 --others-- 8 So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)? -- Marshall

16 25

svn.boost.org is down
by Mateusz Loskot 23 Dec '10

23 Dec '10

Hi, The svn.boost.org (http and https) is not responding. I confirmed it with a few people on the IRC channel. Could anyone resurrect it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Proposed changes to page running_regression_tests.html
by Jim Bell 22 Dec '10

22 Dec '10

I propose these changes to boost's web-page <http://www.boost.org/development/running_regression_tests.html> I've attached the full file. My change is at the beginning: how to run regression tests locally. The previous contents follow, under "Running Boost's Automated Regression and Reporting." Comments welcome. Who would actually make the change?

3 2

[PATCH 2/2] Fixed warning: use of logical && with constant operand; switch to bitwise & or remove constant [-Wconstant-logical-operand]
by Vasyl' 21 Dec '10

21 Dec '10

--- boost/uuid/name_generator.hpp | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)

2 1

[OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
by Dean Michael Berris 21 Dec '10

21 Dec '10

On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot <mateusz(a)loskot.net> wrote: > Hi, > I will only refer to complain on the slow SOCI release schedule. > So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help > to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it. I'm not sure but is CppDB a fork of SOCI? If that was the case, then the original copyright holders of the original code would have to be consulted if the fork was going to be released under a different license. IANAL, but there may be some issues with forking a BSL-licensed project to be an LGPL project. > > This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about > software here makes me asking, what's next? Boost libraries forked? > Well... actually... forks are a valid means of diversification in FOSS projects. Whether it's successful in what the fork is supposed to achieve is a different issue altogether. About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained". The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;) > Anyways, I'm just disappointed how much FOSS is ego-driven > where it should mean collaboration. Just pity. > +1 in general. -- Dean Michael Berris deanberris.com

11 34

Boost Users Map
by Dean Michael Berris 21 Dec '10

21 Dec '10

Good day everyone! Thanks to the great idea that some people on the #boost IRC channel in FreeNode proposed, (thanks to heller, mjcaisse, for the prodding and the ideas) I've started a Google Map to show where in the world Boost Users are -- please feel free to add yourself and your location and maybe connect with other Boost Users in your area! You can add yourself to the map from here: http://goo.gl/RbmNq -- it might require that you log in using your Google account for you to add your location to the list. Please add yourself to the map and be counted -- show how well Boost is used around the world! Thanks in advance and I definitely look forward to seeing users of Boost around the world at least in the map! -- Dean Michael Berris about.me/deanberris

1 0

Interest in a list comprehension library?
by Brent Spillner 21 Dec '10

21 Dec '10

I uploaded sample code to the Vault (in the "Miscellaneous/" directory) that provides a concise notation for list comprehensions. The comprehensions are evaluated lazily and can be used to populate a std::list, vector, or deque, appended to the same, inserted after a given iterator, or interpreted as a boost::range, including compatibility with BOOST_FOREACH. Containers, iterator-defined ranges, or nullary function objects can be used as generators, and arbitrary function objects can be used to specify filter conditions. For example, the Pythagorean Triples example from http://rosettacode.org/wiki/List_comprehensions can be coded as std::vector< boost::tuple<int,int,int> > triples =_(x, y, z)[x <<= range(1, n), y <<= range(x, n), z <<= range(y, n), x*x + y*y == z*z]; , and the (toy) prime number generator at http://www.secnetix.de/olli/Python/list_comprehensions.hawk can be implemented as std::vector<int> nonprimes = _(j)[i <<= range(2, sqrt_max), j <<= range(2 * i, sqrt_max * sqrt_max, i)]; boost::function<std::vector<int>::const_iterator ()> is_composite = bind(std::find<std::vector<int>::const_iterator, int>, nonprimes.begin(), nonprimes.end(), ref(p)); BOOST_FOREACH(int x, (_(p)[p <<= range(2, sqrt_max * sqrt_max), call(is_composite) == nonprimes.end()])) { std::cout << x << std::endl; } (Note the use of call() to represent delayed invocation, and the extra () around the comprehension when used with BOOST_FOREACH.) I've tested this so far with GCC 4.4.4, GCC 4.5.2, and Clang 2.9, using Boost 1.42 and 1.45, and with and without -std=c++0x. Reports of success/failure with other environments are most welcome. The code is still in a prototype stage, so I'm more than happy to take design suggestions and would love to hear about use cases I've overlooked. If there's sufficient interest I will work on getting it to production quality and writing some real documentation. I apologize in advance for wasting everybody's time if something like this already exists in Phoenix; I'm not too familiar with it but I skimmed the docs and didn't see anything. Enjoy, Brent

5 8

Interval Trees & ICL
by Bruce Adams 20 Dec '10

20 Dec '10

Hi, I have been working on a problem for which a suitable solution is an efficient container of intervals. The two main candidates would be something like to boost::split_interval_set or a centred interval tree (along the lines of http://en.wikipedia.org/wiki/Interval_tree) It seems to me that the characteristics of an interval tree differ sufficiently from the containers defined in ICL that they might make a useful addition. For the case where there is a potentially large number of overlapping intervals a split_interval_set will be less efficient than an interval tree. In the worst case intervals would be split down to unit size. Searching the archives I see there was some discussion of interval trees in the context of ICL but the additional of an interval tree container did not, as far as I can tell, come up (perhaps because it should first appear in a boost release before there is any consideration of adding to it?). I have a few questions: 1. Is there a specific name for the data structures provided by the ICL? I have searched the literature and cannot find any mention of sets that split or combine intervals this way. It is either a genuinely novel concept, which I find difficult to believe, or I haven't used the correct search terms (interval, extent or segment). Either way, I would like to update wikipedia appropriately to help other lost souls. 2. Are there any compelling reasons why interval trees are less useful than the containers provided by the ICL? 3. Perhaps based on the answer to 2. Would interval trees be a sensible addition to the ICL? 4. Are there any other classes of interval container worthy of mention? Regards, Bruce.

6 19

1.46 closing for new libraries tomorrow
by Vladimir Prus 20 Dec '10

20 Dec '10

Our calendar at http://www.boost.org/development/index.html say that 1.46 will be closed for new libraries tomorrow. I believe we have two libraries that were accepted, but not released. On those, Interval Containers library appears to have been merged to release branch already. The other one, Ratio, does not appear to be present in trunk, and therefore is not likely to be included in 1.46. The next deadline is on Jan 10, when the trunk will be closed for major changes. Thanks, Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

5 4

how to distinguish between const char* and const char[N]
by Jochen Wilhelmy 20 Dec '10

20 Dec '10

Hi! is there a (possibly boost powered) way of distinguishing between const char* and const char[N]? e.g. const char* foo = "foo"; bar(foo); bar("foo"); The second call to bar should extract the length at compile time, e.g. template <size_t length> void bar(const char (&data)[length]) {...} The problem is that in the presence of the first variant (void bar(const char*)) the second variant does not get called. -Jochen

4 4

[quickbook] error with links when building documentation
by Christian Henning 19 Dec '10

19 Dec '10

Hi there, I keep getting these strange errors when building my documentation: Error: no ID for constraint linkend: _Tutorial_. Error: no ID for constraint linkend: _extenting_io_. Error: no ID for constraint linkend: _Supported_Formats_. Error: no ID for constraint linkend: _Supported_Formats_. The file I'm trying to build is here: http://gil-contributions.googlecode.com/svn/trunk/gil_2/libs/gil/io_new/doc… plus the jam file http://gil-contributions.googlecode.com/svn/trunk/gil_2/libs/gil/io_new/doc… I read somewhere that I need to use two-pass processing but I don't understand what means. Any help is very welcome. Thanks, Christian

3 14

[quickbook] list rendering
by Cromwell Enage 19 Dec '10

19 Dec '10

Hi, all! I notice that Quickbook converts paragraph-level lists into <programlist> elements in Docbook rather than the <itemizedlist> and <orderedlist> elements that I was expecting. This causes my text to be rendered a bit like code--preformatted with some syntax highlighting. Also, Quickbook list markup nested within table entries are treated as ordinary text. I know I could escape Boostbook markup instead, but my lists contain Quickbook links that I would rather not figure out how to hand-code. Otherwise, thanks for a great documentation tool! Cromwell D. Enage

2 1

Boost.Locale (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
by Dean Michael Berris 19 Dec '10

19 Dec '10

On Tue, Dec 14, 2010 at 10:48 PM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > On 12/14/2010 9:03 AM, Artyom wrote: >> >> Accidentally (or not) there is a Boost.Locale library that I had submitted >> for a >> formal >> review is stuck in queue waiting for the formal review. >> >> It supports charset conversions and much more of Unicode handling. >> >> And accidentally (or not) it recommends using UTF-8 anywhere >> and not to use wide strings... > > That's fine as long as you realize that it may not be the most common usage > of Unicode for everybody ( such as in Windows programming ). > +1 -- if there was a library that did easy conversion from std::wstring (usually the default in Windows now) to proper UTF-8 encoded std::string in Boost that would be *awesome*. I can totally use that library in cpp-netlib too. ;) I'm not sure, but maybe Spirit.Karma can handle something like that? I haven't checked yet but a string conversion/encoding utility like that would be very much appreciated IMO. > I am looking forward to the review of Boost.Locale. +1 -- Dean Michael Berris deanberris.com

12 36

Trusting Subversion, reducing server load
by Jim Bell 18 Dec '10

18 Dec '10

Doing an SVN update instead of a full check-out would reduce server bandwidth considerably (and reduce test cycle time). I wonder if Ticket #4916 <https://svn.boost.org/trac/boost/ticket/4916> has something to do with the decision (not) to trust Subversion. '--force-update' doesn't wipe out intermediate files as regression.py clearly intends it, making it act like '--incremental'. I think someone should fix #4916, make '--force-update' the default, and see what that does to server load. Then, bring back source browsing if we can.

2 1

[Bug Sprint] The Boost bug sprint has begun!
by Marshall Clow 18 Dec '10

18 Dec '10

As of 7 AM PDT, there are 939 open bugs. [ I see that Vicente and Mattias have already started - that's great! ] General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow If you're looking for some way to contribute, I would suggest looking at the oldest active tickets, <https://svn.boost.org/trac/boost/report/1?sort=created&asc=1&page=1> and see if they are still valid. There are about 90 active tickets from 2005-2007. [ Many of them are feature requests, but there are bugs there too. ] Here are a couple of summary tables to give you an idea of where we are: https://svn.boost.org/trac/boost/report/20 Type Tickets Bugs 549 Feature Requests 250 Patches 99 Tasks 28 Support Requests 13 https://svn.boost.org/trac/boost/report/21 Milestone Tickets To Be Determined 352 Boost 1.43.0 102 Boost 1.44.0 98 Boost 1.42.0 75 Boost 1.36.0 50 Boost 1.40.0 48 Boost 1.39.0 44 <blank> 41 Boost 1.41.0 40 Boost 1.38.0 30 Boost 1.37.0 25 Boost-1.45.0 15 Boost-1.46.0 11 Website 1.X 4 Boost-1.47.0 1 Boost.Jam 3.1.18 1 Boost.Jam 4.0.0 1 https://svn.boost.org/trac/boost/report/19 Component Tickets date_time 61 thread 50 Python 48 filesystem 42 build 40 asio 38 mpl 38 smart_ptr 37 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall

6 12

reducing file size after I am done with an mmap
by Clark Sims 18 Dec '10

18 Dec '10

Is there some way to downsize a file? More specifically, if I open a filebuff: f( "foo.txt",std::ios_base::in|std::ios_base::out|std::ios_base::trunc|std::ios_base::binary); then space forward, write a character, f.pubseekoff( 10000, std::ios_base::beg); write a character, f.sputc(0); f.pubsync(); Is there someway for me to "unwrite the character", and reduce the file size? I am in a situation where I am allocating big files for mmap's, and then when I am done, I have a lot of unused space which I would like to release.

2 1

Formal Review of IO and Toolbox extensions to Boost.GIL ends TOMORROW
by Mateusz Loskot 18 Dec '10

18 Dec '10

Folks, According to the extended schedule and to my UTC-based watch, we have literally two days to complete the review. Best regards, Mateusz On 09/12/10 22:26, Mateusz Loskot wrote: > Dear All, > > Today, I announced we are close to the end of the review: > > http://lists.boost.org/boost-announce/2010/12/0275.php > > Later on, Christian asked for extension of the review. > The Review Wizards agreed and suggested to extend the review until > > Friday, December 17th, 2010 > > So, I'm happy to announce that the new cut-off date of the reviews > submission is December 17th. Let's say Midnight, UTC Time. > > Thanks to all reviewers who submitted their comments, to the Review > Wizards for the extension and we are hoping to receive more > feedback from the reviewers. > > > Mateusz > Review Manager for the proposed Boost.GIL.IO and > Boost.GIL.Toolbox extensions > > > On 09/12/10 11:37, Mateusz Loskot wrote: >> Dear All, >> >> The formal review of the IO and Toolbox extensions terminates >> tomorrow. I'd like to set the cut-off time at Midnight on Saturday, >> 11 December 2010, UTC Time >> >> > (http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=12&year=2…) >> >> >> I think we have been doing well and received decent amount of >> feedback. However, anyone feels there is a need for extension, >> please let me know as soon as possible, so I will have time to >> negotiate it with the Review Wizards. >> >> Mateusz Review Manager for the proposed Boost.GIL.IO and >> Boost.GIL.Toolbox extensions >> >> >> On 30/11/10 18:01, Mateusz Loskot wrote: >>> Dear All, >>> >>> According to the Boost Formal Review Schedule [1], review of >>> Christian Henning's extensions to the Boost Generic Image Library >>> (Boost.GIL, [2]), it is: * Boost.GIL.IO * Boost.GIL.Toolbox starts >>> on December 1st and lasts until December 10th, 2010. >>> >>> [1] http://www.boost.org/community/review_schedule.html [2] >>> http://www.boost.org/doc/libs/release/libs/gil/doc/index.html >>> >>> =========== What is it? =========== >>> >>> The Boost.GIL.IO extension provides an easy to use interface for >>> reading and writing various image formats. It also includes a >>> framework for adding new formats. The Boost.GIL.IO is indent to >>> replace the current IO extension which is part of Boost for >>> several years now. >>> >>> Features: >>> >>> * A unified way to read and write image encoded in BMP, JPEG, PNG, >>> PNM, and TIFF formats. The capabilities to read and write in >>> various formats have improved dramatically. >>> >>> * Image data can be provided via standard file or string streams >>> >>> The Boost.GIL.Toolbox provides new color spaces and other small >>> code to ease programming with Boost.GIL. >>> >>> Features: >>> >>> * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and >>> XYZ * Utilities to support dynamic image workflows and color >>> conversions. * Collection of metafunctions to determine alignment, >>> similarity and homogeneity at pixel level. >>> >>> The Boost.GIL as well as the proposed extensions are provided in >>> form of a headers-only library Although, some image formats come >>> with their format dependency, it is corresponding third-party >>> libraries: >>> >>> JPEG - libjpeg PNG - libpng TIFF - libtiff >>> >>> =================== Getting the library =================== >>> >>> The latest version of both extensions can be downloaded as Zip >>> package: >>> >>> http://gil-contributions.googlecode.com/files/boost_review.zip >>> >>> or directly from the Subversion repository: >>> >>> http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ >>> >>> >>> >>> > and the docs can built as usual with bjam and quickbook tools >>> from within libs/gil/io_new/doc directory >>> >>> The libs/gil/io_new/test/readme.txt provides a step by step guide >>> to configuring, building and running the unit tests. >>> >>> The boost_review.zip is about 20MB due to its extensive collection >>> of test images. They are part of the test suite to make sure that >>> different variations of each image format is read and written >>> correctly. >>> >>> Please, be aware no guarantee can be given that all formats in >>> their all variants are completely supported. >>> >>> ================ Writing a review ================ >>> >>> If you feel the new IO and Toolbox are interesting extensions to >>> the Boost.GIL library, then please submit your review to the >>> developer list (preferably), or to the review manager (mateusz at >>> loskot dot _n_e_t_) >>> >>> Here are some questions you might want to answer in your review: >>> >>> - 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 extensions? - Did you try to use the extensions? >>> 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 extensions should be accepted as a part of >>> Boost.GIL library? >>> >>> Be sure to say this explicitly so that your other comments don't >>> obscure your overall opinion. >>> >>> Mateusz Review Manager for the proposed Boost.GIL.IO and >>> Boost.GIL.Toolbox extensions >> >> > > -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 1

Re: [boost] [GIL] locator and cached_location_t
by fabien.castan＠free.fr 18 Dec '10

18 Dec '10

Thanks for your answer. > To answer both of your questions, I don't see any particular obstacle to adding those APIs to image_view, > but we didn't add them because that will be a lot of methods for something that is advanced and not frequently used (cached_location). > Not to mention it doesn't make sense to use for all image views, but only "memory-based" ones, as opposed to virtual ones, for example. Ok for my first question. I understand the idea of not polluting the "image_view" class with something specific that can not be used in all cases. But what about the second question: adding 2 functions inside the locator class. The idea is to allows to get a locator or an iterator from a locator using cached_location ? Currently we have an operator[] inside the locator class which takes a cached_location_t and returns a pixel. It seems interesting to add x_at(const cached_location_t&) and xy_at(const cached_location_t&) versions which returns respectively iterator or locator, isn't it ?

3 2

[Config] Macro for C++0x range-based for
by Michel MORIN 17 Dec '10

17 Dec '10

Hi, C++0x range-based for is available on GCC 4.6 (Pre-release). There is no BOOST_NO_RANGE_BASED_FOR macro, so I made a patch against trunk and made a test case. Please see attached files. Is it reasonable to add this macro? Regards, Michel

5 10

boost-build for ps3?
by Emil Dotchevski 17 Dec '10

17 Dec '10

Has anyone got the MinGW cross-compiling of PS3 code working with boost-build? Thanks, Emil

1 0

Solaris, iterator_traits, wrong number of template arguments
by Jeremy C. Reed 17 Dec '10

17 Dec '10

I upgraded from 1.41.0 to 1.45.0 and started getting the following: /udir/jreed/pkg/include/boost/array.hpp:94: error: wrong number of template arguments (2, should be 1) I looked at config.log output from the /boost_1_45_0/libs/config and it showed: "./../../libs/config/test/boost_no_std_iter_traits.ipp", line 34: Error: iterator_traits is not a member of std. So BOOST_NO_STD_ITERATOR_TRAITS was defined in my user.hpp. This is on Solaris 10 with g++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Anyone using boost with gcc 3.4.x on Solaris 10? I know the gcc is old. My workaround is to comment out the BOOST_NO_STD_ITERATOR_TRAITS macro in my /udir/jreed/pkg/include/boost/config/user.hpp. Anyone have a workaround for this? Jeremy C. Reed echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \ tr '#-~' '\-.-{'

1 0

Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
by Matt Calabrese 16 Dec '10

16 Dec '10

For those of you who were following the Boost.Auto_Function call for interest, this thread sort of spawned off of that. Boost.Generic (not a part of boost) is a C++0x library intended to replace BCCL as a way of specifying concepts and concept maps, and, when used in conjunction with Boost.Auto_Function (also not a part of boost, though it's in the sandbox and has online documentation at http://www.rivorus.com/auto_function ) as a way to get concept-based function template overloading. For anyone who followed the original thread, I'm happy to say that I'm just a few days away from being able to fully and automatically recognize standard library and user-defined iterator types, though I've had a [not so] surprising amount of compiler crashes and workarounds along the way. For an example of how concept mapping will look (revised from earlier versions as I've made much more progress with implementation), see http://codepaste.net/n47ocu And for an example of how this will be used by Boost.Auto_Function, see http://codepaste.net/1faj21 . At this point I'm not trying to do the equivalent of what would have been C++0x "scoped" concept maps, though at some point I may try to support them, but it would imply calling algorithms through macro invocations (yuck). During development, I've come to some realizations that I'd like discussion about here, mostly concerning concept map lookup and ODR. Essentially, the way the library works is by assembling a compile-time list of concept maps piecewise throughout a translation unit for a given type or combination of types via a clever use of overload resolution that I talked about briefly in the BOOST_AUTO_FUNCTION call for interest thread. Underneath the hood, there is something that resembles tag-dispatching, however it is all done entirely within decltype. In short, the way the concept-based overloading works is that the macro used for specifying a function that dispatches based on concept maps generates something along the lines of this. The "magic" shown in comments is something I'm able to already do, as talked about in the other thread: ///// template< class It > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( /* magical way to get a type that inherits from all concept tags */() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Now, this is great, but I'm wondering what this means with respect to ODR. If the user is working with the algorithm "correctly", the typedef will resolve to the same type regardless of the translation unit, however, the "path" taken when inside of the decltype via overload resolution may vary depending on the translation unit when different, orthogonal concept maps are specified for the same type in one translation unit but not in the other (or if concept maps are specified in a different order I.E. via different #include orders). My question is, does this violate ODR in any meaningful sense? Since technically the typedefs should resolve to the same type in each translation unit, not including user error, is there a problem? The next question is much more devious and I have a feeling implies a blatant violation of ODR. Consider the following code, assuming "foo" does concept-based dispatching in a way similar to the above: ///// foo( 5 ); /* a concept map that specifies "int" models a concept that may affect dispatching */ foo( 5 ); ///// With the definition of foo given above, what would effectively happen is that the second call to "foo" will not be able to dispatch based on the new concept map! The reason why is because both calls will use foo< int >, and since it was already instantiated once for int, that first definition will be used. Note that this problem technically even exists with traditional tag dispatch, though I wonder if there may be some sort of solution that is standard. A hackish workaround I've come up for this is if we change the defintion of "foo" to be generated as the following: ///// // Uses C++0x function template default arguments template< class It, class TagType = /* magical way to get a type that inherits from all concept tags */ > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( TagType() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Going back to the example calling code, "foo" will now correctly dispatch differently if the intermediate concept map should affect concept-based dispatch. This might seem like a perfect solution, but now we are pretty much definitely violating ODR, since a function that calls "foo" in different translation units will very possibly see different TagTypes even though the overload resolution internal to "foo" would resolve the same. Am I clear on this problem and why I believe my solution only works if you don't consider ODR violations? The final solution that I believe sidesteps all ODR violations would be if I force calls to such algorithms to be done via a macro. The macro would internally do the trick that is currently shown inside of the definition of "foo", only it would now do it at the caller's scope. If I decide to eventually try to support scoped concept maps I would be forced down such a route anyway, so my question ends up being at what point does the library cease being a convenience? Is it worth supporting concepts as accurately as possible, including the above desired behavior, if the calling code has to become: ///// BOOST_GENERIC_CALL( (foo)( 5 ) ); /* a concept map that specifies "int" models a concept that may affect dispatching */ BOOST_GENERIC_CALL( (foo)( 5 ) ); ///// or, if you want a more practical example: ///// BOOST_GENERIC_CALL( (advance)( vector_.begin(), 5 ) ); ///// This is a problem that I would prefer to be resolved sooner rather than later since I want to reduce code rewrites. Any feedback is greatly appreciated, especially if you have insight into these problems. I'll try to get Boost.Generic in its current, very limited form up on the sandbox and the docs online as soon as possible. -- -Matt Calabrese

6 32

compilation error in tokenizer
by Sorin Manolache 16 Dec '10

16 Dec '10

Hello, This code does not compile: #include <boost/tokenizer.hpp> #include <iostream> const char test_string[] = "|abc|def||g|u|||"; int main(int argc, char *argv[]) { typedef boost::tokenizer<boost::char_separator<char>, const char *, const char *> tokenizer_t; const boost::char_separator<char> sep("|"); const tokenizer_t tok(test_string, test_string + sizeof(test_string) - 1, sep); tokenizer_t::const_iterator i = tok.begin(); return 0; } The compilation error is: In file included from /usr/include/boost/token_iterator.hpp:24, from /usr/include/boost/tokenizer.hpp:20, from tokenizer.cc:1: /usr/include/boost/token_functions.hpp: In static member function ‘static void boost::tokenizer_detail::assign_or_plus_equal<IteratorTag>::assign(Iterator, Iterator, Token&) [with Iterator = const char*, Token = const char*, IteratorTag = std::random_access_iterator_tag]’: /usr/include/boost/token_functions.hpp:458: instantiated from ‘bool boost::char_separator<Char, Traits>::operator()(InputIterator&, InputIterator, Token&) [with InputIterator = const char*, Token = const char*, Char = char, Traits = std::char_traits<char>]’ /usr/include/boost/token_iterator.hpp:70: instantiated from ‘void boost::token_iterator<TokenizerFunc, Iterator, Type>::initialize() [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ /usr/include/boost/token_iterator.hpp:77: instantiated from ‘boost::token_iterator<TokenizerFunc, Iterator, Type>::token_iterator(TokenizerFunc, Iterator, Iterator) [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ /usr/include/boost/tokenizer.hpp:86: instantiated from ‘typename boost::token_iterator_generator<TokenizerFunc, Iterator, Type>::type boost::tokenizer<TokenizerFunc, Iterator, Type>::begin() const [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ tokenizer.cc:12: instantiated from here /usr/include/boost/token_functions.hpp:227: error: request for member ‘assign’ in ‘t’, which is of non-class type ‘const char*’ The compiler is g++ 4.4.5. The version of boost is 1.42 but the token_functions.hpp, token_iterator.hpp, and tokenizer.hpp files are almost identical in 1.45. I've traced the error to the fact that get_iterator_category<const char *>::iterator_category is std::random_access_iterator_tag but the assign_or_plus_equal<IteratorTag> is specialized for std::input_iterator_tag only and not for std::random_access_iterator_tag. Sorin

1 0

[icl] Permission to merge to release branch
by Joachim Faulhaber 16 Dec '10

16 Dec '10

Hi, Interval Containers [Boost.Icl] are release ready now. It passes the regression tests on boost/trunk, is warning free, has updated html-docs etc. I have updated libs/libraries.htm, maintainers.txt and merged the latest version from trunk to my branches/release/-workspace (which was no fun ... slowly and error prone). I have tested the merge result locally. Everything works. Do I have the permission to commit my sources to the release branch now? Best regards, Joachim

6 8

boost::python: to-python conversion on polymorphic class
by Allan Johns 15 Dec '10

15 Dec '10

Hi, Is it possible to register to-python converters for polymorphic types held in shared_ptr? This does not seem to work for me. I have a virtual base class Object, and derived classes TypedAttribute<T> (with method 'value()' that returns a simple type - float, int etc). My boost.python registration code looks like so: template<typename Attrib> struct typed_attrib_topython { static PyObject* convert(const Attrib& a) { return bp::incref(bp::object(a.value()).ptr()); } }; template<typename T> struct TypedAttribBind { typedef TypedAttribute<T> attrib_t; TypedAttribBind() { boost::python::to_python_converter<attrib_t, typed_attrib_topython<attrib_t> >(); } }; However this doesn't work. I have other bound functions that return a boost::python::object(boost::shared_ptr<Object>), but these do not get converted. Am I misunderstanding to-python conversion? Should I expect this to work on polymorphic types? thanks in advance, Allan

2 6