- Boost - lists.preview.boost.org

[conversion] Isolating the phantom file changes problem
by Beman Dawes 01 Dec '13

01 Dec '13

This is the simplest case I could come up with where git clone produced a initially modified state. Any ideas why this is happening? Is this another manifestation of crlf problems? --Beman D:\modular-boost\libs\intrusive>git clone --recursive git@github.com:boostorg/boost.git modular-boost ... much output, no apparent error messages... D:\modular-boost>git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: libs/interprocess (modified content) # modified: libs/intrusive (modified content) # modified: libs/pool (modified content) # no changes added to commit (use "git add" and/or "git commit -a") D:\modular-boost>cd libs/pool D:\modular-boost\libs\pool>git status # Not currently on any branch. # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: doc/images/mb1.svg # modified: doc/images/mb2.svg # modified: doc/images/mb3.svg # modified: doc/images/mb4.svg # modified: doc/images/pc1.svg # modified: doc/images/pc2.svg # modified: doc/images/pc3.svg # modified: doc/images/pc4.svg # modified: doc/images/pc5.svg # no changes added to commit (use "git add" and/or "git commit -a") D:\modular-boost\libs\pool>cd ..\interprocess D:\modular-boost\libs\interprocess>git status # Not currently on any branch. # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: proj/vc7ide/managed_shared_memory.vcproj # modified: proj/vc7ide/offset_ptr_test.vcproj # no changes added to commit (use "git add" and/or "git commit -a") D:\modular-boost\libs\interprocess>cd ..\intrusive D:\modular-boost\libs\intrusive>git status # Not currently on any branch. # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: proj/vc7ide/avl_multiset/avl_multiset.vcproj # modified: proj/vc7ide/avl_set/avl_set.vcproj # modified: proj/vc7ide/sg_multiset/sg_multiset.vcproj # modified: proj/vc7ide/sg_set/sg_set.vcproj # modified: proj/vc7ide/splay_multiset/splay_multiset.vcproj # modified: proj/vc7ide/splay_set/splay_set.vcproj # no changes added to commit (use "git add" and/or "git commit -a")

7 25

An open typeswitch using lambdas
by Sumant Tambe 30 Nov '13

30 Nov '13

Hi, I would like to get feedback on a small typeswitch library I've been working on for some time now. The library is designed to dispatch code (lambdas) based on the actual value of boost::any, boost::variant, and also general polymorphic hierarchies. An example is in order. template <class Poly> void test_poly(Poly& p) { match(p)( [](int i) { std::cout << "int = " << i << "\n"; }, [](double d) { std::cout << "double = " << d << "\n"; }, [](const std::string &s) { std::cout << "string = " << s << "\n"; }, [](std::ostream &o) { std::cout << "found ostream" << "\n"; } ); } int main(void) { std::ios_base &stream = std::cout; boost::any any(std::string("C++ Truths")); boost::variant<int, std::string> var("boost"); double d = 9.99; test_poly(stream); // prints found stream test_poly(any); // prints string = C++ Truths test_poly(d); // prints double = 9.99 test_poly(var) // prints string = boost } The implementation of the library is a little over 250 lines. Check it out here: http://coliru.stacked-crooked.com/a/72597a93b12916d4. clang is the only compiler I've been able to compile it with. It resembles Scala's match statement. Scala's match is way more powerful than what I've been able to achieve with C++ library emulation. It is also quite similar to Stroustrup's "Open and Efficient Typeswitch for C++" ( http://www.stroustrup.com/OOPSLA-typeswitch-draft.pdf) A quick benchmark shows that lambda-based typeswitch is about 4 to 5 times *slower*. If there is sufficient interest, I would be thrilled to contribute this library to boost. I believe it can be further generalized to support n-ary method dispatching. Thoughts? R/ Sumant

4 7

[git] Line endings in bootstrap.bat on Windows
by Björn Pollex 29 Nov '13

29 Nov '13

I just cloned the modularized Boost repository from Github [1]. Right after the clone is done, git status gives me a complete diff on bootstrap.bat (so probably line endings). I do have autocrlf = true in my system configuration, so this shouldn't be the problem, right? Is anyone else seeing this? Am I doing something wrong? If so, how to do it correctly? Regards, Björn Pollex [1] https://github.com/boostorg/boost

16 41

Is there a thin array wrapper/proxy lying around somewhere?
by Mostafa 29 Nov '13

29 Nov '13

(Yes, I'm aware of boost.array, boost.multiarray, and std::vector.) Is there any thin but complete array wrapper/proxy lying around somewhere in boost? A class that if substituted for an array will behave just like the substituted array? Thanks, Mostafa

7 10

Re: [boost] [conversion] Enforcing tabs to spaces conversions and other git goodies.
by Cox, Michael 28 Nov '13

28 Nov '13

Michael On Thu, Nov 28, 2013 at 8:06 AM, Beman Dawes <bdawes(a)acm.org> wrote: > > On Thu, Nov 28, 2013 at 5:00 AM, Mateusz Loskot <mateusz(a)loskot.net> wrote: > > > On 28 November 2013 08:49, Cox, Michael <mhcox(a)bluezoosoftware.com> wrote: > > > In addition to re-normalizing the line endings, we could also start > > > enforcing coding standards, e.g. tabs converted to spaces standard via > > > gitconfig/gitattribute filters. Git allows you to define filters in your > > > .git/config or ~/.gitconfig file and specifying their use in > > > .gitattributes, e.g. in .gitconfig: > > > > > > # Convert tabs to 4 spaces (uses Linux expand/unexpand commands, so not > > > cross-platform) > > > [filter "tabspace"] > > > smudge = unexpand --tabs=4 --first-only > > > clean = expand --tabs=4 --initial > > > [...] > > > > ...automatically behind the scene? Scary! > > > > IMHO, this belongs to commit hooks. > > > > Qt's sanitize-commit may be a good example > > > > https://qt.gitorious.org/qt/qtrepotools/source/b69da7d675774be14027808328ea… > > > > Michael and Mateusz, > > Yes - sanitizing and commit hooks are important topics. But the way to > handle them is to start a new thread so that they don't get lost in the > line-ending bicycle shed discussion. > > Thanks, > > --Beman Mateusz, I agree hooks have to be used for the "golden" boostorg repositories since folks may forget to configure their local/public repositories with the appropriate hooks/filters, but if Boost goes fully distributed like Linux, there may be a lot of integration repositories a change flows through on it's way to boostorg and it's probably best to get the code normalized as soon as possible. Michael

1 0

More flexible any_cast for boost::any
by DeadMG 28 Nov '13

28 Nov '13

Hello, I've been looking at ABIs and such (various unpleasant reasons). But I recently created the following code: #include <iostream> struct Base { virtual void check() = 0; template<typename T> T* IsDerivedFrom() { try { check(); } catch(T* p) { return p; } catch(...) { return nullptr; } return nullptr; } }; template<typename T> struct Derived : public Base { Derived(T obj) : t(obj) {} T t; void check() override final { throw &t; } }; struct A { virtual ~A() {} virtual void print() = 0;}; struct B : public A { int x; B(int y) : x(y) {} void print() override final { std::cout << x; } }; int main() { Base* b = new Derived<B>(B(5)); A* p = b->IsDerivedFrom<A>(); p->print(); } Whilst this is hardly the cleanest piece of code I've ever written, it also provides a base for implementing a more generic any_cast<ValueType>, which could succeed if ValueType is a base class of the stored type. Amazingly, the Standard requires the code to work but does not provide a cleaner means of implementation. I also note that, for some configurations, you could fall back to the Itanium ABI provided function directly, which would presumably be substantially faster and cleaner. Enabling this variety of any_cast would substantially improve the composability of boost::any. For example, it's arguable that std::function is merely boost::any but with additional interface requirements. With such an any_cast enhancement, it would be quite trivial to compose std::function implementations or similar concepts on top of boost::any.

5 7

Re: [boost] [conversion] Isolating the phantom file changes problem
by Cox, Michael 28 Nov '13

28 Nov '13

In addition to re-normalizing the line endings, we could also start enforcing coding standards, e.g. tabs converted to spaces standard via gitconfig/gitattribute filters. Git allows you to define filters in your .git/config or ~/.gitconfig file and specifying their use in .gitattributes, e.g. in .gitconfig: # Convert tabs to 4 spaces (uses Linux expand/unexpand commands, so not cross-platform) [filter "tabspace"] smudge = unexpand --tabs=4 --first-only clean = expand --tabs=4 --initial Then in .gitattributes: # Code formats *.c text filter=tabspace *.cpp text filter=tabspace *.h text filter=tabspace *.hpp text filter=tabspace *.ipp text filter=tabspace *.tpp text filter=tabspace On a related topic, what is the svneol .gitattribute being used in the .gitattributes file do? I couldn't find it documented (I discovered the filter attribute while searching for the svneol attribute). Also, the mime type specified in a # comment following some attribute rule specification doesn't seem to be a supported syntax, i.e. the '#' has to be in the first column. Michael On Wed, Nov 27, 2013 at 3:02 PM, Gavin Lambert <gavinl(a)compacsort.com>wrote: > On 28/11/2013 05:17, Quoth Dave Abrahams: > > Another possibility might be to explicitly mark all text files in >>> .gitattributes with eol=lf and then run the conversion; I think that >>> would fix the repository blobs, >>> >> >> What goes into .gitattributes has no effect on the content of blobs in >> the repository. >> > > Sorry, when I wrote that I was envisaging the conversion process doing the > equivalent of an SVN checkout and then git add/commit. (And git commit > does take the attributes into account for eol conversion.) > > Since apparently it doesn't work like that, just ignore that suggestion. > > I still think that we need to renormalise the line endings though. Whether > that's done as a reconversion (fixing history) or just as an extra commit > (fixing current heads), that's up to you guys. ;) > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/ > mailman/listinfo.cgi/boost >

3 2

[conversion] Verification check results: svn trunk vs git develop
by Beman Dawes 28 Nov '13

28 Nov '13

* There is an entire library, Boost.Compose, long since deprecated and removed from svn in favor of Boost.Bind or Boost.Lambda, present in the git repos, both in master and develop. * Boost.Interprocess, git develop contains a header libs\include\boost\interprocess\fully_mapped_file.hpp that does not appear in the svn trunk head. * Boost.Type-Traits, git develop contains a header directory, \include\boost\detail, with two header files. Neither these two headers nor the directory are present in svn trunk head. * All 9974 headers in svn trunk/boost head have git super-project boost header entries generated by "b2 headers" and the content, ignoring end of line differences, is identical in all of them. * Exactly the same 5680 regression tests passed for both svn trunk head and git develop head. It doesn't get any better than that! --Beman

2 2

[exception][range] boost/range/size_type.hpp + unexpected dependenciies Exeception -> Units -> Algorithms -> Range -> Concepts
by Vicente J. Botet Escriba 28 Nov '13

28 Nov '13

Hi, The regression test signal this error Test output: MinGW-w64-4.5 jc-bell.com - thread - async__async_p / gcc-mingw-4.5.4 Rev 85699 / Mon, 16 Sep 2013 13:58:07 +0000 Compile [2013-09-16 17:53:55 UTC]:fail "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -mthreads -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "F:\boost\GCC\trunk\results\boost\bin.v2\libs\thread\test\async__async_p.test\gcc-mingw-4.5.4\debug\threading-multi\sync\futures\async\async_pass.o" "..\libs\thread\test\sync\futures\async\async_pass.cpp" In file included from ../boost/range/size.hpp:21:0, from ../boost/range/functions.hpp:20, from ../boost/range/iterator_range_core.hpp:28, from ../boost/range/iterator_range.hpp:13, from ../boost/algorithm/string/replace.hpp:16, from ../boost/units/detail/utility.hpp:25, from ../boost/exception/detail/type_info.hpp:19, from ../boost/exception/detail/object_hex_dump.hpp:15, from ../boost/exception/to_string_stub.hpp:16, from ../boost/exception/info.hpp:16, from ../boost/exception/detail/exception_ptr.hpp:20, from ../boost/exception_ptr.hpp:9, from ../boost/thread/future.hpp:28, from ..\libs\thread\test\sync\futures\async\async_pass.cpp:29: ../boost/range/size_type.hpp:80:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:80:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:87:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:87:5: error: expected ';' before '}' token BOOST_RANGE_CONCEPT_ASSERT((boost::SinglePassRangeConcept<T>)) This is surely due to a changeset on Boost.Range (85690?). Maybe an inclusion to Concepts is missing. Could the maintainer take a look? What is more surprising is the chain of dependencies the inclusion of boost/exception_ptr.hpp conveys. Exeception -> Units -> Algorithms -> Range -> Concepts. Is there a way to break these dependencies? Best, Vicente

4 8

Git conversion fixes
by Dave Abrahams 28 Nov '13

28 Nov '13

We have two issues currently extant: 1. Some files that were deleted in SVN history are still present in the Git HEAD 2. Some people are dissatisfied with the way line endings are handled, especially on Windows I didn't expect to spend my Thanksgiving vacation working on this stuff, but I am getting myself set up to diagnose and fix #1. I am not going to try to fix #2, mostly because it's too open-ended, and there isn't even a consensus in the community about what a fix should look like. If a consensus is formed around a desired outcome, I am willing to at _least_ help in an advisory capacity, in which case someone should send me a personal email. Thanks, Dave

5 5

[build] clang-win help needed
by Edward Diener 28 Nov '13

28 Nov '13

The clang-win.jam file, which was provided by 'tr1gun' as an attachment to another thread in Boost Build, inherits its generators, flags, and rules from msvc.jam. The lines in clang-win.jam are: toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ; In order to eliminate the VC++ /EH(x) option, which clang using VC++ RTL does not use, I added into the file a rule: rule compile.c++ ( targets * : sources * : properties * ) { C++FLAGS on $(targets) = [ set.difference [ on $(targets[1]) return $(C++FLAGS) ] : /EHs ] ; } suggested by Steve Watanabe. This effectively eliminates the /EHs option when compiling with clang. However when a 'run' action is done, with clang as the compiler, the compile step is never called. If I remove the 'rule compile.c++' from the clang-win.jam file the compile step is called before the link and execute steps of the 'run' action, but of course the compile step then issues the /EHs warning which the insertion of the above rule eliminated. Does anybody know why adding the above rule causes the 'run' action to not compile the appropriate fle before attempting the link and execute ?

1 0

Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
by Niall Douglas 27 Nov '13

27 Nov '13

Please let me know as soon as possible any errata, missing credits etc. Niall Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013 This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas http://www.nedprod.com/. Source: https://github.com/apolukhin/type_index/zipball/master Documentation: http://apolukhin.github.com/type_index/index.html Peer review discussion detail: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library… My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Joël Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd. Contents: · Summary of consensus from peer review ......................................................................................................... 1 · My recommendation to the library author and the Review Wizards ................................................................ 3 Summary of consensus from peer review: The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation). Note that my personal opinion based on post-review reflection is written in [square bracketed italics]. · Many seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay. [I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be “ported” to it due to having a breaking API, but thereafter produces reliable code. I’ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.] · A large minority seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info’s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers. [This is really use case (iii) in the previous item.] · It was mentioned that it should be possible to optionally specialise std::hash<> for type_info for optional seamless use in hash taking containers. · Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred. [This is really use case (iii) in the previous item.] · boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate. [I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.] · Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion. [I agree] · It was mentioned that some function-local static data members are initialised in a thread unsafe way. [For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?] · Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don’t technically exist there. Checks for their existence ought to be within a function. · It was requested that a boost::type_id<> which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index<T> type would be valuable. · A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested. My recommendation to the library author and the Review Wizards: · In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc. A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be: Text Box: /*! Returns a static const char string of unknown format uniquelyidentifying this type.The only guarantee is that this string will beunique to the type within this process lifetime. */const char *unique_name() const noexcept;/*! Returns a representation of this type suitable for printing.This call may take some time as its storage may not be cached. */std::string pretty_name() const;class enum mangling{Native, //!< Whatever the native mangling used by this toolset isMSVC, //!< The Microsoft C++ mangling formatItanium //!< The Itanium C++ mangling format};/*! Returns the mangled form of the string representation of the type.After the calculation the value is cached statically such that the c_str()function can be used to convert the returned string to a const char *format identical to what may be returned by std::type_info::name() (orraw_name() on MSVC).This function may throw an exception if it does notsupport mangled type string calculation, including when mangling=Native onsome Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions. · In other words, here I think “less is more” in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution. · I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested. Niall Douglas Waterloo, Canada, November 2013

6 26

[conversion] Verification check results: svn branches/release vs git master
by Beman Dawes 27 Nov '13

27 Nov '13

* As reported previously, the follow extra header files are present in the git repos: > boost\functional\hash\Attic\deque.hpp > boost\functional\hash\Attic\list.hpp > boost\functional\hash\Attic\map.hpp > boost\functional\hash\Attic\pair.hpp > boost\functional\hash\Attic\set.hpp > boost\functional\hash\Attic\vector.hpp > boost\property_tree\detail\exceptions_implementation.hpp > boost\property_tree\detail\path_implementation.hpp > boost\property_tree\detail\pugxml.hpp > boost\property_tree\detail\translator_implementation.hpp > boost\property_tree\detail\xml_parser_read_pugixml.hpp > boost\property_tree\detail\xml_parser_read_pugxml.hpp > boost\property_tree\detail\xml_parser_read_spirit.hpp > boost\property_tree\detail\xml_parser_read_tinyxml.hpp * There were no missing header files in master. * Except for line endings and svn $Id$, $Revision$, and $Date$, there were no differences in content between header files in svn branches/release and git master. * Regression tests were run on both svn branches/release and git master. 5447 tests passed on each, however each had one test that passed on it but failed on the other. See the following two items for details. * Boost.Thread test_thread_lib passed on svn branches/release (and in the public regression tests) but failed on svn master. The message was: ====== BEGIN OUTPUT ====== Running 8 test cases... d:/modular-boost/libs/thread/test/./util.inl(160): fatal error in "test_creation_through_reference_wrapper": Timed test didn't complete in time, possible deadlock. *** 1 failure detected in test suite "Master Test Suite" EXIT STATUS: 201 ====== END OUTPUT ====== Windows decided to go to sleep in the middle of the run, and that may account for this error. * Boost.Thread ex_executor_lib passed in git master, but failed in svn branches/release. The message was: ====== BEGIN OUTPUT ====== 1178 ..\libs\thread\test\..\example\executor.cpp[ 58] int __cdecl main(void) 940 6776 ..\libs\thread\test\..\example\executor.cpp..\libs\thread\test\..\example\executor.cpp[[ 2126] ] void __cdecl p1(void)void __cdecl p2(void) 940 d5c1a78 ..\libs\thread\test\..\example\executor.cpp..\libs\thread\test\..\example\executor.cpp[[ 2121] ] void __cdecl p1(void)void __cdecl p1(void) d5c 1a78 ..\libs\thread\test\..\example\executor.cpp..\libs\thread\test\..\example\executor.cpp[[ 2621] ] void __cdecl p2(void)void __cdecl p1(void) ..\libs\thread\test\..\example\executor.cppd5c [ 1a..\libs\thread\test\..\example\executor.cpp] [void __cdecl p2(void)26 ] void __cdecl p2(void) 940 d5c ..\libs\thread\test\..\example\executor.cpp..\libs\thread\test\..\example\executor.cpp[[ 2126] ] void __cdecl p1(void)void __cdecl p2(void) d5c 940 ..\libs\thread\test\..\example\executor.cpp..\libs\thread\test\..\example\executor.cpp[[ 3131] ] int __cdecl f1(void)int __cdecl f1(void) Assertion failed: 0 && "Boost::Chrono - Internal Error", file C:\boost\svn-release-final\boost/chrono/detail/inlined/win/chrono.hpp, line 44 1178 ..\libs\thread\test\..\example\executor.cpp[ 67] int __cdecl main(void) t1= 1 EXIT STATUS: 3 ====== END OUTPUT ====== I have no idea why it would pass for testers but not for me, but am much less worried about a failure in svn branches/release than git master. --Beman

3 5

[conversion] Serious header integrity test failures.
by Beman Dawes 27 Nov '13

27 Nov '13

This integrity test verifies that every header file present in svn branches/release and trunk is also present in git master and develop, respectively, and visa versa. The branches/release vs master comparison is in pretty good shape - no missing headers, but a small number of extra headers. Two libraries are affected. But the trunk vs develop comparison turned up problems in many libraries. For example, the whole Boost.Chrono stopwatches sub-directory is missing. These look serious. What is the fix? --Beman

4 12

Code to address requirement 7(a) of IOStreams Roadmap
by Gene Panov 26 Nov '13

26 Nov '13

Colleagues, I posted this before, but didn't get answers to some questions so far. I think I addressed the "output" part of requirement 7(a) from the IOStreams Roadmap: https://svn.boost.org/trac/boost/wiki/IostreamsRoadmap in this library: https://code.google.com/p/async-ostream/ Does anyone mind if I create a patch for Boost.IOStreams to add those five files and ask the maintainer (or volunteers) for feedback? Regards, Gene

5 14

[type_erasure]
by Andrzej Krzemienski 26 Nov '13

26 Nov '13

Hi, I am trying to use Boost.TypeErasure library with a 'concept' that provides contextual conversion to *bool*. That is, I want to type-erase types that provide the following operations for some invented object *o*: * if (o) {}* * if (!o) {}* * bool (o); * I cannot find a predefined concept for that, nor can I use BOOST_TYPE_ERASURE_MEMBER or BOOST_TYPE_ERASURE_FREE, because that will not work for built in types. Is there any convenience tool that enables specifying such concept? Regards, &rzej

2 2

{git]
by Richard Dale 25 Nov '13

25 Nov '13

Probably the problem is between the keyboard and chair, but ... what's up? On which end is permission denied? rsd/myroot> git clone git@github.com:boostorg/boost.git modular-boost Cloning into 'modular-boost'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. users/rsd> git --version git version 1.7.12.4 ??

3 3

New Version (0.4.2) of proposed Boost.Application library is available.
by Renato Forti 25 Nov '13

25 Nov '13

Documentation: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html Code: https://github.com/retf/Boost.Application News in this release: * Now aspect_map class is Thread Safe. * Now aspect_map interface use names are more in line with the STL (e.g.: insert, find and so on) The documentation of aspect_map: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost/applic ation/aspect_map.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost/applica tion/aspect_map.html * Some fixes on code and docs. Please send your comments!

1 0

Re: [boost] Boost Digest, Vol 4191, Issue 4
by Cox, Michael 25 Nov '13

25 Nov '13

On Sun, Nov 24, 2013 at 3:57 PM, <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > Date: Sun, 24 Nov 2013 23:20:43 +0100 > From: Bj?rn Pollex <bjoern.pollex(a)googlemail.com> > To: boost(a)lists.boost.org > Subject: [boost] [git] Line endings in bootstrap.bat on Windows > > I just cloned the modularized Boost repository from Github [1]. Right after > the clone is done, git status gives me a complete diff on bootstrap.bat (so > probably line endings). > > I do have autocrlf = true in my system configuration, so this shouldn't be > the problem, right? Is anyone else seeing this? Am I doing something wrong? > If so, how to do it correctly? > > Regards, > > Bj?rn Pollex > > [1] https://github.com/boostorg/boost > > I think "they" are working on it. See the following links: http://lists.boost.org/Archives/boost/2013/10/208067.php http://lists.boost.org/Archives/boost/2013/11/208141.php

2 1

[TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
by Niall Douglas 25 Nov '13

25 Nov '13

Boost community feedback is requested for the formal peer review of the TypeIndex library by Antony Polukhin. Feedback requested includes: 1. Should this library be accepted into Boost? 2. Any conditions which should be attached to acceptance into Boost e.g. fixes, additional testing, changes to documentation. Please be as specific as possible here (bullet points are good!) Peer review ends on Thursday 21st Nov, ten days from today. Based on your feedback, at that point I will decide if I recommend TypeIndex for inclusion in my report to the review wizards. Comments can be posted to boost(a)lists.boost.org if you expect others to comment on your post, or to me privately if you wish your comment to not be made public. What is Boost.TypeIndex? TypeIndex performs three main functions: 1. It provides a consistent, well defined, portable boost::typeid() implementation with a consistent, well defined, portable boost::type_info class implementation which mirrors std::type_info. Implementation-specific weirdnesses (e.g. std::type_info::raw_name(), the fact the hash_code is often terrible and collides frequently) are abstracted out into a single, portable API. 2. It provides the ability to convert a type into a uniquely identifiable, container indexable, boost::type_info instance (e.g. &typeid(T) or C++11 class std::type_index) with RTTI disabled, thereby removing the need for requiring RTTI enabled for many type_info use cases. Any features which require RTTI are very clearly denominated in the API's name. 3. It allows the following Boost libraries to eliminate their dependency on RTTI which is a big win for embedded systems use, and it supplies patches for these libraries replacing RTTI std::type_info with boost::type_info. Feedback from the maintainers and users of these Boost libraries is *particularly* welcomed: Any, Graph, Property Map, Property Tree, Test, Variant, Xpressive I believe that TypeIndex meets the Boost library requirements at http://www.boost.org/development/requirements.html, and I have personally verified that it builds and passes all unit tests on GCC 4.6, clang 3.0 and MSVCs 10-12 [1]. I should add that Antony has already done three rounds of changes according to my feedback, and my thanks to him for being so dilligent and responsive. NOTE: Please read the TypeIndex documentation (linked to below) before asking any questions e.g. about potential code bloat etc. You'll probably find the answer already there. Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Any questions about topics not in the documentation? Please do ask. [1]: A single unit test currently always is reported as failing to link correctly on MSVC. Antony believes this to be a bug in Windows bjam, as the Jamfile marks the link as expected to fail using link-fail but bjam does not respect this on Windows in this one use case scenario (yet weirdly the other expected link failures work fine!). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

12 85

PDB files missing from Windows binaries
by Fredrik Orderud 24 Nov '13

24 Nov '13

First, I want to give a big thank for the streamlined availability of precompiled Windows binaries. The "Windows binaries" link from the Boost download webpage significantly lowers the barriers for Boost usage on the Windows platform. That said, there seem to be an issue with missing PDB files from the most recent Boost 1.55 binaries. This makes it difficult to debug applications, since debug information is missing. I suspect that the reason for the missing PDBs is that the build script doesn't install them to the target folder, which have previously been reported on [1]. Unfortunately, there has been little response to this problem. Would if be possible for someone to look into this problem, and improve the build script? [1] http://lists.boost.org/boost-build/2013/08/26894.php Thanks in advance, Fredrik

5 5

[build] File / path lengths difficult to manage on Windows
by Ben Craig 24 Nov '13

24 Nov '13

I was unzipping boost 1.55 on my Windows machine, into what I thought was a reasonable location. 7-zip eventually complained about a file that it could not write because the path was too long. Most APIs on Windows restrict paths to ~260 characters. The longest file in the boost 1.55 release is the following: boost_1_55_0\libs\geometry\doc\html\geometry\reference\spatial_indexes\boost__geometry__index__rtree\rtree_parameters_type_const____indexable_getter_const____value_equal_const____allocator_type_const___.html This is 207 characters long. Next on the list are a whole bunch of html and png documentation files, all with length 174. Here is one example: boost_1_55_0\doc\html\images\accumulators\structboost_1_1accumulators_1_1detail_1_1is__tail__variate__feature_3_01tag_1_1tail__variate_3_01bd5040caa5e48b0af425af2314206bf.png As you may notice, the end of that particular file ends in a uuid / guid. It may be as easy as making that uuid appear 30 or 40 characters sooner in the path. ************************************************************************************************************** Is it unreasonable to ask that the boost zip only use half (130 characters) of the available Windows path size for itself? ************************************************************************************************************** On a related note, is it unreasonable to ask that an --abbreviate-paths build of boost limit itself to 130 characters? I acknowledge that this one is a bit harder to solve as there can be a large number of build "pivots" that all add to the path, but some clients (like me) need to layer other build pivot and version information on top of what boost already provides, and I need some amount of character wiggle room to make that happen. This isn't currently in as bad of a shape as the zip file. For an outdated piece of information, my win64 builds of boost 1.50 have a path part of 151 characters. boost\bin.v2\libs\test\build\msvc-11.0\rls\adrs-mdl-64\async-excpt-on\dbg-symbl-on\lnk-sttc\thrd-mlt\libboost_unit_test_framework-vc110-mt-1_50.lib.rsp Is there significant value in putting "bin.v2\libs" in the path?

6 16

[Config] Need more macros for VS2013
by Daryle Walker 24 Nov '13

24 Nov '13

I tried to use Visual Studio 2013 for the first time. I added the version of Boost 1.55 from NuGet. I've been adding macros from Boost.Config to help, but we need some more: 1. VS2013 doesn't support the "alignof" operator. 2. VS2013 doesn't support in-class class-static constants besides integers and enumerations. In my case, I had an array of size_t. C++11 is supposed to allow any literal (including arrays thereof) type. I had some other weird errors that are show-stopping. 1. I guess VS2013 uses smart iterators for std::array by default/debugging-mode. They don't convert to a pointer-to-element-type. I changed one function to use a pair of const_iterator, but a different function gave an internal error (C1001) when I tried to fix that one. 2. Boost.Test macros are complaining all over about mismatched arguments. When using MinGW, I used Boost from the trunk, because the release branch wouldn't compile. I'm guess that the NuGet version of Boost grabs from release, therefore I get the Boost.Test problems back. How do I use a copy of the Boost trunk in VS 2013 Express? (I got a Subversion download of both branches.) Daryle W.

5 4

Design query using Boost.
by Rahul Mathur 24 Nov '13

24 Nov '13

All, I have a design sinerio. I have different struct (C structures) having different data's but NO similarities between struct and each struct does different operations. The struct for example are - struct Apple { int A; char B; long C; double d; .. ..}; struct Orange { char A; int B; unsigned int C; long d; .. }; and maybe few more. Above few struct data members have dynamic data and other members have fixed/hardcoded datas. The complete struct is send as a buffer to a remote machine through native send()/read() API calls which has been successfully implemented. Please note this data as tested were hard coded or completely static but didn't had combination of dynamic/real and static data.. Now such operations (viz different or repeated) with ONE/MULTIPLE SET of data could be many as 1000, I wish now to send complete operations to remote machine, get a ACK from it and work on this struct data with modification/cancellation/reject/etc operations. One way could be to work with something similar - struct Apple { ... ..}; vector <Apple> data; data.insert (begin();end()) --- But, I have few questions - 1. I can have "std::map<string, vector>" and send this data as native send(). Latter read/recv() with string. Am I correct as I would have multiple operations? 2. I do wish to maintain synchronisation using Boost::lockfree mechanism latter? 3. Any other techniques? Thanks.

1 0

Adjacency lists
by Nouf M. 24 Nov '13

24 Nov '13

Hi, I have two *huge* text file with graph data.. the format of the files are as follows: File 1(vertices): Two field in each line (name + weight) e.g. Dan 5 David 7 Jack 3 File 2(edges): Three fields in each line (name name weight) e.g. Dan David 3 Jack David 1 I would like to store the data in an adjacency list using boost. I have wrote the following code: struct VertexProperties { //std::size_t index; std::string name; int weight; }; struct EdgeProperties { EdgeProperties(const int& w) : weight(w) { } int weight; }; My question, is the above code correct? should I include an index in the VertexProperties (I don't have an index in my graph data)? What is more efficient in the searching (latter on) with or without an index? Thank you...

1 0