- Boost - lists.preview.boost.org

[pool][hit-squad] Kudos! Updates?
by Jim Bell 12 Feb '11

12 Feb '11

Looking at the commit log (/sandbox/guild/pool), I see commits by pbristow, ktchan, danieljames, marshall, and steven_watanabe. Thanks for your efforts! Kudos to John Maddock for the idea and impetus. How's it going? Road-blocks? Show-stoppers? Thoughts? Need more hands/eyeballs/brains/hours-in-the-day? Best, -Jim

2 1

[integer][type_traits] invaid values for integer_traits<boost::intmax_t>
by Vicente Botet 12 Feb '11

12 Feb '11

Hi, the following has different behavior depending on whether <climits> in included in gcc-4.5 #include <climits> #include <boost/mpl/assert.hpp> #include <boost/mpl/bool.hpp> #include <boost/integer_traits.hpp> #include <boost/type_traits/integral_constant.hpp> #include <boost/cstdint.hpp> BOOST_MPL_ASSERT_MSG(false, BOOST_RATIO_OVERFLOW_IN_MUL, ( boost::integral_constant<boost::intmax_t,boost::integer_traits<boost::intmax_t>::const_min>, boost::integral_constant<boost::intmax_t,boost::integer_traits<boost::intmax_t>::const_max> )); With error: no matching function for call to 'assertion_failed(mpl_::failed************ (BOOST_RATIO_OVERFLOW_IN_MUL::************)(boost::integral_constant<long long int, -0x8000000000000000ll>, boost::integral_constant<long long int, 0x7fffffffffffffffll>))' and without error: no matching function for call to 'assertion_failed(mpl_::failed************ (BOOST_RATIO_OVERFLOW_IN_MUL::************)(boost::integral_constant<long long int, 128ll>, boost::integral_constant<long long int, -0x000000081ll>))' As you ca see the const_min and cont_max values are not correct in the last case. I was wondering if the <climits> file must be included by <boost/integer_traits.hpp> or <boost/cstdint.hpp>. Comments? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/integer-type-traits-invaid-values-for-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

[filesystem] Should recursive_directory_iterator follow directory symlinks by default?
by Beman Dawes 12 Feb '11

12 Feb '11

recursive_directory_iterator currently always follows directory symlinks It seems to me that whether or not this behavior is desirable is application dependent. Thus I'd like to add an option to either following directory symlinks or not. Which should the default be? Following symlinks by default avoids breaking existing code, so that's my mild preference, but I'm wondering if anyone has a strong argument for not following directory symlinks by default? --Beman PS: Windows identifies symlinks to directories, so it is possible to have a dangling symlink to a non-existent directory. recursive_directory_iterator currently tries to recurse into the non-existent directory. That's just a bug and I'm about to fix it.

6 8

[UTF String] Feedback on UTF String library, please
by Chad Nelson 11 Feb '11

11 Feb '11

I reiterate my request from this message <http://permalink.gmane.org/gmane.comp.lib.boost.devel/214601>: would those interested in the UTF String library please comment on the new version? Specifically, I'm looking for feedback on: * Technical opinions on the design; * How useful it would be to you as-is; * What would make it more useful to you. The code can be found here: <http://www.oakcircle.com/toolkit.html>. Thanks in advance. -- Chad Nelson Oak Circle Software, Inc. * * *

4 5

[range] A macro to disable iterator_range io
by Samuel Debionne 11 Feb '11

11 Feb '11

Hello, would it be possible to add a configuration macro in iterator_range.hpp like : #if !defined(BOOST_ITERATOR_RANGE_NO_IO) #include "boost/range/iterator_range_io.hpp" #endif so that custom versions of the insertion operator for iterator_range won't clash with the one provided by boost ? We could include only the core include (iterator_range_core.hpp) but other boost libraries seems to include iterator_range.hpp which include the io header... Samuel

1 0

[announce] mirror-lib 0.5.4 released
by Matus Chochlik 11 Feb '11

11 Feb '11

Dear list, I would like to announce that a new version of the Mirror reflection library is available for download from SourceForge: http://sourceforge.net/projects/mirror-lib/files/mirror-lib-0.5.4/ The documentation is hosted online here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ To get an idea what the library can do you can look at the examples: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/examples.html Just to mention some of the more important changes since the last announce: 1) The factory generator now fully supports enumerated types in both Mirror (compile-time reflection) and Lagoon (run-time layer) 2) The factory generator now supports (container) types which have a constructor taking a pair of forward iterators. This does not work with the run-time layer yet. See for example: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/mirror_2example_2factor… Some screenshots of input dialogs generated by the factory generator utility can be found here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/mirror__wx__gui__fact__… NOTE: Since Mirror uses C++1x AFAIK it will currently compile only with gcc (tested with gcc 4.5.1 and 4.5.2 64-bit on Linux and 4.5.1 on cywin) Questions, comments, feedback or potential contributions are always appreciated. Best regards, Matus

1 0

TTI library updated in the sandbox
by Edward Diener 10 Feb '11

10 Feb '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.1. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Features of the update include support for the older gcc 3.4.2 and 3.4.5, finer-grained introspection for the basic macro metafunctions, documentation examples, better and tighter design, and better use of Boost MPL methodology ( metafunctions are now passed as lambda expressions and metafunction globbing has been removed from the two metafunctions where it previously existed ). You can view the changes in the History section of the documentation. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also lifts functionality, for the purposes of orthogonality, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. There is a readme.txt in the top-level sandbox tti directory, for anyone browsing the sandbox for interesting libraries, which basically replicates what is written here. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. Questions, comments, suggestions, and bug reports are all welcome.

4 9

[random] [tr1] xor_combine min/max
by Steven Watanabe 10 Feb '11

10 Feb '11

AMDG Currently these are implemented as std::min(_rng1.min(), _rng2.min()) and std::max(_rng1.max(), _rng2.max()). This is obviously wrong, although it happens to work for taus88 which is the only use of xor_combine right now. I looked at boost/tr1/random.hpp and it has a more complex implementation. Unfortunately, I don't think it's completely right either as computes min/max(x ^ y) where (_rng1.min() << s1) <= x <= (_rng1.max() << s1) and (_rng2.min() << s2) <= y <= (_rng2.max() << s2) Alas, when a random value is shifted left, the low order bits are always zero, so this algorithm may overestimate the bounds. Also, when the shift causes either base engine to lose bits, the algorithm forces the max to std::numeric_limits::max. This is clearly wrong if _rng1.min/max = [0x80000000, 0x800000FF], s1 = 1, since this ends up being equivalent to [0, 0xFF]. So, I have a couple of options a) Require the base ranges to be something sane like [0, 2^k-1]. The advantage of this is that it's easy, and it's automatically guaranteed that the combined engine is equidistributed if the base engines are. b) Somehow make it work. It would be nice if it were fully general, but working out the bit-twiddling for this will be a pain and the code will probably end up unintelligible. I'd rather not do this unless it's really needed. Are there any algorithms that need to xor numbers from non power-of-two ranges? For example, is xoring the outputs of two LCG's ever useful? Thoughts? In Christ, Steven Watanabe

1 0

[fiber] mini review - symmetric a. asymmetric continuation
by Oliver Kowalke 10 Feb '11

10 Feb '11

I've uploaded a new version to boost vault (section 'Concurrent Programming') which contains to fiber implementations - sym_fiber (symmetric fiber/continuation) and asym_fiber (asymmetric fiber/continuation). I'd like to ask for a mini review in order to get a bit feedback if the design is appropriate. Oliver

3 7

Re: [boost] Patch to make code_converter flushable
by Eddie Carle 10 Feb '11

10 Feb '11

On Thu, 03 Feb 2011 17:35:56 -0700, Eddie Carle wrote: > I've attached a little patch that makes iostreams::code_converter > flushable. It seems like it really should be. Is there any chance > someone could look at this? I've included some test code as well that > outputs the following. Is anyone actually interested in this? I've been working on moving the fastcgi++ library over to boost iostreams but unless this patch is applied I cannot actually do so. One cannot derive from iostreams::code_converter to make it flushable because the necessary components are private and not protected. Is there any chance whatsoever of getting this patch applied or am I just wasting my time? -- Eddie Carle

3 4

Using Boost without confusing Intellisense
by Matthew Chambers 10 Feb '11

10 Feb '11

Hi, I use many Boost libraries, develop with MSVC (currently 2008), and build both my project and its Boost dependencies with Boost.Build. The one thing that's always frustrated me using boost is its tendency to confuse MSVC's Intellisense. I don't know if this holds true for other IDEs with an Intellisense-like capability, but heavy use of boost::shared_ptr and BOOST_FOREACH in particular seem to confuse Intellisense in a large project. MSVC never knows what to show when dereferencing a shared_ptr and it never defines the instance variable in BOOST_FOREACH. I came up with two fairly simple workarounds for this but I'm interested to hear if there's a better solution. If not, I'm wondering if the workarounds could go in boost itself. For shared_ptr, I use a conditional macro like: #ifdef INTELLISENSE #define TYPEDEF_SHARED_PTR(type) typedef type* type##Ptr #else #define TYPEDEF_SHARED_PTR(type) typedef boost::shared_ptr<type> type##Ptr #endif For BOOST_FOREACH, I do basically the same thing: #ifdef INTELLISENSE #define BOOST_FOREACH(a, b) a; #else #include <boost/foreach.hpp> #endif Then I just add INTELLISENSE to the VC project's preprocessor macros (not my build system) and Intellisense gets the job done a lot more often. I didn't look into whether MSVC defines an automatic preprocessor variable when Intellisense is parsing (which would be useful for helping it navigate complex code), but of course that would be even better. The obvious flaw for TYPEDEF_SHARED_PTR in my implementation is that it assumes a particular variable name scheme, but an "official" version could make both type names explicit. The are some other confusing libs like Boost.Preprocessor but I don't think they are as commonly used. The nice thing about these workarounds is they can be applied separately to each library. I'm wondering if other boost devs or users would be interested in having these workarounds in the official boost distro. For the smart_ptrs, it could go at the end of the headers. For BOOST_FOREACH, the whole foreach.hpp could be surrounded by #ifndef INTELLISENSE (so that all the stuff inside it doesn't need to be parsed for Intellisense) and the #else would define BOOST_FOREACH and BOOST_REVERSE_FOREACH as I did above. If not, maybe it's time I switched IDEs. Are there any that provide Intellisense-like capability with smart_ptrs and BOOST_FOREACH? :) Thanks, -Matt

9 11

Problem with boost::random seed
by Anton Skvorts 10 Feb '11

10 Feb '11

Testing boost::random with the following code boost::mt19937 gener(1); boost::normal_distribution<> normal(0,1); boost::variate_generator<boost::mt19937 &,boost::normal_distribution<> > rng(gener, normal); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; gener.seed(2); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; I'm getting unexpected values after gener.seed(2) -2.971829031 1.706951063 -0.430498971 -2.282022417 x -0.5887503675 0.2504171986 The value -2.282022417 is the forth number in the sequence originated by gener(1) and not the first number in the sequence originated by gener.seed(2) as one would expect (this number is actually -0.5887503675). If I reseed next with gener.seed(3)it works fine, but if after that I reseed again with gener.seed(1) I'll get the same problem, and so on and off... How can I reseed the random number generator to overcome this problem? Thanks in advance

3 10

[general] What will string handling in C++ look like in the future [was Always treat ... ]
by Matus Chochlik 10 Feb '11

10 Feb '11

The string-encoding-related discussion boils down for me to the following: What fill the string handling in C++ look like in the (maybe not immediate) future. *Scenario A:* We will pick a widely-accepted char-based encoding that is able to handle all the writing scripts and alphabets that we can think of, has enough reserved space for future additions or is easily extensible and use that with std::strings which will become the one and only text string 'container' class. All the wstrings, wxString, Qstrings, utf8strings, etc. will be abandoned. All the APIs using ANSI or UCS-2 will be slowly phased out with the help of convenience classes like ansi_str_t and ucs2_t that will be made obsolete and finally dropped (after the transition). *Scenario B:* We will add yet another string class named utf8_t to the already crowded set named above. Then: library a: will stick to the ANSI encodings with std::strings It has worked in the past it will work in the future, right ? library b[oost]: will use utf8_t instead and provide the (seamles and straightforward) conversions between utf8_t and std::string and std::wstring. Some (many but not all) others will follow library c: will use std::strings with utf-8 ... library [.]n[et]: will use String class ... library q[t]: will use Qstrings .. library w[xWidgets]: will use wxStrings and wxChar* library wi[napi]: will use TCHAR* ... library z: will use const char* in an encoding agnostic way Now an application using libraries [a..z] will become the developers nightmare. What string should he use for the class members, constructor parameters, who to do when the conversions do not work so seamlesly ? Also half of the cpu time assigned to running that application will be wasted on useless string transcoding. And half of the memory will be occupied with useless transcoding-related code and data. *Scenario C:* This is basically the status quo; a mix of the above. A sad and unsatisfactory state of things. *Consequences of A:* - Interface breaking changes, which will require some fixing in the library client code and some work in the libraries themselves. These should be made as painless as possible with *temporary* utilities or convenience classes that would for example handle the transcoding from utf8 to UCS-2/UTF-16 in WINAPI and be no-ops on most POSIX systems. - Silent introduction of bugs for those who still use std::string for ANSI CP####. This is worse than above and will require some public-relations work on the part of Boost to make it clear that using std::strings with ANSI may be an error since Boost version x.y.z. - We should finally accept the notion that one byte, word, dword != one character and that there are code points and there are characters and both of them can have variable length encoding and devise tool to handle them as such conveniently. - Once we overcome the troubled period of transition everything will be just great. No headaches related to file encoding detection and transcoding. Think about what will happen after we accept IPV6 and drop IPV4. The process will be painful but after it is done, there will be no more NAT, and co. and the whole network infrastructure will be simplified. *Consequences of B:* - No fixing of existing interface which IMO means no or very slow moving on to a single encoding. - Creating another string class, which, let us face it, not everybody will accept even with the Boost influence unless it becomes standard. - We will abandon std::string and be stuck with utf8_t which I *personally* already dislike :) - People will probably start to use other programming languages (although this may by FUD) *Consequences of C:* Here pick all the negatives of the above :) *Note on the encoding to be used* The best candidate for the widely-accepted and extensible encoding vaguely mentioned above is IMO UTF-8. - It has been given a lot of thought - It is an already widely accepted standard - It is char-based so no need to switch to std::basic_string<whatever_char_t> - It is extensible, so once we have done the painful transition we will not have to do it again. Currently utf-8 uses 1-4 (or 1-6) byte sequences to encode code points, but the scheme is transparently extensible to 1-N bytes (unlike UCS-X and i'm not sure about UTF-16/32). So, [dark-sarcasm] even if we dig out the stargate or join the United Federation of Planets and captain Kirk, every time he returns home, brings a truckload of new writing scripts to support, UTF-8 will be able to handle it. just my 0.02 strips of gold pressed latinum :) [/dark-sarcasm] Best regards, Matus

23 117

[process] FileSystem version
by vicente.botet 09 Feb '11

09 Feb '11

Hi, with witch version of Boost.FileSystem Boost.Process is working, V2, V3 or both? Best, Vicente

3 4

Re: [boost] [gsoc] Boost.Process done
by Claude Quézel 09 Feb '11

09 Feb '11

I noticed that the boost::process::child does not have a default constructor. If I have a coding requirements like the following example, I would be stuck: // Note the required default constructor boost::process::child child; // Create a scope for the mutex guard { boost::lock_guard<boost::mutex> guard(process_launch); // Here I must do something within guard scope // that must be done with the boost::process::launch do_something(); child = boost::process::launch(exec, args, ctx); } // ... boost::process::status s = child.wait(); // ...

6 6

[Git] Moving beyond arm waving?
by Beman Dawes 09 Feb '11

09 Feb '11

To move discussion of Git beyond the arm waving stage, I'd like to suggest several concrete steps: * Use the tag "[git]" to identify list postings discussing integration of Git into Boost daily life. If that gets unwieldy, we can start a separate mailing list. * Start building documentation, with a lot of the initial effort going into rationale and "how to do it". To that end, I've started to populate a "Git" hierarchy on the Trac wiki: https://svn.boost.org/trac/boost/wiki/Git/GitHome. Please contribute! * As a demonstration and proof-of-concept, a Boost library should begin using Git. Presumably a public repository (on GitHub?) can channel changes back to Boost svn. I'll volunteer the filesystem library. Comments? --Beman

28 90

Library proposal: Boost.JniTools - The easy way to call Java methods from C++ (build on top of JNI)
by Boris Brodski 09 Feb '11

09 Feb '11

Hello everyone, I'm the maintainer of the 7-Zip-JBinding project: - On SourceForge: http://sevenzipjbind.sourceforge.net/ - On GitHub: https://github.com/borisbrodski/sevenzipjbinding/tree/RW (Check the RW branch) In order to call C++ code from Java and vice versa the JNI (Java Native Interface) should be used. This interface is low level and provides little safety. (Java VM crashes very easy) Also to get a good performance, a bunch of code is always needed to cache ids and some pointers returned from jni. In the new version of 7-Zip-JBinding (see git RW branch) I wrote a library, that solves some of JNI problems. It uses simple DSL (defines) to describe java classes/interfaces with their methods/fields. It generates from the DSL during pre-compile time some kind of easy to use skeletons around Java classes and interfaces, providing very simple access to their methods and fields. Here are the features: - Type-safe calls from C++ to Java - The compiler will check the number and type of all passed arguments to the called methods. The same applies to setting field. - Caching of method ids and class pointers. - Auto-determining java method signature from the DSL. - Consistent JNI low level error handling - Tools to debug checking and cleaning exceptions after each method call. - Code completion of the java methods and fields from C++ with IDE, capable of expanding defines (for example, with Eclipse CDT). Here is a very simple example, how this library can be used: --- JAVA package test; class MyClass { public long doSomething(boolean param1, int param2, long param3) { ... } } --- C++ (The classic usage of the JNI) jlong callDoSomething(JNIEnv * env, jobject instance, jboolean param1, jint param2, jlong param3) { c = env->FindClass("test/MyClass"); if (!c) { ... handle_error ... } // Writing signatures is annoying jmethodID mid = env->GetMethodID(c, "doSomething", "(ZI)J"); // MethodId should be cached here if (!mid) { ... handle_error ... } // Wrong parameter type/count here cause VM to crash jlong result = env->CallLongMethod(instance, mid, param1, param2, param3); if (env->ExceptionOccurred()) { ... handle_exception ... } env->ExceptionClear(); // Failing to call this method cause VM to crash ONLY IN CASE of exception return result; } --- C++ (Using JniTools) // Describe class. (This could be also generated directly from Java class) JT_BEGIN_CLASS("test", MyClass) JT_CLASS_VIRTUAL_METHOD(Long, doSomething, JT_BOOLEAN(param1, JT_INT(param2, JT_LONG(param3, _)))) JT_END_CLASS jlong callDoSomething(JNIEnv * env, jobject instance, jboolean param1, jint param2, jlong param3) { // with Eclipse CDT: // - the class and method can be auto-completed. // - the parameters can be viewed with the real names (from DSL) // - the return type can be viewed // - "Jump to definition" jumps to the corresponding DSL jlong result = jni::InArchiveImpl::doSomething(env, instance, param1, param2, param3); if (env->ExceptionOccurred()) { ... handle_exception ... } // Failing to call this method cause VM to crash ALWAYS in debug mode // Controlled by define: // JNI_TOOLS_DEBUG_CALL_AND_EXCEPTION_CLEAR_BEHAVIOR jni::expectExceptionCheck(env); return result; } The JniTools library is currently not fully stand-alone. There are some dependencies to other .h files from the 7-Zip-JBinding. Also JniTools doesn't cover all the jni features, that can be covered. The test-coverage of the existing features is however good. Here a some direct links: - The JniTools library: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/jbinding-cpp/JavaS… (has to be renamed) - The usage example: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/jbinding-cpp/JavaS… Tests (called from JUnit): - C++: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/test/CTests/JniToo… - Java: https://github.com/borisbrodski/sevenzipjbinding/tree/RW/test/JavaTests/src… In case, this library has a real chance to become a part of the Boost library, I would be happy to remove all the7-Zip-JBinding dependencies, implement missing features and discuss other possible improvements. It would be match better, if someone will volunteer to help me on this and share the responsibility. Regards, Boris Brodski ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front

3 2

[process] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Oliver Kowalke 09 Feb '11

09 Feb '11

I'm missing the possibility to send signals to a process and to wait for a process to be stopped (SIGSTOP) or resumed (SIGCONT) using boost.asio. Oliver

1 0

[spirit.phoenix] Phoenix test coverage
by Jim Bell 09 Feb '11

09 Feb '11

>From names in the spirit regression test matrix <http://www.boost.org/development/tests/release/developer/spirit.html>, I see these four with phoenix in the name: dedent_handling_phoenix, lex_dedent_handling_phoenix, lex_set_token_value_phoenix, set_token_value_phoenix. When I search for phoenix in all libs/spirit/test code, I see references in 104 files, so tests span more than just above four. But how well do phoenix's tests span its content? Is this documented somewhere? Thanks in Advance, -Jim

5 12

Preliminary review request for (Boost) QVM
by Emil Dotchevski 08 Feb '11

08 Feb '11

This is a library for working with Quaternions, Vectors and Matrices of static size. A type traits system is used to enable generic namespace-scope (operator) function templates that implement various Q, V and M operations for any (user-defined) compatible type. The library also defines view proxies which provide lvalue or rvalue access to objects as if they are of a different type. For example, col<1>(m) refers to column 1 of the matrix m as if it is a vector. This system works without creating temporary objects, and should enjoy zero abstraction penalty with most compilers (assuming inlining works.) The online documentation is at http://revergestudios.com/boost-qvm. Complete source code and documentation can be downloaded here: http://revergestudios.com/boost-qvm/boost-qvm.zip. Note: QVM supersedes (Boost) LA which was submitted for preliminary review about a year ago. It adds a few missing pieces (most notably support for quaternions), uses shorter names for types and functions, and is organized into fewer header files. Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 4

GSoC
by Dave Abrahams 08 Feb '11

08 Feb '11

Has anyone moved to do something about GSoC this year? Someone should get back to this guy, but it shouldn't be me unless the answer is going to be "we're not participating in 2011," which would be a shame!

3 4

Re: [boost] [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Mateusz Loskot 08 Feb '11

08 Feb '11

On 07/02/11 23:58, Boris Schaeling wrote: > As Marshall announced that the formal review of my library has > started I'd like to provide some information which is maybe helpful > for those interested in submitting a review. [...] This may be off-topic in this thread, but I think it's a good occasion to touch this subject. Why the review is discussed on the boost-users mailing list? The review manager is supposed to announce review on boost and boost-announce lists *only*. The results however go also to boost-users. I don't understand why the review is being conducted on boost-users. Even worse, it's cross-posted! Signal to noise ratio on the Boost mailing list has been worse than ever recently and if we start cross-posting reviews, it's going to become a chaos impossible to monitor and participate in. I am not trying to mother to anyone. I simply regret there is lack of self-discipline in the Community regarding the ml participation. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

[context] test on Mac OS X requested
by Oliver Kowalke 08 Feb '11

08 Feb '11

I've uploaded boost.context 0.6.4 - unfortunately I've no Mac OS X installation and I hope someone can test the lib on the Mac platform: ucontext_t: bjam toolset=gcc --debug-building fcontext_t on i386: bjam toolset=gcc architecture=x86 instruction-set=i686 address-model=32 context-impl=asm --debug-building fcontext_t on x86_64: bjam toolset=gcc architecture=x86 instruction-set=yorksfield address-model=64 context-impl=asm --debug-building thx, Oliver

4 6

GCC 4.6.x + Boost.Signals == failure
by Bryce Lelbach 08 Feb '11

08 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Who is the Boost.Signals maintainer? Boost.Signals fails to build against a stage-3 GCC build (GCC 4.6.x, r169444) due to an ambigious call to the erase method of a std::map<>. Do we have a GCC 4.6.x tester? This compiler is in the Debian- and Ubuntu- distribution these days. According to the regressions page, we don't appear to have a GCC 4.6.x tester... this would be nice to have. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1M4qUACgkQ9cB/V3/s9EwaGACeLl0j1IqPnrifdouCW1IfLGAC MqoAn2Z8IrxozFNbvwpNsS/HSr0XUD4f =JTd2 -----END PGP SIGNATURE-----

3 5

[thread] upgrading read lock to write lock
by Edd Dawson 07 Feb '11

07 Feb '11

I'm struggling to find the correct incantation to upgrade a (conceptual) read lock to a write lock. Here's my best guess at what I think should work, but it deadlocks at the highlighted point: #include <iostream> #include <iomanip> #include <boost/thread/shared_mutex.hpp> #include <boost/thread/locks.hpp> int main() { using namespace boost; shared_mutex m; shared_lock<shared_mutex> readlock(m); // reads go here // ... // Ah, need to write actually. // Upgrade to a write lock now. upgrade_lock<shared_mutex> uglock(m); std::cout << __LINE__ << std::endl; upgrade_to_unique_lock<shared_mutex> writelock(uglock); // <-- deadlock? std::cout << __LINE__ << std::endl; return 0; } I've been trying this with various combinations of msvc 9, msvc 10, mingw 4.3, boost 1.39 and boost 1.45, but always with the same results. Could someone kindly put me out of my misery? :) Kind regards, Edd

3 6