- Boost - lists.preview.boost.org

Mag Gam
by Mag Gam 21 Jul '13

21 Jul '13

http://yumaonline.it/bau/bcjk.xvdhjqpdiniqwmxf Mag Gam 7/21/2013 7:26:51 AM

1 0

Re: [boost] [regression] patch for running tests in parallel and out-of-sync files
by Robert Kawulak 20 Jul '13

20 Jul '13

> From: Robert Kawulak > When I was running tests in parallel (using b2 -j option) I was getting random > warnings in the results table because "msvc.manifest" lines were interleaved with > compile/link actions. I've fixed this with the attached patch - is it OK to apply > it to trunk/release? Due to the lack of feedback I've gone ahead and applied the fix in trunk for now. If nobody objects or reports issues, I'll merge it into release later. > BTW, I've noticed that the following files in tools/regression/src haven't been > updated in release branch even though they've been changed in trunk a long time > ago: > compiler_status.cpp (trunk date 2012-01-21, release date 2011-10-06) > library_status.cpp (trunk date 2013-03-25, release date 2013-03-09) > Is it OK to update these in release branch? Likewise, I've updated the two files in release. I've also added tools/regression/build/bin directory to ignore list (it's created when invoking b2 from tools). Best regards, Robert

1 0

[git conversion] type_traits problems; spurious headers
by Beman Dawes 20 Jul '13

20 Jul '13

libs/type_traits/include/boost has these files: aligned_storage.hpp call_traits.hpp config.hpp smart_ptr.hpp timer.hpp type_traits.hpp utility.hpp AFAIK, call_traits.hpp and type_traits.hpp are supposed to be there, but the rest are spurious, and are causing "b2 headers" to create some incorrect links that are preventing testing many libraries. --Beman

2 1

[git-help] Status?
by Rene Rivera 20 Jul '13

20 Jul '13

I started looking at making the final minor set of changes to the regression testing scripts to have the option of testing the modular git version of the boost super-project. Unfortunately it now seems that the super-project no longer has *any* of the references to the library sub-projects. Me not being able to get this work done now is rather annoying as it likely means that the testing will not be ready early in the 1.55 release cycle. Which is the release currently scheduled to switch to git. What is the status of the git transition? When will the Boost release team be able to start working on the switch? Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

5 11

Re: [boost] A more convenient Variant visitation syntax
by Charlls Quarra 19 Jul '13

19 Jul '13

________________________________ De: Dave Abrahams <dave(a)boostpro.com> Para: boost(a)lists.boost.org Enviado: sábado, 14 de abril de 2012 22:49 Asunto: Re: [boost] A more convenient Variant visitation syntax on Sat Apr 14 2012, Thomas Heller <thom.heller-AT-googlemail.com> wrote: > On Sat, Apr 14, 2012 at 5:41 PM, Mathias Gaunard > <mathias.gaunard(a)ens-lyon.org> wrote: >> On 14/04/12 17:00, Kevin Wu Won wrote: >>> >>> This is C++11 only because it's quite pointless without lambda >>> functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, >>> which can't handle the variadic templates. >> >> >> It can be done in C++03 and expression-template-based lambdas just fine as >> well. >> >> All you need to do is generate a function object that inherits recursively >> from a set of other function objects. >> >> The function objects in question need to be either monomorphic or to be >> sufficiently constrained with SFINAE so that each operator() overload is not >> ambiguous. >> >> Unfortunately, Boost.Phoenix was never extended to support this. > > I really like the idea, and i think the C++11-based solution above is > nice! I didn't have the time yet to glance through the code though ... > > Phoenix didn't tackle that yet because it is a hard problem ... the > main problem is the syntax how to express which lambda is responsible > for what types. The above solution with C++11 lambdas is nice indeed! Yeah, the first time I've actually been happy that non-polymorphic lambdas exist! Nice idea, Kevin! > However, what's missing is something like a "catch all" aka a > templated lambda ... ...ah, yes... there's the rub. And my day is now spoiled :-) There is a catch all case. Just provide a lambda for boost::blank. See the original thread on StackOverflow where Me and R. Martinho Fernandes came up with the template syntax. There is also a complete code snippet with test cases on the post http://stackoverflow.com/q/7867555/170521

1 1

Boost Mingw w64 compilation issues and fixes
by Andrew Ho 19 Jul '13

19 Jul '13

Hi, I've been working on getting Boost to compile properly with Mingw w64 on Windows x64 (specifically, Mingw w64 with GCC 4.8.1 rev 2/Windows threads, http://sourceforge.net/projects/mingwbuilds/files/host- windows/releases/4.8.1/64-bit/threads-win32/seh/). Link to trac bug reports/patches: Boost config/Boost thread: https://svn.boost.org/trac/boost/ticket/8817 I believe this fix works with all target platforms, though I can't test with Windows CE to verify that it works. At least works with VS2012 and Mingw w64. Boost Python: https://svn.boost.org/trac/boost/ticket/8818 This fix again works with VS2012 and Mingw w64. It moves an #undef hypot directive (which python.h unfortunately uses) to be used any time python.h decides it needs to define it. I don't know if any platforms/compilers rely on having hypot being defined as a macro. Doesn't link for me because I think the official Windows Python release is built with VS, I'll need to find/build Python with Mingw w64 to see if it works. Boost Log: https://svn.boost.org/trac/boost/ticket/8819 (apparently has already been reported as https://svn.boost.org/trac/boost/ticket/8786) Boost Math: TBD There is some compile error with Boost Math which is causing my compiler to crash. I don't know if this is on the Boost Math side, or is a bug with Mingw w64. I'll submit a bug report and possibly a patch when I have a bit more time to dig into the issue. I think these are the main outstanding issues with getting Boost to compile with Mingw w64 on x64 Windows. I was able to get everything else to compile smoothly with Mingw w64 and VS2012 (targeting x64).

3 9

invalid "this is an old version of boost" links
by Mathieu Champlon 19 Jul '13

19 Jul '13

Hi, All the links at the top of documentation pages for previous versions of boost seem to have suddenly become invalid as they all link to http://www.boost.org/doc/libs/ For instance see http://www.boost.org/doc/libs/1_48_0/libs/config/doc/html/boost_config/boos… I cannot remember when I first noticed it, maybe a couple of weeks ago. Cheers, MAT.

2 1

[serialization][static_assert] Moving BOOST_STATIC_WARNING to Boost.StaticAssert?
by Petr Machata 19 Jul '13

19 Jul '13

Hi there, do you think it would make sense to move static_warning.hpp from boost/serialization up directly under boost/, and perhaps move it conceptually under Boost.StaticAssert umbrella? It seems strange how a serialization library exposes such general-purpose service. We could still provide a forwarding header in Serialization namespace for backward compatibility. Shall I prepare a patch to that effect? Thanks, PM

2 3

[git] creating symlinks in the git layout
by Beman Dawes 19 Jul '13

19 Jul '13

Steven added "Initial supprort for creating symlinks in the git layout" in changeset 84524. How is this support used? Is it working reliably? Thanks, --Beman

2 2

[bitstream] Copy stream buffer or pass pointer?
by Paul Long 18 Jul '13

18 Jul '13

While working on a bitstream library I proposed a while back (http://article.gmane.org/gmane.comp.lib.boost.devel/242574) I came across a design decision for which I'd like to get some feedback. The proposed bitstream library (https://github.com/dplong/bitstream) mimics the std::stringstream class hierarchy and semantics as close as possible. In general, when the consumer of the std::stringstream/stringbuf classes provides a string for the stream buffer, a copy gets made; likewise, when it retrieves the stream buffer, it gets a copy of the string. For example, the following snippet prints "hello, goodbye". char c[BUFSIZ] = "hello"; istringstream iss(c); strcpy(c, "goodbye"); cout << iss.str() << ", " << c; However, the library I'm working on doesn't copy. Instead, pointers are passed in and out. So, for example, this code prints "goodbye, goodbye". char c[BUFSIZ] = "hello"; ibitstream ibs(c); strcpy(c, "goodbye"); cout << ibs.data() << ", " << c; I don't think either way is more correct than the other. The reason I don't copy is for memory and CPU performance, thinking that the streams a bit-stream library typically processes are larger than the streams that a string-stream library processes and are more time critical. I very well may be mistaken, though. Anyway, what do you people think? Copy or don't copy? Maybe I should do copies just to follow the semantics of std::stringstream. Oh, also, am I being presumptuous by including "[bitstream]" in the Subject header of this post since it's just a _proposed_ library? IOW, should I stop doing that? Paul

3 3

[build] bootstrap.sh is triply broken on MinGW
by Stephan T. Lavavej 18 Jul '13

18 Jul '13

Hi, For over a year I've been suffering from bootstrap.sh being broken on MinGW, although I figured out a horrible hackaround. In 1.54.0 two more breaks appeared, and I figured out real fixes for them. I'd like to offer my real fixes here, and request two things: (A) a real fix to replace my horrible hackaround for the original bug, and (B) bootstrap.sh to be tested on MinGW for each release, because it's clearly not receiving sufficient coverage. The first break appears to be tracked by https://svn.boost.org/trac/boost/ticket/5680 and https://svn.boost.org/trac/boost/ticket/6350 . The problem is that bootstrap.sh and b2.exe don't agree on what MinGW should be called: is it mingw or is it gcc? No permutations of toolsets passed on the command lines work. I've used the following horrible hackaround in 1.49.0 through 1.54.0 inclusive: diff -aurN boost_1_54_0/bootstrap.sh boost_1_54_0-fixed/bootstrap.sh --- boost_1_54_0/bootstrap.sh 2013-03-09 14:55:05 -0800 +++ boost_1_54_0-fixed/bootstrap.sh 2013-07-18 00:12:38 -0700 @@ -215,7 +215,7 @@ if test "x$BJAM" = x; then echo -n "Building Boost.Build engine with toolset $TOOLSET... " pwd=`pwd` - (cd "$my_dir/tools/build/v2/engine" && ./build.sh "$TOOLSET") > bootstrap.log 2>&1 + (cd "$my_dir/tools/build/v2/engine" && ./build.sh mingw) > bootstrap.log 2>&1 if [ $? -ne 0 ]; then echo echo "Failed to build Boost.Build build engine" Of course, this is completely unacceptable for other toolsets, but I basically know nothing about Boost's build machinery, so I can't figure out a real fix. Ideally, bootstrap.sh followed by b2.exe would work automatically, without toolsets being specified. However, I would still be extremely happy if it worked with manually specified toolsets, as long as I didn't have to patch or sed files. The second and third breaks are new to 1.54.0 and are tracked by https://svn.boost.org/trac/boost/ticket/8762 . Here are my fixes that should work for all platforms: diff -aurN boost_1_54_0/tools/build/v2/engine/build.jam boost_1_54_0-fixed/tools/build/v2/engine/build.jam --- boost_1_54_0/tools/build/v2/engine/build.jam 2013-05-20 21:14:18 -0700 +++ boost_1_54_0-fixed/tools/build/v2/engine/build.jam 2013-07-18 00:12:43 -0700 @@ -483,8 +483,8 @@ make.c make1.c mem.c object.c option.c output.c parse.c pathsys.c regexp.c rules.c scan.c search.c subst.c w32_getreg.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c - modules/set.c modules/path.c modules/regex.c modules/property-set.c - modules/sequence.c modules/order.c ; + [ .path modules set.c ] [ .path modules path.c ] [ .path modules regex.c ] + [ .path modules property-set.c ] [ .path modules sequence.c ] [ .path modules order.c ] ; if $(OS) = NT { jam.source += execnt.c filent.c pathnt.c ; It appears that build.jam needs to use this .path machinery to generate either forward slashes or backslashes. When forward slashes are literally used, the bootstrap complains that it doesn't know how to make the corresponding object files. Once this is fixed, the final break is revealed: diff -aurN boost_1_54_0/tools/build/v2/engine/build.sh boost_1_54_0-fixed/tools/build/v2/engine/build.sh --- boost_1_54_0/tools/build/v2/engine/build.sh 2013-05-20 21:14:18 -0700 +++ boost_1_54_0-fixed/tools/build/v2/engine/build.sh 2013-07-18 00:12:43 -0700 @@ -247,18 +247,18 @@ BJAM_SOURCES="\ command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c\ hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c\ - object.c option.c output.c parse.c pathsys.c pathunix.c regexp.c rules.c\ + object.c option.c output.c parse.c pathsys.c regexp.c rules.c\ scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c\ builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c\ modules/path.c modules/regex.c modules/property-set.c modules/sequence.c\ modules/order.c" case $BOOST_JAM_TOOLSET in mingw) - BJAM_SOURCES="${BJAM_SOURCES} execnt.c filent.c" + BJAM_SOURCES="${BJAM_SOURCES} execnt.c filent.c pathnt.c" ;; *) - BJAM_SOURCES="${BJAM_SOURCES} execunix.c fileunix.c" + BJAM_SOURCES="${BJAM_SOURCES} execunix.c fileunix.c pathunix.c" ;; esac (It took me quite some time to figure out this one.) Although pathunix.c compiles on MinGW, it doesn't work, causing the bootstrap to complain about not being able to write its command file. The correct pattern to follow (as correctly done in build.jam; you can see half of it at the bottom of the build.jam diff here) is for pathnt.c to be used for mingw and pathunix.c to be used for all other build.sh platforms (i.e. real Unixes). Thanks, Stephan T. Lavavej

1 0

[container][set, map, flat_set, flat_map, +multi_xxx] operator< and operator== seems to ignore custom KeyCompare
by Thorsten Ottosen 18 Jul '13

18 Jul '13

Hi Ion & others, I think that there might be a problem in the implementation of operator< for these containers. There might be a problem with operator== too. The problem is that they all use some variant of the following definition: template <class Key, class Value, class KeyOfValue, class KeyCompare, class A> inline bool operator<(const rbtree<Key,Value,KeyOfValue,KeyCompare,A>& x, const rbtree<Key,Value,KeyOfValue,KeyCompare,A>& y) { return std::lexicographical_compare(x.begin(), x.end(), y.begin(), y.end()); } There is no KeyCompare (or other compare object) passsed to lexicographical compare. Reading up on the standard, it seems that all standard containers are implemented this way. Consequence: when having e.g. set<T*>, the comparison is not portable, since only std::less<T*> is guaranteed to be. So isn't this a defect? The other issue is perhaps more sensitive. What should users expect from typedef set<std::string,CaseInsensitiveLess> Set; Set s1{ "foo", "BAR" }; Set s2{ "FOO", "bar" }; assert( s1 < s2 ); // true? assert( s1 == s2 ); // true? I was at least surprised by this behavior. regards Thorsten

3 4

Git Modularization example Boost .gitattributes
by Niall Douglas 16 Jul '13

16 Jul '13

> > Shouldn't the repositories contain a .gitattributes file indicating the > > eol flavor to be used for text files where it has significance? > > Perhaps! I don't know anything about .gitattributes. Where can I find > out more? Dave, I can probably save you some work here with my "perfect" mirror of Boost's EOL and MIME type config into a .gitattributes with which I configured my subgit to mirror my git repo into Boost sandbox. Taken from https://github.com/ned14/TripleGit/blob/master/.gitattributes: * text=auto !eol svneol=native#text/plain *.gitattributes text svneol=native#text/plain # Scriptish formats *.bat text svneol=native#text/plain *.bsh text svneol=native#text/x-beanshell *.cgi text svneol=native#text/plain *.cmd text svneol=native#text/plain *.js text svneol=native#text/javascript *.php text svneol=native#text/x-php *.pl text svneol=native#text/x-perl *.pm text svneol=native#text/x-perl *.py text svneol=native#text/x-python *.sh eol=lf svneol=LF#text/x-sh configure eol=lf svneol=LF#text/x-sh # Image formats *.bmp binary svneol=unset#image/bmp *.gif binary svneol=unset#image/gif *.ico binary svneol=unset#image/ico *.jpeg binary svneol=unset#image/jpeg *.jpg binary svneol=unset#image/jpeg *.png binary svneol=unset#image/png *.tif binary svneol=unset#image/tiff *.tiff binary svneol=unset#image/tiff *.svg text svneol=native#image/svg%2Bxml # Data formats *.pdf binary svneol=unset#application/pdf *.avi binary svneol=unset#video/avi *.doc binary svneol=unset#application/msword *.dsp text svneol=crlf#text/plain *.dsw text svneol=crlf#text/plain *.eps binary svneol=unset#application/postscript *.gz binary svneol=unset#application/gzip *.mov binary svneol=unset#video/quicktime *.mp3 binary svneol=unset#audio/mpeg *.ppt binary svneol=unset#application/vnd.ms-powerpoint *.ps binary svneol=unset#application/postscript *.psd binary svneol=unset#application/photoshop *.rdf binary svneol=unset#text/rdf *.rss text svneol=unset#text/xml *.rtf binary svneol=unset#text/rtf *.sln text svneol=native#text/plain *.swf binary svneol=unset#application/x-shockwave-flash *.tgz binary svneol=unset#application/gzip *.vcproj text svneol=native#text/xml *.vcxproj text svneol=native#text/xml *.vsprops text svneol=native#text/xml *.wav binary svneol=unset#audio/wav *.xls binary svneol=unset#application/vnd.ms-excel *.zip binary svneol=unset#application/zip # Text formats .htaccess text svneol=native#text/plain *.bbk text svneol=native#text/xml *.cmake text svneol=native#text/plain *.css text svneol=native#text/css *.dtd text svneol=native#text/xml *.htm text svneol=native#text/html *.html text svneol=native#text/html *.ini text svneol=native#text/plain *.log text svneol=native#text/plain *.mak text svneol=native#text/plain *.qbk text svneol=native#text/plain *.rst text svneol=native#text/plain *.sql text svneol=native#text/x-sql *.txt text svneol=native#text/plain *.xhtml text svneol=native#text/xhtml%2Bxml *.xml text svneol=native#text/xml *.xsd text svneol=native#text/xml *.xsl text svneol=native#text/xml *.xslt text svneol=native#text/xml *.xul text svneol=native#text/xul *.yml text svneol=native#text/plain boost-no-inspect text svneol=native#text/plain CHANGES text svneol=native#text/plain COPYING text svneol=native#text/plain INSTALL text svneol=native#text/plain Jamfile text svneol=native#text/plain Jamroot text svneol=native#text/plain Jamfile.v2 text svneol=native#text/plain Jamrules text svneol=native#text/plain Makefile* text svneol=native#text/plain README text svneol=native#text/plain TODO text svneol=native#text/plain # Code formats *.c text svneol=native#text/plain *.cpp text svneol=native#text/plain *.h text svneol=native#text/plain *.hpp text svneol=native#text/plain *.ipp text svneol=native#text/plain *.tpp text svneol=native#text/plain *.jam text svneol=native#text/plain *.java text svneol=native#text/plain Hope that's useful. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 4

detail/endian.hpp replacement?
by Philip Bennefall 15 Jul '13

15 Jul '13

Hi all, I just wanted to ask about the possibility of getting the Boost licensed fix for detail/endian.hpp into the next release of Boost? It would be great to have that license ambiguity resolved for version 1.55.0. Kind regards, Philip Bennefall

2 2

[thread] Is future.then( scheduler , task ) abandoned?
by Klaim - Joël Lamotte 15 Jul '13

15 Jul '13

On this page: http://www.boost.org/doc/libs/1_54_0/doc/html/thread/future.html And in the task list: https://svn.boost.org/trac/boost/query?status=!closed&component=thread We can see that there are plans to add async( scheduler, task ). However there are no tasks for future.then( scheduler, task ). The documentation suggests that it will be implemented in a future release. So I just wanted a confirmation: is it still planned or is it abandoned? Or is it just a missing task? Joel Lamotte

2 2

Git Modularization hiccups
by Beman Dawes 15 Jul '13

15 Jul '13

* "git clone --recursive http://github.com/boostorg/boost modular-boost" is mostly working fine here (on Win7) but is producing one set of error messages: Cloning into 'libs/assign'... fatal: reference is not a tree: 57ec5d1534810090649b18c88e66a46f48cdcf1c ... Unable to checkout '57ec5d1534810090649b18c88e66a46f48cdcf1c' in submodule path 'libs/assign' The remaining hiccups are in the root directory, comparing trunk to master: * boost.css is missing content from revisions 36243 and 53553. * boost-build.jam has different comments and history. Something is totally whacky. * boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings. * Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings. * c++boost.gif not present in trunk, present in master. * index.html missing in master. * Jamfile.v2 and Jamroot.jam not present in trunk, present in master. * INSTALL missing in master. * LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master. * project-config.jam missing in master. * rst.cc missing in master. * README.txt not present in trunk, present in master. HTH, --Beman

9 17

Release branch now open for merging
by Marshall Clow 15 Jul '13

15 Jul '13

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

[function] type conversion ambiguity?
by Andrew Ho 15 Jul '13

15 Jul '13

Consider the overloaded functions foo and bar: typedef boost::function<void(void)> function_type1; typedef boost::function<void(int)> function_type2; typedef std::function<void(void)> function_type3; typedef std::function<void(int)> function_type4; void foo(const function_type1 &a) { // blah } void foo(const function_type2 &a) { // blah } void bar(const function_type3 &a) { // blah } void bar(const function_type4 &a) { // blah } calling foo with a function pointer is ambiguous, but calling bar is not: void doit1(void) {} void doit2(int) {} foo(&doit1); // ambiguous bar(&doit2); // compiles and runs fine This occurs despite the fact that boost::function<void(void)>(&doit2) can be caught at compile time. Is there some way to fix the definition of boost::function such that this is no longer ambiguous?

2 1

Nullable types
by Bjorn Reese 15 Jul '13

15 Jul '13

It seems like different Boost libraries use different nullable types. * Optional uses boost::none * Tribool uses boost::logic::indeterminate_keyword_t * Tuple uses boost::tuples::null_type * Variant uses boost::blank And there are possibly more. What are your opinions about unifying these?

4 3

Extremely large Visual Studio libboost_log_setup* binaries
by Tom Kent 14 Jul '13

14 Jul '13

In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs. Does anyone know if there is a reason for this? Is it a configuration error? Tom Kent

8 22

Boost.Operators and make_shared
by Pieter 13 Jul '13

13 Jul '13

LS, I have noticed that using Boost.Operators has a side-effect which I can't explain. I am using std::make_shared as a default, however, some of the boost libraries I use pull in boost::make_shared as well. When using some class T2 derived from one of the boost.operators classes, this causes MSVC2010 to not compile when invoking make_shared<T2> as the compiler can no longer resolve between the two overloaded versions of make_shared for some reason. I am hoping that someone out can explain what is happening here. A minimal example is included here: #include <memory> #include <boost\operators.hpp> #include <boost\make_shared.hpp> struct T1 {}; struct T2 : boost::equality_comparable<T2> {}; int main( int argc, const char* argv[] ) { T1 Object1; T2 Object2; using std::make_shared; std::shared_ptr<T1> Ptr1 = make_shared<T1>(Object1); // OK std::shared_ptr<T2> Ptr2 = make_shared<T2>(Object2); // error C2668: 'boost::make_shared' : ambiguous call to overloaded function return 1; } Thanks in advance! Pieter

4 6

[regression] patch for running tests in parallel and out-of-sync files
by Robert Kawulak 13 Jul '13

13 Jul '13

When I was running tests in parallel (using b2 -j option) I was getting random warnings in the results table because "msvc.manifest" lines were interleaved with compile/link actions. I've fixed this with the attached patch - is it OK to apply it to trunk/release? BTW, I've noticed that the following files in tools/regression/src haven't been updated in release branch even though they've been changed in trunk a long time ago: compiler_status.cpp (trunk date 2012-01-21, release date 2011-10-06) library_status.cpp (trunk date 2013-03-25, release date 2013-03-09) Is it OK to update these in release branch? Best regards, Robert

1 0

[log] Set default log source name
by Renato Forti 12 Jul '13

12 Jul '13

Hi All, Have any way to define a custon log source name on simple_event_log_backend! I foud a method to get (get_default_source_name), but where is "set" method! HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\do kagent simple event source I want set/change default name (in my case) : "dokagent simple event source" Thanks

2 1

[config] Feature request: BOOST_OVERRIDE
by Borislav Stanimirov 12 Jul '13

12 Jul '13

Hi, I think it will be a nice feature to add BOOST_OVERRIDE to Boost.Config in a manner similar to BOOST_CONSTEXPR. It's a nice keyword and it would be nice if people could make use of it when it's available. -- Borislav

5 4

multi_index broken on gcc4.7
by Hartmut Kaiser 12 Jul '13

12 Jul '13

In code which compiled just fine until yesterday I'm now seeing: /opt/boost/trunk-release/boost/multi_index/detail/index_base.hpp: In member function 'std::pair<typename boost::multi_index::detail::multi_index_node_type<Value, IndexSpecifierList, Allocator>::type*, bool> boost::multi_index::detail::index_base<Value, IndexSpecifierList, Allocator>::final_emplace_(Args&& ...)': /opt/boost/trunk-release/boost/multi_index/detail/index_base.hpp:214:29: error: expected primary-expression before ')' token /opt/boost/trunk-release/boost/multi_index/detail/index_base.hpp: In member function 'std::pair<typename boost::multi_index::detail::multi_index_node_type<Value, IndexSpecifierList, Allocator>::type*, bool> boost::multi_index::detail::index_base<Value, IndexSpecifierList, Allocator>::final_emplace_hint_(boost::multi_index::detail::index_base<Value , IndexSpecifierList, Allocator>::final_node_type*, Args&& ...)': /opt/boost/trunk-release/boost/multi_index/detail/index_base.hpp:233:16: error: expected primary-expression before ')' token OS: Debian Unstable Kernel: Linux 3.2 GCC: 4.7 (C++11, x86-64) Boost: SVN Trunk Build Type: Release Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2