- Boost - lists.preview.boost.org

[metagraph]
by Kitten, Nicholas 03 Feb '12

03 Feb '12

Hi Gordon (and whoever else is involved), What's the current status of metagraph / mpl_graph? I've been using msm::mpl_graph for error-checking/scheduling in a compile-time filter graph framework (similar to state machines, but focus is on data flow), and I'd certainly like to see more. As is, I've already implemented a topological sort based on the BFS which doesn't yield errors on cyclic graphs (which I'd be happy to contribute if you don't already have one), and I have some thoughts on improvement. I saw the BoostCon slides and the current state of the sandbox, and I was wondering if there's more code lurking out there somewhere, unchecked-in. Anyway, the single biggest flaw I see with the current BFS and DFS (and the BGL models they're based on) is that there is no way for the user to specify a termination condition in the base algorithm. It seems silly that an algorithm called "Search" can't end without traversing the whole connected component! Indeed, if there were simply an optional predicate determining whether a candidate vertex should be added to the stack/queue, I wouldn't have needed to write a separate algorithm for topo sort. The other thing is that not all of the listed visitor operations are called in the current implementations. Adding things like "initialize_vertex" and "non_tree_edge" to BFS is an easy fix. Thanks, Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc. http://www.objectvideo.com

3 6

[range] Performance benchmarks?
by Beman Dawes 02 Feb '12

02 Feb '12

A question came up in a long bikeshed discussion on a C++ committee mailing list as to the performance of range based interface versus a begin/end iterator interface (I.E. traditional STL interface) to the same algorithms. Out of curiosity, I checked the Boost.Range docs, but didn't see any performance measurements. It might encourage potential users to take the leap if the Boost.Range "Introduction" page made some mention of performance implications for use of the Boost library. The intro gives a "Push the even values from a map in reverse order into the container target" example: // Assume that is_even is a predicate that has been implemented elsewhere... push_back(target, my_map | map_values | filtered(is_even()) | reversed); Are there any benchmarks available for this? What does the straight STL version of the code look like? --Beman

5 8

[1.49] No description about Boost.Heap in Library Documentation page
by Michel Morin 02 Feb '12

02 Feb '12

There is no description about Boost.Heap at http://www.boost.org/doc/libs/1_49_0_beta1/ Ditto for "trunk/boost/libs/libraries.htm" Regards, Michel

3 3

[1.49.0] New libraries in 1.49.0?
by Beman Dawes 02 Feb '12

02 Feb '12

What are the new libraries in 1.49.0? --Thanks, --Beman

5 8

[interprocess] utf8 file names in memory mapped files
by Thorsten Ottosen 01 Feb '12

01 Feb '12

Hi Ion, It would be great if we could support utf8 encoded file names on windows too. I guess all it requires is a utility function that converts from utf8 to utf16 on windows. Such a function is avaiable in the windows API, and I can supply it. kind regards Thorsten

3 6

[1.49.0] Beta 1 release candidates available
by Beman Dawes 01 Feb '12

01 Feb '12

Release candidate files for 1.49.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers --PS: I downloaded the 7z version, and it build without errors on Win7/VC++ Express 2010 sp1

19 32

[1.49.0] Branches/release open for bug fixes and documentation updates
by Beman Dawes 01 Feb '12

01 Feb '12

branches/release is now open for bug fixes and doc updates, without need to ask for a release manager's permission. It will remain open until Monday, February 13th. The final release is scheduled for February 20th. The hope is that this somewhat longer beta period will allow time to fix more bugs that surface during the beta period. --Beman

4 4

[local_function] ready
by Lorenzo Caminiti 01 Feb '12

01 Feb '12

Hello all, I have finished making the modifications requested by the Boost.Local(Function) review. The code is now in the sandbox ready to be moved into trunk. Can I get write access to the trunk? 1) Boost.LocalFunction New: This library allows to program functions locally, directly within the scope where they are needed. https://svn.boost.org/svn/boost/sandbox/local_function/libs/local_function/… 2) Boost.ScopeExit Improved APIs (variadic macros, this_, void, and C++11 closures) while keeping full backward compatibility. https://svn.boost.org/svn/boost/sandbox/local_function/libs/scope_exit/doc/… 3) Boost.Utility/IdentityType New: Macro to wrap type expressions within round parenthesis so they can be passed to macros even when they contain commas. https://svn.boost.org/svn/boost/sandbox/local_function/libs/utility/identit… 4) Boost.Functional/OverloadedFunction New: Overload different functions into a single function object. https://svn.boost.org/svn/boost/sandbox/local_function/libs/functional/over… All source files: https://svn.boost.org/svn/boost/sandbox/local_function/ Thanks. --Lorenzo

2 1

[math_constants] Lots of "extra ';'" warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags "-Wall -Wextra -ansi -pedantic", I get the following warnings: boost/math/constants/constants.hpp:211:199: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:212:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:213:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:214:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:215:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:216:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:217:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:218:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:219:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:220:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:221:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:222:211: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:223:197: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:224:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:225:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:226:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:227:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:228:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:229:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:230:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:231:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:232:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:233:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:234:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:235:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:236:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:237:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:238:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:239:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:240:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:241:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:242:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:243:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:244:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:245:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:246:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:247:196: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:248:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:249:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:250:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:251:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:252:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:253:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:254:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:255:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:256:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:257:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:258:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:259:198: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:260:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:261:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:262:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:263:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:264:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:265:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:266:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:267:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:268:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:269:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:270:217: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:271:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:272:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:273:219: warning: extra ‘;’ [-pedantic] Could you fix them? Thank you very much, Best, -- Marco

1 0

[strings][unicode] Proposals for Improved String Interoperability in a Unicode World
by Beman Dawes 31 Jan '12

31 Jan '12

Beman.github.com/string-interoperability/interop_white_paper.html describes Boost components intended to ease string interoperability in general and Unicode string interoperability in particular. These proposals are the Boost version of the TR2 proposals made in N3336, Adapting Standard Library Strings and I/O to a Unicode World. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. I'm very interested in hearing comments about either the Boost or the TR2 proposal. Are these useful additions? Is there a better way to achieve the same easy interoperability goals? Where is the best home for the Boost proposals? A separate library? Part of some existing library? Are these proposals orthogonal to the need for deeper Unicode functionality, such as Mathias Gaunard's Unicode components? --Beman

7 27

[c++TR2] N3334, Proposing array_ref<T> and string_ref
by Beman Dawes 31 Jan '12

31 Jan '12

On Sat, Jan 28, 2012 at 8:12 PM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > On 01/28/2012 05:46 PM, Beman Dawes wrote: >> >> Beman.github.com/string-interoperability/interop_white_paper.html >> describes Boost components intended to ease string interoperability in >> general and Unicode string interoperability in particular. >> >> These proposals are the Boost version of the TR2 proposals made in >> N3336, Adapting Standard Library Strings and I/O to a Unicode World. >> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. >> >> I'm very interested in hearing comments about either the Boost or the >> TR2 proposal. Are these useful additions? Is there a better way to >> achieve the same easy interoperability goals? > > > I think you should consider the points being made in N3334. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html While this proposal isn't from Boost, it impacts interests of Boost developers enough that I think it is worth discussing here as a separate topic. Mathias continues: > While that proposal is in my opinion not good enough, it raises an important > issue that is often present with std::string-based or similar designs. > > A function that takes a std::string, or a boost::filesystem::path for that > matter, necessarily causes the [caller] to copy the data into a heap-allocated > buffer, even if there is no need to. Some std library string implementations avoid the heap allocation for small strings, but still there is an unnecessary copy happening even in those implementations. Your point is well taken and I've often worried about it with boost::filesystem::path. > Use of the range concept would solve that issue, but then that requires > making the function a template. A type-erased range would be possible, but > that has significant performance overhead. > a string_ref or path_ref is maybe the lesser evil. One of my blink reactions is that array_ref<T> and basic_string_ref<charT, traits> are range generators and I was a bit surprised to see the implementation was a pointer and length rather than two pointers. Or better yet, two iterators or an explicit range component. With iterators, a basic_string_ref could do encoding conversions on-the-fly without need of temporary strings. But I have no idea if that is workable or actually is better. What do other Boosters think? --Beman --Beman

5 7

[conversion] Lot of 'long long' warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags '-Wall -Wextra -ansi -pedantic', I get the following warnings concerning the use of the 'long long' type under the ISO C++98: boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:16:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:21:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:28:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:33:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:40:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:45:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:52:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:57:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:64:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:69:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:76:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:81:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:88:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:93:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:100:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:105:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:112:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:117:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:124:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:129:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:136:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:141:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:148:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:153:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:160:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:165:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:172:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:177:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:184:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:189:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:196:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:201:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:208:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:213:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:220:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:225:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:232:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:237:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:244:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:249:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:256:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:261:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:268:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:273:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:280:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:285:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:292:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:297:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:303:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:304:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:309:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:315:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:316:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:321:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:327:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:328:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:333:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:339:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:340:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:345:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] Could you fix them? Thank you very much. Best, -- Marco

3 3

[context] Boost.Context library accepted
by Giovanni Piero Deretta 31 Jan '12

31 Jan '12

Hi All, The mini-review of the boost.context library from Oliver Kowalke ended two weeks ago. After a slow start, three reviews were eventually submitted, all positive. For a mini-review, I think this is enough and, as the review manager, I'm happy to announce that Boost.Context is accepted as an official boost library. Congratulations to Oliver for this achievement and thanks for submitting an useful library to Boost. Most of the review discussions were around the quality of the documentation and some misunderstanding of some details of the library. While the documentation has greatly improved since the first review, I think that it can be still improved. I encourage Oliver to seek the help of some native English speaker to help copy edit the docs. Finally I would like to thanks everybody that participated in the review discussions and in particular those that submitted reviews. regards, -- Giovanni Deretta,

2 1

Requesting a review of Metaparse
by Abel Sinkovics 31 Jan '12

31 Jan '12

Hi, I've created a version of Metaparse that depends on the Boost libraries only. I request this version of Metaparse be placed in the queue for formal review. The zipped source code can be found here: http://abel.web.elte.hu/metaparse/metaparse.zip The documentation can be found here: http://abel.web.elte.hu/metaparse/metaparse The library has been tested on the following compilers: - GCC 4.6 (with and without -std=c++0x) - GCC 3.4 - Clang 2.9 - Visual C++ 10 A quick summary: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Regards, Abel

7 16

My non-system GCC doesn't link programs under b2
by Daryle Walker 30 Jan '12

30 Jan '12

I'm still using my 2002 PowerPC/G4 Mac with Mac OS X 10.4 (Tiger). I loaded GCC 4.6 (with multiprocessor options) onto it with MacPorts. I have a "user-config.jam" in my home folder like: //===using xsltproc : /opt/local/bin/xsltproc ; using boostbook : /opt/local/share/xsl/docbook-xsl/ : /opt/local/share/xml/docbook/4.2 ; using doxygen ; using darwin ;using gcc : 4.6 : g++-mp-4.6 : <cxxflags>-std=c++0x <cxxflags>-pthread ;//=== I've tested GCC-4.6 (with C++11 active) with a "Hello World!" program, so I know it works with single-file programs. I wanted to test "base_from_member" (part of Boost.Utility) and it worked with the default "darwin" target. (I ran "b2" in "BOOST_ROOT/libs/utility/test".) However, running "b2 toolset=gcc-4.6" ended in errors like: //===common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debuggcc.compile.c++ ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o../base_from_member_test.cpp: In constructor 'bad_class::bad_class()':../base_from_member_test.cpp:129:21: warning: 'bad_class::x_' will be initialized after [-Wreorder]../base_from_member_test.cpp:510:39: warning: base 'base_class' [-Wreorder]../base_from_member_test.cpp:507:1: warning: when initialized here [-Wreorder]gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test/usr/bin/ld: unknown flag: --start-groupcollect2: ld returned 1 exit status "g++-mp-4.6" -o "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test" -Wl,--start-group "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test......skipped <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test.run for lack of <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test......failed updating 20 targets......skipped 40 targets......updated 126 targets...//=== GCC-4.6 compiles each C++ file into an object file just fine. The problem happens when linking various object and library files into an executable; whichever linker gets called (the system linker?) chokes on a "--start-group" flag. When I first started writing this message, I thought the problem was GCC-4.6 being too new for the linker, but maybe we have to tweak something in our Jam files instead. (Could it be the fact I downloaded the multiprocessor variant of GCC-4.6?) BTW, how do I specify that I only want to try out the base_from_member test without trying to build all other tests in the directory? Daryle W.

4 4

[thread] Can't use boost/thread/mutex.hpp without boost_system
by Artyom Beilis 30 Jan '12

30 Jan '12

Hello, The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before: #include <boost/thread/mutex.hpp> #include <iostream> int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } } Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System. It breaks some code and breaks at least Boost.Locale. Is this change intentional or a bug? If it is intentional I'd like to know to fix Boost.Locale if not then is it possible to fix it. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

9 30

Re: [boost] [Boost-users] numeric_cast_traits/cstdint: request for fix in boost1.49
by John Maddock 30 Jan '12

30 Jan '12

>Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was >being interpreted as a char, This causes duplicate class definition >in the file >./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp >and hence many of compiled boost libs fail. Thanks for raising this on the list, I just posted these comments to the Trac ticket: "IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc. IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout. BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux. Reassigning to the person who made these changes..." Not sure if we can fix this for 1.49, but you're right, it is a high priority. Hopefully Brandon Kohn is reading this as he made those changes? John.

5 9

[Boost.Asio] Asio is using Boost.Chrono for 1.49?
by Christian Hägele 30 Jan '12

30 Jan '12

Hello, as I looked through the changes for Boost.Asio with boost 1.49 I noticed that it looks like Boost.Chrono's steady_clock is used for timers (when std::chrono is not available). First of all that very nice, because steady_clock is not affected by change of the system-time. However I think there is a major problem on windows. On windows there are some problems with QueryPerformancecoutner in multi-processor systems (http://support.microsoft.com/kb/274323) There is also a comment in boost/chrono/system_clocks.hpp about this issue and no real solution provided. Is that problem solved by now? If not will the better choice be to stick with the old system-time implementation until std::chrono is supported on MSVC? Or is this problem rather a minor problem and can be ignored? Regards, Christian

1 0

[bjam] copy a file
by lcaminiti 30 Jan '12

30 Jan '12

Hello all, I'd have a Jamfile that has a "doc" rule to build documentation `bjam doc`. I'd like to program another rule "config_doc" inside the Jamfile that does the following: bjam config_doc: 1) Copy the file /etc/config.txt to ./ 2) Copy the file ./src/config.txt to /etc/ 3) Run the doc rule 4) Copy the file ./config.txt into /etc/ Where ./ is the current directory from where I'm running bjam. Ideally, I'd like 4) to be executed even if 3) fails. Is there a way to do this? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-copy-a-file-tp4321537p4321537… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 15

Latest Boost.Process ?
by Mathias Gaunard 29 Jan '12

29 Jan '12

I wanted to use Boost.Process, and the latest I could fine is from June at <https://github.com/JeffFlinn/boost-process>. Including the main file is enough to get lots of errors, and after fixing them (and there are quite a lot), it appears the functions from the documentation are not there (stdout_to etc.) Is there any recent usable version somewhere?

2 3

[1.49.0] Beta 1 available
by Beman Dawes 28 Jan '12

28 Jan '12

Boost release 1.49.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains a new library, Boost.Heap priority queues, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_49_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[phoenix] msvc 8.0 errors
by Lorenzo Caminiti 27 Jan '12

27 Jan '12

Hello all, Why doesn't this Phoenix 3.0 code compile? (I'm sure, I'm doing something wrong... but I can't see what...) #include <boost/spirit/include/phoenix.hpp> #define BOOST_TEST_MODULE AddPhoenix #include <boost/test/unit_test.hpp> #include <algorithm> #include <iostream> BOOST_AUTO_TEST_CASE( add_phoenix ) //[add_phoenix { using boost::phoenix::let; using boost::phoenix::local_names::_f; using boost::phoenix::cref; using boost::phoenix::ref; using boost::phoenix::arg_names::_1; int sum = 0, factor = 10; int nums[] = {1, 2, 3}; // Passed to template, `factor` by constant, and defined in expression. std::for_each(nums, nums + 3, let(_f = cref(factor))[ // Unfortunately, body cannot use C++ statement syntax. ref(sum) += _f * _1 // Access `sum` by reference. ]); BOOST_CHECK( sum == 60 ); } //] On MSVC 8.0: ...patience... ...patience... ...found 3219 targets... ...updating 114 targets... compile-c-c++ bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj add_phoenix.cpp C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,T0,boost::phoenix::actor<BaseT1>>::type> boost::phoenix::operator *(const T0 &,const boost::phoenix::actor<BaseT1> &)' : could not deduce template argument for 'const boost::phoenix::actor<BaseT1> &' from 'boost::mpl::void_' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::phoenix::result_of_multiplies<X,Y>' being compiled with [ X=const int &, Y=boost::mpl::void_ & ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(76) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::or_<boost::phoenix::is_actor<const int &>,boost::phoenix::is_actor<boost::mpl::void_ &>>, F1=boost::phoenix::re_curry<boost::phoenix::multiplies_eval,const int &,boost::mpl::void_ &>, F2=boost::phoenix::result_of_multiplies<const int &,boost::mpl::void_ &> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/detail/composite_eval.hpp(88) : see reference to class template instantiation 'boost::phoenix::multiplies_eval::result<Env,A0,A1>' being compiled with [ Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, A0=boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>, A1=boost::phoenix::argument<0> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/composite.hpp(60) : see reference to class template instantiation 'boost::phoenix::detail::composite_eval<2>::result<Composite,Env>' being compiled with [ Composite=boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(68) : see reference to class template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::result<Env>' being compiled with [ EvalPolicy=boost::phoenix::multiplies_eval, EvalTuple=boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/detail/composite_eval.hpp(88) : see reference to class template instantiation 'boost::phoenix::plus_assign_eval::result<Env,A0,A1>' being compiled with [ Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, A0=boost::phoenix::reference<int>, A1=boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/composite.hpp(60) : see reference to class template instantiation 'boost::phoenix::detail::composite_eval<2>::result<Composite,Env>' being compiled with [ Composite=boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/scope/let.hpp(48) : see reference to class template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::result<Env>' being compiled with [ EvalPolicy=boost::phoenix::plus_assign_eval, EvalTuple=boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/actor.hpp(56) : see reference to class template instantiation 'boost::phoenix::let_actor<Base,Vars,Map>::result<Env>' being compiled with [ Base=boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Vars=boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Map=boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>, Env=boost::phoenix::basic_environment<> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::phoenix::eval_result<Eval,Env>' being compiled with [ Eval=boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, Env=boost::phoenix::basic_environment<> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/actor.hpp(91) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::bool_<false>, F1=boost::mpl::identity<boost::phoenix::detail::error_expecting_arguments>, F2=boost::phoenix::eval_result<boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>,boost::phoenix::basic_environment<>> ] add_phoenix.cpp(29) : see reference to class template instantiation 'boost::phoenix::actor<Eval>' being compiled with [ Eval=boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,boost::phoenix::actor<Eval>,T1>::type> boost::phoenix::operator *(const boost::phoenix::actor<Eval> &,const T1 &)' : could not deduce template argument for 'const boost::phoenix::actor<Eval> &' from 'const int' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,boost::phoenix::actor<Eval>,boost::phoenix::actor<BaseT1>>::type> boost::phoenix::operator *(const boost::phoenix::actor<Eval> &,const boost::phoenix::actor<BaseT1> &)' : could not deduce template argument for 'const boost::phoenix::actor<Eval> &' from 'const int' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2677: binary '*' : no global operator found which takes type 'boost::mpl::void_' (or there is no acceptable conversion) C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2866: 'boost::phoenix::result_of_multiplies<X,Y>::size' : a const static data member of a managed type must be initialized at the point of declaration with [ X=const int &, Y=boost::mpl::void_ & ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2057: expected constant expression C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2975: 'N' : invalid template argument for 'boost::mpl::at_c', expected compile-time constant expression C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/at.hpp(41) : see declaration of 'N' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj.rsp" ...failed compile-c-c++ bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj... ...failed updating 1 target... Thanks a lot! --Lorenzo

1 0

multi_index problems
by brook＠biology.nmsu.edu 26 Jan '12

26 Jan '12

I am trying to use boost.MultiIndex as a class data member and am having difficulty because it seems that calling get<>() will not compile on a NetBSD box (gcc version 4.1.3). The code below illustrates a simple test case. Am I missing something obvious or doing something clearly mistaken? Any help is greatly appreciated. Thanks alot. Cheers, Brook =========================================================================== #include <boost/multi_index_container.hpp> #include <boost/multi_index/sequenced_index.hpp> namespace mi = boost::multi_index; template < typename T > struct container { typedef mi::multi_index_container< T, mi::indexed_by< mi::sequenced< > > > type; }; template < typename T > struct S { typedef typename container< T >::type container_type; void operator () () const { c_.get<0>(); // XXX - will not compile } private: container_type c_; }; int main () { return 0; }

2 1

[codecvt] UTF-8 codecvt
by Artyom Beilis 26 Jan '12

26 Jan '12

Hello, There is an implementation of UTF-8 codecvt facet for various purposes. Unfortunately it has two problems: 1. It does not implement UTF-16 properly (only UCS-2) 2. It requires linking with some library. Boost.Locale provides codecvt facets and I'm planning to add some template for codecvt converter in header files basically Boost.Locale will have header only version of utf-8 codecvt facet and actually very simple pattern to implement any codecvt facet for stateless encoding. I thought about two options: 1. Put it in boost::locale namespace as part of Boost.Locale library 2. Create some small "codecvt" boost library that would provide a simple framework for generation of codecvt facets for boost in general and it would include utf8 codecvt as well. Generally it would look like this: Converter concept: class Converter { public: // copyable Converter(Converter const &); // Max MB length for single Unicode code point int max_length() const; // convert a single mb sequence to code point // returing constants illegal or incomplete in case // if invalid sequence to incomplete sequence uint32_t to_unicode(char const *&begin,char const *end) const; // Convert codepoint u to [begin,end) returning mb length // or returning illegal if it is impossible to convert u to mb sequence // or U is invalid or incomplete if [begin,end) has not enough space uint32_t from_unicode(uint32_t u,char *begin,char const *end) const; }; Note, the converter works only for stateless encodings (which are 99% of all used encodings) And the basic facet would be defined as following: template<typename CharType,typename EncoderType,int size = sizeof(CharType)> class code_converter; Such that for converter concept utf8_converter I can create a utf8_codecvt facet as code_converter<wchar_t,utf8_converter> - is a facet that can be imbued to the locale object. The biggest "trick" is actually implementing codecvt facet to handle UTF-16 properly and it is implemented in Boost.Locale. So Boosters: Do You Want It Boost.Codecvt or it is fine to have it as part of Boost.Locale. In either case it would be header only "codecvt" framework. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

Scoped Enum Emulation
by Joshua Boyce 26 Jan '12

26 Jan '12

I'm currently updating some of my code to take advantage of C++0x features where available, but I also want to retain backwards compatibility with C++03. I was looking at scoped enums and noticed a thread on the mailing list by Beman Dawes discussing a scoped enum emulation implementation for Boost. I see that it's currently being used by Boost, and resides in /boost/detail/scoped_enum_emulation.hpp. My question is, why is this an implementation detail? Would it be possible for it to be moved to Boost.Config with the other 'helper' macros like BOOST_CONSTEXPR? Obviously it's not hard to reimplement, but I figured that it would be useful to other library users, so it would be best (imo) if it were moved somewhere public, rather than being hidden away. Thanks.

4 10

Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
by Matthew Chambers 26 Jan '12

26 Jan '12

On Oct 13, 2011 Michel Morin wrote: > lexical_cast made optimizations for some types (such as `std::string`) > to achieve better performance. But, from my experience, > it seems that lexical_cast does not make any optimization for > `boost::iterator_range<std::string::iterator>`. > > Is there any plan to add optimization for such iterator ranges? > Currently, > - `lexical_cast<int>(std::string(iter_rng.begin(), iter_rng.end()))` > is faster > than `lexical_cast<int>(iter_rng)`. > - Assuming it is safe to use `std::atoi`, > `std::atoi(&iter_rng.front())` is faster > than both of the above two methods. > (`iter_rng` is an instance of `boost::iterator_range<std::string::iterator>`.) > > Regards, > Michel This post was on the boost users list but never got a reply. I figure it might be a better fit on the developer list. I too would like to see optimized conversions work on string ranges; what's the point in doing a fast conversion if you have to do a string copy first? :) -Matt

8 16

Attribute names with underscores for GCC
by Michel Morin 26 Jan '12

26 Jan '12

Recently, Petr Machata created several trac tickets for requesting the use of attribute names with underscores for GCC. Since there is no link to the GCC's documentation in the tickets, I'd like to put a link to the documentation. In the GCC's manuals --> "Extensions to the C Language Family" --> "Declaring Attributes of Functions", "Specifying Attributes of Variables", and "Specifying Attributes of Types", there is description about attributes with preceding and following `__`: You may also specify attributes with `__' preceding and following each keyword. This allows you to use them in header files without being concerned about a possible macro of the same name. For example, you may use __noreturn__ instead of noreturn. Here are links to the gcc-2.9.5's documentation: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84 http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90 http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91 I also checked manuals of gcc-3.0.4 and 4.0.4, and found the same description. Hope this helps, Michel

2 2

[assert] [exception] Fast output binary file size growth
by Antony Polukhin 26 Jan '12

26 Jan '12

Greetings, When BOOST_ENABLE_ASSERT_HANDLER is defined or BOOST_THROW_EXCEPTION used, compiler generates a string with function name. If a function is templated, compiler will generate a string for each function template. That leads to a huge binary files. Consider the following example: #define BOOST_ENABLE_ASSERT_HANDLER #include <boost/assert.hpp> template <class MplVectorT> void do_something(bool v) { BOOST_ASSERT(v); } void do_something<boost::mpl::vector<int, double>>(v); void do_something<boost::mpl::vector<int, int>>(v); This two functions will generate strings like "void do_something<MplVectorT>(bool v) [with MplVectorT = boost::mpl::vector<int, double> ]" and "void do_something<MplVectorT>(bool v) [with MplVectorT = boost::mpl::vector<int, int> ]". When there is more mataprogramming, one such string can have a size of a few kilobytes. In one of my binaries, such strings take more than 50 megabytes of binary size (total size of binary is 70 megabytes). I`ve got a patch and documentation update for Boost.Assert and Boost.Exception, that allow to disable construction of such strings or to use different macro for current function name (for example macro that prints ONLY function name). Is there interest in this feature/patches? Best regards, Antony Polukhin

2 2

[filesystem] noexcept question? [was: Scoped Enum Emulation]
by Beman Dawes 26 Jan '12

26 Jan '12

On Tue, Jan 24, 2012 at 8:38 PM, Joshua Boyce <raptorfactor(a)raptorfactor.com> wrote: > While I've got your attention, I have a similar question along the same > lines. I notice in the mailing list archives that you added some noexcept > related macros to Boost.Config on trunk back in October 2011, I can't see > them in the current trunk or release though. What happened to those? They won't go in 1.49.0, but will begin to go into trunk within the next month. Likewise some other C++11 support, such as rvalue reference signatures. --Beman

2 1

[filesystem] documentation typo
by Greg Rubino 26 Jan '12

26 Jan '12

Hello, It looks like there's some copy/paste residue in http://www.boost.org/doc/libs/1_48_0/libs/filesystem/v3/doc/reference.html#… basic_filesystem_error has become filesystem_error, but in the anchor it's still called 'basic_filesystem_error', and also there are a couple of references on the page to basic_filesystem_error. This momentarily confused me when I was moving a codebase from v1 to v3 yesterday, so I thought it was worth mentioning. I've entered a trac ticket for this issue: https://svn.boost.org/trac/boost/ticket/6448 but I would be delighted to submit a patch for this since I've been wanting to get more involved in Boost, but it would be my first time doing and I'm not quite sure how to go about it. I assume that it involves checking out the trunk and modifying the necessary files, but I'm not sure after that. Greg

2 1

Boost.Application
by Renato Tegon Forti 26 Jan '12

26 Jan '12

Hi All, I have the first prototype of the "Boost.Application" ready! I would like to receive comments so I can refine the library. Please send your feedback to re.tf(a)acm.org 0) Introduction A Boost.Application allows a developer run your application as a Windows service, as a Unix/Linux daemon, or as a usual interactive application (terminal) without the need to add extra code, the library abstract OS specific API and provide a ease common interface. In case of server application, developer need only compile your code on a Windows to have a ready to play Windows Service or in a UNIX/Linux to have Daemon. CTRL-C signals and SCM (Service Control Manager) controls handlers are available for terminating, pause/resume(windows) the application constructively and many other until methods are available in application class like a single instance running limitation! 1) Download: https://sourceforge.net/projects/boostapp/ 2) Installation: The library is one: Automatic linking You should unpack the files and copy: Boost.Application_pre_alpha_1\boost\application To: boost_1_48_0\boost and, Boost.Application_pre_alpha_1\libs\application To: boost_1_48_0\libs 3) Build Then you must build, for example (in windows): bjam toolset=msvc-9.0 variant=debug threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION 4) Documentation The project has an incomplete documentation: Boost.Application_pre_alpha_1\libs\application\doc\html\index.html 5) Use however, the tutorial explains how to use the lib, and that generally goes like this: ---------------------------------------------------------------------------- -------------------- #include <boost/application/engine.hpp> class myapp : public boost::application::application { protected: int main(const std::vector<std::string>& args) { // your application logic here! while(1) { std::cout << "Hello Boost.Application!" << std::endl; // ... if(state() == boost::application::application_stoped) { break; } } return 0; } }; BOOST_APP(myapp, "MainTutorial1", "Boost.Application Main Tutorial 1!", boost::application::default_application_type, 1, 0, 1) ---------------------------------------------------------------------------- -------------------- The folder: Boost.Application_pre_alpha_1\libs\application\example\tutorial Has all tutorial files! I tested the lib on Windows VC9 (Windows Service) and Ubuntu 11 GCC 4 (Daemon)! 6) Questions: * Is there any interest in this library? * If Yes! What are the refinements? (see todo, for some) Please send your feedback to re.tf(a)acm.org Thanks to all Renato

3 5

Boost.Application (PART II)
by Renato Tegon Forti 26 Jan '12

26 Jan '12

Hi all, I want to emphasize: 1) This is a prototype, a starting point to find out if this is an interesting lib to boost! 2) And if 1 is true! I will compile all comments and make modifications to meet "boost"! My doubt is if this lib don't violate: "The library must be generally useful and not restricted to a narrow problem domain." About comments of friends! First, thank you for the comments! They always show a new way of doing things, which I had not thought of! This is the main reason I'm doing (trying to) this lib, to have the opportunity to learn (and contribute) with you! I will try to enumerate the comments, and then build a path to follow for next version (if [1] is satisfied. Do you think I need more votes to continue the effort?) a) >>So selling it as "ready to play" UNIX/Linux daemon is a bit - erm - exaggerating. Sorry about this, I will change this description! I agree with you! Sorry! b) >> Why is the application not a functor or even a function? . Again I agree with you! This is a better way!, for sample I can handle exception in my main too! Thanks about this suggestion! >> I don't like it, though I don't have an alternative solution at hand. Somehow this feels very clumsy with that init() method. As example of a pure OO approach you could have a look at Qts QApplication. I will look QApplication! If you have time! You could describe what you think would be the right path follows in more detail, I appreciate it! c) >> The biggest concern for me is that you're using narrow strings I will provide wide strings. I don't know how yet. I will check Boost.Filesystem! Besides, there is other example to follow? For sample, I need use W version (GetModuleFileNameW) on all? And use a function like this to convert: inline void convert(const char* from, std::wstring & to, const codecvt_type& cvt) D) Other question, to handle exceptions! Any Idea? e) "Install and uninstall windows service" functionality, be a part of the application instead of a separate one and using a callback. f) * In the unknown mode, the program can run in either mode provided someone puts something in the command line. Could that rather be a callback maybe post initialize such that we tell your application which one we want. This way the developer controls his command line. After all, it might not come from the command line but instead from a configuration file. -------------------------------------------------------------------------- What else? Thanks for help!!!

1 0

boost filesystem path as utf-8?
by Emil Dotchevski 25 Jan '12

25 Jan '12

Hello, I understand that the path class .native() member function's return type differs depending on the platform (wstring on windows, for example.) Is there a way to get the path as a utf-8 string regardless of the platform? Likewise, is there a way to construct a path object from a utf-8 string regardless of the platform? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 9

[log][phoenix] Questions on porting to phoenix
by Andrey Semashev 25 Jan '12

25 Jan '12

Hi, [My apologies for the long post] I'm trying to port filters and formatters of Boost.Log to Boost.Phoenix and I'm not sure I understand what's the best way to go. Hope someone can help me out. A short introduction of the terms and what is currently available. * An attribute value is a type-erased value, something similar to boost::any but with more advanced interface to allow visitation and extraction of the stored value. * A log record is an object which contains a set of named attribute values. For simplicity, let's say: class attribute_value; typedef map< string, attribute_value > attribute_values_view; class record { public: attribute_values_view const& attribute_values() const; string const& message() const; }; * A filter is a function that accepts attribute values and returns a bool: typedef function< bool (attribute_values_view const&) > filter; The filter is assumed to pass the log record if it returns true. * A formatter is a function that accepts a log record and a stream and outputs strings or attribute values to the stream: typedef function< void (ostream&, record const&) > formatter; * I already have the code that extracts attribute values from log records. What I'm trying to achieve is something along these lines (this is not a finalized interface yet): enum my_severity { info, warning, error }; BOOST_LOG_REGISTER_ATTRIBUTE("Severity", severity, my_severity) filter flt = severity >= warning; formatter fmt = stream << "[" << severity << "] " << message; Here, "stream" and "message" are keywords provided by Boost.Log, the former is a placeholder for the stream argument of the formatter function, and the latter returns the result of the record::message() method. Now, the BOOST_LOG_REGISTER_ATTRIBUTE macro is what I'm struggling on. It should create a new keyword (severity) which should: 1. Be a POD object to be statically initialized. 2. Contain the information on the type (my_severity) and name ("Severity") of the attribute to be able to extract it from the log record. 3. Be a Phoenix object to initiate lazy expression generation. >From what I gathered from the docs and examples, the generated keyword should be a terminal, in terms of Proto. Am I correct? In order to produce the value, during the evaluation the keyword should receive either a log record or a attribute_values_view and I can't quite understand how do I do that. Basically, I don't quite understand how do I declare and implement a terminal so that it works with Phoenix. This question also applies to the "stream" and "message" keywords but I suspect the solution will be similar. Maybe there is an example of doing this in the docs or elsewhere. I'll be glad if someone provides a link or example of doing this. Thanks in advance.

5 11

[quickboost] single HTML page?
by lcaminiti 24 Jan '12

24 Jan '12

Hello all, Is there a way to have quickbook generate a single HTML page? (Maybe some XSL param...) Right now, different sections appear on different HTML pages. But for a very simple doc, I only have 3 short sections and it'd make more sense for them to be displayed on a single page while still remain separate section and appear separately in the table of context. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickboost-single-HTML-page-tp4323… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Bug reports - Showstoppers and Regressions
by Marshall Clow 24 Jan '12

24 Jan '12

There are a couple of useful reports on svn.boost.org: Active Showstoppers: https://svn.boost.org/trac/boost/report/43 Active Regressions: https://svn.boost.org/trac/boost/report/30 To shortcut part of the discussion, here are some definitions (taken from https://svn.boost.org/trac/boost/wiki/TicketWorkflow) • Showstopper - this problem is so bad, that we should hold up a release if it's not fixed. Note that the release managers and/or the library maintainers may have different opinions. • Regression - something used to work (in a previous release), but no longer does. IMHO, these bugs should be at least looked at before each release. -- 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

8 15

[BGL] Any interest in updated maximum adjacency search?
by Fernando Vilas 23 Jan '12

23 Jan '12

Hi, As a part of my graduate research, I have been using the maximum adjacency search algorithm. In the BGL, it is implemented in the stoer_wagner_min_cut functions. I have already broken it out of there, to be a search with a visitor, like BFS. I also implemented a dummy visitor and wrote visitors for my research. It would be very easy to implement a min-cut visitor so that the Stoer-Wagner functionality is maintained without a public API change. As a contributor in other FLOSS projects, I would like to contribute this code back to the Boost library, under the Boost license, if there is interest in the code. That said, this will be my first contribution to Boost, so I would most likely need someone willing to help me navigate the approval process and let me know where the code needs to be improved to meet the normally high standards on this project. -- Thanks, Fernando Vilas fvilas(a)iname.com

2 2

[quickbook] email tag?
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, Is there a preferred way or special tag to specify the author's email within the [library ...] tag? [library Boost.LocalFunction [author [Caminiti, Lorenzo]] ... ] Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-email-tag-tp4310264p4310… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

[local] name (was Re: "protected" APIs)
by Lorenzo Caminiti 21 Jan '12

21 Jan '12

On Mon, Jan 16, 2012 at 6:06 AM, Thomas Klimpel <Thomas.Klimpel(a)synopsys.com> wrote: > Hartmut Kaiser wrote: >> > On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote: >> > > Hello all, >> > > >> > > Boost.Closure (formerly, Boost.Local) needs to use some macros, >> types, >> > > etc that are currently marked private in Boost.ScopeExit: >> > >> > Boost.Closure? I really don't like that name is at implies functional >> > programming capabilities. Didn't you decide to name it >> Boost.LocalFunction >> > instead? >> >> I second that concern. I wouldn't like for the local function library >> to >> claim the name 'closure'. >> This would be >> >> a) totally misleading and >> b) inhibits to give that name to a potential real closure library in >> the >> future. > > +1 As I said before, I'm equally happy with Boost.LocalFunction and Boost.Closure. I'm checking with my review manager about going back from Closure to LocalFunction given that a few people have now expressed such a preference. I'll keep everyone posted :) > Or more precisely, just ignoring mails questioning the name Boost.Closure is not good style. In a functional programming language, many things can be done with a closure (for example returning it from a function), and it is unclear to me, whether Boost.Local really is able to approximate this functionality in a sufficiently usable way. It might be true, but then please point me to the corresponding passage in the documentation. Boost.Local docs do not (yet) explain how and when local functions can be returned because that was a homework from the review. I'm pasting below a few examples that I will include in the docs: //[test_return_inc_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnInc #include <boost/test/unit_test.hpp> boost::function<int (void)> inc(int& value) { int BOOST_CLOSURE(bind& value) { return ++value; } BOOST_CLOSURE_END(i) return i; } BOOST_AUTO_TEST_CASE( return_inc ) { int value1 = 0; // Reference valid in scope where closure is used. boost::function<int (void)> inc1 = inc(value1); int value2 = 0; boost::function<int (void)> inc2 = inc(value2); BOOST_CHECK( inc1() == 1 ); BOOST_CHECK( inc1() == 2 ); BOOST_CHECK( inc2() == 1 ); BOOST_CHECK( inc1() == 3 ); } //] //[test_return_setget_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnSetGet #include <boost/test/unit_test.hpp> #include <string> boost::function<void (std::string const&)> set; boost::function<std::string const& (void)> get; void action(void) { // State `message` hidden behind access functions from here. BOOST_CHECK( get() == "abc" ); set("xyz"); BOOST_CHECK( get() == "xyz" ); } BOOST_AUTO_TEST_CASE( return_setget ) { std::string message = "abc"; // Reference valid where closure used. void BOOST_CLOSURE(bind& message, std::string const& text) { message = text; } BOOST_CLOSURE_END(s) set = s; std::string const& BOOST_CLOSURE(const bind& message) { return message; } BOOST_CLOSURE_END(g) get = g; action(); } //] //[test_return_derivative_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnDerivative #include <boost/test/unit_test.hpp> boost::function<int (int)> derivative(boost::function<int (int)>& f, int dx) { int BOOST_CLOSURE(bind& f, const bind dx, int x) { return (f(x + dx) - f(x)) / dx; } BOOST_CLOSURE_END(deriv) return deriv; } BOOST_AUTO_TEST_CASE( return_derivative ) { int BOOST_CLOSURE(int x) { return x + 4; } BOOST_CLOSURE_END(add2) boost::function<int (int)> a2 = add2; // Reference valid where closure used. boost::function<int (int)> d2 = derivative(a2, 2); BOOST_CHECK( d2(6) == 1 ); } //] //[test_return_this_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnThis #include <boost/test/unit_test.hpp> struct number { number(int value) : value_(value) {} boost::function<int (void)> inc(void) { int BOOST_CLOSURE(bind this_) { return ++this_->value_; } BOOST_CLOSURE_END(i) return i; } private: int value_; }; BOOST_AUTO_TEST_CASE( return_this ) { number n1 = 0; // Object valid in scope where closure is used. boost::function<int (void)> inc1 = n1.inc(); number n2 = 0; boost::function<int (void)> inc2 = n2.inc(); BOOST_CHECK( inc1() == 1 ); BOOST_CHECK( inc1() == 2 ); BOOST_CHECK( inc2() == 1 ); BOOST_CHECK( inc1() == 3 ); } //] Thanks. --Lorenzo

3 2

[quickbook] changing paths
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, How can I change the paths were Boost.QuickBook looks for the following files? 1) CSS and icon images by default from BOOST_ROOT/doc. 2) Navigation bar by default from BOOST_ROOT/tools/boostbook/xls. Essentially, I'd like to put the CSS, icon images, and navbar into a different path. Also, I'd like to change the navbar to one of my own. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-changing-paths-tp3925967… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 4

[review] WANTED: Review Managers
by Ronald Garcia 20 Jan '12

20 Jan '12

Hi all, Currently the Boost review schedule has 8 libraries ready for review, but we need some individuals to volunteer to be review managers so that we can schedule reviews for them. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. The libraries on the review schedule are as follows (the "(M)" simply means that a manager is needed): * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Predef (M) If you are interested, able, and qualified to be a review manager for one of these libraries, please contact myself and/or John Phillips. Thank you. Best, Ron

1 0

[move] error: duplicate 'inline'
by Vicente J. Botet Escriba 19 Jan '12

19 Jan '12

Le 16/01/12 20:48, Beman Dawes a écrit : > On Mon, Jan 16, 2012 at 1:38 PM, Vicente J. Botet Escriba > <vicente.botet(a)wanadoo.fr> wrote: >> Le 16/01/12 19:30, Vicente J. Botet Escriba a écrit : >> >> Hi there is a minor Bug on trunk regression test for Boost.Move and all the >> libraries using it. >> >> Test output: Sandia-darwin-4.4_0x - move - back_move_inserter / >> darwin-4.4_0x >> Rev 76539 / Mon, 16 Jan 2012 11:49:32 +0000 >> Report Time: Mon, 16 Jan 2012 16:05:03 +0000 >> Compile [2012-01-16 12:32:57 UTC]: fail >> >> "/opt/local/bin/g++-mp-4.4" -ftemplate-depth-128 -std=gnu++0x -O0 >> -fno-inline -Wall -g -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -I".." -c >> -o >> "/Volumes/scratch/kbelco/boost/results/boost/bin.v2/libs/move/test/back_move_inserter.test/darwin-4.4_0x/debug/link-static/back_move_inserter.o" >> "../libs/move/test/back_move_inserter.cpp" >> >> In file included from ../libs/move/test/back_move_inserter.cpp:11: >> ../boost/move/move.hpp:486: error: duplicate 'inline' >> ../boost/move/move.hpp:522: error: duplicate 'inline' >> >> >> Could this be fixed quickly? >> >> >> It seems that the problem has been merged to the release branch also. > Shouldn't this be posted on the main list? Maintainers don't > necessarily read the testing list. > > > Ion, could you analyze this blocking issue? Vicente

4 3

Permission to merge to release a remove-warnings-update
by Barend Gehrels 19 Jan '12

19 Jan '12

Hi, Christophe sent me this week a patch to avoid many warnings about unused parameters in many files. I applied that (all but one file which was not about unused parameters) and fixed some more. So this is a low-risk update which might be convenient for many users. All tests run fine. Do I have permission to still merge this with the Release branch? Thanks, Barend

1 0

Vote Boost Up for SourceForge Project of the Month
by Dave Abrahams 19 Jan '12

19 Jan '12

Folks, I was just informed that Boost is a top contender for SourceForge's February Project Of The Month. The vote is happening on TwtPoll, here: http://twtpoll.com/7vt4lq It's pretty close, so if you could vote Boost up, it could be good for our profile and our future. Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

9 8

boost log project - compile with mingw (gcc 4.5.4) on win7- problems
by Aleksander Sandro GRM 19 Jan '12

19 Jan '12

Dear, recently I started to use boost::log api. I work on win7 machine and use mingw-x86-64 compiler ver. 4.5.4. Now I got trunk version for boost and boost::log api and encountered problems with compilation. Problem is with: C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk>bjam --with-log -a toolset=gcc target-os=windows variant=release link=shared runtime-link=sha red define=BOOST_ALL_DYN_LINK define=BOOST_LOG_USE_CHAR stage C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1085: in ensure-type from module generators error: target { simple_event_log.mc. } has no type C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1319: in generators.construct from module generators C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1298: in object(typed-target)(a)354.generate from module objec t(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)834.generate from module object( main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)343.generate from module obje ct(project-target)@343 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(install-ta rget-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in object(install-target-class)(a)97.generate from modul e object(install-target-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)808.generate from module object( main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(top-level- target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in alias-target-class.generate from module object(top- level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:409: in build-multiple from module object(top-level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:373: in object(top-level-target)(a)106.generate from module object(top-level-targe t)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)812.generate from module object( main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2\build-system.jam:736: in load from module build-system C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel/bootstrap.jam:142: in boost-build from module C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\boost-build.jam:17: in module scope from module To correct the error in the spirit of link ...( unfortunately I can't find it now ) 1. boost_trunk\tools\build\v2\tools\mc.jam: line 41: actions compile { # mc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" # --- replace mc with windmc --- windmc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" } 2. boost_trunk\tools\build\v2\tools\gcc.jam: line 28: addin additional import import fortran ; import mc ; After compile starts but got errors in compile time. All compile message is attached in compile.log I use trunk versions from date 18.01.2012 for both, boost and boost::log api. Best regards, Sandro.

1 0

Re: [boost] [thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Evan Wallace 18 Jan '12

18 Jan '12

On Thu, 05 Jan 2012 07:00:27 +0100, Vicente J. Botet Escriba wrote:>Mankarse please, could you post here the patch for the boost.thread >class so that I can start the integration of what you have already done? I have attached a patch to the ticket (https://svn.boost.org/trac/boost/ticket/6194) This patch is fairly comprehensive in terms of code, but it does not include any tests or documentation. In the course of writing the patch, I created some simple tests, but I have not yet translated these into Boost.Test testcases, or included them in the patch. I have tested the basic functionality on a number of compilers, but there are probably still some bugs in the patched code. The patch contains a number of known problems that may be worth discussing:1) Explicit move() and copy() calls:boost::thread and boost::packaged_task both have templated constructors that take an rvalue reference to a functor (which they move or copy as appropriate). Templates parameters cannot be deduced to a type that is only reachable through an conversion operator. Template constructors can also never be explicitly instansiated. (As far as I know.) This means that the overloads that are used in the definitions of BOOST_COPYABLE_AND_MOVABLE types (BOOST_RV_REF(type), BOOST_CATCH_CONST_RLVALUE(type), type&), are not matched for rvalue objects (in C++03 mode). Example: //In C++11 the `CopyableAndMovableFunctor` would be //moved into the thread. //In C++03 this does not compile. boost::thread((CopyableAndMovableFunctor())) Here, no overload would be matched, because the `type` in the overloads is templated. To solve this problem I modified Boost.Move to add two member functions - `copy()` and `move()` - which forward to the rv const& and rv& conversion operators. With these, the above example can be rewritten as: //In both C++11 and C++03 the `CopyableAndMovableFunctor` //will be moved or copied into the thread as appropriate. boost::thread(CopyableAndMovableFunctor().move()), boost::thread(CopyableAndMovableFunctor().copy()) I can imagine the names `copy` and `move` being quite common, so this might cause unfortunate conflicts. Is this an acceptable change to Boost.Move? Is there another way to get the functionality that does not require this? 2) SFINAE requiredBoost.Move requires SFINAE, and by extension Boost.Thread now also requires SFINAE. Previously, Boost.Thread did not require SFINAE. Is this an acceptable regression, or should more work be put into maintaining compatibility with compilers that do not support SFINAE? 3) Not using has_move_emulation_enabledI did not notice the `has_move_emulation_enabled` metafunction, and instead used `is_convertible!(T&, boost::rv!(T))`. This may mean that some situations that `has_move_emulation_enabled` accounts for will not be accounted for by the code in the patch. I have not yet evaluated whether simply replacing all the occurrences will work. Any thoughts? 4) Not using Vicente's patches for #6174 or #5990By the time that I was aware of these patches, I had already independently fixed the issues. I have not looked at either patch in detail, but they each go about fixing the issues in a significantly different way from my patch. Which code should be used in each of these cases? Where should I go from here? I could do the integration into the svn trunk version, write the documentation, or update the tests to the new version. Are there any other tasks that I can help out with? I will of course keep the patch updated with fixes for any bugs that I find in it. Evan Wallace

5 11

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

[preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
by lcaminiti 18 Jan '12

18 Jan '12

Hello all, Why does Boost.Preprocessor redefines BOOST_PP_VARIAIDCS instead of just using BOOST_NO_VARIADIC_MACROS from Boost.Config? Furthermore, GCC supports variadics also when C++11 extensions are not enabled so I think the following should not && __GXX_EXPERIMENTAL_CXX0X__: // File: boost/preprocessor/config/config.hpp # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && __GXX_EXPERIMENTAL_CXX0X__ # define BOOST_PP_VARIADICS 1 Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-variadic-BOOST-PP-VAR… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Need some 64-bit testing help.
by John Maddock 18 Jan '12

18 Jan '12

Folks, I need some help with the tests in: sandbox/big_number/libs/multiprecision/test Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a: bjam release --disable-concepts in that directory with whatever 64-bit compilers you have access to. Many thanks in advance! John.

4 8

Request for Interest in several Modules
by Artyom Beilis 18 Jan '12

18 Jan '12

Hello, I have several modules/libraries I developed and released under Boost License. - CppDB Sql Connectivity - Stack Trace - Shared Object Loading - Nowide UTF-8 friendly standard C/C++ library API. ---------------------------------- Let's start Boost.CppDB CppDB library: Sql Connectivity library currently not Boostified, released and actively maintained. http://cppcms.sourceforge.net/sql/cppdb/index.html How much interest in this library as-is with small obvious modifications like using Boost Namespace Boost.SharedObject: Simple Shared Object class for loading DLLs/SO - i.e. cross platfrom dlopen/dlclose + naming (libfoo.3.dylib/libfoo.so.3/foo-3.dll) http://cppcms.sourceforge.net/cppcms_ref_v0_99/classbooster_1_1shared__obje… Any interest in this simple class? Boost.StackTrace Collecting stack trace automatically from exception and printing it. Very Very useful for debugging. http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__t… http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html Any interest in this library. It works (collects a trace and prints it) on: Windows, Solaris, Linux, Mac OS X Boost.NoWide Standard C and C++ library UTF-8 friendly API for windows classes/functions: boost { nowide { [of]stream - iostreams with UTF-8 file names f(re)open - FILE * functions with UTF-8 file names remove, rename- UTF-8 parameters getenv,putenv - UTF-8 environment variables args - UTF-8 argc, argv } } Under non windows just (using std::...) These functions (like Boost.Locale) all are parts of CppCMS C++ Web framework. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

17 43

[build] How to build a multi version non-header-library
by Vicente J. Botet Escriba 18 Jan '12

18 Jan '12

Hi, I want to provide two versions for Boost.Thread, one using Boost.Chrono and the other not. Boost.Thread is a non-header-only library so I guess that I need to build two libraries with different names. Is there already a library in Boost in the same context on which I can base my build design? What is the simples way to do this with Boost.build? Any pointers to the doc? Thanks in advance, Vicente

2 2

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

Hi, Sorry for the late reply. On 1/10/2012 11:01 AM, Topher Cooper wrote: > > On 1/10/2012 1:37 AM, Adrian Michel wrote: >> The way I see it, the only common point between different optimization >> algorithms (if they are generic enough) is the objective function, >> which should have a very simple prototype: >> >> double f( std::vector< double> ); >> >> so in theory if different algorithms are implemented to accept the >> same types (in C++ sense) of objective functions, then you could run >> them interchangeably between GA, DE etc without any modification to >> the function or algorithm. > > That ignores multi-objective optimization. In that case the return type > would be, at a minimum std:vector<double>, and might require information > on what characteristics are maximized. > ... > The points you raised make sense, but I think they go beyond the intended scope of this initial release. Unlike many other boost libraries whose main purpose is to enhance the language, DE is intended almost exclusively for solving domain specific problems. Because DE can be applied in many areas, by developers with a variety of requirements and levels of knowledge, I believe taking an iterative approach based on users' feedback will increase the chances of creating a library that's useful in solving real problems. As I mentioned before, this is an initial implementation. Some of the features I intend to add in a later release are: - multi-objective optimization - constraint functions (as opposed to just plain boundary constraints) - design centering ("Design centering is a constraint satisfaction problem whose goal is to find the solution, which, when perturbed, remains feasible more often than any other solution") and others. But these features are not trivial, and it would help me to get a sense of how the library is used before I start working on them. So far, I have received several good suggestions, I would like to nail down a list of specific additional requirements that this library needs to meet before moving on to the next step (and I'm not sure what that may be). Please let me know how to proceed. Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/10/2012 1:32 AM, Graham, Jeff wrote: > > I can help test on i686, amd64 and arm9 running linux. > Great, thanks! Can you please download the library from http://www.amichel.com/de/de.zip and try to build it? Let me know if you need help or have any questions. Best, Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/11/2012 11:29 AM, Simonson, Lucanus J wrote: >The DE library description needs to be > very clear that it is for non-linear numerical optimization. I'm also > curious about how it compares industrial solvers like CPLEX. That is what I > had in mind when I said "good". It may be DE is one of the best ways to > solve a class of problems for which we don't know of a good way. There is > no point arguing about it in subjective terms, however. Instead, > quantifying how big of a problem it can handle in how many compute hours and > then providing a reference comparison to other solvers for other classes of > problem will put it into context and people will understand easily that it > is what it is and be able to tell if it is right for their problem or not. > There are people who may need it and not know it. There are people who may > need something else and not know it. The documentation should help both types of people. > Noted. In general I prefer to link to other sources that deal with the subject in much greater detail, but I can certainly add more information to help first time readers get a sense of why this library may be useful to them. > As far as design goes I would say that you want to split it into generic > genetic algorithm engine and a module for performing DE mutations. The GA > and DE-mutation modules would be configured separately and then composed to > produce the solution. That means you need to define an interface between > the GA and DE modules, but once you do that then you are able to easily swap > out GA engines or apply different mutation modules to achieve different GA > algorithms. I don't think that the mutation module needs to couple to > anything to do with the objective function at all. If someone wants to plug > in their HADOOP powered genetic algorithm instead of using the library > provided one then they would just use the DE mutations module. Alternately > they could use ASIO to build their own distributed GA module based on the > one provided by the library. There are already several policy components to allow user customization of DE, one of them being the "Mutation Policy" component. Does this address your suggestion, or are you referring to something even more general than that? Thanks, Adrian www.tradery.com

1 0

[config] How to use on Mac with C++11 dialect?
by John M. Dlugosz 17 Jan '12

17 Jan '12

I've asked this on Boost-User and had no reply. Maybe someone here would know? Using the current Boost 1.48 and the current Clang for the Apple Macintosh, when the compiler is set to accept the C++11 dialect (that is, new "auto" usage, lambda functions, rvalue references, etc.) then Boost headers choke. So currently we can use either C++11 or Boost, but not both. I'm sure it's a matter of configuration, of telling Boost headers that the compiler is indeed supporting these constructs. Can someone please point out what needs to be done? Thanks, —John

3 2

Re: [boost] compile time parser generator
by Martin Bidlingmaier 16 Jan '12

16 Jan '12

I'm not sure it's possible to get a string literal in a template< char ... > class string; 'Literals transformation is redefined into two distinct phases: raw and cooked. A raw literal is a sequence of characters of some specific type, while the cooked literal is of a separate type. The C++ literal 1234, as a raw literal, is this sequence of characters '1', '2', '3', '4'. As a cooked literal, it is the integer 1234. The C++ literal 0xA in raw form is '0', 'x', 'A', while in cooked form it is the integer 10. Literals can be extended in both raw and cooked forms, with the exception of string literals, which can only be processed in cooked form. This exception is due to the fact that strings have prefixes that affect the specific meaning and type of the characters in question.' - source: wikipedia - http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals . Parsing string literals with constexpr is described in this article: http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-pa… For building the parser generator I used compile time polymorphism. Each symbol in EBNF would be represented as a class. The interface each symbol defines looks like this: struct symbol { constexpr symbol( const_string str , unsigned int begin = 0 ); //for an implementation of const_string see the article I linked constexpr bool valid(); constexpr unsigned int end(); }; For example, a symbol that parses a single character 'a' looks like this: struct sym_a { constexpr sym_a( const_string str , unsigned int begin = 0 ) : m_end ( begin >= str.size() ? 0u - 1 : //invalid index str[ begin ] == 'a' ? begin + 1 : 0u - 1 ) { } constexpr bool valid() { return m_end != 0u - 1; } constexpr unsigned int end() { return m_end; } unsigned int m_end; }; constexpr sym_a s1( "a" ); constexpr sym_a s2( "b" ); static_assert( s1.valid() , "" ); static_assert( !s2.valid() , "" ); The source for my current version of the parser generator is appended. I've also created a simple calculator that can handle + and * (and will accept any digit sequence as number, including "00000"). Notice, that currently only char strings are completely supported, defining terminals and the opt< T > operator won't work with other literals. (I know I can improve this for terminals, but I'm not sure about opt< T >.) The source compiles with gcc 4.6 and c++11 turned on without errors. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

6 19

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

"protected" APIs
by Lorenzo Caminiti 16 Jan '12

16 Jan '12

Hello all, Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit: BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ... So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named? These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users: BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead: BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared What's the best convention to follow here? Thanks a lot. --Lorenzo

8 8

build error in Release branch
by Barend Gehrels 15 Jan '12

15 Jan '12

Hi, I get a build error in the release branch: .../release/tools/build/v2/build/project.jam:266: unbalanced parentheses I just looked for differences in Trunk and Release and indeed that line differs. I updated the file conform trunk, locally, and I can build now. I then get the message: warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.12.00 warning: Boost.Build core (at /home/barend/svn/boost/release/tools/build/v2) is 2011.04-svn So this might be my problem (not sure). However I'm normally using only one bjam, copying it to /usr/local/bin, but this time I cannot do that... Should I use different bjam's for Trunk/Release versions? Is this a known problem / will this be solved? Regards, Barend

2 2

[scope_exit] improvements
by Lorenzo Caminiti 15 Jan '12

15 Jan '12

Hello all, I've been working with Alex to make the following improvements to Boost.ScopeExit (as they were discussed during Boost.Local's review). The update docs: https://svn.boost.org/svn/boost/sandbox/closure/libs/scope_exit/doc/html/in… 1) It is possible to use variadic macros on compilers that support them: int r = 0, v = 0; BOOST_SCOPE_EXIT(&r, v) { r = v; } BOOST_SCOPE_EXIT_END To support compilers without variadics and for backward compatibility with previous ScopeExit versions, all macros also accepts pp-sequences: BOOST_SCOPE_EXIT( (&r) (v) ) { r = v; } BOOST_SCOPE_EXIT_END 2) It is possible to capture no variable using `void`: BOOST_SCOPE_EXIT(void) { std::cout << "cout is a global variable << std::endl; } BOOST_SCOPE_EXIT_END This same syntax works on compilers with and without variadics. 3) From within member functions, it is possible to capture the object this using `this_`: BOOST_SCOPE_EXIT(&r, v, this_) { r = this_->f(v); } BOOST_SCOPE_EXIT_END On C++11, you can also (but you don't have to) use `this`: BOOST_SCOPE_EXIT(&r, v, this) { // C++11 only. r = this->f(v); } BOOST_SCOPE_EXIT_END 4) On C++11, you can (but you don't have to) use `;` instead of BOOST_SCOPE_END. 5) On C++11, there is an additional macro that allows to capture all variables using lambda-style `&` or `=`: BOOST_SCOPE_EXIT_ALL(&, v, this) { // C++11 only. r = this->f(v); }; Or equivalently: BOOST_SCOPE_EXIT_ALL(=, &r) { // C++11 only. r = this->f(v); }; I still have to move these changes from the sandbox into trunk. Comments are welcome. Thanks, --Lorenzo

2 1

[typeof] TYPEOF(this) on MSVC 7.1 and 8.0
by Lorenzo Caminiti 14 Jan '12

14 Jan '12

Hello all, BOOST_TYPEOF(this) generates error C2355 on MSVC 7.1 and 8.0 because of a MSVC bug. The code below was suggested to workaround the problem but it only works with native typeof. Is there a way to make BOOST_TYPEOF(this) work on MSVC 7.1 and 8.0 with Boost.Typeof in emulation mode? // Adam Butcher's workaround to deduce `this` type on MSVC revision < 10. // Boost.Typeof for VC71's typeid-based workaround does not work to determine // `this` type due to error C2355 being incorrectly reported. The typical // avoidance strategy implemented below is to make an indirect compile-time // constant by assigning an enum and use that as type-index-- this only works // with the sizeof() approach and not with the typeid() approach. This does not // work in typeof emulation mode. #if BOOST_WORKAROUND(BOOST_MSVC, >= 1300) && /* MSVC 7.1 */ \ BOOST_WORKAROUND(BOOST_MSVC, <= 1400) && /* MSVC 8.0 */ \ !defined(BOOST_TYPEOF_EMULATION) /* doesn't work in typeof-emu mode */ namespace boost { namespace scope_exit { namespace aux { namespace msvc_typeof_this { template<int Id> struct msvc_typeid_wrapper { typedef typename boost::type_of::msvc_extract_type<boost::mpl::int_<Id> >::id2type id2type; typedef typename id2type::type type; }; template<> struct msvc_typeid_wrapper<4> { typedef msvc_typeid_wrapper<4> type; }; template<typename T> struct encode_type { BOOST_STATIC_CONSTANT(unsigned, value = boost::type_of::encode_counter<T>::count); typedef typename boost::type_of::msvc_register_type<T, boost::mpl::int_<value> >::id2type type; BOOST_STATIC_CONSTANT(unsigned, next = value + 1); }; template<class T> struct sizer { typedef char(*type)[encode_type<T>::value]; }; template<typename T> typename boost::disable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T const&); template<typename T> typename boost::enable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T&); template<typename Organizer, typename T> boost::type_of::msvc_register_type<T, Organizer> typeof_register_type(const T&, Organizer* = 0); } } } } #define BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ BOOST_PP_CAT(boost_se_thistype_index_, id) #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ enum { \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) = sizeof( \ *::boost::scope_exit::aux::msvc_typeof_this::encode_start(this)) \ }; \ typedef ::boost::scope_exit::aux::msvc_typeof_this::msvc_typeid_wrapper< \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ >::type new_type; #else // typeof(this) on other compilers are OK. #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ typedef BOOST_TYPEOF(this) new_type; #endif // typeof(this) For example: // within a member function BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(__LINE__, this_type); this_type obj = this; Thanks. --Lorenzo

1 0

[context] mini-review comments
by Jeffrey Lee Hellrung, Jr. 14 Jan '12

14 Jan '12

[Late, I know] [I'm going off http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html] [Apologies if these are just repeating previous comments!] How do you store the function and function arguments passed to the context constructor? Are they bundled into memory allocated by the stack allocator? I couldn't find it in the documentation, and whatever the answer, seems like something that should be mentioned. "The maximum number of arguments of *context-function* is defined by BOOST_CONTEXT_ARITY (default is 10) and might be changed." Hopefully you mean, more specifically, that BOOST_CONTEXT_ARITY might be *increased*. Also, consider using variadic templates if available? Great examples! Would it be possible to also show the expected output, just so the reader can verify that he or she understands what should be happening? Given that void pointers are used to communicate between contexts, I almost would've expected the context constructor to simply take a void (*)( void* ) argument and context::start to take a void* argument which would be passed to the function pointer. Can you elaborate on the rationale for the low-level interface for communicating between contexts while still providing a relatively high level interface for specifying the context function? The documentation for the stack allocator concept doesn't completely define the semantics of the size parameter of stack_allocator::allocate/deallocate. I presume it is the stack size in bytes, but that should be explicit in the documentation. And I presume allocate is only required to return a pointer to *at least* size bytes of free memory. Also, you don't mention alignment requirements; what are they? I'm somewhat surprised default_stacksize() always returns 256*1024. I think it might be safer to make this implementation-defined, but some minimum size (as with everything else in C++...). Also, strictly speaking, the documentation is incorrect. It reads "Defines a default stack size of 256 kB", but defalt_stacksize() doesn't define anything, it just returns a number. And this description is inconsistent with the remaining function descriptions. I would do: "Returns the default stack size, which is implementation-defined but at least 256 kB." In "Low level API (boost_fcontext_t)", s/stated/started/. Also, what's the magic number 262144? Oh, I see, 262144 = 256 * 1024...maybe the latter expression would be more intuitive? Again, I can guess what the output of the example would be, but would be helpful to have the expected output handy. Just a nitpick on member variable names. boost_fcontext_stack::ss_base/ss_limit: what does "ss" mean? boost_fcontext::fc_stack/fc_link: I presume the prefix "fc" is short for "fcontext", in which case, isn't it redundant? Normally I wouldn't be picky about member variable names but these are precisely the documented API. In "Rationale", you give "[o]ther low level APIs and their caveats"; I'm guessing these are, specifically, alternatives to boost_fcontext_t but are *deficient* in some respect. It might clear things up if you make that explicit, and further group "setjump()/longjmp()", "ucontext_t", and "Windows fibers" into a common heading. Overall, I think the documentation and interface are good. I didn't look at the implementation, but I did see that someone else did, so...I'm not too worried about a correct implementation. As long as there's a full suite of tests. I also didn't try to use the library, but now I'll have to find an excuse :) These are all relatively minor comments, and although I hope Oliver will address them, it won't hold up my approval of Boost.Context. - Jeff

3 7

[fusion] Getting the adapted structure's member names
by Andy Venikov 14 Jan '12

14 Jan '12

struct alien { std::string color_; std::string planet_; bool benevolent_; }; BOOST_FUSION_ADAPT_STRUCT( alien, (std::string, color_) (std::string, planet_) (bool, benevolent_) ) I know how I can get to the actual member values, i.e. I could check at<2>(anAlien) to see if I should run away or not. But what if I wanted to get to the member names? (In this example it would be "color_", "planet_" and "benevolent_") It could be very useful for example for serialization that stores not just values but also the names of the values. Printing structures to stdout for inspection would be a breeze too. Since BOOST_FUSION_ADAPT_STRUCT is a macro, surely the member names could be strigized and stored somewhere. Thanks, Andy.

2 1

__COUNTER__ vs __LINE__
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, Many of Boost macro APIs PP_CAT symbols with either __LINE__ or __COUNTER__ to make them unique (MPL_STATIC_ASSERT, SCOPE_EXIT, etc). AFAIK, __LINE__ is C++03 standard while __COUNTER__ is only a MSVC extension. I think using __COUNTER__ instead of __LINE__ might allow to expand a macro multiple times on the same line... but a part from that: What's the reason for using __COUNTER__ on MSVC instead of just using __LINE__ for all compilers? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-COUNTER-vs-LINE-tp4286398p4286398.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 6

[Boost.Move] A few notes
by Dan Ivy 13 Jan '12

13 Jan '12

Hi, I was recently trying out Boost.Move and a few issues worth sharing surfaced: 1. It would be helpful to have configuration macros to force emulation mode, even on C++11 compilers, as well as to disable move semantics altogether (that is, the conversion operators to boost::rv& should be disabled, and move/forward should return lvalue-references. BOOST_RV_REF and friends should remain intact, so that overloads remain unique.) In many cases, the higher level semantics of a program are expected to be identical under all three configurations, so having a quick way to switch between them is useful during testing/debugging. 2. Boost.Move is a little bit too opaque, as it stands. What's really missing are Boost.Move-aware type traits. Things like add_rvalue_reference are often necessary to calcuate return types of move-aware generic functions, and so on. Whether this belongs in Boost.TypeTraits or Boost.Move is a separate question. Likewise, there should be type traits to calculate the return types of boost::move and, in particular, boost::forward. On C++11, the return type of forward<T> conincides with add_rvalue_reference<T>, but not so in emulation mode, hence the necessity for this trait. 3. For some reason, the emulated boost::move is written so it doesn't accept temporaries. This doesn't play too nicely with forwarding: Unavoidably on C++03, there has to be made a choice whether forwarding functions use non-const or const-qualified references (bad wording, but you get the point), where the former accepts modifiable lvalues and rejects temporaries, and the latter does the opposite (well, sort of). Boost.Move chooses the latter. This means that while BOOST_FWD_REF parameters accept temporaries, these temporaries are bound as lvalues, which pretty much defeats the purpose of the library (note that these temporaries aren't eligible for copy-elision, since they're bound to a reference.) While there's not much you can do about it on the callee-side, callers could use boost::move on the temporaries to force them into rvalue-refs. Only that they can't. This creates a somewhat confusing situation where forwarding functions are able to take temporaries, but they won't move them, while the only things that can actually be moved are lvalues... Ultimately, this is what I suggest: First of all, have boost::move accept temporaries. Secondly, seriously consider changing the definition of BOOST_FWD_REF(T) from const T& to T&, as this would acheive two desirable, IMO, goals:: a. Forwarding functions would accept modifiable lvalues (and keep them modifiable). b. Forwarding functions would REJECT temporaries, UNLESS they're passed through boost::move, which assures that they're treated as rvalues. A few notes on the implementation: 4. There are many one-liner functions floating around that aren't declared inline. This is a big-deal for less-capable compilers, such as Sun and older versions of GCC. In fact, they simply won't inline boost::move calls without it. 5. boost::rv<T> unconditionally inherits from T, with the assumption that it would never get instanciated for non-class types, since it is only ever used as a reference. This is a false assumption in general. In the context of overload-resolution, the compiler is allowed, though not required, to instanciate the types of function parameters, even if the best overload can be determined without doing this. Consider this move-aware, but not very useful vector class: #include <boost/move/move.hpp> template <typename T> struct vector { void push_back(const T&) {} void push_back(BOOST_RV_REF(T)) {} }; int main() { vector<int> v; v.push_back(123); } The last line of main could potentially instanciate rv<int>, breaking the program. And it does. Sun falls right into this trap. It doesn't take much to make it break on GCC either, for the same reason. Fortunately, the fix is trivial: specialize boost::rv correctly for non-class types. All comments refer to the 1.48 release. I don't know what's going on on trunk. HTH

5 14

Release 1.49
by Barend Gehrels 13 Jan '12

13 Jan '12

Hi, I did not see (m)any recent mail traffic on the list w.r.t. release 1.49. According to the Calendar it was to be merged last Monday (major changes) and next Monday (all changes). Is this planning still up-to-date? Thanks, Barend

2 2

[interprocess] Crash of singleton_module in Windows
by JOAQUIN M. LOPEZ MUÑOZ 13 Jan '12

13 Jan '12

Steps to reproduce the problem: * Create singleton_dll.dll. * Create singleton_exe.exe, which uses singleton_dll.dll. * Run. On exit, an access violation happens. Seemingly, the problem happens when two different singletons are created, one in the main executable and the other in a DLL. If both singletons are created in the same module everything's OK, though. Best regards, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 7

[bjam] if MSVC 7.1 or 8.0 compile-fail
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, If there a way to program the following within a Jamfile? import testing ; if(MSVC 7.1 or MSVC 8.0) { # How do I program this? [ compile-fail native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } else { [ run native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-if-MSVC-7-1-or-8-0-compile-fa… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Boost.Variant] Parameterized Visitors
by Andy Jost 13 Jan '12

13 Jan '12

New poster. When I'm using Boost.Variant, I often want to pass additional parameters to a visitor. A common case is when the variant is a class member and I want to have access to other members (or even "this") in the visitor. I muddled through for a long time writing visitors with explicit constructors and data members to take whichever parameters I needed, but I finally got around to making this generic with Boost.Fusion and I love it. I'm wondering whether I should submit this for consideration as an addition to the Boost.Variant library and how. First a few questions: 1. Is there already an equivalent solution that I should be aware of? 2. Should this be considered for an addition to Boost? 3. If so, how do I begin the review process? 4. This is a small change (400 or so lines of code). Is there anyone willing to help with the logistics, testing, and/or documentation (perhaps in exchange for a credit in the docs)? Here's an example, which should be fairly self-explanatory: struct A {}; struct B {}; struct C {}; struct my_visitor1 : param_visitor<my_visitor1, bool> { result_type operator()(int, float, char, A) const {...} result_type operator()(int, float, char, B) const {...} result_type operator()(int, float, char, C) const {...} }; struct my_visitor2 : fused_param_visitor<my_visitor2, bool> { template<typename Sequence> result_type operator()(Sequence const &, A) const {...} ... }; int main() { boost::variant<A,B,C> abc; boost::apply_visitor(my_visitor1().tie(1, 3.14, 'k'), abc); boost::apply_visitor(my_visitor2().tie(1, 3.14, 'k'), abc); return 0; } In terms of technical detail, there's not much to it. The base classes provide tie() and load() methods to take arguments by reference or value, respectively. A call to one of those returns a helper object that contains a copy of the derived visitor and a fusion::vector of arguments. Visiting that causes the user-defined visitor to be called with all of the arguments. For parameter forwarding, I use an implementation of perfect forwarding based on boost/flyweight/detail/dyn_perfect_fwd.hpp (I used a default limit of 4 parameters). Thanks, Andy

2 2

tuple and virtual functions
by Mark Snelling 12 Jan '12

12 Jan '12

I'm having a problem with Boost.Tuple virtual functions. Consider the code below, I would have expected the output to be "B::foo()" but instead get "A::foo()". Am I missing something here? #include <boost/tuple/tuple.hpp> #include <iostream> class A { public: virtual void foo() { std::cout << "A::foo()" << std::endl; } }; class B :public A { public: void foo() { std::cout << "B::foo()" << std::endl; } }; boost::tuple< A > make( const A& a ) { return boost::make_tuple( a ); } int main( int argc, char* argv[] ) { B b; make( b ).get< 0 >().foo(); return 0; }

3 2

abi-compliance-checker
by Neal Becker 12 Jan '12

12 Jan '12

Sounds useful: http://forge.ispras.ru/projects/abi-compliance-checker

1 0

[context] mini-review period ended
by Giovanni Piero Deretta 12 Jan '12

12 Jan '12

Hi all, The boost.context mini-review period ended sometime betweend yesterday and today depending on your timezone. We didn't get many reviews, but we had some interesting discussions and I should be able to reach a conclusion. If anybody is still completing a review, please let me know me ASAP, otherwise I should be able to wrap everything up by this weekend and announce the results next week. Thanks for everybody that partecipated in the review and thanks to Oliver for submitting his library. -- gpd

1 0

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 12 Jan '12

12 Jan '12

Vicente, > I'm reworking the timed wait interface using Boost.Chrono. In this case > you could use a steady clock to mean a MONOTONIC clock. Unfortunately my > refactoring did use pthread_condattr_setclock to force a monotonic clock > while waiting on the condition. Even if this should not be the source of > the problem as it works when you don't generate the signals, I think > that this will be better when available. I will need some time to make > this working but I hope I could release it for boost 1.50 :( Looking forward to that. For the moment we have a workaround, but I will keep an eye on changes in this area, so we can move back when this becomes available. >> The demo application shows where things go right and wrong, so hopefully >> you should be able to reproduce the issue. > > I have not understood the example completely. How do you change the time > forward or backward? Could you point me where or how do you do? by hand? Sorry, should have mentioned that. I change the time externally by hand, using the date command. When I change the time backwards (so an earlier time) the problem occurs. When I change the time forward again to a time equal to or before the time I changed the time the application continues. >> >> Again, thank you for your quick response. >> >> > Thanks for reporting this and for the application example. > Vicente Thank you for your work on this. Kind regards, Johan Borkhuis

1 0

problem in trunk with file system library
by Robert Ramey 12 Jan '12

12 Jan '12

I'm seeing this message on bunch of tests "/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -fPIC -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=binary_archive.hpp -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/serialization/test/test_array_binary_archive.test/gcc-4.3.4/debug/test_array.o" "../libs/serialization/test/test_array.cpp" In file included from ../boost/filesystem.hpp:36, from ../libs/serialization/test/test_tools.hpp:5, from ../libs/serialization/test/test_array.cpp:22: ../boost/filesystem/v3/operations.hpp:139: error: extra ???;??? ../boost/system/error_code.hpp:214: warning: ???boost::system::posix_category??? defined but not used ../boost/system/error_code.hpp:215: warning: ???boost::system::errno_ecat??? defined but not used ../boost/system/error_code.hpp:216: warning: ???boost::system::native_ecat??? defined but not used This is provoked by the following code:symlink_perms = 0x4000 // on POSIX, don't resolve symlinks; implied on Windows};BOOST_BITMASK(perms); // line 139//--------------------------------------------------------------------------------------//Would it be possible to get this fixed. I don't what the exact fix is. Robert Ramey

2 1

Fwd: How to build the documentation
by Pedro Larroy 11 Jan '12

11 Jan '12

---------- Forwarded message ---------- From: Pedro Larroy <pedro.larroy.lists(a)gmail.com> Date: Sun, Dec 25, 2011 at 7:35 PM Subject: How to build the documentation To: boost-docs(a)lists.boost.org Hi I created a small patch for libs/python/doc/tutorial/doc/tutorial.qbk How can I check that it builds correctly and generates propper html? Regards. Pedro.

5 8

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 11 Jan '12

11 Jan '12

Vicente, Thank you for your quick reply. I did not get the message from the mailing list, so I copied your questions into this mail. As requested I opened a ticket (ticket# 6377) and I attached the demo application to it, with a small description. > Do you mean that you are not using Boost.thread here? No, the application is running in one thread. The condition variables are used as an alternative sleep method. We discovered that other sleep-methods are even more vulnerable to time changes, and also have different responses to Posix signals. The condition variables continue to work correctly, even with Posix signals, however in combination with time changes there are some issues. In our real application we are using boost threads quite heavily though. > What do you changed exactly? Could you post a patch? I attached the demo application to the issue. It includes the regular Boost condition variable use and the changed implementation. It also includes the Posix timer code to generate the signals. I did not change the Boost code (yet), as I am not that familiar with it. > Please, could you post the test that fails and the one that succeeds, it > will help me a lot. The demo application shows where things go right and wrong, so hopefully you should be able to reproduce the issue. Again, thank you for your quick response. Regards, Johan Borkhuis

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 11 Jan '12

11 Jan '12

On 1/9/2012 12:09 PM, Simonson, Lucanus J wrote: > > > I think that numerical optimization is more general than its application to > machine learning. While you argue that you'd like to see the library go > deep in machine learning I don't see anything wrong with a general purpose > numerical optimization library. However, DE is more general than numerical > optimization, while the library seems to be an application of DE to > numerical optimization. I'm not sure that DE is even one of the best ways > to do numerical optimization (I'm pretty sure genetic algorithm is a bad > way, so I'm skeptical), and I know I'd like a more general interface to a DE > engine than one designed for numerical optimization problems. I'd like to > see the library go wide for max applicability rather than deep. Hopefully > that will keep it out of all the different cans of worms that could be > opened in each application domain. Put numerical optimization and machine > learning applications in the example code of the library and submit just the > core engine as the library itself. Narrowing the scope of a library submission > is usually the path to success. > I forwarded Ken Price (one of the DE co-authors) some of the comments I received for his view on things and here's his reply, which hopefully should clarify some of the issues that have been raised: "The skeptic is right in believing that GAs have traditionally done poorly at numerical optimization, primarily because they rely on general data manipulation operations (bit flips, exchanges, rotations, insertions, replacements...) that are not appropriate for real-parameter optimization. DE, however, was specifically designed for numerical optimization (although it has since been applied with limited success to combinatorial problems). Instead of relying on general data manipulation operations, DE's unique differential mutation operation is a real-valued vector operation that is appropriate for the numerical optimization problem domain. More than just appropriate, the differential mutation operation at the core of DE is effective because it exploits the tendency of a population to distribute itself around function contours. Randomly sampling the difference in the location of population members when they are distributed along a function's level surfaces turns out to be a very effective way to deal with some of the most challenging aspects of numerical optimization, e.g. multiple optima, parameter-dependence, slow-down at high resolution and disparate parameter sensitivities. As evidence of DE's utility as a numerical optimizer, I would offer that it has been part of Mathematica's numerical optimization toolbox for over a decade. It helped the Mathematica team win the SIAM 100-digit challenge (ten problems to ten-digit accuracy) by solving what the contest participants agreed was the contest's most difficult (numerical optimization) problem. (DE also solved one of the other problems in the contest). In the many other contests that have been held to compare numerical optimizers, DE has consistently placed at or near the top. DE is also part of the OPTIMUS package, which is highly respected and in wide use by several automobile manufactures. Alternatively, skeptics can do an Internet search and discover for themselves the enormous range of engineering problems the DE has successfully solved, nearly all of which are numerical optimization problems, often with multiple, non-linear constraints. DE has also proven effective in the domain of multi-objective numerical optimization. Finally, I would suggest that since DE is so simple and easy to implement, skeptics ought to just try it. Most people are surprised by how effective something as simple as DE can be."

2 1

[concept_check] Should OutputIterator check for output_iterator_tag?
by Ronald Garcia 11 Jan '12

11 Jan '12

Hello, In tracking down a problem with Boost.MultiArray, I'd like to write a test case that exhibits the failure. Specifically, certain iterators should be models of OutputIterator, and it's my impression that an output iterator needs to have an iterator_category that's convertible to output_iterator_tag(). However, it looks like the OutputIterator Concept checker in the concept checker library does not check that the output iterator has such an iterator_category. Is that an oversight, or is it not the case that an output iterator have a category that's convertible to output_iterator_tag? It looks like InputIterator, RandomAccessIterator concept checkers perform such a check. Thanks, Ron

3 4

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 11 Jan '12

11 Jan '12

On 1/9/2012 9:41 AM, Brian Schrom wrote: > > On 01/09/2012 09:11 AM, Paul A. Bristow wrote: >>> -----Original Message----- >>> >>> I, for one, think this looks a very useful library. >>> [...] >>> So you may need to find and drum up support from some potential (or > better still, actual) users ? >>> > I will provide a review if this library gets to review, so > far, I've not looked much at this submission. > Thanks. > I think that machine learning is an area where there is enough maturity > that implementations in Boost are desirable. > > A couple of things to consider. > > It would be desirable that the machine learning topic area be > designed a bit more comprehensively than a single library. For example, I > should be able to run a GA on the same data as the DE. I would hope > that they have the same API. This somewhat implies to me that DE/GA are > instances of training algorithms, for which, many are possible. The way I see it, the only common point between different optimization algorithms (if they are generic enough) is the objective function, which should have a very simple prototype: double f( std::vector< double > ); so in theory if different algorithms are implemented to accept the same types (in C++ sense) of objective functions, then you could run them interchangeably between GA, DE etc without any modification to the function or algorithm. > > There are many things that go into a ML solution. Data conditioning, > model training, model validation, model evaluation. Training in > batch modes, instance based, etc. Just to name a couple issues... > > Then the normal list of library desires...completely generic, optimized > for every conceivable configuration (embedded processor, server farm, > etc i.e. single process, multi-threaded, mpi, etc) > > My advice is to be prepared for the big can of worms that this topic could > potentially bring up. > I think the topic area will be a very hard sell, but would be very > useful. > There are many real-life applications that I believe would benefit immediately from a maybe less than perfect implementation, so if it were my choice, I would rather release an initial version sooner and enhance it based on experience gathered from its practical use. Adrian Michel www.tradery.com

2 2

Weak functor: Interested? (How to boost::bind to a weak_ptr)
by Vladimír Třebický 11 Jan '12

11 Jan '12

Hi! I saw people asking how to do boost::bind using a weak pointer. Generally it's not possible without first specifying what should happen if the weak_ptr cannot be converted to shared_ptr. The "weak_fn" I wrote is a small class holding a member pointer, a weak pointer and a "policy": * It is callable so you can insert it to boost::bind. * You can construct it using free function templates. * The policy says what should happen when the object is called yet the weak_ptr cannot be converted to shared_ptr. * It's implemented both using variadic templates and Boost.Preprocessor. Copy of the help comment: /** Returns a callback that can be used eg. in boost::bind. When called, it * tries to lock weak_ptr to get a shared_ptr. If successful, it calls * given member function with given arguments. If not successful, it calls given * policy functor. Built-in policies are: * * "ignore_if_invalid" - does nothing * "throw_if_invalid" - throws "bad_weak_ptr" * "return_default_if_invalid" - returns given value * * Example: * * struct Foo { * void bar(int i) { * std::cout << i << std::endl; * } * }; * * struct do_something { * void operator()() { * std::cout << "outdated reference" << std::endl; * } * }; * * int main() * { * boost::shared_ptr<Foo> sp(new Foo()); * boost::weak_ptr<Foo> wp(sp); * * boost::bind(boost::weak_fn(&Foo::bar, wp), _1)(1); * sp.reset(); * boost::bind(boost::weak_fn(&Foo::bar, wp), 1)(); * boost::bind(boost::weak_fn(&Foo::bar, wp, do_something()), 1)(); * } */ What's missing: * Cannot point to a free function. Only member functions. * ? Wdys? Vladimir.

6 16

Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 11 Jan '12

11 Jan '12

I came across the following issue with condition variables. I don't know if this is an issue with my application or with Boost condition variables. First my setup. I am using Linux on an ARM system, running Boost 1.47. My application needs accurate timing, and for this I use a POSIX timer using SIGRTMIN. This part is not something that I can control, it is an external library that implements this. I use condition variables are a timing mechanism with in my software. When I use condition variables without the POSIX timer there is no problem. The timing continues correctly, even if I change the time forward or backward. When I start the POSIX timer the condition variable does not time-out when I change the time backward. It only times out when the original time (plus timeout) is reached. The code I use to create the condition variable: boost::mutex m; boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); cond.timed_wait(lk, duration); I tested this also by extracting the code from Boost and implementing this inline. This gave the same results. When I changed the clock of the pthread condition variable to monotonic (call to pthread_condattr_setclock(&condattr, CLOCK_MONOTONIC)) the result was OK again. Is this an issue with my implementation, can I change some setting or is this a (known) issue with the Boost condition variables? If people are interested, I do have a small test application that I used to test this issue that I can post here. I don't know however what the policy is on this list wrt posting of attachments. Kind regards, Johan Borkhuis

3 2

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

Thomas Klimpel wrote: >THOMAS JORDAN wrote: > > Thanks, yes that would be the sensible way to proceed. > > My other question was, though - > > Does Boost::Move library rely on compiler optimisations of > > copy-elision/return value optimisation, as is the case with the Adobe > > Source Library (ASL) Move library, for example. The reason I ask is > > that I suspect the compiler I want to target is not very good at > > said optimisations. Or are there any other known factors which > > could > > mitigate > > against its effectiveness for a. n. other compiler? > Note the RVO (return value optimization) is a feature that is either working > or not, similarly to tail recursion in functional languages. This is unlike > URVO (unnamed return value optimization), which depends on the code > analysis capabilities of a optimizer. (Well, some compilers used to turn off > RVO in debug mode, but this should no longer be the case.) > Writing tests to check whether RVO is implemented is easy. I guess you > have a pretty good chance that even your compiler supports RVO (so I > guess the ASL Move library would work). But this doesn't mean that it will > be easy to get Boost.Move working with your compiler. Actually, just to clarify, I ran some tests which indicate the compiler (Sun C++ 5.10) does RVO on temporaries, but does not do NRVO and also does not seem to do copy-elision (as often as it might, at least). Now the ASL Move library does definitely depend on copy elision to provide any performance benefit, as is stated in its documentation. I tried that library and saw no gain - exactly the same call sequence took place. That seems to make sense I have pulled in the Boost::Move library - actually I only just pulled/hacked in the bare minimum, i.e., the macros and the ::boost::rv class and little else, as I am not so concerned about the C++0x/C++03/platform portability to begin with, just the performance. I got it compiling and running just before I knocked off for the day. It looks like there may be a couple fewer copies than with ASL or than without any move library, but not as much of a reduction as I wanted/expected, though I need to analyse it again more thoroughly tomorrow. It looks from the design of the boost::rv classes and associated overloads, and the conversion operators generated like the macros, that unlike ASL, Boost::Move doesn't rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable assumption? Or is there anything else that people are aware of which could hinder the optimal performance of Boost::Move? Regards, T.

1 0

[range] SinglePassIterator concept check is too strict
by Nathan Ridge 10 Jan '12

10 Jan '12

Hello, It seems to me the concept checking performed by Boost.Range for the SinglePassIterator concept is too strict. In boost/range/concepts.hpp, SinglePassIteratorConcept checks for the following usage (line 157 in trunk): BOOST_DEDUCED_TYPENAME boost::detail::iterator_traits<Iterator>::reference r1(*i); This requires that the return type of operator* be convertible to the iterator's reference type. However, looking at the specification for single pass iterators [1], I don't see any requirement that the return type of operator* be convertible to the reference type - it just needs to be convertible to the value type. An example of an iterator for which the return type of operator* is not convertible to the iterator's reference type is std::istreambuf_iterator<charT>, whose reference type is charT&, but the return type of its operator* is charT. (Both of these are specified explicitly in section 24.5.3 of the C++03 standard.) As a result, code such as the following fails to compile with GCC or MSVC in C++03 mode: #include <boost/range/concepts.hpp> #include <boost/range/iterator_range.hpp> #include <iterator> #include <istream> int main() { BOOST_CONCEPT_ASSERT (( boost::SinglePassRangeConcept< boost::iterator_range< std::istreambuf_iterator<char> > > )); } (In C++11, things changed - a requirement was added that the return type of operator* be the same as the iterator's reference type, and correspondingly std::istreambuf_iterator<charT>'s reference type was changed to be charT). What can be done about this? Regards, Nate [1] http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/new-iter-concepts.ht…

3 2

[context review] Performance questions
by Antony Polukhin 10 Jan '12

10 Jan '12

I`ve read through the documentation of Boost.Context and some questions pop up: 1) What if we reimplement the ASIO example without Boost.Context (server class will look like this): class server : public boost::enable_shared_from_this< server > { private: boost::asio::ip::tcp::acceptor acceptor_; boost::array< char, 1024 > buffer_; void do_() { boost::asio::ip::tcp::socket socket( acceptor_.get_io_service() ); acceptor_.async_accept( socket, boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } void do_1_(boost::system::error_code ec) { if (!ec) { socket.async_read_some( boost::asio::buffer(buffer_), boost::bind( & server::do_2_, this->shared_from_this(), _1, _2) ); } else { do_(); } } void do_2_(boost::system::error_code ec, size_t n) if (!ec) { boost::asio::async_write( socket, boost::asio::buffer( buffer, n), boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } else { do_(); } } } server( boost::asio::io_service & io_service, short port) : acceptor_( io_service, boost::asio::ip::tcp::endpoint( boost::asio::ip::tcp::v4(), port) ), {} public: typedef boost::shared_ptr< server > ptr_t; static ptr_t create( boost::asio::io_service & io_service, short port) { return ptr_t( new server( io_service, port) ); } void operator()( boost::system::error_code /*ec*/, size_t /*n*/) { do_(); } }; Looks like this implementation will be faster (it has the same amount of io_service posted functions, no dynamic allocations, but has no context switches). Am I missing something? 2) Can we use contexts like condition variables? For example: struct task{ }; std::deque void thread_1() void threads

3 7

[C++ Now! 2012] Deadline extension: Call for Submissions, new deadline is January 20th, 2012
by Hartmut Kaiser 10 Jan '12

10 Jan '12

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 20th, 2012. UPDATED! Proposals decisions sent (tentative program): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements In Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

2 1

[Boost.Test] g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)
by Torsten Maehne 10 Jan '12

10 Jan '12

Hello, I would like to draw your attention to an issue in Boost.Test that I'm experiencing with Boost trunk after the 1.48.0 release up until at least SVN rev. 76398. Just including directly or indirectly boost/typeof/ native.hpp into a unit test module (which includes boost/test/included/ unit_test.hpp) will cause compiler errors with g++: ==== begin: test_boost_test_decorator_enable_if.cpp ==== #define BOOST_TEST_MODULE test_boost_test_decorator_enable_if #include <boost/test/included/unit_test.hpp> #include <boost/typeof/native.hpp> //! \test Dummy test. BOOST_AUTO_TEST_CASE(test_dummy) { // do nothing } ==== end: test_boost_test_decorator_enable_if.cpp ==== g++ reports: In file included from test_boost_test_decorator_enable_if.cpp:62: boost/typeof/native.hpp:30: error: expected nested-name-specifier before ‘enable_if’ boost/typeof/native.hpp:30: error: expected initializer before ‘<’ token boost/typeof/native.hpp:34: error: expected nested-name-specifier before ‘disable_if’ boost/typeof/native.hpp:34: error: expected initializer before ‘<’ token The reason is an ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if in boost/typeof/native.hpp, as well as the disable_if counterparts. The test case compiles correctly against Boost 1.48.0 using Apple g++ 4.2.1, MacPorts? g++ 4.5.3 and 4.6.2 as well as Apple clang++ 3.0 on Mac OS X Lion 10.7.2 and Xcode 4.2.1. It fails to compile against Boost trunk until at least svn rev. 76217 using any of the mentioned g++ versions. Surprisingly, clang++ 3.0 is still able to correctly compile the test case. The test case is derived from test_signed_integer_output_with_karma.cpp in Trac ticket #6126. During the discussion of ticket #6126 on the Boost- Spirit-general mailing list, Jeroen Habraken identified the header boost/ test/tree/decorator.hpp as the origin for the compilation failure of the test case against Boost trunk. He found the cause to be an ambiguity: $ g++-mp-4.6 -o test_boost_test_decorator_enable_if test_boost_test_decorator_enable_if.cpp -I.../boost-trunk In file included from test_boost_test_decorator_enable_if.cpp:58:0: boost/typeof/native.hpp:30:18: error: expected nested-name-specifier before 'enable_if' boost/typeof/native.hpp:30:27: error: expected initializer before '<' token boost/typeof/native.hpp:34:18: error: expected nested-name-specifier before 'disable_if' boost/typeof/native.hpp:34:28: error: expected initializer before '<' token These occur because the code states "typename enable_if<Cond, T>::type" and the type name doesn't make sense in combination with boost::unit_test::decorator::enable_if. When removing the typename, on gets the following ambiguity error: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if showing the conflict between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if. As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. My search on trac for boost::unit_test::decorator_enable_if turned up changeset 74663 by rogeeff, who I therefore put in CC of the ticket 6331, which describes the findings of Jeroen and me. However, there hasn't been any feedback over the past 12 days. Therefore, I'm posting it now to the Boost.Devel mailing list hoping that the issue can be resolved before Boost 1.49 is released. Regards, Torsten Maehne

1 0

Re: [boost] FW: FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 10 Jan '12

10 Jan '12

On 1/9/2012 9:11 AM, Paul A. Bristow wrote: > > I, for one, think this looks a very useful library. > > But few of the Boosters who follow these lists will be expert or even > potential users of this > 'niche' topic - which is why I think you've not had a deservedly rave > response ;-) > Thanks. I'm actually not surprised by the limited response for the exact reasons you mention, but I imagine this must have been the case with other libraries as well. > The documentation looks in a good state. The code looks clean and portable, > but finding someone to > run on a non-MSVC platforms would be useful - Boost likes to be *seen* to be > portable. > I thought that was going to be a requirement in a later stage, after the library was accepted. Nevertheless, if somebody on this list is willing to test the library on a non MS platform and using a compiler different from Visual Studio, I will appreciated your help! > The folder structure should be 'Boost standard' so that it is possible to > use bjam to build and use > Boost.Test. (Do not hesitate to ask for help - bjam is the Outer Mongolian > of computer languages > and using it is a dark art!) I'll look into it and make the necessary changes. > > You will first need to find a review manager (preferably a Boost > contributor), and it will be > necessary to have some reviewers too! (Reviewers need not necessarily be > currently active Boost > followers for a specialist library like this - expertise is the key thing). > > So you may need to find and drum up support from some potential (or better > still, actual) users ? The library was reviewed from a functional and conceptual standpoint by the creators of the DE algorithm and they seem to have validated it, maybe less so from a C++ standpoint though. I also received very useful feedback for further enhancements that I'll be adding in a future release. As far as a boost review manager and other reviewers, I can only count on list members that are willing to volunteer some of their time for this purpose (please let me know if interested). I'll also try to gather some support outside of the list. One of the nice things about DE is that it is relatively simple and generic, and it doesn't require any advanced or domain specific knowledge, so I'm sure anybody on this list could learn enough about it to be able to review the library, without spending too much time and effort. Adrian Michel www.tradery.com

2 1

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

>From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> >To: boost(a)lists.boost.org >Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with > older versions of Boost and Performance >Message-ID: <4F09F0C3.4080306(a)wanadoo.fr> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ø Le 08/01/12 12:25, Thomas Jordan a ?crit : Ø >> Message: 3 Ø >> Date: Sat, 07 Jan 2012 15:58:20 +0100 Ø >> From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> Ø <snip> Ø >> Le 07/01/12 12:10, Thomas Jordan a ?crit : Ø >>> Hi, Ø >>> I am interested in experimenting with v1.48 Boost.Move and Ø >>> Boost.Container. However, I am otherwise constrained to using Boost Ø >>> libraries v1.33.1 with Ø >>> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library Ø >>> dependencies' listed in the Move/Container documentation, but a Ø >>> quick look through the header files suggests Ø >>> that it is mainly MPL and Type Traits. So... Ø >>> First question: would it be feasible for me to combine the headers Ø >>> for these two libraries with the v1.33.1 libraries and get it to Ø >>> work (albeit maybe with a little customisation), or would it be a Ø >>> big job/non-starter? Ø >>> Second question - I don't see any performance analysis published for Ø >>> Boost.Move. I know that move semantics is about more than improved Ø >>> performance, but am interested in that side of things, especially as Ø >>> the above compiler appears suboptimal in terms of copy elision and Ø >>> RVO. I am wondering for example whether are there any Ø >>> (compiler-specific) factors which could mitigate against the Ø >>> performance benefits of doing a move vs a copy of a vector, using Ø >>> these libraries, for example. Ø >>> Ø >> Ø >> Hi, Ø >> Ø >> unfortunately Boost.Move and Boost.Container are not working up to now Ø >> on Sun c++ even on trunk (1.49). See Ø >> http://www.boost.org/development/tests/trunk/developer/container.html. Ø >> Ø >> Best, Ø >> Vicente Ø Ø >Thanks for pointing me to that. In general is there anything more Ø >detailed than pass/fail available to look at? Ø >Is the assumption that something with so many fails it not fixable one Ø >the library side, and is not worth investigating? Ø > Ø > Ø Lastly there were some issues reporting the failure on the Sandia Ø testers. Sun compiler miss a lot of useful features for many Boost Ø libraries. Ø I think the best you can do is to install the version 1.48 (or the Ø trunk), run the tests yourself, look for the first failures in Ø Boost.Move and try to understand what is going wrong. Report the Ø failures here and try to solve them with the help of Ion and the Boost Ø comunity. Ø HTH, Ø Vicente Thanks, yes that would be the sensible way to proceed. My other question was, though - Does Boost::Move library rely on compiler optimisations of copy-elision/return value optimisation, as is the case with the Adobe Source Library (ASL) Move library, for example. The reason I ask is that I suspect the compiler I want to target is not very good at said optimisations. Or are there any other known factors which could mitigate against its effectiveness for a. n. other compiler? Regards, T.

2 1

[random] uniform_real problem (what, again?)
by Neal Becker 10 Jan '12

10 Jan '12

Testing with 1.47.0, I know we added an assert min <= max But is min==max valid? I just tried testing with a uniform_real (0,0), and it seems to hang forever. I haven't tried to fully analyze the code, but I'm guessing this could be a problem: if(result < max_value) return result; So should that assert be min < max? Also, I find it unfortunate that it is not possible to use uniform_real (x,x) as a limiting case - it occurs naturally in my code when I don't actually want to generate a range of values but just a constant value.

1 0

Boost Review Wizard Report for January 2012
by Ronald Garcia 10 Jan '12

10 Jan '12

============================================== Review Wizard Status Report for January 2012 ============================================== News ==== 1. Type Traits Library Extensions Accepted 2. AutoIndex Tool Accepted 3. Heaps Library Accepted 4. Assign v2 Library Rejected 5. Type Traits Introspection Library Accepted 6. Lockfree Library Accepted 7. Algorithm Library Accepted 8. Atomic Library Accepted 9. Local Library Accepted 10. Context Mini-review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak * GIL.IO - accepted January 2011; author: Christian Henning. * Atomic - accepted July 2011; author Helge Bahmann * Lockfree - accepted August 2011; author: Tim Blechmann. * Algorithm - accepted December 2011; author: Marshall Clow The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Heaps - accepted June 2011; author: Tim Blechmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Log - accepted provisionally March 2010; author: Andrey Semashev. * Endian - accepted provisionally November 2011; author: Beman Dawes. After repeated failed attempts to contact the author, the following library has been marked as Orphaned. * Switch library, accepted provisionally January 2008 author: Steven Watanabe. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Network (M) * Singularity (M) * Predef (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/icaretaker/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Predef ------ :Author: Rene Rivera :Review Manager: Needed :Download: http://tinyurl.com/73n6a3k :Description: The Predef library implements two simple tasks: 1. Definition of a single version number macro to provide consistent version number at the preprocessor level. 2. A collection of detected definitions for compilers, standard libraries, architectures, operating systems, and languages. Unlike the Boost Config Library it doesn't define language features and capabilities. But only defines presence of detected compilation context. Documentation and downloads are available in the sandbox.. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[context] 4 days left on Boost.Context mini-review
by Giovanni Piero Deretta 10 Jan '12

10 Jan '12

Hi All, This is a call for reviewers for Boost.Context. The mini review period will end the 11th of this month and we only had 1 review so far and we were expecting a few more. We had some interesting discussions on the original review period and quite a few people were involved, so anybody who has an interest in boost.context please write a review. thank you all, -- gpd

6 12

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 09 Jan '12

09 Jan '12

On 12/23/2011 10:07 AM, Dave Abrahams wrote: >> On 12.12.2011 06:52, Adrian Michel wrote: >> >> The full documentation is at http://www.amichel.com/de/doc/html but >> I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . > > This looks like important and useful stuff to me. > I was wondering what the status of this proposal is. So far several members have expressed interest, but there have been no new posts on this in a while, and I'm not sure what to expect next as far as the boost inclusion acceptance (or rejection) process. Adrian Michel www.tradery.com

4 3

[iterator] Combining traversal_tags with iterator_tags
by Ronald Garcia 09 Jan '12

09 Jan '12

Hi, In MultiArray I would like use iterator_facade to create an iterator that can satisfy random_access_traversal, input_iterator_tag, and output_iterator_tag. I see that in the file boost/iterator/detail/facade_iterator_category.hpp, at line 138 there is a class in the boost::detail namespace declared template <class Category, class Traversal> struct iterator_category_with_traversal So it looks like passing: boost::detail::iterator_category_with_traversal<boost::detail::input_output_iterator_tag,boost::random_traversal_tag> as the CategoryOrTraversal would be what I want. However, two components above are in the detail namespace, so I am not sure if they are meant to be used by other libraries. Is this a safe operation? Thanks, Ron Side Notes: In my searches, I found a few buggy bits in the docs and code comments: - In boost/iterator/detail/facade_iterator_category.hpp, line 76, there's a comment: // If writability has been disabled per the above metafunction, the // result will not be convertible to output_iterator_tag. This comment corresponds to behavior that was removed in changeset: https://svn.boost.org/trac/boost/changeset/21683 Now the result will never be convertible to output_iterator_tag. - In the documentation for iterator_facade, there's a bit of a booboo where the function is first written: iterator-category(CategoryOrTraversal, value_type, reference) Then defined as: iterator-category(C,R,V) So I think the argument order is flipped.

4 8

Is the review schedule up to date?
by Klaim - Joël Lamotte 08 Jan '12

08 Jan '12

Hi and happy new year, I just wanted to know if the review schedule page is currently up to date ( http://www.boost.org/community/review_schedule.html) I'm asking because I'm a bit surprised that so much proposed libraries don't have a review manager, so maybe it's just that they have not been noted on this page? Thanks. Joël Lamotte

6 5

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by Thomas Jordan 08 Jan '12

08 Jan '12

> Message: 3 > Date: Sat, 07 Jan 2012 15:58:20 +0100 > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> <snip> > Le 07/01/12 12:10, Thomas Jordan a ?crit : >> Hi, >> I am interested in experimenting with v1.48 Boost.Move and >> Boost.Container. However, I am otherwise constrained to using Boost >> libraries v1.33.1 with >> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library >> dependencies' listed in the Move/Container documentation, but a quick >> look through the header files suggests >> that it is mainly MPL and Type Traits. So... >> First question: would it be feasible for me to combine the headers for >> these two libraries with the v1.33.1 libraries and get it to work (albeit >> maybe with a little customisation), or would it be a big job/non-starter? >> Second question - I don't see any performance analysis published for >> Boost.Move. I know that move semantics is about more than improved >> performance, but am interested in that side of things, especially as the >> above compiler appears suboptimal in terms of copy elision and RVO. I am >> wondering for example whether are there any (compiler-specific) factors >> which could mitigate against the performance benefits of doing a move vs >> a copy of a vector, using these libraries, for example. >> > > Hi, > > unfortunately Boost.Move and Boost.Container are not working up to now > on Sun c++ even on trunk (1.49). See > http://www.boost.org/development/tests/trunk/developer/container.html. > > Best, > Vicente Thanks for pointing me to that. In general is there anything more detailed than pass/fail available to look at? Is the assumption that something with so many fails it not fixable one the library side, and is not worth investigating? Regards, T.

2 1

[docs][crc] Did I do new documentation correctly?
by Daryle Walker 08 Jan '12

08 Jan '12

I completely redid the documentation for Boost.CRC in changeset [76335]. It uses Doxygen and Quickbook. I guessed on how to do it by copying files from Boost.Move. But I only did stuff within the BOOST_ROOT/libs/crc/* directory. I didn't make changes to other directories, especially the BOOST_ROOT/doc/* directory. Is stuff in that directory supposed to be automatically built? Other concerns: 1. The quickbook/doxygen system doesn't seem to handle "\todo" constructs correctly. 2. Is there a way to #define various common macros, like BOOST_STATIC_CONSTANT, so they get expanded correctly in Doxygen? Is there a "Doxyfile," or can the needed Doxygen parameters be tweaked in the Jamfile.v2? 3. I guessed that the next release will be "1.49.0", is that right? 4. Content-wise, did I miss anything? Daryle W.

3 4

compile time parser generator
by Martin Bidlingmaier 08 Jan '12

08 Jan '12

Hello, with c++11's constexpr it got possible to parse strings in c++ at compile time. I've written a parser generator to create an AST for a given EBNF syntax at compile time, which can be traversed at both run time and compile time (actually, parsing can take place at run time, too, but it's probably rather slow). At the moment, the only compiler I know of that implements enough of c++11 features is gcc (version >= 4.6). Is refining my implementation worth the effort, has such a library a chance to make it into boost? Is maybe somebody already working on this? Sincerely, Martin Bidlingmaier -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

7 10

no match for ‘operator=’ error with circular_buffer iterator when addressing buffer by reference?
by Bernd Prager 08 Jan '12

08 Jan '12

I am trying do use a circular_buffer iterator and run into problems when I try to write a copy constructor for my class. g++ (GCC) 4.5.3 generates following error: Test.cpp: In copy constructor ‘Test::Test(const Test&)’: Test.cpp:23:18: error: no match for ‘operator=’ in ‘it2 = boost::circular_buffer<T, Alloc>::begin() const [with T = int, Alloc = std::allocator<int>, boost::circular_buffer<T, Alloc>::const_iterator = boost::cb_details::iterator<boost::circular_buffer<int>, boost::cb_details::const_traits<std::allocator<int> > >]()’ /usr/local/include/boost/circular_buffer/details.hpp:253:15: note: candidate is: boost::cb_details::iterator<Buff, Traits>& boost::cb_details::iterator<Buff, Traits>::operator=(const boost::cb_details::iterator<Buff, Traits>&) [with Buff = boost::circular_buffer<int>, Traits = boost::cb_details::nonconst_traits<std::allocator<int> >, boost::cb_details::iterator<Buff, Traits> = boost::cb_details::iterator<boost::circular_buffer<int>, boost::cb_details::nonconst_traits<std::allocator<int> > >] What do I miss. Can anybody help? Thank you, -- Bernd #include <boost/circular_buffer.hpp> class Test { public: Test(); Test(const Test&); private: boost::circular_buffer<int> b; }; Test::Test() { b.resize(10); } Test::Test(const Test &t) { b.resize(10); size_t s1 = b.size(); size_t s2 = t.b.size(); boost::circular_buffer<int>::iterator it1 = b.begin(); boost::circular_buffer<int>::iterator it2 = t.b.begin(); } int main() { Test *t = new Test(); return 0; }

2 2

Re: [boost] [Boost.smart_ptr] Thread Safety
by Thomas Jordan 08 Jan '12

08 Jan '12

Message: 7 Date: Sat, 07 Jan 2012 16:49:07 -0500 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] [Boost.smart_ptr] Thread Safety Message-ID: <m24nw7p4j0.fsf(a)pluto.luannocracy.com> Content-Type: text/plain >on Sat Jan 07 2012, "Thomas Jordan" <thomasjordan-AT-btinternet.com> wrote: >> Hi, >> Is shared_array completely thread-safe, including >> destruction/reference counting? From the code in >> /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but >> according to >> >> http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… >I can't reach that (very ancient) page right now, but... The documentation for this is example is the same in the latest v1.48 release. >> // thread A >> p3 = p2; // reads p2, writes p3 >> >> // thread B >> // p2 goes out of scope: undefined, the destructor is considered a "write >> access" >> >> shared_ptr isn't completely thread-safe for simultaneous read and >> write/destruct access? The same would presumbly apply to shared_array? >> Maybe I've missed something, are there compile-time configuration >> options to determine level of safety? >shared_ptr<T> is almost exactly as threadsafe as T* is. In this case, >thread A has a reference to an object on B's stack. That object is >called p2. If thread A tries to use that object's value while the >object is being destroyed, yeah, that's a race condition. >The way to avoid this situation is for thread B to pass p2 to thread A >by value, thus creating p2a, which thread A can read without concern. >Now there's no race condition. Note: this change does /not/ cause the T >object held by p2 to be copied. Thanks, I think my confusion arose from my inferring that the P2 in thread A in this example was shorthand for P2a, i.e., a copy of the actual P2 in thread B. Makes sense as per your interpretation. Regards, T.

1 0

[Boost.Poly] Runtime Concepts
by Thomas Jordan 08 Jan '12

08 Jan '12

Hi, Forgive me if this post strays into territory beyond Boost, but I was looking at the Adobe library http://stlab.adobe.com/group__poly__related.html and some of the research papers by Sean Parent et al. describing it, which I guess many people on this list will be familiar with. Is there any reason why this library/something akin has not been put into Boost? Is it simply that it will always live in Adobe Source Libraries and there is no point duplicating in Boost? Second question - the research papers on this seemed to peter out around 2009, is there any further work going on, or has this approach been taken as far as deemed interesting, or even been informally deprecated in favour of something else? Regards, T.

4 3

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Sorry, please ignore my previous post - finger trouble. The question is as follows: ------ Hi, Is shared_array completely thread-safe, including destruction/reference counting? From the code in /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but according to http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" shared_ptr isn't completely thread-safe for simultaneous read and write/destruct access? The same would presumbly apply to shared_array? Maybe I've missed something, are there compile-time configuration options to determine level of safety? Regards, T.

2 1

[Boost.Move] [Boost.Container] Compiling with older version of Boost and performance
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, I am interested in experimenting with v1.48 Boost.Move and Boost.Container. However, I am otherwise constrained to using Boost libraries v1.33.1 with a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library dependencies' listed in the Move/Container documentation, but a quick look through the header files suggests that it is mainly MPL and Type Traits. So... First question: would it be feasible for me to combine the headers for these two libraries with the v1.33.1 libraries and get it to work (albeit maybe with a little customisation), or would it be a big job/non-starter? Second question - I don't see any performance analysis published for Boost.Move. I know that move semantics is about more than improved performance, but am interested in that side of things, especially as the above compiler appears suboptimal in terms of copy elision and RVO. I am wondering for example whether are there any (compiler-specific) factors which could mitigate against the performance benefits of doing a move vs a copy of a vector, using these libraries, for example. Regards, T.

2 1

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, Is shared_array completely thread-safe. including destruction/reference counting? http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" /bb/source/boost/boost_1_33_1/boost/detail/sp_counted_base_pt.hpp

1 0

On the lack of manpower: (Apache stdcxx)
by Jim Bell 06 Jan '12

06 Jan '12

Though this isn't news, I just came across it and it speaks to our common problem. (And it's of interest to boost users in general.) Note that ARM and Sun are even invested in stdcxx to some extent. From Apache's C++ Standard Library project <http://stdcxx.apache.org/status/2011-02.txt>: Stdcxx continues to be dormant. All but [1] committer have moved on to other projects. The only remaining committer (the VP of the project) is too busy with his day job to make even small changes, or to put out the long-awaited patch release, stdcxx 4.2.2. A number of users and organizations have been using the project and expressed interest in contributing to it. Several submitted patches, others have offered help with the project build and test infrastructure. Unfortunately, since no committer is available to review patches and guide the contributors through the ASF process to enable them to gain commit privileges there seems to be little hope of reviving stdcxx. A possible solution that would allow contributions to resume is to grant commit privileges to the handful of contributors who have already submitted some patches or expressed serious interest in contributing going forward. Another alternative is to move stdcxx to a repository outside of ASF such as SPI (http://www.spi-inc.org/) where interested developers could start committing changes on their own right away, without going through the "training" process. This seems to the preferred solution among at least some of the interested users. Are there any other options? Future plans: Unless the issue with contributions can be resolved in the next quarter I suggest to retire the project.

5 6

[Boost.Lambda] Some new features are suggested: return, iterating yield, & local var
by Huang Huan 06 Jan '12

06 Jan '12

Hi boosters, I'm intrested in Lambda, so I have worked out some new features, and suggest boost lib add them. What can I do next? NEW features: 1. return. why lambda lib do not include this? 2. generate iterator/iteration by lambda using yield return/yield break. 3. local/global var declare and using. 1. return e.g. boost::function<char(int)> f = ( if_ ( _1 >= 0 ) [ return_('a') ], return_('b') ); p.s. return should be supported. 2. iterator/iteration generation by lambda using yield return/yield break const char* p; // we shuld use the local var inside lambda instead of this var p. refer to section 3 iteration<char> it = ( for_(var(p) = _1, *var(p), var(p)++) [ if_(*var(p) != ' ') [ yield_return(*var(p)) ] if_(*var(p) == ';') [ yield_break() ] ] ) ("I love this game; no use"); p.s. The packing iteration interface is very like the yield keyword in C# IEnumeable 3.local/global var declare and using e.g. char a; var_name x, y, z; global_var<int>(y); // put this line inside lambda is ok, just before use it ( ( local_var<int>(x), // local var declare // global_var<int>(y), var(a) = 'a', var<int>(x) = _2, // using local var x ), ( local_var<char>(z), var(a), var<int>(x) = _1, // error! x is not local var here. var<int>(y), // ok for global even if another lambda var<char>(z) = 'b', ) ) p.s. Now, in my work. It's hard to simplify var<T>(x) to var(x). It's a hard template working.

5 14

Re: [boost] [log] Status (was: Is there any interest in a Group of library like to Application System!)
by Andrey Semashev 06 Jan '12

06 Jan '12

On Wednesday, January 04, 2012 09:08:16 Renato Tegon Forti wrote: > Hi Andrey, > > Thanks for your response! What is status of your lib? Do you need any help? The library is moving slowly to v2 release. Right now I'm wrapping up bounded async frontends, I intend to finish them by the weekend. Other things left to be done before the release are: - Port filters and formatters to Phoenix v3. As a part of it, improve error messages in exceptions and make filters and formatters not throw by default. - Introduce "default" sink concept to mitigate problems with trivial and advanced logging coexistence. Trivial logging will no longer initialize the library under the hood. - Implement a common attribute registration mechanism to simplify library extension. This should solve problems with settings file parser not recognizing user-defined attribute types. - Update the documentation. There are many other things to be done but they are not showstoppers for the release. Yes, help would be much appreciated, most notably in the porting to Phoenix v3 part. If anyone is willing to help, please contact me privately or through this list.

3 9

[Graph] Concept check VertexMutablePropertyGraph
by Jens Müller 05 Jan '12

05 Jan '12

Hi, http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/MutablePropertyGraph.ht… (I cannot find docs for VertexMutablePropertyGraph or EdgeMutablePropertyGraph) says that the types boost::graph_traits<G>::vertex_property_type and boost::graph_traits<G>::edge_property_type must exist. However, the concept checks (in boost/graph/graph_concepts.hpp) check for vertex_property_type<G>::type and edge_property_type<G>::type, respectively. Several questions: 1. Should there be separate docs for VertexMutablePropertyGraph and EdgeMutablePropertyGraph? 2. Should there be an actual concept check implementation for MutablePropertyGraph combining the two? 3. Should the concept check look for boost::graph_traits<G>::vertex_property_type instead of ertex_property_type<G>::type? [and the same for edge] 4. For the LEDA adapter, i.e., external adaptation, do I have to specialize vertex_property_type<G> and edge_property_type<G>? Best, Jens

2 3

[graph] VertexListGraph and InputIterator, and LEDA graph
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, I'm currently fixing up leda_graph.hpp so it passes the tests, or indeed, fixing the tests ... A leda::GRAPH<int,int> (=Graph) has to fulfill VertexListGraphConcept. This means that boost::graph_traits<G>::vertex_iterator has to be a MultiPassInputIterator, i.e., also a InputIterator. I cannot read from http://www.sgi.com/tech/stl/InputIterator.html that it must be possible that you can compute the difference between two iterators. But apparently the concept check (which fails) requires a difference type, which must be a signed integer. Is this a bug in the concept check? The vertex_iterator type is defined in leda_graph.hpp using iterator_facade: class vertex_iterator : public iterator_facade<vertex_iterator, leda::node, bidirectional_traversal_tag, const leda::node&, const leda::node*> { public: vertex_iterator(leda::node node = 0, const leda::GRAPH<vtype, etype>* g = 0) : base(node), g(g) {} private: const leda::node& dereference() const { return base; } bool equal(const vertex_iterator& other) const { return base == other.base; } void increment() { base = g->succ_node(base); } void decrement() { base = g->pred_node(base); } leda::node base; const leda::GRAPH<vtype, etype>* g; friend class iterator_core_access; }; Is maybe iterator_facade insufficient? For me, bidirectional_traversal_tag does not indicate that random access is possible ... -- Jens

2 4

[chrono] Possible bug in boost::chrono::process_real_cpu_clock::now() under Windows 32bits
by ivan.lelann＠free.fr 05 Jan '12

05 Jan '12

Hi, As of 1.48 Boost.Chrono contains code below for boost::chrono::process_real_cpu_clock::now() (boost\chrono\detail\inlined\win\process_cpu_clocks.hpp) clock_t c = ::clock(); /* ... */ return time_point( duration(c*(1000000000l/CLOCKS_PER_SEC)) ); duration::rep is int64/nanoseconds, clock_t is long. This is VS2008, Win XP 32bits. I think "c" should be cast to duration::rep before being multiplied. I randomly get negative time_point and this seems to be fixed by replacing "c" with "((duration::rep) (c))" in duration constructor : duration( ((duration::rep) (c)) *(1000000000l/CLOCKS_PER_SEC)) Can someone confirm my view and that the fix is correct ? Regards, Ivan

3 3

Is there any interest in a library for Application System? (Request for comments)
by Renato Tegon Forti 05 Jan '12

05 Jan '12

Some detail (Brainstorm): This library will provide a simple way to create an application that can be: . A Server Application A server application usually starts when system boot, and then remain running as background process, don't matter who is currently logged. In Windows this will a "Windows Service" and in UNIX a "UNIX Daemon", and we can create a "Neutral Application" that is not a daemon and service, but uses "service interface" that will provide methods like an "init", "interrogate", "restart" and so on. Some type of "system global mutex" will be implemented in this flavor, then if user want, he can determine that only one instance of service will run in a system in same time. A web server, data base server and so on area examples. . A Usual Application A usual application is a normal application, that don't need all of features provided by "server application" usually is started by a user and run by a determined period. A command, mail client, MPI master/Slave and so on area examples. . Base Class Both classes will be derivated of environment class that will provide common thinks and proprieties like an "app path", "app name", "app work dir" and so on. For sample: A user that want create a server, extend your class of "server class" and then override methods that want to get needed behavior. // windows service, or daemon class myapp : public boost::application::server{}; // neutral server class myapp : public boost::application::server<neutral>{}; // usual application class myapp : public boost::application::app{}; Note that: 1) Application can be configured using Boost.Program_options 2) I want use Boost.Log to provide log functionality when available. 3) I want create a "service model" then I want use Boost.Extension to provide dynamically late bind extension (Pluf-in System). What Boosters think? This is useful or is fool lib? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Please make suggestions! What more else? Thanks

2 2

Copyright and authorship notices
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, what is the policy of adding a Copyright notice and entries to the author list when patching existing files? I found http://www.boost.org/development/requirements.html#Ownership, but it is not completely helpful. -- Jens

3 5

[thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Hartmut Kaiser 05 Jan '12

05 Jan '12

VC10, SVN trunk: #include <boost/move/move.hpp> #include <boost/thread.hpp> int main() { return 0; } Results in: .../boost/thread/detail/move.hpp(28) : error C2995: 'remove_reference<T>::type &&boost::move(T &&)' : function template has already been defined .../boost/move/move.hpp(466) : see declaration of 'boost::move' IMHO, Boost.Thread needs to be changed to rely on Boost.Move for move semantics instead of defining its own implementation for boost::move(). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 13

Font used in the current Boost logo
by Mateusz Łoskot 04 Jan '12

04 Jan '12

Hi, I have tried to find what font is used in the Boost logo but without any luck. There seem to be no logo in vector format included in the trunk. The SVG file from the logo variants is not helpful: http://dbp-consulting.com/boostvariantslogo.html Does anyone know where to find the font or vector version of the logo? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

[geometry] GGL mailing list moved
by Mateusz Loskot 04 Jan '12

04 Jan '12

Hi, To Whom It May Concern... The Boost.Geometry library mailing list has moved from ggl at lists.osgeo.org server to geometry at lists.boost.org server. All existing subscribers and archives have been moved to the new server. The new list is available at: http://lists.boost.org/mailman/listinfo.cgi/geometry as well as listed on the main page: http://lists.boost.org/ It is also mirrored at Nabble: http://boost-geometry.203548.n3.nabble.com/ (Mirror at gmane.org may be added in future.) The old list at lists.osgeo.org will be wiped out soon. If anyone experiences any problems with the new geometry at lists.boost.org, please contact me directly. I'd like to thank OSGeo Foundation for hosting the first mailing list and the Boost mailman admins for help with the new one. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] [Container] deque emplace() requirements
by Ion Gaztañaga 04 Jan '12

04 Jan '12

El 04/01/2012 12:50, Szymon Gatner escribió: > 2011/12/13 Ion Gaztañaga<igaztanaga(a)gmail.com>: >> >> You are right, it's a bug. I'll try to fix it when I get some time. >> > > Got a chance to take a look at this? I think it's fixed in trunk, you'll need to update Boost.Intrusive as well. Best, Ion

1 0

Is there any interest in a Group of library like to Application System!
by Renato Tegon Forti 04 Jan '12

04 Jan '12

I am proposing before a Log library in model of Log4cxx, but my plan is provide a full application system that will have: * Log System (Log4cxx Model) * Application System (Windows Service, Unix Daemon and Usual Application) -> Process Management (I don't know?) * Plugin System (service model): dynamically late bind extension. This will provide modular functionality that can be loaded in applications. For sample a service that can be loaded in application container, or a skin loaded in Client (MP3) Application. To illustrate: A developer that need create a server application will do: 1) Extend for "boost::application::server" and in this it use boost::log. (here if app is a Win32 then it have a Windows Service, or a daemon in unix) 2) To create service (modular application) he extend of "boost::service" to create a service and plug this service in runtime on "boost::application::server". Note that: Application can be configured using Boost.Program_options for sample. We can use Boost.Log to log, or (I don't know) we can buid Log4 model on top of Boost.Log? What Boosters think? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Anyone that want participate is welcome! Ps: Ps: We already have some discussion in "Log Lib" topic! Thanks

3 3

Log Lib?
by Renato Tegon Forti 04 Jan '12

04 Jan '12

Is there any interest in a library to "Log" in model of Log4cxx? Thanks

2 1

Log Lib!
by Renato Tegon Forti 03 Jan '12

03 Jan '12

Is there any interest in a library to "Log" in model of Log4cxx? Thanks

6 10

[context review] Quick Review
by Stewart, Robert 03 Jan '12

03 Jan '12

Here's my quick review of the proposed Boost.Context library. I'm not familiar with the kernel-level machinations involved to save and restore the execution state managed by the context class, so I cannot comment on such implementation details and whether they satisfy the acceptance criteria. Consequently, I didn't bother to look at the implementation. The examples are good, but the discussion or comments are somewhat lacking. For example, the Enumerator example is based upon an enumerator class type which is not commented and has very little introductory text. There's a link to C# documentation on the yield keyword, but no association of enumerator's yield_return() to C#'s "yield return" statement or yield_break() to "yield break". Those associations can be inferred easily enough, but are better stated explicitly. The enumerator example is further confused by indicating that a call to yield_return() in the power derivate returns a value to the while loop in main(). What's missing is that yield_return() calls context::suspend() on enumerator's context data member which returns control to enumerator<T>::get(), which is called by main()'s while loop. The entire enumerator example should be introduced by discussing the power class first, without implementation details: class power { public: power(int _base, int _exponent); bool get(int & _value); }; Then, the example can show main(), since the above interface is sufficient. That done, the example can turn the reader's attention to how to implement power by referring to the C# yield documentation example and then relating it to Boost.Context. That will lead to the enumerator class. (Making enumerator a class template complicates matters more than necessary, BTW.) Finally, you should show expected output. I'd like to see a performance comparison of using Boost.Context versus Chris Kohlhoff's coroutines. Can his coroutines be replaced with yours without loss of efficiency? Would it require a different stack allocator to match the performance of his coroutines? (Developing the example in that direction would be useful to illustrate writing a custom stack allocator.) I don't find anything related to the Movable Stack concept suggested in the acceptance criteria. The documentation of the StackAllocator is lacking, but I've suggested a rewrite below. With that rewrite, I think it satisfies the Stack concept required for acceptance. There are no performance figures for Windows. Shouldn't there be? I think I recall that the build system doesn't support the necessary information, by default, to permit building an ABI compatible version of the library. If that's not the case, then the "How to build and install" section needs more work. Either way, the Build acceptance criteria has not quite been met yet. The _suggested_ callback-based linking was not adopted in lieu of fc_link. There should be some rationale or a FAQ for that. I've called for still more work on the documentation, but as it stands, with the concept changes I've suggested, I'm satisfied that Oliver has met the documentation acceptance criteria. _____________________________________________ Documentation comments follow. _______________ Overview This section is useful and clear, except for the second sentence of the third paragraph. It doesn't connect to the library in question as it ought and is worded a little unclearly. I'd suggest the following instead: "By contrast, transferring control within a single thread, as _context_ does, requires only a few hundred CPU cycles since it involves no system calls." You might also add something like, "which makes them useful in more contexts, particularly when implementing higher level execution control systems", to that sentence. What's missing is a Motivation section or more information in the Overview to better explain why someone would want to use Boost.Context versus other options (whatever they may be). _______________ How to build and install There should be an introductory paragraph, something like the following: "Boost.Context must be built for the particular compiler(s) and CPU architecture(s) being targeted. Each combination requires specific build command arguments as documented below." The bullets at the top of the page are only needed until the library is accepted, so be sure to remove them upon acceptance. "On POSIX and Windows systems, GNU AS and MASM are respectively required for the assembler implementation of Boost.Context" is awkward. I suggest the following instead: "Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, and MASM for Windows systems." The Note is a little awkward and includes a spelling error. I suggest the following instead: "The architecture, instruction set, and address model are optional Boost.Build properties that must be given on the bjam command line, as shown in the table below." _______________ Executing a context 3rd para: s/a function or callable object/a _context-function_/ 5th para: this should be merged with para 4 and "and might be changed" should be inside the parentheses or I don't understand how it "might be changed". 6th para, 4th sent: Add the following to the end: ", after saving the new state of the original context" 6th para, last sent: Is there anything that ensures start() is called first and only once? Example: - The control transfer comments in fn() could be a little clearer: // transfer execution control back to main() ... // execution control transferred back from main() - The first "main() calls context ctx" would be better as "main() starts context ctx" - The comment, "// ctx.suspend() was called", in the while loop is only accurate until the for loop, in fn(), terminates, right? - Expected output is not shown _______________ Transfer of data Example: - Missing comments discussing the pointers on the receiving end. For example, in fn(), I'd expect the following: void * vp = ctx.suspend(&i); // vp is &x from main()'s call to ctx.resume(&x) int j = *static_cast<int *>(vp); // j == 10 because x == 10 in main() - Expected output is not shown _______________ Exceptions in context-function s/emits/emits/ Is forced_unwind a documented exception type? That is, can it be caught explicitly? If so, the reference to "forced_unwind" should be a link to its documentation and the following might be documented as legitimate: try { // code that might throw } catch (forced_unwind) { throw; } catch (...) { // possibly not rethrow pending exception } _______________ Terminating context Shouldn't this section name be something more like, "Handling execution context termination"? 2nd example: remove the "Done" line. The "never reached" comment can then be applied to "return EXIT_SUCCESS". _______________ Chaining contexts The first two sentences should be merged something like the following: "Boost.Context provides the ability to chain context instances by passing a reference to another context, other than _not-a-context,_ as the last constructor argument." You note that the application terminates or control is transferred back to the last invocation of context::resume(). Might not the transfer also be to context::start() (if suspend()/resume() are never called)? Important: I think you mean, "context::start() must not be called on a context that is a link in the chain begun by another context. That is, call context::start() only on the first context in a chain." _______________ Unwinding stack Name this section "Stack unwinding" 2nd para, 1st bullet: Should "not-a-context" be italicized? Speaking of italics, "context" is sometimes italicized and blue and other times plain. Example: Expected output is not shown Important: s/exception!/exceptions!/ _______________ context.html Variously through this page: s/an context/a context/ or s/an context/an instance/ s/unwinds the stack before destructing it/unwinds the stack first/ s/if precondition is not fulfilled/if a precondition is not satisfied/ s/nxt is linked/nxt becomes a subsequent link in a chain/ s/the execution control/execution control/ s/The execution control/Execution control/ s/Destroyes/Destroys/ Is the move assignment operator safe against self-move assignment? start(): s/with wich/with which/ s/When the function returns/Upon return/ (to avoid confusion about whether start() or fn() has returned) resume(): s/back resuming/back, resuming/ s/ (means suspend()/, which means that suspend() returns/ (note the formatting of "returns" should be normal, not code) "[[Returns:]" is malformed Effects could be rewritten, something like the following, to be clearer: "None, if *this was not suspended by a previous call to suspend(). Otherwise, execution control is transferred back to the caller of suspend(), thereby resuming *this. The argument, vp, will be returned by the previous call to suspend()." suspend(): I think Effects is incomplete. There are spelling errors. How about the following? "Transfers execution control to the caller of the most recent call to start() or resume(). The argument, vp, will be returned by start() or resume()." unwind_stack(): Effects: suggestion: "Destroys all objects allocated on the stack, owned by *this, in the reverse order of their allocation." Non-member function swap(): Effects: suggestion: "As if l.swap(r)." _______________ Stack allocation 1st para: - "stack allocator" should probably be italicized rather than rendered as code. - Concept names are usually rendered with camelcase. Thus, s/stack-allocator/StackAllocator/. 2nd para: This should be the start of a "StackAllocator Concept" section: "StackAllocator Concept "A stack allocator must satisfy the StackAllocator concept requirements shown in the following table, in which a is an object of a StackAllocator type, p is a void *, and s is a std::size_t: " " Expression | Return type | Notes " ----------------------------------------------- " a.allocate(s) | void * | Returns a pointer to s bytes allocated from the stack " ----------------------------------------------- " a.deallocate(p, s) | void | Deallocates s bytes of memory beginning at p, a pointer previously returned by alloc.allocate()" The current documentation of allocate() and deallocate() are no longer needed. Important: This should be rephrased in terms of the concept to something like the following: "The implementation of allocate() might include logic to protect against exceeding the context's available stack size rather than leaving it as undefined behavior." You might add a note that the result of calling deallocate() with a pointer not returned by allocate() results in undefined behavior. _______________ Helper functions 1st para: s/an easy/easy/ _______________ Low level API (boost_fcontext_t) You refer to "ucontext_t" with no link or description. The example code is out of place without first seeing the documentation of boost_fcontext_t and related functions. Following the -> navigation order, the example comes first. Commenting the example and providing an introduction explaining what it illustrates would work. There is no expected output shown for the example. Presumably, the low level API is the part to port to new platforms, yet you don't state that. _______________ Struct boost_fcontext_t and related functions There is no documentation for boost_fcontext_t, particularly as it appears to be just an alias for boost_fcontext. I thought for a moment that you intend to permit different platforms to redefine the typedef to refer to different structures, as needed, but you've documented boost_fcontext_stack's ss_base and ss_limit fields, which suggests that you intend those to be part of the low level, yet documented, API. The result is that I can't figure out the purpose of the typedef. The "fc_" prefix makes sense, since it is used in boost_fcontext. By contrast, the "ss_" prefix does not make sense. I could see "fcs_", for example. ss_limit: Is the stack defined by [ss_base, ss_limit) or [ss_base, ss_limit]? "Pointer to the bottom of the stack" is ambiguous. fc_stack: The description is a little off. How about, "Tracks the memory for the context's stack"? fc_link: The description could be improved: "The address of the next context link in a chain, if any." boost_fcontext_start(): Effects are a little confusing. My suggestion: "Stores the current context data (stack pointer, instruction pointer, and CPU registers) to *ofc and restores the context data from *nfc, which implies jumping to *nfc's execution context. This function must be called when first entering *nfc's execution context." boost_fcontext_start(): Need a "Returns:" "The result of calling boost_fcontext_jump()." boost_fcontext_jump(): This likewise needs some work: Effects: "Stores the current context data (stack pointer, instruction pointer, and CPU registers) to *ofc and restores the context data from *nfc, which implies jumping to *nfc's execution context. The pointer argument, vp, is passed to the current context to be returned by the most recent call to boost_fcontext_start() or boost_fcontext_jump() in the same thread." Returns: "The third pointer argument passed to the most recent call to boost_fcontext_jump(), if any." boost_fcontext_make(): Precondition: s/finished /finishes, / and s/inside/in/ boost_fcontext_make(): Effects: s/if the context is activated next time/when the context is activated next/ _______________ Continuation 1st para: s/from Java/from the Java/ 2nd para: s/for functors objects/for a functor/ 3rd para: You say the co-routines run "in parallel", but there is no parallelism, so you should be clear about what does occur. _______________ ASIO 2nd para: s/a echo/an echo/ 3rd para: I quickly got lost in this description because it assumes familiarity with code presented later. It also assumes familiarity with control flow in Asio which can be described rather than assumed. 3rd para: s/reentered a/reentered, a/ s/a asynch./an async/ 4th para: s/adavantage/advantage/ s/bind()-version/bind() version/ s/easier implemented/more easily implemented/ s/For instance if/For instance, if/ s/a message is partialy received/only part of a message is received/ s/parser or serviced)/parsed or serviced),/ _______________ Performance The bullets are too terse. Perhaps the following captures your intent: "Performance of Boost.Context was measured on the platforms shown in the following table. Performance measurements were taken using rdtsc, with overhead corrections, on x86 platforms. In each case, stack protection was active, cache warm-up was accounted for, and the one running thread was pinned to a single CPU. The code was compiled using the build options, 'variant=release cxxflags=-DBOOST_DISABLE_ASSERTS'. "The numbers in the table are the number of cycles per iteration, based upon an average computed over 1000 iterations." _______________ Rationale NoThrow guarantee: I think you meant the following: "Member functions of context do not throw exceptions but do require that certain preconditions are satisfied: context jumps can only be made by instances which are not a _not-a-context_ and which are not complete." Pimpl idiom, 1st para: s/ it was required to separate both features in separate classes via pimpl idiom/, the use of the Pimpl Idiom was necessary/ Pimpl idiom, 3rd para: I suggest the following: "The Pimpl Idiom allows type-erasing the _stack-allocator_ type." Unwinding: s/resource/resources/ and s/a exception/an exception/ Protecting the stack: There are many changes to make here, so I'll suggest this rewrite: "Because the stack's size is fixed -- there is no support for split stacks -- it is important to protect against exceeding the stack's bounds. Otherwise, in the best case, overrunning the stack's memory will result in a segmentation fault or access violation and, in the worst case, the application's memory will be overwritten. stack_allocator appends a guard page to the stack to help detect overruns. The guard page consumes no physical memory, but generates a segmentation fault or access violation on access to the virtual memory addresses within it." setjmp()/longjmp(): s/The C99/C99/ s/frame, e.g. jumping/frame. Therefore, jumping/ ucontext_t: I don't know why anything in this section is included after the first sentence. ucontext_t, para 1: s/makecontext():/makecontext() is:/ ucontext_t, para 2: s/alter/later/ I would omit the "The signature of func is" part. That's clear from the makecontext() function pointer argument. Windows fibers: s/befor/before/ _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[thread] feature request priority
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, here they are a list of 26 feature requests for Boost.Thread. The features are classified as high, middle and low cost (form my point of view of course) I would like to know which features would you like to find on the next release. Please could you choose 3 features and if possible one for each category, the idea been to provide 1 high, 1 middle and 2 low features for the next release. High #2100 <https://svn.boost.org/trac/boost/ticket/2100> thread fails to compile with -fno-exceptions <https://svn.boost.org/trac/boost/ticket/2100> #6195 <https://svn.boost.org/trac/boost/ticket/6195> Provide the standard time related interface using Boost.Chrono <https://svn.boost.org/trac/boost/ticket/6195> #6217 <https://svn.boost.org/trac/boost/ticket/6217> Make uniform Boost.Thread and Boost.Interprocess synchronization interface <https://svn.boost.org/trac/boost/ticket/6217> #6230 <https://svn.boost.org/trac/boost/ticket/6230> Follows the exception reporting mechanism as defined in the c++11 <https://svn.boost.org/trac/boost/ticket/6230> #5150 <https://svn.boost.org/trac/boost/ticket/5150> boost::thread does not print or return the error value when creating a thread fails. <https://svn.boost.org/trac/boost/ticket/5150> #6194 <https://svn.boost.org/trac/boost/ticket/6194> Adapt to Boost.Move <https://svn.boost.org/trac/boost/ticket/6194> Middle #2741 <https://svn.boost.org/trac/boost/ticket/2741> proposal to manage portable and non portable thread attributes <https://svn.boost.org/trac/boost/ticket/2741> #2880 <https://svn.boost.org/trac/boost/ticket/2880> Request for Thread scheduler support for boost .. <https://svn.boost.org/trac/boost/ticket/2880> #3696 <https://svn.boost.org/trac/boost/ticket/3696> Boost Thread library lacks any way to set priority of threads <https://svn.boost.org/trac/boost/ticket/3696> #4710 <https://svn.boost.org/trac/boost/ticket/4710> Missing async() <https://svn.boost.org/trac/boost/ticket/4710> #4725 <https://svn.boost.org/trac/boost/ticket/4725> Synchronization and shared mutex's Get total_count <https://svn.boost.org/trac/boost/ticket/4725> #5173 <https://svn.boost.org/trac/boost/ticket/5173> boost::this_thread::get_id is very slow <https://svn.boost.org/trac/boost/ticket/5173> #5425 <https://svn.boost.org/trac/boost/ticket/5425> This patch will allow the user to obtain the users thread pointer from a thread group. <https://svn.boost.org/trac/boost/ticket/5425> #5956 <https://svn.boost.org/trac/boost/ticket/5956> Add optional stack_size argument to thread::start_thread() <https://svn.boost.org/trac/boost/ticket/5956> #6227 <https://svn.boost.org/trac/boost/ticket/6227> Use of variadic templates on Generic Locking Algorithms on compilers providing them <https://svn.boost.org/trac/boost/ticket/6227> #6228 <https://svn.boost.org/trac/boost/ticket/6228> Add promise and futures constructor with allocator following the standard c++11 <https://svn.boost.org/trac/boost/ticket/6228> #6229 <https://svn.boost.org/trac/boost/ticket/6229> Rename the unique_future to future following the c++11 <https://svn.boost.org/trac/boost/ticket/6229> Low #1789 <https://svn.boost.org/trac/boost/ticket/1789> thread_group not passing variables <https://svn.boost.org/trac/boost/ticket/1789> #1850 <https://svn.boost.org/trac/boost/ticket/1850> request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock <https://svn.boost.org/trac/boost/ticket/1850> #2361 <https://svn.boost.org/trac/boost/ticket/2361> thread_specific_ptr: nature of the key, complexity and rationale <https://svn.boost.org/trac/boost/ticket/2361> #2637 <https://svn.boost.org/trac/boost/ticket/2637> shared mutex lock <https://svn.boost.org/trac/boost/ticket/2637> #3567 <https://svn.boost.org/trac/boost/ticket/3567> Request for shared_lock_guard <https://svn.boost.org/trac/boost/ticket/3567> #6224 <https://svn.boost.org/trac/boost/ticket/6224> Add the use of standard noexcept on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6224> #6225 <https://svn.boost.org/trac/boost/ticket/6225> Add the use of standard =delete defaulted operations on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6225> #6226 <https://svn.boost.org/trac/boost/ticket/6226> add explicit bool conversion from locks <https://svn.boost.org/trac/boost/ticket/6226> #6231 <https://svn.boost.org/trac/boost/ticket/6231> Add BasicLockable requirements in the documentation to follow c++11 <https://svn.boost.org/trac/boost/ticket/6231> Patches are welcome for any feature. Note that a feature that have all the needed patches, code, doc and tests could be included soon. Thanks in advance, Vicente

3 7

[thread] Reducing the number of open tickets.
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, I have committed the following tickets in trunk. Fixed Bugs: * [@http://svn.boost.org/trac/boost/ticket/2639 #2639] documentation should be extended(defer_lock, try_to_lock, ...). * [@http://svn.boost.org/trac/boost/ticket/3762 #3762] Thread can't be compiled with winscw (Codewarrior by Nokia). * [@http://svn.boost.org/trac/boost/ticket/3885 #3885] document about mix usage of boost.thread and native thread api. * [@http://svn.boost.org/trac/boost/ticket/3975 #3975] Incorrect precondition for promise::set_wait_callback(). * [@http://svn.boost.org/trac/boost/ticket/4480 #4480] OpenVMS patches for compiler issues workarounds. * [@http://svn.boost.org/trac/boost/ticket/4819 #4819] boost.thread's documentation misprints. * [@http://svn.boost.org/trac/boost/ticket/5423 #5423] thread issues with C++0x. * [@http://svn.boost.org/trac/boost/ticket/5739 #5739] set-but-not-used warnings with gcc-4.6 * [@http://svn.boost.org/trac/boost/ticket/6168 #6168] recursive_mutex is using wrong config symbol (possible typo). * [@http://svn.boost.org/trac/boost/ticket/6200 #6200] patch to have condition_variable and mutex error better handle EINTR. These are tickets with a simple solution or that had associated a complete patch or a clear solution. Anthony I would prefer that you do the merge so that you can check what goes on the release version. I have not closed the tickets. These tickets have just release 1.49 as Milestone. Please, close them when you merge to release. There were 113 tickets two days ago. There are now 114 tickets associated to Boost.Thread. I have closed some duplicates, but some news tickets have been created since. I would like to reduce by 10% the number of tickets every month. I encourage the Boost users that have created tickets for Boost to provide a clear an complete patch when possible so that we can reduce together the number of tickets associated to this Boost library and make it more portable/usable. Don't forget to provide tests that make evident the bug, or to add doc when you are proposing a anew feature. There are a lot of tickets associated to move semantics emulation. I have created a ticket to adapt Boost.Thread to Boost.Move hoping most of these bugs will be solved. As posted in another thread there is already a patch using Boost.Move that could be a good starting point. Of course the help offered by Ion will be too much appreciated. I have created another to adapt the interface to Boost.Chrono, but I will prefer to take care of this once the one for Boost.Move adaptation is committed, as the chance of collisions is big. On the mean time I will continue with some tickets specific to Windows platform. Best, Vicente

4 12

[C++ Now! 2012] Reminder: Call for Submissions, deadline is January 10th, 2012
by Hartmut Kaiser 03 Jan '12

03 Jan '12

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements In Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

How to get involved ?
by Vijeenrosh PW Vijeen 03 Jan '12

03 Jan '12

Good Morning , My name is Vijeenrosh P.W . Iam an Computer Science and Engineering student . I have knowledge in c,c++,python and linux , and an mind to extend my areas of knowledge. Recently while passing through the list of GSOC accepted organizations I met with boost libraries . it fits me since I have C++ && programming knowledge and is ready to work . I would like to know how to begin to contribute to the project . Where to begin . or is there any warm up excersices to get passed ? -- Vijeenrosh P.W CSE S3 blog : www.BlackJackVijeen.blogspot.com

4 3

RFC: Multiprecision arithmetic library
by John Maddock 03 Jan '12

03 Jan '12

Folks, I'd like to get some feedback on a multiprecision arithmetic library I've been preparing for possible Boost inclusion. The code is in the sandbox under the "big_number" directory. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… The main features are: * A generic front-end that's capable of wrapping almost any type that's a "number". The front end is expression template enabled and handles all the expression optimization and code reduction. For example it's possible to evaluate a polynomial using Horner's rule without a single temporary variable being created. * A series of backends that need only provide a reduced interface and set of operations, implement the actual arithmetic, currently supported backends are: Integer Types ~~~~~~~~~ 1/ GMP (MPZ). 2/ libtommath. Rational Types ~~~~~~~~~~ 1/ GMP (MPQ). [ But note that the integer types can also be used as template aruments to Boost.Rational ] Floating Point Types ~~~~~~~~~~~~~~ 1/ GMP (MPF) 2/ MPFR 3/ cpp_float - an all C++ Boost-licensed backend based on Christopher Kormanyos' e_float code. [ Note these three types are fully compatible with Boost.Math Trunk - so you get full standard library plus special function support ] There's still a bunch to do, but I'd like to see what folks think, and where the main priorities should be before submission. Thanks in advance, John.

12 19

[test] showtopper for release 1.49 - std::forward not found when compiling with clang 3.0 c++0x mode.
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, I have created a show stopper ticket https://svn.boost.org/trac/boost/ticket/6345 as after updating the trunk, I'm unable to test any library using Boost.Test. Recent modification on Boost.Test make it unusable with clang 3.0 c++0x due to std::forward missing or not found. clang-darwin.compile.c++ ../../../bin.v2/libs/thread/test/test_thread.test/clang-darwin-3.0x/debug/threading-multi/test_thread.o In file included from test_thread.cpp:16: In file included from ../../../boost/test/unit_test.hpp:19: In file included from ../../../boost/test/test_tools.hpp:328: In file included from ../../../boost/test/tools/impl.hpp:25: ../../../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' : m_value( std::forward<T>(val) ) ~~~~~^ ../../../boost/test/tools/assertion.hpp:278:29: error: 'T' does not refer to a value : m_value( std::forward<T>(val) ) ^ The revision is https://svn.boost.org/trac/boost/changeset/75370 #ifndef BOOST_NO_RVALUE_REFERENCES explicit value_expr( T&& val ) : m_value( std::forward<T>(val) ) #else explicit value_expr( T const& val ) : m_value( val ) #endif #ifndef BOOST_NO_RVALUE_REFERENCES operator->*( T&& v ) const { return value_expr<T>( std::forward<T>( v ) ); } #else operator->*( T const& v ) const { return value_expr<T>( v ); } #endif This has as consequence that the authors developing mainly with this compiler and using Boost.Test to be unable to deliver new modifications. I have added #include <utility> without success. I guess that the standard library doesn't provides this function even if the compiler provides rvalue references. The code should test for a macro that states if std::forward is available. Please could someone help on this issue? Best, Vicente

5 6

[Boost.Math] Re: [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
by Steve M. Robbins 02 Jan '12

02 Jan '12

Hello, Boost Developers: I recently did rebuilds of all Debian packages that use Boost with Boost 1.48 and this is one of the casualties of the upgrade (from 1.46.1). On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote: > On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins <smr(a)debian.org> wrote: > > This package failed to build using the newest Boost version 1.48: > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In function 'T boost::math::detail::lgamma_small_imp(T, T, T, const mpl_::int_<0>&, const Policy&, const L&)': > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: error: expected primary-expression before 'do' > > I'm not in a position to verify this for myself for another week, but > I have a horrible feeling I know what's wrong: Monotone defines > several one-character macros for its own use, and L() is one of them. > It looks like Boost is using L() for its own purposes and expecting it > not to be a macro. Zack, you are absolutely right. The lgamma_small header has a templated class method using "L" as one of the templates: template <class T, class Policy, class L> T lgamma_small_imp(T z, T zm1, T zm2, const mpl::int_<0>&, const Policy& pol, const L&) The compile error at line 483 is at a call to L(): result = log(gamma_imp(z, pol, L())); > I'd argue that Boost headers should take care to defend themselves > from the possibility of such macros, but fixing that in Boost might be > an enormous amount of work, and in any case, 1.48 is already out > there. Boost.Math developers: What is the right thing to do here? More descriptive class template parameters? Attached is a trivial file to reproduce the bug. Thanks, -Steve

6 6

boost modularisation status?
by Robert Ramey 02 Jan '12

02 Jan '12

https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years. Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this. What is the current status of this? Robert Ramey

9 22

[review] Boost.Context mini-review starts today, January 2nd
by Giovanni Piero Deretta 02 Jan '12

02 Jan '12

Hi all, we will start a new year of Boost reviews with a one week mini-review of the Boost.Context library of Oliver Kowalke. The review period starts today January 2nd and ends January 11. Please use [context review] as prefix of your post. Reviewers are strongly encouraged to send their reviews to the boost development mailing list as this is the I follow more assiduously. Please note that Boost.Context was already reviewed and conditionally accepted last May, so we are not voting for acceptance. Instead, this mini-review is to discuss whether the library meets the conditions on acceptance that were listed by Vicente Botet, the review manager at that time. You'll find the whole list at the end of this email. Since the end of the original review, Oliver has spent a large amount of time on a partial rewrite of the library and both me and Oliver decided to schedule this review only after we determined that all issues had been addressed or at least considered. In your review please state whether the acceptance conditions have been addressed satisfactorily. ---------------------------------------------------------------------------------- About the library: Boost.Context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current execution state in the current thread, including the stack (with local variables) and stack pointer, all registers and CPU flags, and the instruction pointer, a context instance represents a specific point in the application's execution path. This is useful for building higher-level abstractions, like coroutines and fibers. ---------------------------------------------------------------------------------- Useful Links: documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ library: git://github.com/olk/boost.context.git ---------------------------------------------------------------------------------- >From the original review result email: Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local).

1 0

[Graph] LEDA adapter - concept check VertexListGraph fails
by Jens Müller 01 Jan '12

01 Jan '12

Hi everyone, when running the tests for Graph, the first concept check in leda_graph_cc.cpp fails: gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:9:0: ../../../boost/graph/graph_concepts.hpp: In destructor 'boost::concepts::VertexListGraph<G>::~VertexListGraph() [with G = leda::GRAPH<int, int>]': ../../../boost/graph/graph_concepts.hpp:168:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::VertexListGraphConcept<leda::GRAPH<int, int> >]' leda_graph_cc.cpp:21:5: instantiated from here ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' ../../../boost/graph/graph_concepts.hpp:189:9: note: candidate is: ../../../boost/graph/graph_concepts.hpp:45:48: note: template<class T> typename T::ThereReallyIsNoMemberByThisNameInT boost::vertices(const T&) (among some further errors, but I'd like to ask just about this one now) Apparently it cannot find a vertices() function: ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' But there is one in leda_graph.hpp: template <class vtype, class etype> inline std::pair< typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator, typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator > vertices(const leda::GRAPH<vtype,etype>& g) { typedef typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator Iter; return std::make_pair( Iter(g.first_node(),&g), Iter(0,&g) ); } So, can someone enlighten me why it isn't found? Has it something to do with #ifdef BOOST_VECTOR_AS_GRAPH_GRAPH_ADL_HACK // dwa 2003/7/11 -- This clearly shouldn't be necessary, but if // you want to use vector_as_graph, it is! I'm sure the graph // library leaves these out all over the place. Probably a // redesign involving specializing a template with a static // member function is in order :( using boost::vertices; #endif ? Best regards, Jens

2 8

Many Boost.Test unit tests fail
by Barend Gehrels 01 Jan '12

01 Jan '12

Hi, Since today or yesterday, many regression tests fail. http://www.boost.org/development/tests/trunk/developer/summary.html I believe on platforms that are recently added, at last on platforms that were not present at December 17. 1) on clang/darwin, message ../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' 2) on clang/linux, message /usr/bin/ld: skipping incompatible /sierra/Sntools/extras/compilers/gcc-4.4.4/lib/libstdc++.so when searching for -lstdc++ We have these errors in Boost.Geometry but I also noticed them in many other libraries. Regards, Barend

2 2

[filesystem] path thread safety fix impact on POSIX systems
by Beman Dawes 01 Jan '12

01 Jan '12

Class path locale initialization has suffered from a data race for several releases. See https://svn.boost.org/trac/boost/ticket/6320 for an example of code that suffers as a result. The problem was introduced when locale initialization was changed from namespace scope initialization to function scope initialization. For Windows and Mac OS X, the fix is simply to change back to namespace scope initialization. For non-BSD based POSIX systems such as Linux, the problem is more complex. These system need std::locale(""), "the locale-specific native environment". Considerations: * std::locale("") will throw if environmental variables are configured incorrectly. For example, setting LANG=foo on my Ubuntu system causes std::locale("") to throw. * std::locale("") is only needed if conversions between wide and narrow character paths occur in the program, so it would be unfortunate to have programs throw that don't actually do any such conversion. * With GCC, std::locale("") at namespace scope will throw before main() has started! That prevents catching the exception in the user code, and was what led to moving the initialization to a function scope static. Initialization as a function scope static also meant that the exception only occurred if user code actually performed wide - narrow conversions. I can see two possible fixes: (A) Use function scope locale initialization, using boost/detail/lightweight_mutex.hpp to prevent data races. (B) Use namespace scope locale initialization, defaulting the codecvt facet to UTF-8 if std::locale("") throws. The advantage of (B) is that path always initializes without throwing, and that's what users seem to expect. The initialization is correct for all those whose environments are configured correctly, and for those uses who want UTF-8 even if their environments are misconfigured. The POSIX users who prefer an exception on a misconfigured environment can always add a std::locale("") at the start of main(). Comments or opinions? --Beman

4 6

Re: [boost] matrix and vector iterators
by Larry Evans 31 Dec '11

31 Dec '11

On 06/12/01 14:50, David Abrahams wrote: > > ----- Original Message ----- > From: "Larry Evans" <jcampbell3(a)prodigy.net> > > >> David Abrahams wrote: >> >>> One problem with this is that it requires much more of the iterator in > some >>> cases than it otherwise might. In an array stored as vectors of vectors >>> of... vectors, each iterator would need to have references to all of the >>> containing vectors. >> >> Couldn't the iterator just contain a vector of indices of length == rank, >> and a pointer to the vector of vectors of... vectors (VofV), and then just > index into >> the VofV with the vector of indices. > > When you start talking about iterators containing vectors, I get worried. > >> I guess bad thing about that is that it takes longer. > > That's putting it mildly. Iterators should be lightweight. > > -Dave > > Another type of iterator which essentially flattens a multi-dimensional array and *may* be more lightweight is implemented here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/b… and demonstrated here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… A more realistic demonstration is in the Partial Differential Equation example here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which uses an axes rotation feature that, IIUC, was requested by Petros here: http://article.gmane.org/gmane.comp.lib.boost.user/68017 Its also used here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which is probably a bit easier to follow than the array_dyn.diff_pde.cpp one ;) I've done no benchmarks; hence, I can't say how lightweight it is; however, since all it does is keep a stack of indices in a data structure instead of on the stack, I would think it wouldn't be that much more heavyweight than simply a nested for loop nested N deep where N is the array dimensionality. BTW, Petros, in a private email to me, has indicated he has some other method for solving the rotated axes problem; however, I've no idea if that's more or less lightweight than this one. -regards, Larry I've run no benchmarks to show how lightweight it may be. Petros, in a private email to me, says he has another way of

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 31 Dec '11

31 Dec '11

Dave Abrahams: > > No post-hock marshalling? You should be able to add marshalling to a > class without modifying its declaration. > If a class is popular enough, I often do. For example, the C++ Middleware Writer (CMW) has support for the standard containers, std::complex, multi_index_container, stable_vector and others. [...] > > No argument; I'm just sayin'. I don't have to go to any great lengths to find tests where the performance of executables that use Boost Serialization lags behind CMW based executables. I just think up a test and write it. The tests are quite basic. > > That's a fundamentally intrusive design; being able to add serialization > non-intrusively was a major design goal for Boost.Serialization. I see. One thing I didn't mention yesterday is support for stream- based constructors: class Base { template <typename R> explicit Base (ReceiveBufferFile<R>& buf); ... }; Does the Boost Serialization library have support for that? Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Pool lost singleton_default -- replacement?
by Steve M. Robbins 31 Dec '11

31 Dec '11

Hi, Prior to 1.48, Boost.Pool's singleton_pool class used a helper class singleton_default. This was hidden in a detail header <boost/pool/detail/singleton.hpp>, yet I found 3 programs in the Debian distribution that used it directly to instantiate their own singletons. I didn't find any direct replacement for singleton.hpp in Boost 1.48. Is there any plan to introduce this later? Thanks, -Steve

3 2

Boost 1_41 Binary archive exceptions
by KARAN 31 Dec '11

31 Dec '11

I am porting from Linux 32 bit to 64 Bit(x86_64)(Boost Version :1_41). I am facing an Binary archive exceptions mainly (std::bad_alloc,St12length_error-basic_string::resize). There are no exception during the file saving, but when I do a restore I am facing the above exceptions. The same works very well if I change it to text archives. How can I make it work with binary files? The exception is happening in the below code block .Any comments please template<class Archive> void Serialise (Archive & aArchive, const unsigned int aVersion=0) { aArchive & this->A; aArchive & this->B; aArchive & this->C this->p.Serialise(aArchive, aVersion); } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-41-Binary-archive-exceptions-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[interprocess] Timed locks
by Edward Diener 29 Dec '11

29 Dec '11

In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ? I think an end-user calculation is usually one in which he says that a certain lock needs to be acquired in so many seconds ( or milliseconds ) and a boost::posix_time::time_duration would fit that calculation better.

4 5

[MPL] "Unwrap" metafunction
by Robert Kawulak 29 Dec '11

29 Dec '11

Hi, I need a metafunction to check if a type is wrapped as an argument of a template and "unwrap" it if so. Something like: template <template <typename> class T, typename C> struct unwrap { typedef C type; static const bool is_wrapped = false; }; template <template <typename> class T, typename C> struct unwrap<T, T<C>> { typedef C type; static const bool is_wrapped = true; }; So both unwrap<x, int>::type and unwrap<x, x<int>>::type are int, while unwrap<x, y<int>>::type is y<int>. Of course I can use the code above, but I'm just curious - does Boost.MPL already provide a utility that can be used to achieve the same? Thanks and best regards, Robert

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

Robert Ramey: > This first came up several years ago and I spent a little time looking at > it. > I was sort of intrigued in that the usage of TMP driven inline code should > be optimal for cases where tracking wasn't involved. And in these test > cases there isn't any tracking. So I looked a little at the tests on the > page. > > a) first I couldn't compile them so I couldn't repeat the results. > Something > was missing (I forget what now). I believe you are referring to something from several years ago here. > b) so I inspected the code. My conclusion was that the being used was > that in the i/o itself rather than the serialization. Boost serialization > relies > on streambuf to do it's i/o and the time is sensitive to things like buffer > sizes > etc. It seems that brian's code uses some other method which whose > source isn't visible to me. (SendBuffer, etc). This sounds like the present. Did you download and build the archive here -- http://webEbenezer.net/build_integration.html ? (Also in an earlier note today I mentioned recent changes to the test archive here -- http://webEbenezer.net/comp/tests.tar.bz2 .) > c) Brian did point out some cases where boost serialize could be improved > particularly using hints in std collections. These were incorporated. I > also > implemented the binary i/o in terms of streambuf rather than stream which > was a noticible improvement. Yes, now it would probably not be difficult to add support for ::std::move. I'm asking for someone to open a ticket for that so someone doesn't ask me to. ;) [...] > e) So, given tat the timings aren't that far apart, and lacking any other > information, I'm inclined to attribute any discrepencies to the way i/o is > handled > in the different systems. If one had nothing else to do he could make > a replacement for streambuf which focused on fast i/o perhaps at the > expense of portability. In particular, an asyncronous memory mapped i/o > library might be an interesting addition to boost. And that would be cool > to plug in the serialization library. While true that the timings aren't real far apart, I note that the timings of the (slightly) more complicated tests are worse for the Boost Serialization library than the simpler tests. Real uses have more than a vector<deque<double> > of complication. So there may be a compounding effect, but I'm just speculating. > Finally, I think that the scale and breadth of brian's library is much, much > smaller than boost serialization library. The breadth is smaller. I don't support text or XML based serialization. > Then there is the fact that the > distribution model is totally different than that of boost and open source > libraries in general. I just don't see how these packages/approaches > could be considered comparable in any way. While the distribution models are different, I think the binary part of the Boost Serialization library is comparable to the Ebenezer approach. Thanks for mentioning the distribution model. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I found an error that affects two of my test cases -- not comparing apples to apples -- so have updated the page I linked to and the archive with the tests. Only one of the tests showed different results after the change. Rather than claiming the Boost Serialization version of the test was over 3 times slower than the Ebenezer version, I now claim it is over 2.3 times slower. Dave Abrahams: > A few: > > 1. The claim that you provide "full generation of marshalling functions" > is a little hard to swallow. In principle, it's impossible to know > based on a class declaration what to serialize, and how to serialize > it. True. In order to turn off the default generation of marshalling code, one can place a comment like this: // hand_written_marshalling_code in the body of a class. Instances of that class can still be marshalled if you provide the expected marshalling functions yourself. > 2. If you are going to compare yourself to Boost.Serialization, it would > be a good idea to replicate all of that library's tests with your own > system, to demonstrate that you cover the same expressive range. We don't cover the same range, but are working to add to the reperoire. We do have support for some things that the Boost library doesn't: iterator_range, sub_range, several Boost Intrusive containers, flex_string, segmented_array and a few others. To the best of my knowledge Boost Serialization doesn't take advantage of ::std::move. http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html I've checked the 1.48 code also. > It's usually very easy to build something that beats benchmarks of a > more-general system. Well, this is the first time I've had an archive with the tests that I link to, so at least think that is a step in the right direction. > 3. That "our approach writes marshalling functions based on the content > of the types involved" does not explain how you get past the private > member access barrier. The only legal technique I've seen for that > is at https://gist.github.com/1528856, and Boost.Serialization should > probably have support for that approach. C++ Middleware Writer users add function prototypes to their classes. The first two links on this page -- http://webEbenezer.net/rbtree_marshalling.html show an example. In that example the marshalling functions are virtual. In general they aren't required to be. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Extension - any plans?
by Klaim - Joël Lamotte 29 Dec '11

29 Dec '11

Hi, I'd like to know if there are plans from it's author to submit Boost.Extension library for inclusion in boost? ( http://boost-extension.redshoelace.com/docs/boost/extension/index.html) Or any other plans? I remember the development was paused until some C++11 features would be available (I don't know which ones). But maybe I'm wrong. In my opinion, this library would be an excellent addition to boost. Joël Lamotte

1 1

Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I've recently updated a page -- http://webEbenezer.net/comparison.html comparing results obtained using Boost Serialization (1.48) and the C++ Middleware Writer (1.13) on both Linux and Windows7. There's an archive that has all the test files mentioned on that page here -- http://webEbenezer.net/comp/tests.tar.bz2 . In order to build the tests, you would need to build the Boost Serialization library and an Ebenezer library yourself. There's an archive on this page that has the Ebenezer library -- http://webEbenezer.net/build_integration.html . To summarize the results, the Boost versions range from 1.1 to 3 times slower than the Ebenezer versions. And the sizes of the Boost executables range from portly to obese compared to functionally equivalent Ebenezer executables. Comments on the how to improve the tests/process/etc. are welcome. Shalom Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 6

Is there any interest in command line interpreter class templates?
by alexey.tsoy 29 Dec '11

29 Dec '11

Hello everybody, The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation. The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent. The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it. Regards Alexey -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Re: [boost] [Spirit-general] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules
by Jeroen Habraken 29 Dec '11

29 Dec '11

Hi, On 27 December 2011 00:51, Torsten Maehne <Torsten.Maehne(a)gmx.de> wrote: > Hello, > > I'm using Boost.Spirit.Karma to format the output of some nested structs > (direct access of the public member variables) and abstract data types > (ADTs) (access to the private member variables via getters and setters) > in my code. I'm using Boost.Fusion to adapt the ADTs into a sequence of > values of primitive data types for output with Boost.Karma. This worked > fine till Boost 1.44. Since Boost 1.45 up till 1.48 and the current > Boost trunk (I tested svn revs 75505, 75963, and 76196) the output of unsigned > integer members of Boost.Fusion-adapted ADTs doesn't work anymore -- > even though I took into account the change in the name of macro from > BOOST_FUSION_ADAPT_CLASS to BOOST_FUSION_ADAPT_ADT as well as the > additionally required header > boost/spirit/include/support_adapt_adt_attributes.hpp. > > The problem is demonstrated in the attached test case for rational > number ADTs and structs, which use signed integer member > variables. Compilation of this test case against Boost 1.44.0 will > succeed and it will run without any errors. Compilation of this test > case against Boost 1.45.0 and 1.46.1 will fail. Compilation against > Boost 1.47.0 and 1.48.0 will succeed, but the output of negative values > of signed integer members of Boost.Fusion-adapted ADTs will be > wrong. The minus sign is output correctly, but it is followed by a wrong > value, which seems to be yielded by a cast from a signed to an unsigned > integer value instead of taking the absolute value of the signed integer > value. This has been observed on Mac OS X 10.7.2 (x86_64) with Xcode 4.2 > using Apple's g++ 4.2.1, Apple's clang++ 3.0. Interestingly, compiling > the test case against Boost 1.47.0 or Boost 1.48.0 using MacPorts g++ > 4.5.3, will yield more output checks to fail for Boost.Fusion-adapted > ADTs used in Karma output rules. > > Compilation against Boost from the Subversion trunk (I tested > revs. 75505, 75963, and 76196) does only succeed using Apple's clang++ > 3.0 and execution will yield the same wrong output for negative values > of signed integer members of Boost.Fusion-adapted ADTs. Compilation > fails with Apple's g++ 4.2.1 and MacPorts g++ 4.5.3. > > I'm not able to locate the root cause for this problem, whether it is in > Boost.Fusion or Boost.Spirit.Karma. I would appreciate any help to > resolve this annoying issue. Until a solution is found, I'm stuck with > Boost 1.44.0. Several things seem to play a role, but I've had a look at as to why the code doesn't compile using boost-trunk and found the cause to be an ambiguity: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. > Please note that I also submitted a bug report on this issue more than 6 > weeks ago without any reaction so far: > > <https://svn.boost.org/trac/boost/ticket/6126> > > Best regards, > > Torsten Maehne Note: I've included boost(a)lists.boost.org in the discussion. Kind regards, Jeroen Habraken

2 6

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 26 Dec '11

26 Dec '11

Hi everybody, I released a new version of the DE library based on feedback I received on the initial release - see the doc at http://www.amichel.com/de/doc/html. First of all, I updated the documentation to describe in more detail what DE is, its use in one specific case, and links to descriptions of several other use cases - see the Overview page at the link above. I hope this will help make the case why a DE library would be worth being included in boost. BTW, there are already implementations in several languages and for several free or commercial products: Java, C, Matlab, Scilab, Fortran90, Python, Labview, Pascal, C#, etc. As far as the library itself, Thomas Heller noted that requiring the objective functions to be derived from the de::objective_function abstract class limited the user options by not allowing arbitrary unnamed or plain functions to be passed as objective functions. I followed his suggestion and reimplemented parts of the library as template classes, in particular the de::processor class. It is now possible to pass objective functions as: named functions, unnamed functions, functors (all with the right prototype) or objective function factories which create local copies of the objective function. All of these can be passed as either references, plain pointers or boost::shared_ptr. This change should make it easier to integrate the library within existing code. Your comments will be appreciated. Adrian

1 0

[string_algo] New Maintainer
by Pavol Droba 26 Dec '11

26 Dec '11

Dear Boosters, After a careful consideration I finally realized that I can no long act as a maintainer for String Algorithms Library. I simply don't have the required time and I thinks that the library deserves at least development. Therefore I would like to call for a volunteer(s) who would like to take String Algorithm library further. I will still be available for consultations or any such assistance if required. Hopefully I will be also able to contribute a bit if my situation changes. Now, I don't really know if there is an official process for this kind of shift. I would be nice if potential volunteers would send a few words about the future direction they would take. A community can make a decision then. Best Regards, Pavol

3 6

[config, c++11] emplace_back check?
by Tim Blechmann 26 Dec '11

26 Dec '11

hi all, i wonder, is there a way to determine, if std::vector provides emplace_back? this currently causes a compile failure for boost.heap on gcc-4.3 with c++0x enabled: it does not implement emplace_back, although it has rvalue references and variadic templates. thanks, tim

1 0

boost releases on microblogs
by Pedro Larroy 25 Dec '11

25 Dec '11

Hi Wouldn't it be nice to have twitter and identi.ca anouncements of boost releases? Regards. Pedro.

1 0

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 24 Dec '11

24 Dec '11

Hi Philip, On 12/09/2011 4:35 PM, Philip Bennefall wrote: >> The full documentation is at http://www.amichel.com/de/doc/html but I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . >> >> The zip containing the DE C++ library and helper files is at >> http://www.amichel.com/de/de.zip. >> >> The DE main page is at http://www.icsi.berkeley.edu/~storn/code.html . > I took a peak at the overview and some of the other pages and from what I > can see initially, it looks like a very useful library for artificial > intelligence. I have very limited knowledge in the field but this is > something that grabs my interest, so if it's made public I'll definitely use > Thanks for your interest. DE and this library can be certainly used for AI, but many different problems in various areas can be optimized efficiently using DE (references to some of those can be found here: http://www.icsi.berkeley.edu/~storn/code.html) Best, Adrian

5 4

[geometry] MSVC needs namespace even if it is hoisted
by Barend Gehrels 24 Dec '11

24 Dec '11

Hi, We got a strange MSVC compilation problem in a Unit Test for Boost.Geometry. Attached a miminal reproduction. The essention is that we have stated: using strategy::distance::services::returning_type; and somewhere after that: typedef typename returning_type<strategy_type>::type the_return_type; but this is not accepted, in this case, by MSVC. It is well accepted by gcc, clang and comeau. If the namespace is specified, it is accepted by MSVC. The error message is: reproduce_msvc_using_bug.cpp(257): error C2059: syntax error : '<' And that is the same message as if the returning_type would not be a template. If we state: std::cout << typeid(returning_type).name() << std::endl; It compiles in MSVC, but it should not compile, because it is a template. So somehow it picks up this "returning_type" as if it is not a template. But of course it is. I've tried another (much smaller) minimal reproduction to mimic this problem but that is compiled normally by MSVC. So attached this one with (reworked) pieces from Boost.Geometry and even Boost, but still all contained in one file. We've discussed this internally and the current thought is that it is a compiler problem. If so, is this issue known to anyone on this list, or Microsoft? Otherwise I will report it. If not so, what is the problem here? It is of course easy to work around: giving the full namespace is OK for any compiler. So this is more out of curiosity: what is wrong here? Regards, Barend

3 3

TRAC hit hard last night
by Marshall Clow 23 Dec '11

23 Dec '11

We got a major infusion of garbage; strictly speaking, it doesn't appear to be spam, because it's not advertising anything, and the text doesn't contain any links. However, it doesn't have anything to do with boost. I've deleted about 40 tickets this morning. Any suggestions on how to prevent this in the future? -- 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

C++11 challenge: ASSERT_INVALID_EXPR
by Dave Abrahams 23 Dec '11

23 Dec '11

I don't know whether this is actually possible, but I was thinking today that there might be a way to use the new SFINAE to detect errors in a large class of invalid expressions without actually causing a hard error, and thereby build an assertion that fails compilation when passed a valid expression and passes for any invalid expression in the large class mentioned above. Any takers? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 4

[concept_check] Some issues
by Robert Kawulak 23 Dec '11

23 Dec '11

Hi, I've spotted some problems when playing with BCCL: - The implementation of assignable_archetype defines private default and copy constructors, so for example assignable_archetype<copy_constructible_archetype<>> will not actually be copy constructible. The same for convertible_to_archetype and convertible_from_archetype, but additionally with copy assignment. Is this by purpose? - copy_constructible_archetype defines public default constructor - again, am I overlooking something or it should not be there? - Function and predicate archetypes also seem to provide too wide interface (they are copy constructible and assignable). Additionally, they don't allow for archetypes chaining since they lack the Base parameter (with the only exception of binary_predicate_archetype - why the inconsistency?) - Apart from the provided function object concepts and archetypes it seems it would be useful to have a general Callable concept and the corresponding callable_archetype, parameterised with the types of arguments and return value. Wouldn't it be valuable to add them? - There's boost/concept_check directory in the trunk - are the files in it actually used anywhere? I've found no reference to them in Boost headers, documentation doesn't mention them too. Best regards, Robert

3 10

boost and google search
by Edward Rankin 23 Dec '11

23 Dec '11

Hi, I am sure it is pretty common for users of boost to use google to search for documentation/tutorials on their favorite library in boost. I have found that the top hits are typically not the latest documents. For example I just searched for boost,foreach and a documentation from 1.35 was the first hit. It would be great if there is a way to tell google to update their links to the latest version. Anyone knows whether this is possible, and how to make it happen? This problem probably applies to any search engine but I can only comment on google search. Thanks, Edward

11 23

constness in barrier.hpp
by Gaetano Mendola 23 Dec '11

23 Dec '11

Hi all, simple patch to make const the private member m_threshold in class barrier Regards Gaetano --- barrier.hpp.original 2011-12-22 12:05:05.921720854 +0100 +++ barrier.hpp 2011-12-22 12:05:36.936205847 +0100 @@ -52,7 +52,7 @@ private: mutex m_mutex; condition_variable m_cond; - unsigned int m_threshold; + const unsigned int m_threshold; unsigned int m_count; unsigned int m_generation; };

3 3

[config] ok to merge forceinline changeset to release?
by Eric Niebler 23 Dec '11

23 Dec '11

I got a little overzealous and merged to release some code that uses BOOST_FORCEINLINE, only to discover that that macro doesn't exist on the release branch yet. The right fix is probably to get config in sync between the two branches. OK to merge [74917] to release? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Re: [boost] RFC: Multiprecision arithmetic library
by John Maddock 22 Dec '11

22 Dec '11

>I really like the idea, and the API looks good. > > Have you considered an MPIR backend, in addition to GMP and others? Being > the > Windows port of GMP, the interfaces and usage are identical. Nod, the two are treated the same - in fact I use MPIR for testing under Visual Studio. John.

1 0

it would be nice if people logged into trac before commenting on tickets.
by Marshall Clow 22 Dec '11

22 Dec '11

That way we don't get things like this: > Changes (by anonymous): > > * status: new => closed > * resolution: => invalid Thanks, everyone! -- 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

4 3

Re: [boost] ASIO Query
by Olaf van der Spek 21 Dec '11

21 Dec '11

On Wed, Dec 21, 2011 at 9:21 PM, james(a)jamesbb.co.uk <james(a)jamesbb.co.uk> wrote: > Blocking - I've thought about this, but the MySQL C/C++ libraries unfortunately > don't provide asynchronous queries. > > I'm thinking of moving database reads into a seperate thread(s). It would be > nice if I can integrate this with the io_service, but I'm unsure how to do so. > Is it possible to pass arbitrary work items to an io_service, in the same manner > as async_read/write? Does every request involve blocking calls? If so, I'd not go with a 'shared nothing' design. Olaf

2 1

Re: [boost] ASIO Query
by james＠jamesbb.co.uk 21 Dec '11

21 Dec '11

After a little reading of the ASIO documentation, it looks like I should be able to run a seperate io_service on another thread, and post() database queries to it. If I bind a callback with the query, the results/error can be passed back to the initiator without too much trouble. Seems like boost is the answer to everything. Assuming I can keep the database queries asynchronous, would anyone recommend HTTP example 2 or 3? Appreciated, thanks again. On 21 December 2011 at 20:21 "james(a)jamesbb.co.uk" <james(a)jamesbb.co.uk> wrote: > Blocking - I've thought about this, but the MySQL C/C++ libraries > unfortunately > don't provide asynchronous queries. > > I'm thinking of moving database reads into a seperate thread(s). It would be > nice if I can integrate this with the io_service, but I'm unsure how to do so. > Is it possible to pass arbitrary work items to an io_service, in the same > manner > as async_read/write? > > Many thanks. > > > > > On 21 December 2011 at 16:07 Olaf van der Spek <ml(a)vdspek.org> wrote: > > > On Wed, Dec 21, 2011 at 3:27 PM, james(a)jamesbb.co.uk > > <james(a)jamesbb.co.uk> wrote: > > > I'm hoping for opinions on using an io_service per core against a single > > > io_service with multiple threads (similar to HTTP Server examples 2 & 3). > > > The > > > application is a TCP authentication / proxy server, intended to use all > > > available cores. > > > > > > - The TCP streams consist of small messages (usually a few hundred bytes) > > > which > > > can individually be processed quickly. > > > - Connections themselves are fairly long lasting - average around 4 hours, > > > although occasionally up to 10-12 hours. > > > > > > We're looking for a 'shared nothing' design between threads - database > > > queries > > > can be made per-thread (using TLS), for example. > > > > Are database queries blocking or non-blocking? If they're blocking, > > won't this also block other connections handled by the same thread? > > > > Olaf > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] ASIO Query
by Olaf van der Spek 21 Dec '11

21 Dec '11

On Wed, Dec 21, 2011 at 3:27 PM, james(a)jamesbb.co.uk <james(a)jamesbb.co.uk> wrote: > I'm hoping for opinions on using an io_service per core against a single > io_service with multiple threads (similar to HTTP Server examples 2 & 3). The > application is a TCP authentication / proxy server, intended to use all > available cores. > > - The TCP streams consist of small messages (usually a few hundred bytes) which > can individually be processed quickly. > - Connections themselves are fairly long lasting - average around 4 hours, > although occasionally up to 10-12 hours. > > We're looking for a 'shared nothing' design between threads - database queries > can be made per-thread (using TLS), for example. Are database queries blocking or non-blocking? If they're blocking, won't this also block other connections handled by the same thread? Olaf

2 1

Contact to lists.boost.org owners
by Mateusz Łoskot 21 Dec '11

21 Dec '11

Hi, I have tried to get in touch with ML managers at boost-owner(a)lists.boost.org I haven't received any response for a few days. What is the current contact to request new ML on lists.boost.org server? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

ASIO Query
by james＠jamesbb.co.uk 21 Dec '11

21 Dec '11

Hiya, I'm hoping for opinions on using an io_service per core against a single io_service with multiple threads (similar to HTTP Server examples 2 & 3). The application is a TCP authentication / proxy server, intended to use all available cores. - The TCP streams consist of small messages (usually a few hundred bytes) which can individually be processed quickly. - Connections themselves are fairly long lasting - average around 4 hours, although occasionally up to 10-12 hours. We're looking for a 'shared nothing' design between threads - database queries can be made per-thread (using TLS), for example. The application is written for Redhat Linux - I'm unsure if it makes a difference. Any suggestions are much appreciated! Cheers Jim

1 0

[fusion] patch for #5010
by Jürgen Hunold 21 Dec '11

21 Dec '11

Hi, tow weeks ago I have attached a patch to https://svn.boost.org/trac/boost/ticket/5010 changing fusion::nil to fusion::nil_ for better compatibility with Obective-C and my case an ancient version of LEDA. Patch attached for convenience. The questions is how to proceed? May I commit the patch? Any documentation to change? Hoping for feedback, Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 4

[config] Sandia-pgi-11.9 thread support
by Vicente J. Botet Escriba 21 Dec '11

21 Dec '11

Hi, on the regression test I see this error Test output: Sandia-pgi-11.9 - thread - test_barrier / pgi-11.9 Rev 76060 / Mon, 19 Dec 2011 10:30:05 +0000 *Report Time: *Mon, 19 Dec 2011 21:30:12 +0000 Compile [2011-12-19 12:43:58 UTC]: fail "pgCC" -INLINE:none -Kieee -fpic -fPIC -gopt -Minform=warn -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -D__need_IOV_MAX -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/pgi-11.9/debug/threading-multi/test_barrier.o" "../libs/thread/test/test_barrier.cpp" "../boost/config/requires_threads.hpp", line 86: catastrophic error: #error directive: "Compiler threading support is not turned on. Please consult your compiler's documentation for the appropriate options to use" # error "Compiler threading support is not turned on. Please consult your compiler's documentation for the appropriate options to use" ^ 1 catastrophic error detected in the compilation of "../libs/thread/test/test_barrier.cpp". Compilation terminated. Is something missing in the boost/config/requires_threads.hpp file? Best, Vicente

2 1

... broken with clang
by Beman Dawes 21 Dec '11

21 Dec '11

On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >... All in all, I consider clang to be at a too early stage of development > to support it in the libraries. While I believe clang has a bright future, I'm afraid I agree with you. Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang. Looking forward to the day when clang "just works" on Windows, --Beman

11 22

[iostreams] #5908: failure to parse optional fields in gzip header
by Travis Abbott 20 Dec '11

20 Dec '11

Hi, I'm wondering if anyone with commit access can have a look at this ticket/patch I put in a few months ago: https://svn.boost.org/trac/boost/ticket/5908 This is technically a regression, as it did work in 1.40, but support for multiple compressed files within 1 stream was not. When that was added, some refactoring was done which introduced this new bug. I actually need support for both of those features, so I'd really appreciate any consideration that can be given to this bug. Thanks, Travis Abbott

1 0

[Review Results:Algorithms] Boost.Algorithms is accepted
by Dave Abrahams 20 Dec '11

20 Dec '11

Having “reviewed the reviews” of Boost.Algorithms, I'm pleased to announce that it is unconditionally accepted. Congratulations to Marshall Clow! There were 5 yes votes and 1 no vote. The issues raised in all reviews were taken seriously by Marshall and recorded in the issue tracker at https://github.com/mclow/Boost.Algorithm I trust that Marshall will address the most important ones immediately, so I feel no need to place conditions on acceptance. Among the most important issues: https://github.com/mclow/Boost.Algorithm/issues/19 https://github.com/mclow/Boost.Algorithm/issues/18 https://github.com/mclow/Boost.Algorithm/issues/16 https://github.com/mclow/Boost.Algorithm/issues/15 https://github.com/mclow/Boost.Algorithm/issues/2 Thanks, everybody, for your participation! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Home page needs updating
by Nevin Liber 20 Dec '11

20 Dec '11

"Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1." Seems a bit out of date... :-) Nevin :-) -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 1

[date_time] gcc 3.4.6 - int_adapter<T>::from_special(special_values) is not inlined, so duplicated (#6302)
by Vicente J. Botet Escriba 20 Dec '11

20 Dec '11

Hi, I know that gcc 3.4.6 is an old compiler version, but there are a lot of error on the Boost.Thread regression tests. I have created a ticket #6302 <https://svn.boost.org/trac/boost/ticket/6302> int_adapter<T>::from_special(special_values) is not inlined, so duplicated. <https://svn.boost.org/trac/boost/ticket/6302> to follow this issue It seems that this function template<typename int_type_> class int_adapter { static int_adapter from_special(special_values sv) { switch (sv) { case not_a_date_time: return not_a_number(); case neg_infin: return neg_infinity(); case pos_infin: return pos_infinity(); case max_date_time: return (max)(); case min_date_time: return (min)(); default: return not_a_number(); } } is not been inlined with gcc 3.4.6 and so it is duplicated at link time. See link error on regression test Test output: Sandia-gcc-3.4.6 - thread - test_condition_lib / gcc-3.4.6 Rev 76061 / Mon, 19 Dec 2011 12:54:33 +0000 Report Time: Mon, 19 Dec 2011 21:30:12 +0000 Compile [2011-12-19 13:33:17 UTC]: succeed "/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -pthread -fPIC -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o" "../libs/thread/test/test_condition.cpp" Link [2011-12-19 13:33:17 UTC]: fail "/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++" -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition_lib" -Wl,--start-group "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o" "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/tss_null.o" "/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_unit_test_framework.a" "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread -m32 `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) collect2: ld returned 1 exit status Is this a know error for this compiler version? Best, Vicente

4 5

[predef][review-request] Requesting a review of Predef library submission..
by Rene Rivera 20 Dec '11

20 Dec '11

I've completed doing a final pass at the documentation and code for the Predef library. And hence I'm requesting the library be placed in the review "queue" (aka the review bucket). For those who missed it.. The Predef library implements two simple tasks: 1. Definition of a single version number macro to provide consistent version number at the preprocessor level. 2. A collection of detected definitions for compilers, standard libraries, architectures, operating systems, and languages. Unlike the Boost Config Library it doesn't define language features and capabilities. But only defines presence of detected compilation context. Documentation and downloads are available in the sandbox.. * Documentation at <http://tinyurl.com/7yrodwx> * Subversion source at <http://tinyurl.com/75oggaq> * Zip with Windows EOLs at <http://tinyurl.com/6lt7pks> * Bz2 with Unix LF-EOLs at <http://tinyurl.com/73n6a3k> Rene. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

4 4

[1.48.0] Beta 1 release candidates available
by Beman Dawes 20 Dec '11

20 Dec '11

Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

21 44

trac error
by Steve M. Robbins 20 Dec '11

20 Dec '11

OperationalError: database is locked There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could ==== How to Reproduce ==== While doing a GET operation on `/ticket/6131`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'id': u'6131'} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-i686/egg/trac/web/main.py", line 258, in dispatch req.session.save() File "build/bdist.linux-i686/egg/trac/web/session.py", line 88, in save @self.env.with_transaction() File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/web/session.py", line 132, in delete_session_cookie """, (self.last_visit, self.sid, authenticated)) File "build/bdist.linux-i686/egg/trac/db/util.py", line 65, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked }}} a ticket. The action that triggered the error was: GET: /ticket/6131

2 1

LNK1104: cannot open file 'libboost_unit_test_framework-vc90-mt-gd-1_47.lib'
by ankit master 20 Dec '11

20 Dec '11

Hello, I am a newbie in the world of testing and using boost. I went through some of the previous discussion on this topic with no luck at trouble shooting my current issue. I am using visual c+ 2008 express edition, I tried installing boost using boostpro . I right click on project, and under c++ -> general -> additional dir; have added the following path. C:\Program Files (x86)\boost\boost_1_47 Now, when I try to run boost example I get the following error , No matter what I do I just cannot get rid of this error any help is greatly appreciated . 1>------ Build started: Project: UnitTestPrac1, Configuration: Debug Win32 ----- - 1>Linking... 1>LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework- vc90-mt-gd-1_47.lib' 1>Build log was saved at "file://c:\Users\amaster\Desktop\AVM_Documents\CppPractise\UnitTestPrac1\UnitTes tPrac1\Debug\BuildLog.htm" 1>UnitTestPrac1 - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== // Following is my example #define BOOST_TEST_MODULE MyTest #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(MyTestCase) { // To simplify this example test, let's suppose we'll test 'float'. // Some test are stupid, but all should pass. float x = 9.5f; BOOST_CHECK(x != 0.0f); BOOST_CHECK_EQUAL((int)x, 9); BOOST_CHECK_CLOSE(x, 9.5f, 0.0001f); // Checks differ no more then 0.0001% } Thank you in advance. Sincerely, -- >From the withered tree, a flower blooms. - Zen

2 1

[asio] running code before ssl initialization
by Isidor Zeuner 20 Dec '11

20 Dec '11

Hi, boost::asio::ssl::detail::openssl_init<true>::do_init initializes the SSL library using the static initialization hook, thereby preventing code being ran from main() which must be run before SSL initalization (for example custom allocators being set using CRYPTO_set_mem_functions). Is there an intended way to do so when using boost::asio::ssl? Best regards, Isidor

1 0

Boost compatible with Clang C++11 dialect?
by Torrey Lyons 19 Dec '11

19 Dec '11

When enabling C++11 support on Xcode 4.2 using Clang 3.0 there are many build conflicts in Boost. The C++11 language dialect is not on by default, but we would like to use it. Apparently Boost is not detecting that the compiler already has these features built in when C++11 support is turned on. Should we expect Boost 1.48.0 to work with Clang 3.0 using the C++11 language dialect? Is there a known workaround? Thanks for any tips or insights. -- Torrey VSee: torrey(a)vsee.com <http://vsee.com/call?torrey@vsee.com> | Cell: 310.940.6397 Teamwork made simple vsee.com Blog <http://vsee.com/blog/> Facebook <http://www.facebook.com/VSeeLab> Twitter <http://twitter.com/vsee>

1 0

[bind][phoenix] Compliance with function template bind
by Vicente J. Botet Escriba 19 Dec '11

19 Dec '11

Hi, Boosthas Boost.Bind and Boost.Phoenix that provides a bind function. Are them compliant with C++11 for 20.8.9 Function template bind (in particular move semantics)? If yes, how they work for C++03 compilers? If not, is there any plan to adapt them to support move semantics? Best, Vicente

2 3

[Concept Checking] function_requires
by Jens Müller 18 Dec '11

18 Dec '11

Hi all, as far as I understand http://www.boost.org/doc/libs/1_48_0/libs/concept_check/reference.htm#depre…, function_requires() is deprecated. However, the documentation does not mention very clearly how to replace it. Is the BOOST_CONCEPT_ASSERT macro the replacement? E.g., does function_requires< VertexListGraphConcept<Graph> >(); now become BOOST_CONCEPT_ASSERT((VertexListGraphConcept<Graph>)); function_requires still appears in a lot of test cases of the Graph library. So if it is that easy to change, I would hand in a patch. Best regards, Jens

2 7

[math.special_functions] broken in trunk
by Tim Blechmann 18 Dec '11

18 Dec '11

it seems, there is a problem in boost.math in trunk. the boost.heap testsuite originally used boost.random, but the test farm reports some issues: In file included from ../boost/math/special_functions.hpp:32, from ../boost/random/generate_canonical.hpp:22, from ../boost/random.hpp:52, from ../libs/heap/test/mutable_heap_tests.hpp:1, from ../libs/heap/test/fibonacci_heap_test.cpp:12: ../boost/math/special_functions/expint.hpp: In function ???void boost::math::detail::expint_i_imp_113a(T&, const T&)???: ../boost/math/special_functions/expint.hpp:1028: error: expected primary- expression before ???(??? token (compare http://tinyurl.com/bqfputx) for now, i've reverted to the libc random() function to work around this issue, but it would be great, if someone with insights in boost.math could have a look. thanks, tim

2 2

Add macros for the "enum class" concept?
by Daryle Walker 18 Dec '11

18 Dec '11

Should we add preprocessor stuff to conditionally use the C++11 "enum class" construct? #if Whatever #define BOOST_HAVE_ENUM_CLASS #endif //... #if BOOST_HAVE_ENUM_CLASS #define BOOST_ENUM_CLASS( Name ) enum class Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) enum class Name : Type #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Type :: Enumerator) #else #define BOOST_ENUM_CLASS( Name ) enum Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) BOOST_ENUM_CLASS( Name ) #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Enumerator) #endif I'm not sure that the second version of BOOST_ENUM_CLASS_BASE is the best alternative. Nor do I know if the parentheses around enumerators are best. You can use BOOST_ENUM_CLASS in an enum definition header and BOOST_ENUM_CLASS_BASE as a header or a forward declaration. Since enumerators can be scoped, BOOST_ENUM_CLASS_REFER encapsulates the need to add the enum type's name.

5 9

[parameter] type predicates vs. concepts
by Lorenzo Caminiti 18 Dec '11

18 Dec '11

Hello all, What's the difference between using a Boost.Parameter type predicate and using a concept? I think parameter type predicates are unary metafunctions used to resolve the function call, concepts are asserted on the type after the call has been resolved... Is there more? Can I always do with type predicates what I can do with concepts? Is there ever a reason to use/need both? For example here has_equal_to is the type predicate while DefautlConstructible is the concept. Could/should I have used has_[...]_default_constructor in and_ the type predicate instead of the DefaultConstructible concept? #include <boost/parameter.hpp> #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/type_traits/has_equal_to.hpp> #include <iostream> template< typename X > BOOST_CONCEPT_REQUIRES( ((boost::DefaultConstructible<X>)), (bool) ) is_default_impl ( X const& x ) { return x == X(); } BOOST_PARAMETER_NAME(x) BOOST_PARAMETER_FUNCTION( (bool), is_default, tag, (required (x, *(boost::has_equal_to<tag::x::_>)) ) ) { return is_default_impl(x); } struct no_equal {}; struct no_default { no_default(int) {} }; bool operator== ( no_default const&, no_default const& ) { return true; } int main ( void ) { std::cout << is_default(123) << std::endl; // ok // parameter error: cannot resolve is_default() call // std::cout << is_default(no_equal()) << std::endl; // concept error: no default constructor // std::cout << is_default(no_default(1)) << std::endl; return 0; } Thanks a lot. --Lorenzo

4 7

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3

[Math.Constants] Help needed with the preprocessor
by John Maddock 18 Dec '11

18 Dec '11

Folks we have a problem: rather late in the day I've discovered that our Math.Constants code doesn't compile on anything except VC++, and the problem is preprocessor token pasting. So I'm hoping we have some experts around here that can help! The issue is we currently construct the constants from a macro invocation such as: BOOST_DEFINE_MATH_CONSTANT(half, 5.000000000000000000000000000000000000, 00000000000000000000000000000000000000000000000000000000000000000000000000, -01); But the "-01" part (the exponent) isn't a valid pp-token, so trying to token-paste it fails on GCC (compiler error). Does anyone know if there's a way to overcome this? As an alternative, I've considered something like: BOOST_DEFINE_MATH_CONSTANT(ln_two, 6.931471805599453094172321214581765680e-001, "6.93147180559945309417232121458176568075500134360255254120680009493393621969694715605863326996418687542001481021e-001"); But this would still require token pasting of the 6.931471805599453094172321214581765680e-001 part. But is this now a valid pp-token if the "-" is internal to the token? It works on the compilers I've tried, but I don't want to be skewered by this again down the line.... Truly hating the preprocessor yours, John.

6 8

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 18 Dec '11

18 Dec '11

On 24 Nov 2011 09:11:19 Joel de Guzman wrote: >Man! Of course you should use the examples in 1.45. Those examples >are for 1.48 and uses new features implemented in 1.48! Sheesh! I fully understand that. The point is that the Phoenix interface is evolving much more quickly than that of probably any other Boost library. Even apart from the fact that there already have been two bottom-up rewrites, there are enough significant changes between point releases that even small example programs are tied to a particular version of the library. Why is the optimal way to write a small calculator example today so different from the optimal way to write it six months ago? I'm not disputing that you're making forward progress, just highlighting this as another barrier to entry that Local likely won't have. >Double Sheesh! If you've spent even a few seconds looking into the >error (beyond fault-finding), you will see that a simple textual >search of "error" will reveal this: Yes, it's possible to wade through the error messages and figure out what went wrong. And Qi is clearly trying to help out with traceable assertions; that may well be the best we can do. But no reasonable person would claim that hundreds of lines of error message, mostly filled with types that the user never directly constructed, are the most desirable way to report a simple syntax error. This problem is endemic to all ET libraries and compilers, and it would be very, very hard to do much better. Again, though, I think you're underselling this as a barrier to entry. How many people would ever learn C++ if all libraries did this? >Now having said that, and before I leave this thread, let me remind >everyone that **you can also have statement syntax in Phoenix** if you >have a complex statement and you fear writing complex phoenix lambda >expressions. It's called phoenix::functions. The important issue here isn't just statement /syntax/, it's that we have options available that don't turn what looks like an ordinary C++ statement into a massive AST with its own mini-compiler behind the scenes.

18 38

Boost.Math and Math Constants
by Paul A. Bristow 17 Dec '11

17 Dec '11

Boost.Math has always had an inconspicuous collection of useful math constants, mainly those that are used internally. The presentation of these was as a function-template, called for example, as pi<double>(). using namespace boost::math::constants; return pi<Real>() * r * r; This leads to some rather ugly equations and is most unpopular with scientific and engineering users. John Maddock has now added a new cunning feature that allows the vast majority of users who just want a built-in double to get the constants quickly as plain variables. So in non-template code, users can write using boost::math::double_constants; double area = pi * r * r; and users can read the equations easily. (Float and long double are similarly available in their own namespaces). The original mechanism which can be used for higher multiprecision user-defined floating-point types appears unchanged but has been improved to work better with UDTs and high precision types. Some draft detailed docs about just these new proposals are at http://boost-sandbox.sourceforge.net/libs/math_constants/doc/html/index.html We would like to be sure that 1 This additional mechanism of presenting constants is acceptable. 2 It is acceptable to add more constants (current new list is about 60 constants). Are there important constants that you think we have missed? Do we need a mini-review? Other views? Paul PS 1 Are there important constants that you think we have missed? 2 Please tell me of mistakes and typos in the draft docs. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

9 24

Standard library Technical Report 2 proposals for Boost libraries
by Beman Dawes 17 Dec '11

17 Dec '11

The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman

7 18

Slow Bugs Tracker
by Olaf van der Spek 17 Dec '11

17 Dec '11

Hi, Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time. Would it be possible to use a better bugs tracker? -- Olaf

5 14

Submitting patches
by Pedro Larroy 17 Dec '11

17 Dec '11

Hi What's the proper way to submit patches for boost trunk? Regards.

3 4

[thread] 5351 interrupt a future get boost::unknown_exception
by Vicente J. Botet Escriba 17 Dec '11

17 Dec '11

Hi, I have reached to compile the example with some variants. See the attached file in http://svn.boost.org/trac/boost/ticket/5351. It seems the problem comes from the fact that packaged_task catch every exception void do_run() { try { this->mark_finished_with_result(f()); } catch(...) { this->mark_exceptional_finish(); } } and store it to rethrow in the wait() function using boost::rethrow_exception. if(rethrow&& exception) { boost::rethrow_exception(exception); } As thread_interrupted doesn't inherits from std/boost::exception the thrown exception is translated as boost::unknown_exception. A solution could be to catch specifically thread_interrupted and store this fact. catch(thread_interrupted& it) { this->mark_interrupted_finish(); } void mark_interrupted_finish() { boost::lock_guard<boost::mutex> lock(mutex); thread_was_interrupted=true; mark_finished_internal(); } When wait is called, a test if the thread has been interrupted is done so that the exception thread_interrupted is thrown. if(rethrow && thread_was_interrupted) { throw boost::thread_interrupted(); } The single problem I see is that the this new exception doesn't contains from where the initial thread_interrupted was thrown. Could the interested parties inspect the patch attached to http://svn.boost.org/trac/boost/ticket/5351 and check it, please? Is there something I forgot or a simple or more robust way to solve this missing feature? Best, Vicente

1 1

[local] "true" lambdas without C++11 but only on GCC
by Lorenzo Caminiti 17 Dec '11

17 Dec '11

Hello all, A curiosity: On GCC compilers (but _only_ on GCC compilers) it is possible to combine Boost.Local and the non-standard GCC "expression statements" feature to implement lambda functions. In other words, it is possible to define a Boost.Local closure within a GCC expression statement: std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); This is just a curiosity because it is NOT standard C++03 and it will ONLY work with GCC compilers. #include <boost/local/function.hpp> #include <vector> #include <algorithm> #include <iostream> // WARNING: This macros only work on GCC!!! #define LAMBDA_WITH_RESULT(result_type, ...) \ ({ /* open GCC statement expression */ \ result_type BOOST_LOCAL_FUNCTION_PARAMS(__VA_ARGS__) #define LAMBDA(...) \ LAMBDA_WITH_RESULT(void, __VA_ARGS__) #define LAMBDA_END \ BOOST_LOCAL_FUNCTION_NAME(BOOST_PP_CAT(lambda, __LINE__)) \ BOOST_PP_CAT(lambda, __LINE__); \ }) /* close GCC statement expression */ int main() { std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); return 0; } I might mention this code example as a curiosity in Boost.Local docs, currently it's not mentioned there. Thanks. --Lorenzo

2 3

[log] sourceforge trunk broken with clang
by Michael Caisse 17 Dec '11

17 Dec '11

Changeset 633 fails to compile with clang. The trivial logger example in tutorial will trigger multiple errors. My guess is that simply including trivial.hpp will do the same. -- Michael Caisse Object Modeling Designs www.consultomd.com

2 1

New libraries implementing C++11 features in C++03
by Jeffrey Lee Hellrung, Jr. 17 Dec '11

17 Dec '11

Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut: > Ok. However this raises a more serious question. Should we as the > Boost community still encourage solutions and libraries solely for > portability with ancient compilers? I'd say no, but YMMV. Boost will > be still around 2, 5, or 10 years from now. What's the utility of > adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff

20 45

Speeding up set and map insertion
by Tweety 16 Dec '11

16 Dec '11

Hi, I think it would speed up inserting range of elements into set and map, when in tree.hpp we replace: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with end hint, to achieve linear //complexity if [first, last) is ordered const_iterator end(this->cend()); for( ; first != last; ++first) this->insert_equal(end, *first); } with: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with hint, to achieve linear //complexity if data is even partially ordered const_iterator it(this->cend()); for( ; first != last; ++first) it = this->insert_equal(it, *first); } I will make almost linear complexity when data is ordered ascending, descending, and even partially ordered. Because when inserting with end hint (btw. wasn't here a bug? because "end" wasn't updated) it's only linear if we insert elements in ascending order.

2 1

[crc] Does anyone know who did issue #2492?
by Daryle Walker 16 Dec '11

16 Dec '11

I ask because I don't see any bug; his/her example works just fine for me. I need a complete (minimal!) program that shows the error. See more at [https://svn.boost.org/trac/boost/ticket/2492]

1 0

[graph] running test leda_graph_cc.cpp fails - header not found
by Jens Müller 15 Dec '11

15 Dec '11

Hi all, I tried to run the tests for the LEDA adapter in the Boost Graph library. I checked out the latest trunk from SVN. I made the Boost.Build v2, works fine. When running ./../../tools/build/v2/bjam in libs/graph/test, all tests run fine. I installed LEDA (free version) in /home/jens/devel/leda-free/LEDA-6.3-free-fedora-core-8-64-g++-4.1.2-mt After successfully running all other tests, the one for LEDA fails: $ ../../../tools/build/v2/bjam -s LEDA=/home/jens/devel/leda-free/LEDA-6.3-free-fedora-core-8-64-g++-4.1.2-mt/ Performing configuration checks - has_icu builds : yes ...patience... ...patience... ...patience... ...found 6503 targets... ...updating 2 targets... gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:10:0: ../../../boost/graph/leda_graph.hpp:20:30: fatal error: LEDA/graph/graph.h: No such file or directory compilation terminated. "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o" "leda_graph_cc.cpp" ...failed gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o... ...failed updating 1 target... ...skipped 1 target... Note that I edited boost/graph/leda_graph.hpp, fixing a syntax error and making it point to the now location of the LEDA header files (which contains an additional "graph" sub-directory). But the problem seems to be that the include directory is not at all passed to the compiler. What is going wrong here? Best, Jens

2 2

[graph] LEDA adapter
by Jens Müller 15 Dec '11

15 Dec '11

Hi all, are there still people who want to use the LEDA adapter in the Graph library? Back in 2007, I contributed adapters for some property maps. The checkin unfortunately introduced a typo (let's call it a transmission error ...) which is still there. So apparently no-one used it since then?! There also have been some discussions on removing the support, and patch requests were denied due to a lack of maintainer ... If there is _any_ interest in still maintaining leda_graph.hpp, I'd do it, as Douglas had already offered to me in 2007. I have more time and a better understanding now, and I'd really like to dive a bit more into Boost development. Besides, there apparently now is a free (as in beer) version of LEDA available, which should facilitate more widespread testing. Regards, Jens

3 5

Request: sanity check for a jamfile
by Daryle Walker 15 Dec '11

15 Dec '11

I just added a new test file for Boost.CRC on the SVN trunk. I also tried to adapt the test jamfile to accommodate two test programs. I'm not sure that I did it right, so can anyone check that it works. (I use XCode to build and test my programs.) The new file, "crc_test2.cpp", uses the unit-testing apparatus. The old file, "crc_test.cpp", uses the header-only minimal Testing facility. (I'm not sure that its link to the Test Execution monitor, in the jamfile, is needed.) I added a new testing file because I want to add a test case for a bug and Boost.Test has advanced so much that the first file is way too obsolete to be safely extended. It's change #75959 on the trunk, a.k.a. [https://svn.boost.org/trac/boost/changeset/75959]

2 1

[python] [concept] CallPolicies implementation
by Lorenzo Caminiti 15 Dec '11

15 Dec '11

Hello all, Does Boost.Python implement the CallPolicies concept? I couldn't find it... http://www.boost.org/doc/libs/1_48_0/libs/python/doc/v2/CallPolicies.html If not, would something like this be OK?? template<class P> struct CallPolicies { BOOST_CONCEPT_ASSERT((ResultConverterGenerator<P::result_converter>)); BOOST_CONCEPT_ASSERT((Metafunction<P::extract_return_type>)) BOOST_CONCEPT_USAGE(CallPolicies) { bool b = x.precall(a); // convertible to bool PyObject* o = x.postcall(a, r); // convertible to PyObject* } private: P x; PyObject* a; PyObject* r; }; I'd have to implement ResultConverterGenerator and Metafunction as well. Thanks. --Lorenzo

2 1

[parameter] compiler errors with operators
by Lorenzo Caminiti 15 Dec '11

15 Dec '11

Hello all, Does Boost.Parameter support operators? The following example is from the docs but it doesn't compile. Looking at the preprocessed code /EP, the errors seem to be because the macro defines a struct template postfixing it with the operator name and symbol "template <class Args> struct boost_param_result_11operator() { ... };". Maybe this worked once before and it's now broken? #include <boost/parameter.hpp> #include <iostream> BOOST_PARAMETER_NAME(arg1) BOOST_PARAMETER_NAME(arg2) struct callable2 { BOOST_PARAMETER_CONST_MEMBER_FUNCTION( (void), operator(), tag, (required (arg1,(int))(arg2,(int)))) { std::cout << arg1 << ", " << arg2 << std::endl; } }; int main ( void ) { callable2 c; c(1, 2); return 0; } On MSVC 8 with latest Boost trunk: c02.cpp c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : 'type' c02.cpp(11) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : 'type' c02.cpp(11) : error C2334: unexpected token(s) preceding ':'; skipping apparent function body c02.cpp(11) : error C2143: syntax error : missing ';' before '<' c02.cpp(11) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c02.cpp(11) : error C2238: unexpected token(s) preceding ';' c02.cpp(11) : error C2143: syntax error : missing ';' before '<' c02.cpp(11) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c02.cpp(11) : error C2238: unexpected token(s) preceding ';' c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : '<' c02.cpp(11) : error C3861: 'boost_param_parameters_11operator': identifier not found c02.cpp(11) : error C2039: 'type' : is not a member of '`global namespace'' c02.cpp(11) : error C3861: 'boost_param_parameters_11operator': identifier not found c02.cpp(11) : error C2039: 'type' : is not a member of 'boost::parameter::aux::match' ..\..\..\..\..\boost\trunk.windows\boost/parameter/preprocessor.hpp(99) : see declaration of 'boost::parameter::aux::match' c02.cpp(11) : error C2039: 'type' : is not a member of '`global namespace'' c02.cpp(11) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body c02.cpp(14) : error C2270: 'boost_param_default_11operator' : modifiers not allowed on nonmember functions c02.cpp(14) : error C2091: function returns function c02.cpp(20) : error C2064: term does not evaluate to a function taking 2 arguments Thanks. --Lorenzo

2 1

[multiprecision] Docs missing the basics
by Beman Dawes 15 Dec '11

15 Dec '11

Looking at http://boost-sandbox.sourceforge.net/libs/multiprecision/doc/html/multiprec… http://boost-sandbox.sourceforge.net/libs/multiprecision/doc/html/multiprec… I see a lot of details and commentary, but nothing about the big picture. * Needs an explanation of what "multiple precision" means. I would expect the first sentence to be something like "The multiprecision library, like other multiple precision libraries, provides arithmetic types that are not limited to the precision of the built-in C++ arithmetic types." * Needs an early explanation of what kinds of arithmetic types are supported. I would expect the second sentence to be something like "Integer, floating, and user defined types are supported." (I can't even tell from the current intro whether integers and UDTs are supported!) * Needs an early "Hello World" level example. The third sentence might begin a new paragraph, something like "Here is a simple example of muliprecision use: ..." Please remember that the point of a "Hello World" example is to introduce the simplest possible use of the library, not to demonstrate its power! * Although, not as critical as the previous issues, a bullet list of key features would be easier to read than plowing through a bunch of dense text. Once you've done that, the reader can make a quick blink decision as to whether to read on. A reader who isn't interested with thank you for not wasting their time plowing through a lot of text only to discover the library isn't of interest to them. Once docs provided the above view from 30,000 feet, then the remaining introductory details you've provided become interesting and the reader has enough orientation to absorb them. Good luck with this library! --Beman

4 3

Andriod development using boost
by Jan Stetka 14 Dec '11

14 Dec '11

Anyone done any andriod development. I'm interested on how much you can use boost for andriod development. Also JNI looks like the way of using C++ code, does anyone have experience of using JNI?

3 2