- Boost - lists.preview.boost.org

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