- Boost - lists.preview.boost.org

Re: [boost] Compiler error in gcc3+ involving template template parameter and default parameters
by Brent Spillner 16 Jan '11

16 Jan '11

On 01/15/2011 10:41 PM, Edward Diener wrote: >I am showing this gcc3 bug just in case any other Boost developer has >run into it and knows some easy workaround. It will save me some time as >the workaround in the actual case, which is more complicated, is very >laborious as I envision it ( I have not yet attempted to code up the >laborious workaround ). I ran into this type of case as the problem in >my tti library which is keeping it from supporting gcc3+. Your sample code compiles for me without errors or warnings (other than the unused variable) under GCC 4.4.4 and 4.5.2. Is there a particular GCC version that you need to support? In my experience GCC versions before 4.4 have badly broken template support and should be avoided if at all possible. >I am looking for a workaround for gcc3+ compilers which does not involve >getting rid of the default parameters. If I remove the default >parameters, and change the instantiation of tkf to: I would start by removing the "template<class>" / "template<class, class>" specifications on the dependent types F. Those may be what sent you into a poorly-tested and bug-ridden corner case in whichever release of GCC you're using, and should be unnecessary--- the compiler will not be able to instantiate the base class F<typename P1::type> when F requires two parameters, nor F<typename P1::type, typename P2::type> when it accepts only one, and should SFINAE to the proper case. If you do need those explicit constraints on F to work around problems in GCC 3 or another compiler, and it's feasible to nest a new typedef into all types that are legal as the F argument of eval<>, you could construct something like template <class T, class P = noparam> struct ptmf { typedef int type; typedef ptmf<T, P> is_unary; }; template <class T, class P1, class P2> struct other { typedef int type; typedef other<T, P1, P2> is_binary; }; template <template<class> class F, class P1> struct eval<F<P1> > : typename F<typename P1::type>::is_unary {}; template <template<class,class> class F, class P1, class P2> struct eval<F<P1, P2> > : typename F<typename P1::type, typename P2::type>::is_binary {}; If you need to support F types to which you can't add typedefs, you'll have to use the template <class F> struct F_traits{} pattern to provide ::is_unary, ::is_binary, etc.

2 1

GIL io_new review
by Lubomir Bourdev 16 Jan '11

16 Jan '11

First I apologize for not being active in the past several years in the Boost community due to time constraints. I only had a few hours to do this review, but I also reviewed Christian's code a couple of years ago. When we introduced GIL to Boost I was hesitant to include the I/O extension in the Boost submission. I felt that doing the I/O right is a major project and it is better to do it right or not at all. However, without any I/O support it would be very hard to use GIL, so we had to include some I/O extension that provides reasonable support for common formats. Christian has been (and still is) very passionate to make the next generation I/O. He started working on this at least four years ago and have been improving and polishing the code ever since. The problem with I/O is that you can never declare success. There are an unlimited number of file formats, back-ends, ways to read and write the image, image representations, compression settings, etc. For each of these one needs to deal with completeness, performance, test cases, failure modes, platform dependencies... All we can hope for is push the boundary as much as we can, and leave the rest for the next update. What is important in the first release is to get the design right. Once we have a solid foundation we can add a lot of functionality quickly and transparently. Domagoj had some constructive criticism so I will start with that. On the issue of using classes vs free functions, I don't think there is a huge difference either way. The the new_io code borrows the style from GIL, which uses free functions as algorithms (if you call I/O "algorithms"). GIL in turn borrows this style from the STL. Using functions one can extend functionality with overloading (but there are ways to do this with classes too) and it is nicer to be able to read/write a file with one line, without having to first construct a reader/writer and then call it. But these are minor quibbles. On the issue of performance, I don't think one test with one file format being 30% slower proves that there are serious performance issues. My guess is that Christian has been focusing on adding functionality and never got around to work on performance improvements, which usually means that we can get a lot of speedup by doing some simple optimizations in the inner loops. On the issue of using/not using streams, I don't have a strong opinion, except that stream support for I/O was one of the highest requested functionalities in GIL's review. Domagoj, you should have been more vocal at that time. Christian simply responds to the wishlist of the Boost community. In general, I feel that performance might be a bit overhyped in recent discussions. The image I/O operations are often dominated by disk access and by compression, etc. I don't think avoiding a copy of the pixels would make much of a difference in the majority of uses. That said, we do want to make sure GIL I/O is as fast as it can be. On the issue of supporting different backends, I agree with Domagoj that this is important and we should make sure to support it. In Christian's design everything is done in reader and writer classes, which are currently specialized for a specific file format and backend. One could imagine creating classes for other backend+file format combinations without much (any?) changes to the current design. The reader/writer files from the same backend could have common base classes or share functionality in other ways as appropriate. - What is your evaluation of the design? The design is fine, but I would like the requirements for adding new file formats / backends to be made more explicit. Specifically we want a concept for a file format reader/writer/etc and adding new file formats would constitute providing models for these concepts. - What is your evaluation of the implementation? It looks fine but haven't played with it much. - What is your evaluation of the documentation? The documentation is adequate, but requires cleanup and fixing of lots of typos. - What is your evaluation of the potential usefulness of the extensions? Very useful. However, there is some missing functinality which in my opinion is important to have: 1. The ability to read an image without specifying the file format at compile time 2. The ability to support multiple back-ends 3. The ability to efficiently read/write an image in parts - Did you try to use the extensions? With what compiler? Did you have any problems? I did not do anything non-trivial with them. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 3 hours looking at the code (but I reviewed a verion about 3 years ago) - Are you knowledgeable about the problem domain? I am familiar with GIL but not very much with file format libraries. - Do you think the extensions should be accepted as a part of Boost.GIL library? Let us consider our options carefully. We could do a "reject" on the basis that there is another alternative libarary (Domagoj's library). I don't think this is a good idea. I looked briefly at his library; there are things I like about it but also things I don't. There are certainly a lot of things that are missing. I will refrain from discussing it because it is not under review but the point is that in its current state it is not superior to what Christian has. Domagoj can improve his library further, but so can Christian, and Christian has been working on this for four years now and had submitted his library for review long time ago. This is a huge effort on behalf of Christian, he produced some great and very useful work and a reject will be demoralizing after so many years of work, and is unjustified given that fundamentally he has the right design. We could do an "accept". I would be ok with this, but there is some important functionality that is missing and adding it will require moderate work and some changes to the interface So my recommendation is "conditional accept" after the above identified must-have functionality has been added, specifically: - Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the filename. - Support for different backends. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. It is not immediately obvious to me why this would be a bad design choice; if someone disagrees they should elaborate. - Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. I'd like to hear the opinion of people who would use this more advanced options. My preference is that Christian joins forces with Domagoj to collaborate on these and take the best of their libraries to gil.io. Looks like Domagoj also spent a lot of time and effort on this problem and has gained a lot of valuable intuition. I don't want to see his efforts go to waste either. Other todo items: - Improve the language in the documentation section. - Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. - Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. - Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. Finally, here is an idea that I like, but may be too much work to do in the current release: I would like to have a GIL virtual image view associated with a given file. That would allow reading/writing to simply be copy_pixels, and reading into a different format to be copy_and_convert_pixels. Reading a given ROI could simply be done by creating a subimage_view. The cool thing about this is one could in theory make changes to images without even loading them in memory. The caviat is that doing this right and efficiently is very hard, requires clever caching, plus a wrong access pattern can result in horribly bad performance. Lubomir

5 20

[ratio] namespace ratios
by vicente.botet 16 Jan '11

16 Jan '11

Hi, Before moving all the classes on Boost.Ratio from boost:: to boost::ratios:: I wanted to signal that Boost.Ratio follows the names on the C++0x standard and that these names where choosen to be used in the std context and that any class is prefixed by ratio_. If a specific ratios namespace were in their minds, I'm sure that they will not use the ratio_add<> but just add<>. Please let me know if I'm wrong here. typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::add<R1, R2> R; If we put all of them in boost::ratios maybe the class names contains redundant information typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::ratio_add<R1, R2> R; Do the Boost community agree with these names or is this one of the special cases that needs consideration? Best, Vicente

3 2

[tools/regression] compiler_status & library_status build error
by KTC 16 Jan '11

16 Jan '11

Executing bjam in tools/ fail to build library_status on trunk or release, and fail to build compiler_status on release. I'm guessing they still need to be fixed for Boost.Filesystem v3. KTC

1 0

[Creasing (Sequence Properties)] where is the documentation
by Edward Diener 16 Jan '11

16 Jan '11

For the Creasing (Sequence Properties) library up for review I do not see how to build any documentation, nor is there any documentation for it in the download.

1 0

[bitset] documentation does not build
by Edward Diener 16 Jan '11

16 Jan '11

Attempting to build the documentation for bitset, I get a bunch of errors: "C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1079 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p..\..\..\bin.v2\libs\integer\doc\msvc- 10.0\debug\threading-multi>bitfield.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-bitf ield.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-bitfi eld.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: added properties: <preserve-test-targets>on <python-debugging>off <python >2.6 <threadapi>win32 error: removed properties: none C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1078.actualize from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1087.actualize from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1088.actualize from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1092.actualize from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1093.actualize from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:748: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module C:\Programming\VersionControl\sandbox\boost-build.jam:66: in module scope from m odule" The docs need to be buildable for anyone to use the library or be willing to review it.

1 0

[1.46] Release notes
by Daniel James 15 Jan '11

15 Jan '11

Hello all, Since the code freeze is coming up, it's time to write your release notes. If you want to add them yourself, you can edit 'boost_1_46_0.qbk' in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. I didn't get the new site building system ready in time for this release, so you should probably leave it to me to generate the html from your changes. Daniel

2 1

[Review] Dead link for Endian on the Review Schedule page
by Edward Diener 15 Jan '11

15 Jan '11

On the review schedule page at http://www.boost.org/community/review_schedule.html the link for Beman Dawes Endian library is dead.

1 0

Re: [boost] [context] new version - support for Win64
by Andrzej Krzemienski 15 Jan '11

15 Jan '11

> I've uploaded boost.context-0.3.0.zip to boost vault. Hi, I am new to the idea of context switching, and the idea seams very interesting. I have gotone question regarding the interface. The two arguments that are passed when creating a new context, of type void(*)(void*) and void* look like a way of providing a callback. I am used to, in Boost libraries and C++0x threads, to see function<void()> as a type of callbcak. Is there a reason for not using it in case of context switching? Regards, &rzej

3 3

Improving review process
by Vladimir Prus 15 Jan '11

15 Jan '11

Recently, there were various comments about current review process, and its possible improvements. However, I wanted to start with a small point. Looking at: http://www.boost.org/community/review_schedule.html it seems that a few libraries have a review manager assigned, but there's no date. This means that: - It looks like our review schedule is full, because the item is there, and - It prevents anybody to volunteer as review manager for such library. I think there might be several reasons why a library does not have a review date: - The library is not actually ready. In that case, it should not be in that table at all. - The library author does not have the time for review. In that case, the library should also be removed from the list, because Boost is not responsible if the author is busy. - The review manager does not have the time for review. In that case, he should not be listed as assigned, and should not block others. Can we set a policy that: - A library can only be added in the review schedule if the author has time in near future to have a review, where near future is, say, 3 months. - A review manager is only assigned if a review date is set at the same time, where the date should be in near future -- say, 3 months again. I think such a policy might not improve our overall review speed too much, but surely will make the situation a bit clear, and allow to understand the real problems with the review system. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

20 52

Re: [boost] [Boost-commit] svn:boost r66696 - in trunk: boost/config boost/config/compiler boost/config/platform libs/config/doc libs/config/doc/html libs/config/doc/html/boost_config
by Steven Watanabe 15 Jan '11

15 Jan '11

AMDG On 11/22/2010 10:33 PM, admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2010-11-23 01:33:35 EST (Tue, 23 Nov 2010) > New Revision: 66696 > URL: http://svn.boost.org/trac/boost/changeset/66696 > > Log: > Added *nix identification macros to Boost.Config; BOOST_NIX, BOOST_GENETIC_NIX, > BOOST_TRADEMARK_NIX and BOOST_FUNCTIONAL_NIX. Bryce, these macros are not used by anything in Boost and I saw no discussion on the mailing list about adding them. Please provide a justification for them, or I will revert this. Boost.Config should not have macros that we don't need. In Christ, Steven Watanabe

2 1

Re: [boost] [pgi-10.1] relocations compiler option
by vicente.botet 15 Jan '11

15 Jan '11

Hi, Sorry for the cross-post. It seems as nobody is posting on the Testing ML. Noel Belcourt is out until the 24th. Could someone check if the modification is needed? Vladimir? Best, Vicente ----- Original Message ----- From: vicente.botet To: Running Boost regression tests Sent: Wednesday, January 12, 2011 7:49 PM Subject: [Boost-testing] [pgi-10.1] relocations compiler option Hi, there are some test in trunck that are failing Test output: Sandia-pgi-10.1 - chrono - xtime_static / pgi-10.1 It seems that the we need to add -fPIC, but -fpic . I don't know the compiler command syntax, but in case this could help, it will be worth to try. Could someone change this on trunk? Best, Vicente Test output: Rev 68033 / Wed, 12 Jan 2011 07:53:19 +0000 Report Time: Wed, 12 Jan 2011 15:19:47 +0000 Compile [2011-01-12 10:41:10 UTC]: succeed "/sierra/Sntools/extras/compilers/pgi/linux86-64/10.1/bin/pgCC" -INLINE:none -Wc,-a --brief_diagnostics --error_limit1 --compress_names --diag_suppress450 --no_using_std --zc_eh -Kieee -fpic -gopt -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_DYN_LINK=1 -D__need_IOV_MAX -I".." -c -o "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o" "../libs/system/src/error_code.cpp" Link [2011-01-12 10:41:10 UTC]: fail "/sierra/Sntools/extras/compilers/pgi/linux86-64/10.1/bin/pgCC" -gopt -fpic --zc_eh -shared -o "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/libboost_system.so" "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o" -Wl,-h -Wl,libboost_system.so -Bdynamic -lrt -lrt -Bstatic -Bdynamic /usr/bin/ld: /scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o: relocation R_X86_64_PC32 against `__catch_clause_number' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value TinyUrl http://tinyurl.com/6z8ndcg _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/ ------------------------------------------------------------------------------ _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 0

Re: [boost] [Boost-commit] svn:boost r67851 - trunk/boost/asio
by Steven Watanabe 15 Jan '11

15 Jan '11

AMDG On 1/8/2011 8:47 PM, admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2011-01-08 23:47:56 EST (Sat, 08 Jan 2011) > New Revision: 67851 > URL: http://svn.boost.org/trac/boost/changeset/67851 > > Log: > Pathscale 4.0.0's stdlib (rw) has a<streambuf> that doesn't include<iostream>; > added an include to<iostream> here as this file needs it. > > Modified: trunk/boost/asio/basic_socket_iostream.hpp > ============================================================================== > --- trunk/boost/asio/basic_socket_iostream.hpp (original) > +++ trunk/boost/asio/basic_socket_iostream.hpp 2011-01-08 23:47:56 EST (Sat, 08 Jan 2011) > @@ -19,6 +19,7 @@ > > #if !defined(BOOST_NO_IOSTREAM) > > +#include<iostream> > #include<boost/preprocessor/arithmetic/inc.hpp> > #include<boost/preprocessor/repetition/enum_binary_params.hpp> > #include<boost/preprocessor/repetition/enum_params.hpp> This is more than is needed. std::iostream is defined in <istream>. <iostream> contains std::cout, etc. In Christ, Steven Watanabe

1 0

the <boost/detail/iomanip.hpp> header (please use it)
by Bryce Lelbach 15 Jan '11

15 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Linux, both clang and icc use GNU's C++ standard library by default. As of version 4.5 of GNU's stdlib, a new implementation of the <iomanip> header has been added, which makes use of C++0x features which only GCC supports (the latest versions of clang, e.g. a very recent nightly build, might work; intel certainly won't). The refactored <iomanip> header in GNU's stdlib does not detect C++0x support and fallback on the old C++98 friendly code, which unfortunately leaves clang-linux and intel-linux users in a bit of a bind. In particular, this plagues clang users on Linux as clang will use the latest available version of the GNU stdlib by default, meaning most users cannot have both gcc-4.5 and clang installed without problems. I have implemented the <iomanip> header in <boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system <iomanip> headers that users/other code might include). The implementation conforms to the C++03 standard (at least, I'm fairly confident it is standard compliant - reviews and feedback would be welcome). I just committed (r68140) a patch which replaces the use of <iomanip> with <boost/detail/iomanip.hpp>. I've tested on a few different compilers, and I'm pretty sure there are no regressions. If it does cause any problems, please let me know. This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library. P.S. For maximum portability, please use <boost/detail/iomanip.hpp> in Boost code in the future! - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0vurkACgkQ9cB/V3/s9Exh0gCdF5vcDD0DfyONhrob4YFVBZzO 2KwAoIqFS06nk5TV98K0jea1rTj6FkHF =QGJS -----END PGP SIGNATURE-----

6 16

Section on suppressing gcc warnings complete in boost warning guidelines
by Patrick Horgan 14 Jan '11

14 Jan '11

I added a section to the boost warnings guidelines page about suppressing warnings with GCC. I think it's pretty good bringing together information I got on the gcc-help list, from reading the source and from browsing through the documentation for various releases of GCC. If anyone wants to check it for correctness and/or style I would be very appreciative. I would in particular like to thank Jonathan Wakely for his willingness to help and for the great help he gave me on the gcc-help list. https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines If you scroll to the bottom directly you'll see the end of the section on suppressing GCC warnings. I moved it after the sections on turning on warnings and on how to deal with some common warnings to reflect the viewpoint of the document that suppressing should be the last resort. I have some improvements to make to the section on strict aliasing to reflect the better work I did in my white paper on the subject, and I know the common warnings section needs information on more common warnings. The way I picked the ones that are in there originally was by turning on warnings for an earlier version of boost, saving the output of building the whole tree, then checking to see what the most common warnings were that indicated real bugs. That was without running tests or any program that used boost. Just building boost. It's been a long time and much good work has been done in the tree to get rid of those, so I should take a look at that again by turning on the -Wsystem-headers -Wall -Wextra and maybe -Wpedantic and seeing what warnings pop up in boost code that indicate real problems again. Wouldn't it be great if there were none? The most painful one is -Wsystem-headers which tells GCC to report warnings even in files considered system files, but since many of the boost files include the #pragma GCC system_file it will be necessary to see the warnings. Unfortunately, that means that I'll see warnings from real system files as well. In boost there are 21 headers that include the pragma, 15 of them in boost/exception. It's possible that they all really have spurious warnings you can't code around. Those certainly exist. I hope they're documented as to why they use the pragma to save me time looking at them. Perhaps I'll find real bugs in them. Probably not though. Thank you, Patrick

1 0

[context/fiber] new version
by Oliver Kowalke 14 Jan '11

14 Jan '11

issues related to boost.move (msvc) and DLLs are fixed.

1 0

[ratio][mpl] static metafunctions
by vicente.botet 14 Jan '11

14 Jan '11

Hi, during the Boost.Ratio review as requested to push some of the static integer metafunctions as static_abs, static_sign, static_gcd, static_lcm to a public library. At the begining I has the impression that these functions should be added to Boost.Integer or Boost.Math, but after reflexion I think that these static metafunctions could be better integrated into Boost.MPL with the existing integral functions. I have prepared a patch for 3 of them. Do you think that these can be added to Boost.MPL if I provide the needed documentation and tests? Best regards, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 7

[announce] mirror-lib 0.5.2 released
by Matus Chochlik 14 Jan '11

14 Jan '11

Dear list, I would like to announce that a new version of the Mirror reflection library is available for download from SourceForge: http://sourceforge.net/projects/mirror-lib/files/mirror-lib-0.5.2/ Since version 0.5.0, Mirror is being developed outside the boost namespace, but the directory linked above contains also a 'boostified' version of the sources with Jamfiles etc. Besides the docs package, the documentation is also hosted online here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ To get the idea what the library can do you can look at the examples. http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/examples.html Some screenshots of input dialogs generated by the factory generator utility can be found here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/mirror__wx__gui__fact__… NOTE: Since Mirror uses C++1x AFAIK it will currently compile only with gcc (tested with gcc 4.5.1 and 4.5.2 64-bit on Linux and 4.5.1 on cywin) Questions, comments, feedback or potential contributions are always appreciated. Best regards, Matus

2 4

Files only in release branch
by Marshall Clow 14 Jan '11

14 Jan '11

As of revision 68145, there are a bunch of files that exist only in the release branch, and not in the trunk. Is this on purpose? boost/graph/kolmogorov_max_flow.hpp boost/pending/integer_range.hpp boost/smart_ptr/enable_shared_from_this2.hpp libs/functional/hash/test/container_fwd_test.cpp libs/functional/hash/test/container_no_fwd_test.cpp libs/graph/doc/kolmogorov_max_flow.html libs/serialization/vc7ide/polymorphic_derived2.vcproj libs/serialization/vc7ide/readme.txt libs/serialization/vc7ide/test_recusion.vcproj libs/test/example/cla/Jamfile libs/test/example/est_example1.cpp libs/test/example/est_example2.cpp libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/test/CMakeLists.txt tools/build/v2/doc/src/v1_vs_v2.xml tools/build/v2/engine/doc tools/build/v2/example/customization/jamfile.jam tools/inspect/run_inspect.sh -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 2

boost_thread-vc80-mt-1_43.dll "the application failed to inialize properly"
by Clark Sims 14 Jan '11

14 Jan '11

I can link to boost_thread-vc80-mt-1_43.lib with no problem, but when I try to run the executable, I et an error The application failed to initialize properly )0xc0150002) Clico on OK to terminate the application. Does anyone know how to fix this?

1 0

TTI library in the sandbox
by Edward Diener 14 Jan '11

14 Jan '11

I have uploaded to the sandbox 'tti' directory version 1.0 of the TTI library. The TTI library, which is an abbreviation for the Type Traits Introspection library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also lifts functionality, for the purposes of orthogonality, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection which other template metaprogrammers can use in their code. There is a readme.txt in the top-level sandbox tti directory, for anyone browsing the sandbox for interesting libraries, which replicates what is written here. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. There is a list of todo items in the sandbox on which I will be working for the next release, but the library is already feature rich. The library has been tested and works with gcc 4.30, 4.4.0, 4.5.0-1 and VC++ 8.0, 9.0, and 10.0. It may also work with other compilers. There is a bug in versions of gcc prior to version 4 for which I will attempt to find a workaround if it is deemed important, which prevents it from working with the library. Questions, comments, suggestions, and bug reports are all welcome.

2 2

[ASIO] Compilation error on NetBSD
by Marek Dopiera 14 Jan '11

14 Jan '11

Hello everybody, this is my first post to this list. Recently I got an error when compiling a program which uses ASIO on NetBSD. It is related to kqueue. From what I see it is caused by passing descriptor_state* to EV_SET. Under NetBSD it should be intptr_t. Moreover, the udata field of kevent is implicitly cast to void* later on, which also causes an error. Explicit casts solve the issue. Maybe it's worth adding? Could someone with commit access check it and eventually correct it, please? I don't know how it is under FreeBSD, maybe an ifdef is needed to support both. The relevant compilation error (boost-1.44.0, NetBSD 5.1, i386, gcc 4.3.1) In member function 'void boost::asio::detail::kqueue_reactor::start_op(int, boost::asio::detail::socket_type, boost::asio::detail::kqueue_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool)': asio/detail/impl/kqueue_reactor.ipp:132: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp:136: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp:142: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp: In member function 'void boost::asio::detail::kqueue_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&)': asio/detail/impl/kqueue_reactor.ipp:237: error: invalid conversion from '__intptr_t' to 'void*' [...] Regards

2 1

status of type traits addition (has_operator_xxx)
by Frédéric Bron 14 Jan '11

14 Jan '11

Here is the status of the type-traits addition: - I added the following operators: +=, *=, -=, /*, %=, &=, |=, ^=, <<, >>, >>=, <<=, prefix ++, prefix --, postfix ++, postfix -- so that the covered operators are now: - I added in the doc. the fact that private operators are not covered and lead to compile time errors - for operators on built-in types that require integer arguments (%, bitwise op.): I replaced a long list of specialiazation by an automatic detection Remaining work: 1. check what happens for pointer arguments, 2. implement trait for: . operator= . has_address_of_op<T> . has_dereference_op<T> . has_member_access_op<T> . has_subscript_op<T1 [,T2]> . has_pointer_to_member_op<T1 [,T2]> . has_comma_op<T1 [,T2]> . has_function_call_op<T,R [,P1, ...]> 3. have an MPL predicate for return value As I have only little time (full time work and 3 young children...), I will: - certainly do 1., - I will certainly leave 3. to somebody else in the future because I am not enough agile with MPL, - as for 2., 3 possibilities: (i) I do it but it will probably postpone the addition for a long time, (ii) I just leave it and I know is is a shame not to provide all operator detection (nobody's perfect) or (iii) somebody else agrees to add them and have them reviewed at the same time. Frédéric

3 2

[build]problems
by Matthias Schabel 13 Jan '11

13 Jan '11

Clean default install on OSX system with OpenMPI installed claims MPI is building, but does not build MPI component by default - it's a little confusing... ./bjam Building the Boost C++ Libraries. ...found 14 targets... ...updating 8 targets... common.mkdir bin.v2 common.mkdir bin.v2/libs common.mkdir bin.v2/libs/regex common.mkdir bin.v2/libs/regex/build common.mkdir bin.v2/libs/regex/build/darwin-4.2.1 common.mkdir bin.v2/libs/regex/build/darwin-4.2.1/debug darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o libs/regex/build/has_icu_test.cpp:12:30: error: unicode/uversion.h: No such file or directory libs/regex/build/has_icu_test.cpp:13:28: error: unicode/utypes.h: No such file or directory libs/regex/build/has_icu_test.cpp:14:27: error: unicode/uchar.h: No such file or directory libs/regex/build/has_icu_test.cpp:15:26: error: unicode/coll.h: No such file or directory libs/regex/build/has_icu_test.cpp: In function ‘int main()’: libs/regex/build/has_icu_test.cpp:23: error: ‘UErrorCode’ was not declared in this scope libs/regex/build/has_icu_test.cpp:23: error: expected `;' before ‘err’ libs/regex/build/has_icu_test.cpp:24: error: ‘UChar32’ was not declared in this scope libs/regex/build/has_icu_test.cpp:24: error: expected `;' before ‘c’ libs/regex/build/has_icu_test.cpp:25: error: ‘err’ was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -no-cpp-precomp -gdwarf-2 -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I"." -c -o "bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o" "libs/regex/build/has_icu_test.cpp" ...failed darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o... ...skipped <pbin.v2/libs/regex/build/darwin-4.2.1/debug>has_icu for lack of <pbin.v2/libs/regex/build/darwin-4.2.1/debug>has_icu_test.o... ...failed updating 1 target... ...skipped 1 target... ...updated 6 targets... Performing configuration checks - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam ...found 7 targets... ...updating 5 targets... common.mkdir bin.v2/libs/math common.mkdir bin.v2/libs/math/config common.mkdir bin.v2/libs/math/config/darwin-4.2.1 common.mkdir bin.v2/libs/math/config/darwin-4.2.1/debug darwin.compile.c++ bin.v2/libs/math/config/darwin-4.2.1/debug/has_gcc_visibility.o ...updated 5 targets... - ../config//has_gcc_visibility builds : yes ...found 47 targets... ...updating 1 target... darwin.compile.c++ bin.v2/libs/math/config/darwin-4.2.1/debug/has_long_double_support.o ...updated 1 target... - ../config//has_long_double_support builds : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - wave : building

2 1

[1.46.0] Unmerged changes to boost/detail
by Beman Dawes 13 Jan '11

13 Jan '11

The following files in boost/detail have not been merged to trunk. If appropriate, these should be merged. container_fwd.hpp wash 28 Dec 2010 endian.hpp johnmadddock 26 May 2010 extended_integer.hpp dwalker 24 Jul 2008 iomanip.hpp wash 08 Dec 2010 Thanks, --Beman PS: Who is "wash"?

6 13