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

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[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

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

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

11 Dec '10

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

9 30

[serialization] boost 1.45. I did not find any information about serios flaw in 1.44
by Sergey Voropaev 09 Dec '10

09 Dec '10

I am reporter of bug #4660 (https://svn.boost.org/trac/boost/ticket/4660) I am glad this bug was fixed in 1.45 version. But I did not find any information in release notes (http://www.boost.org/users/download/version_1_45_0) and in library documentation (http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/index.html) about what was fixed in 1.44 version. There are not any recommendations or comments about using version 1.44 with binary archives. I think that the absence of such information is very dangerous for the future of the serialization library, since this is a serious indicator of the quality of maintenance of the library. (I have no complaints about the quality of the library and its design) Should I reopen this bug, or open a new one, or this letter would be sufficient to restore order to the documentation of serialization library?

4 4

Library for configuration file parsing
by Denis Shevchenko 04 Dec '10

04 Dec '10

Hi all! Is there any interest in a library for configuration file parsing? I know there is a good library Program_options, but it supports (asit is written in the documentation) "parsing of simple INI-like configuration files". If all you need for configure your programs is INI-like files - use Program_options and forget about this letter. But if you want to use a more complex configuration files, you may be interested in my library, Configurator. simplest.conf: Host = 127.0.0.1 Code for work with this config: cf::configurator configurator; configurator.add_option( "Host" ); configurator.parse( "/some/path/to/simplest.conf" ); std::cout << "Value of host: " << configurator.get_value( "Host" )<< std::endl; Features - Header-only - Allows to set option's default value or/and necessity. - Allows to use arbitrary nesting of sections. - Provides "standard" checks of value's semantic, like correct path, IP validity, email correctness, etc. - Provides "extended" checks of value's semantic, like time period and file size. - Provides common checks of options and sections, like duplication, incorrection, etc. - Supports single-line and multi-line comments (in C++ style). - Allow to register values with multi-values. - Allows to set another "name-value" separator (including space symbol), instead default '='.

23 72

Probing interest in a typed XML traversal library
by Sumant Tambe 02 Dec '10

02 Dec '10

Hello boosters! I'm interested in gauging interest in a typed XML traversal library that combines the succinctness of XPath with the type-safety of XML data-binding tools. I've been developing one such library called LEESA: Language for Embedded Query and Traversal <http://www.dre.vanderbilt.edu/LEESA>. LEESA has several capabilities: 1. Succinct and expressive XPath-like notation for writing object structure traversals 2. Supports child, parent, sibling, descendant, ancestor axes 3. Compile-time schema conformance checking 4. Supports GOF visitors and hierarchical visitors 5. Strategic Programming ... and more! Here are two quick examples comparing XPath and LEESA. More examples are available on the LEESA homepage. XPath expression: "/catalog/book/author/name/text()" LEESA expression: *std::vector<name> author_names = evaluate(root, catalog() >> book() >> author() >> name()); * XPath expression: "//name/text()" LEESA Expression: *std::vector<name> names = evaluate(root, catalog() >> DescendantsOf(catalog(), name())); * The above expressions are checked for schema-conformance at compile-time. LEESA builds these capabilities on top of existing XML data binding tools that generate C++ code from .xsd files. The general process of using LEESA is as follows: 1. Generate C++ classes using your favorite XML data binding tool 2. A python script that comes with LEESA adds a few functions in every generated C++ class. It generates a lot of typedefs and helper functions, which invoke tool generated code. This creates a bridge between LEESA and the code generated by the xml data binding tool. Currently it supports Code Synthesis's xsd and Universal Data Model (UDM) from Vanderbilt University as the underlying code generators. 3. The user includes LEESA.h in his/her C++ program (it is header-only), uses its programming model, compiles, and links with the tool generated code and libraries. So folks, please speak up if you are interested in having such a library in Boost. Thanks, Sumant

3 5

[Bug Sprint] The November bug sprint starts tomorrow!
by Marshall Clow 02 Dec '10

02 Dec '10

The Boost bug sprint starts tomorrow Saturday, November 27, 2010 and runs through Sunday December 5th. The goal of the bug sprint is to make Boost better; the way we measure this is to look at the open tickets in the Trac system. In the last bug sprint (back in June), we closed over 200 tickets. However, in the past five months, the number of open tickets has crept back up, so that we once again have more than 900 open tickets. (the count was down under 800 at the end of the previous 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 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

11 25

Getting volunteers' changes back to trunk
by Jim Bell 01 Dec '10

01 Dec '10

Say you have a team of volunteers attacking failed regressions and tickets. They're creating (hopefully) good trunk patches. They can't commit to the trunk, but can modify tickets. If maintainers are active, they could review and incorporate them. But this increased activity may be more of a strain for them. If maintainers are MIA, it won't happen. So we need at least one person to bring these changes back into the trunk. Changes to libraries they're not familiar with. What's the best way for the volunteers to signal to these trunk-authority people to pick up their change? A Ticket keyword and corresponding report should work. Is there a better way? Should we look for a person or two from the volunteers for this role? A regular schedule (say, twice a week) to run the report and patch would be good, I think. Trunk regressions need time to bake. Thoughts?

6 29

Is merging to the release branch allowed again?
by Hartmut Kaiser 01 Dec '10

01 Dec '10

Since I hate holding back merging to the release branch to the last minute before the next release I would like to start doing this asap. Any idea when this might be allowed again? Regards Hartmut --------------- http://boost-spirit.com

6 7

[mpl-cf] [RFC] MPL Real Numbers using Continued Fractions
by Hal Finkel 01 Dec '10

01 Dec '10

Hello, A few months ago, I created an MPL extension type for representing real numbers. The indented use is for compile-time generation of floating-point constants, although it could also be used for MPL-based graph algorithms, etc. The primary design requirement was that almost any compiler would be able to completely inline the conversion to floating-point (which means no functional recursion can be used), and I think I've achieved that. The current implementation uses a modified version of MPL's vector type (modified to add the conversion to floating point, add "overloads", and to remove the typeof-based implementation variant (which is incompatible with the floating-point conversion)). I've posted the code to the Boost vault under the "Template Metaprogramming" section; the file name is boost-mpl-cf-20100531.zip Continued fractions were chosen for the representation because the associated algorithms are simple, and simple proved important for keeping down compilation times. Even so, the compilation times might be too long for practical use. You can decrease the compilation time by using a shorter maximum cf-length by defining BOOST_MPL_LIMIT_CF_SIZE to be 10 instead of 20. The current default is 20 to allow an effective precision near that of a double. Also, continued fractions, being "based on" rational numbers, can exactly represent any rational (for example, 1/3) so the computations can be more accurate than those using a floating-point representation. If you don't know what a continued fraction is, and would like to know, you can check out the wikipedia page: http://en.wikipedia.org/wiki/Continued_fraction The current implementation supports addition, subtraction, multiplication and division, comparison ops, some constants like pi, and I've included sin()/cos() as well. I've not yet written any real documentation, but the archive has a couple of test programs; the usage is pretty simple. Each test program has many individual tests, so its compilation time will be representative of a more-complicated computation, if you just need to do a few things, it would be much faster. If there is interest, I'll add support for generating numbers using metafunctions, write some documentation, jam files, etc. Let me know what you think, and I welcome suggestions, criticisms, etc. Also, I've currently tested using only the GNU and Intel compilers, so let me know whether it does or does not work when using something else. Thanks again, Hal P.S. I know that there is a mpl_math archive on the vault from back in 2007. I did not discover this until after I had almost finished writing my mpl-cf implementation, but, the mailing-list messages from the time indicate that it was too slow to be used practically, since I think the continued fractions algorithms are simpler, mpl-cf might be better, but I've not tested it to find out.

6 11

Re: [boost] Boost 1.45 compile error
by Eric Niebler 01 Dec '10

01 Dec '10

(bringing in boost dev...) This sounds bad. Can anybody confirm? -- Eric Niebler BoostPro Computing http://www.boostpro.com On 11/19/2010 4:35 PM, gast128 wrote: > Hello all, > > just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only > including type_traits: > > #include <boost/type_traits.hpp> > > int main() > { > return 0; > } > > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2027: > use of undefined type '<Unknown>' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(143) : see > declaration of '<Unknown>' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : see > reference to class template instantiation '<Unknown>' being compiled > C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(121) : see > reference to class template instantiation '<Unknown>' being compiled > C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(123) : see > reference to class template > instantiation 'boost::type_traits_detail::common_type_2<T,U>' being compiled > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2146: > syntax error : missing ';' before identifier 'wrapped_type' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error > C2501: '<Unknown>' : missing storage-class or type specifiers > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(161) : error > C2653: 'wrapped_type' : is not a class or namespace name > > afaik it seems located on 121 in 'boost/type_traits/coomon_type.hpp' > > Anyone can help?

12 27

[gil] New IO release
by Christian Henning 30 Nov '10

30 Nov '10

Hi there, a new gil IO extension is ready for download. Here is the link: http://code.google.com/p/gil-contributions/downloads/detail?name=boost_revi… This is the final version that will be used for the boost review. Could someone try to build documentation on Linux? Thanks to all people that have helped me out. Regards, Christian

5 18

Sandbox cleanup
by Vladimir Prus 30 Nov '10

30 Nov '10

Folks, it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in particular: - 'boost' directory, that has assorted headers supposedly meant for future. - 'libs' directory, with various libraries - Pile of top-level directories for libraries-in-development, each containing 'boost' and 'libs' subfolders. - Subdirectory SCons, with a copy of entire Boost tree, buildable with scons. - Subdirectory 'win32-doc-tools', which surely does not contain a library - Some directories named after specific people. It's not clear whether those directories contain a single future library, or several, or what. It seems that a straight-forward approach to fix that is to have two separate areas in sandbox, as follows: [using fixed font to read the below might work better] /sandbox /libraries /proposed-lib1 /boost /libs .... /branches /jrhacker-assorted-fixes [complete branch of trunk, with changes] /SCons [complete branch of trunk, with SConstruct, etc] Comments? -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

8 9

[Bug Sprint] Status for Tuesday, November 30th
by Marshall Clow 30 Nov '10

30 Nov '10

There were 59 changes to the trac database yesterday. [ I'd like to say "59 tickets were changed", but some tickets were changed more than once. ] A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" 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) If you want to contribute, I would suggest looking at the old tickets, and seeing what you can do with them: Here are the tickets by milestone: Milestone Tickets To Be Determined 362 Boost 1.43.0 100 Boost 1.44.0 94 Boost 1.42.0 74 Boost 1.36.0 48 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.40.0 48 Boost 1.39.0 43 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.41.0 39 <blank> 36 Boost 1.38.0 30 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.37.0 25 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.45.0 13 Boost 1.46.0 12 Website 1.X 4 Boost 1.47.0 1 Boost.Jam 3.1.18 1 Boost.Jam 4.0.0 1 Activities on the trac system yesterday: viboes 16 anonymous 12 ramey 7 mikhailberis 3 marshall 3 --others-- 18 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

3 2

virtual protected inheritance and default constructors
by gzp 30 Nov '10

30 Nov '10

Hello, This might be an off-topic question, but there must be here some clever guy who can answer my question. class Impl { public: Impl() { std::cout << "j"; } // want to eliminate, but cannot :( Impl(int j) { i = j; std::cout << "i"; } int i; }; template<typename TImpl> class A : virtual protected TImpl { public: void geti() const { std::cout << "gi" << i << "\n"; } }; template<typename TImpl> class B : public A<TImpl> { public: void seti(int a) { this->i = a; } }; class CA : public A<Impl> { public: CA() : Impl(3) { std::cout << "ca " << i;} }; class CB : public B<Impl> { public: CB() : Impl(2) { std::cout << "cb " << i;} }; //abuse of interfaces template<typename TImpl> void foo( A<TImpl>& p_a ) { p_a.geti(); } template<typename TImpl> void foo( B<TImpl>& p_a ) { p_a.seti( 2 ); } template<typename TImpl> void foo2( A<TImpl>& p_a ) { p_a.geti(); } int main( int, char*[] ) { CA a; std::cout << "\n"; CB b; std::cout << "\n"; foo(a); foo(b); foo2(a); foo2(b); return 0; } The basic concept was that: there is a simple implementation class and using some interfaces (bridge classes) the appropriate function call (foo) can be ensured using compile time type checking. The implementation might provide implementation to multiple interfaces (bridge classes) and these interfaces guarantee the required operation for each (template)functions. The role of A and B is to provide the interface and bridge it to the implementation. The only missing part was, how to construct a CA and CB object. They might have completely different construction parameters and the virtual protected inheritance partially solved the problem. BUT the default constructor is always required (VC2008) even tough it gets never called (I don't want to create any object from A,B (who are missing these default ctors) but I couldn't tell it to the compiler) "The declare and don't define" doesn't solve the problem either as the linker requires the default Impl ctor even though it never gets called. For example: impl1: a range iterator for an 1D array: ctor requires the array.begin, array.end impl2 a random generator range: ctor requires the random seed CA: isEmpty, front, popFront CB: put, mutable front copy from random range to array is valid (template foo(A,B)), but not the other way (no template foo(B,A)) Thanks, Gzp -- View this message in context: http://boost.2283326.n4.nabble.com/virtual-protected-inheritance-and-defaul… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.45][filesystem3] utf8 support
by Jochen Wilhelmy 30 Nov '10

30 Nov '10

Hi! now I switched to filesystem3. Everything works, but there is one issue on windows. I'd like to use utf8 in my application. I can imbue an utf8-locale to path. But if I have legacy libraries that take only 8 bit strings then I would pass utf8 instead of ansi (e.g. latin1). Therefore filesystem::path can be seen as a gateway between the application and the operating system and therefore needs two locales, one for the application and one for the operating system. Or an additional method utf8() that returns utf8 regardless of the locale. What do you think? -Jochen

2 1

[thread] On shared_mutex
by Howard Hinnant 30 Nov '10

30 Nov '10

Three years ago I wrote N2406 "Mutex, Lock, Condition Variable Rationale" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html) for the C++ committee in an attempt to explain the combined proposed std::mutex/std::unique_lock package and how it fit together with the tr2-targeted shared_mutex/shared_lock package. This paper also proposed an upgrade_mutex and upgrade_lock. Since that time, the std-proposed stuff has been accepted with some name changes, and a reworking of the timed-locking interface. Additionally Anthony Williams has implemented much of the shared-locking functionality in boost (and done a very nice job with it). That being said, I disagree with some fairly major design changes between N2406 and what is now in the boost library. Four of the major changes are: 1. upgrade_mutex has been dropped. 2. Some, but not all of the functionality in upgrade_mutex has been moved into shared_mutex. 3. Some of the upgrade_mutex functionality is missing completely. The missing functionality is summarized in the "Ownership Modes" charts in the form of red arrows. 4. boost allows implicit conversions between the lock types. N2406 made these conversions explicit. Rationale: changing the ownership mode of a mutex is something that should be well documented in the code. I have an updated implementation of <shared_mutex> (under the boost license) here: http://home.roadrunner.com/~hinnant/mutexes/shared_mutex http://home.roadrunner.com/~hinnant/mutexes/shared_mutex.cpp There is a tutorial-style description of this library here: http://home.roadrunner.com/~hinnant/mutexes/locking.html The tutorial includes a brief description of the use of most of the components, complete synopses, and an examples section. It also notes where this design differs from the boost design and explains why I believe the boost design is in error. Comments appreciated, and all are welcome to use this code under the boost license. I will likely update this document in response to comments and its date at the top will correctly reflect the last time it was updated. This library, or a variation of it, will probably be submitted to TR2, and so getting feedback on the differences between this and the boost implementation is important. Thanks, Howard

5 17

Re: [boost] Moving Boost.Geometry to trunk (was: Sandbox cleanup)
by Hartmut Kaiser 30 Nov '10

30 Nov '10

> > 1. Declare that /sandbox should follow<library>/{boost,libs} layout. > > 2. Move everything else into /sandbox-branches > > Boost.Geometry follows <library>/{boost,libs,other} layout where other > contains small programs not fitting within libs. I hope this is permitted. > I'm quite dependent on the current place and so are many users. I will > remove the (now obsolete) ggl folder which is still there. > > Maybe it is also possible (now or in the future) to make a distinction > between already-accepted-but-not-yet-incorparted libraries (such as > Boost.Geometry) and proposed libraries. > > Finally there is also /sandbox-tags, of which the structure is also not so > clear to me. I've taken the freedom to create a "geometry" folder there, > and below that are our tags. > > So the there structure is for me: > /sandbox-tags/<library>/<tagname>/{boost,libs} > > And I propose that as a convenient layout. Barend, not really related but a question anyways: why don't you move your overall activities to the trunk? I know you're not satisfied with certain details of your library. However, doing the development on trunk (and Boost.Geometry is an accepted library) gives you more exposure to potential users and full integration with the regression tests. Additionally, having the library on trunk doesn't mean you need to merge it to the release branch for any release in the near future... Regards Hartmut --------------- http://boost-spirit.com

2 1

[Bug Sprint] Status for Monday, November 29th
by Marshall Clow 30 Nov '10

30 Nov '10

There were 37 changes to the trac database yesterday. [ I'd like to say "37 tickets were changed", but some tickets were changed more than once. ] A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" 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!) Activities on the trac system yesterday: anonymous 11 mikhailberis 10 viboes 5 ktchan 4 --others- 7 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

7 8

[Preprocessor] Adding variadic macros support
by Mathias Gaunard 30 Nov '10

30 Nov '10

Variadic macros would allow to support tuples better in Boost.PP, as it would not be necessary to specify the size of the tuple, and it could be possible to provide other nice features around tuples. Other possible applications could be to accept the sequence (a)(b, c, d)(e) as being the same as (a)((b, c, d))(e). If you think other things could be improved in PP with variadic macros, feel free to point out where. The question is: how should it be done? Should the new macros be named, say, BOOST_PPV_*? Should the macros in BOOST_PP_* be "overloaded" on arity (a possibility with variadic macros) so as to exhibit both the old and new interface?

10 39

[range] Problem with adaptors::map_keys
by Alexander Fokin 29 Nov '10

29 Nov '10

I'm having some troubles using adaptors::map_keys with custom iterators over Qt associative containers. The problem with Qt associative containers is that they provide iterators over a set of values, not over a set of key-value pairs. I have worked that around by introducing boost range bindings: http://codepad.org/xnZrpZ5i However, when these binding are used, the following code produces a compilation error: BOOST_FOREACH(auto pair, (QMap<int, int>()) | boost::adaptors::map_keys); Everything works fine if the code of boost::range_detail::select_first is slightly modified. You'll find the patch attached. I believe it's a problem in boost range, but I may be wrong, so I need some expert help here. -- Best regards, Alexander Fokin, http://elric.ru.

2 4

[GIL] [patch] read multipage TIFF files
by Robert Pollak 29 Nov '10

29 Nov '10

Hello, the following patch (against the current trunk) allows to read any page of a multipage TIFF file, by optionally specifying the zero-based directory number. (The correct term for a TIFF page is "directory".) It adds a "dirnum" to the relevant functions, and uses the corresponding libtiff functionality. The "dirnum" default value is 0 for compatibility with present callers. Additionally, it defines the function tiff_get_directory_count to get the number of directories in the TIFF file. Please give me some feedback or consider applying the patch. This patch would close the corresponding feature request https://svn.boost.org/trac/boost/ticket/2373 . Credits go to Roland Richter, whose code the patch is based on. Best Regards, Robert Pollak Index: boost/gil/extension/io/tiff_io.hpp =================================================================== --- boost/gil/extension/io/tiff_io.hpp (revision 64065) +++ boost/gil/extension/io/tiff_io.hpp (working copy) @@ -122,9 +122,13 @@ protected: TIFF *_tp; public: - tiff_reader(const char* filename) { + tiff_reader(const char* filename,tdir_t dirnum=0) { io_error_if((_tp=TIFFOpen(filename,"r"))==NULL, "tiff_reader: fail to open file"); + if(dirnum>0) { + io_error_if(TIFFSetDirectory(_tp,dirnum)!=1, + "tiff_reader: fail to set directory"); + } } ~tiff_reader() { TIFFClose(_tp); } template <typename View> @@ -171,10 +175,10 @@ private: CC _cc; public: - tiff_reader_color_convert(const char* filename) : - tiff_reader(filename) {} - tiff_reader_color_convert(const char* filename,CC cc_in) : - tiff_reader(filename),_cc(cc_in) {} + tiff_reader_color_convert(const char* filename,tdir_t dirnum=0) : + tiff_reader(filename,dirnum) {} + tiff_reader_color_convert(const char* filename,CC cc_in,tdir_t dirnum=0) : + tiff_reader(filename,dirnum),_cc(cc_in) {} template <typename View> void apply(const View& view) { point2<std::ptrdiff_t> dims=get_dimensions(); @@ -336,18 +340,34 @@ }; /// \ingroup TIFF_IO +/// \brief Returns the number of directories in the TIFF file +inline int tiff_get_directory_count(const char* filename) { + TIFF *tif; + io_error_if((tif=TIFFOpen(filename,"r"))==NULL, + "tiff_get_count: fail to open file"); + + int dircount = 0; + do { + dircount++; + } while (TIFFReadDirectory(tif)); + + TIFFClose(tif); + return dircount; +} + +/// \ingroup TIFF_IO /// \brief Returns the width and height of the TIFF file at the specified location. /// Throws std::ios_base::failure if the location does not correspond to a valid TIFF file -inline point2<std::ptrdiff_t> tiff_read_dimensions(const char* filename) { - detail::tiff_reader m(filename); +inline point2<std::ptrdiff_t> tiff_read_dimensions(const char* filename,tdir_t dirnum=0) { + detail::tiff_reader m(filename,dirnum); return m.get_dimensions(); } /// \ingroup TIFF_IO /// \brief Returns the width and height of the TIFF file at the specified location. /// Throws std::ios_base::failure if the location does not correspond to a valid TIFF file -inline point2<std::ptrdiff_t> tiff_read_dimensions(const std::string& filename) { - return tiff_read_dimensions(filename.c_str()); +inline point2<std::ptrdiff_t> tiff_read_dimensions(const std::string& filename,tdir_t dirnum=0) { + return tiff_read_dimensions(filename.c_str(),dirnum); } /// \ingroup TIFF_IO @@ -356,17 +376,17 @@ /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its color space or channel depth are not /// compatible with the ones specified by View, or if its dimensions don't match the ones of the view. template <typename View> -inline void tiff_read_view(const char* filename,const View& view) { +inline void tiff_read_view(const char* filename,const View& view,tdir_t dirnum=0) { BOOST_STATIC_ASSERT(tiff_read_support<View>::is_supported); - detail::tiff_reader m(filename); + detail::tiff_reader m(filename,dirnum); m.apply(view); } /// \ingroup TIFF_IO /// \brief Loads the image specified by the given tiff image file name into the given view. template <typename View> -inline void tiff_read_view(const std::string& filename,const View& view) { - tiff_read_view(filename.c_str(),view); +inline void tiff_read_view(const std::string& filename,const View& view,tdir_t dirnum=0) { + tiff_read_view(filename.c_str(),view,dirnum); } /// \ingroup TIFF_IO @@ -375,25 +395,25 @@ /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its color space or channel depth are not /// compatible with the ones specified by Image template <typename Image> -void tiff_read_image(const char* filename,Image& im) { +void tiff_read_image(const char* filename,Image& im,tdir_t dirnum=0) { BOOST_STATIC_ASSERT(tiff_read_support<typename Image::view_t>::is_supported); - detail::tiff_reader m(filename); + detail::tiff_reader m(filename,dirnum); m.read_image(im); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, and loads the pixels into it. template <typename Image> -inline void tiff_read_image(const std::string& filename,Image& im) { - tiff_read_image(filename.c_str(),im); +inline void tiff_read_image(const std::string& filename,Image& im,tdir_t dirnum=0) { + tiff_read_image(filename.c_str(),im,dirnum); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its dimensions don't match the ones of the view. template <typename View,typename CC> -inline void tiff_read_and_convert_view(const char* filename,const View& view,CC cc) { - detail::tiff_reader_color_convert<CC> m(filename,cc); +inline void tiff_read_and_convert_view(const char* filename,const View& view,CC cc,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<CC> m(filename,cc,dirnum); m.apply(view); } @@ -401,31 +421,31 @@ /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its dimensions don't match the ones of the view. template <typename View> -inline void tiff_read_and_convert_view(const char* filename,const View& view) { - detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter()); +inline void tiff_read_and_convert_view(const char* filename,const View& view,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter(),dirnum); m.apply(view); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. template <typename View,typename CC> -inline void tiff_read_and_convert_view(const std::string& filename,const View& view,CC cc) { - tiff_read_and_convert_view(filename.c_str(),view,cc); +inline void tiff_read_and_convert_view(const std::string& filename,const View& view,CC cc,tdir_t dirnum=0) { + tiff_read_and_convert_view(filename.c_str(),view,cc,dirnum); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. template <typename View> -inline void tiff_read_and_convert_view(const std::string& filename,const View& view) { - tiff_read_and_convert_view(filename.c_str(),view); +inline void tiff_read_and_convert_view(const std::string& filename,const View& view,tdir_t dirnum=0) { + tiff_read_and_convert_view(filename.c_str(),view,dirnum); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. /// Throws std::ios_base::failure if the file is not a valid TIFF file template <typename Image,typename CC> -void tiff_read_and_convert_image(const char* filename,Image& im,CC cc) { - detail::tiff_reader_color_convert<CC> m(filename,cc); +void tiff_read_and_convert_image(const char* filename,Image& im,CC cc,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<CC> m(filename,cc,dirnum); m.read_image(im); } @@ -433,23 +453,23 @@ /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. /// Throws std::ios_base::failure if the file is not a valid TIFF file template <typename Image> -void tiff_read_and_convert_image(const char* filename,Image& im) { - detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter()); +void tiff_read_and_convert_image(const char* filename,Image& im,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter(),dirnum); m.read_image(im); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. template <typename Image,typename CC> -inline void tiff_read_and_convert_image(const std::string& filename,Image& im,CC cc) { - tiff_read_and_convert_image(filename.c_str(),im,cc); +inline void tiff_read_and_convert_image(const std::string& filename,Image& im,CC cc,tdir_t dirnum=0) { + tiff_read_and_convert_image(filename.c_str(),im,cc,dirnum); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. template <typename Image> -inline void tiff_read_and_convert_image(const std::string& filename,Image& im) { - tiff_read_and_convert_image(filename.c_str(),im); +inline void tiff_read_and_convert_image(const std::string& filename,Image& im,tdir_t dirnum=0) { + tiff_read_and_convert_image(filename.c_str(),im,dirnum); } /// \ingroup TIFF_IO

2 7