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

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