- Boost - lists.preview.boost.org

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

07 Feb '11

I would suggest to provide a function indicating if you are running on a POSIX platform: bool is_posix_platform(); if ( boost::process::is_posix_platform() ) { ... } The lib could provide an encapsulation for testing the exit code against WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG, WIFSTOPPED, WSTOPSIG, WIFCONTINUED, WCOREDUMP (as the old version of boost.process did). posix_status ps( status); if ( ps.terminated() ) int sig = ps.termination_signal(); if ( ps.has_coredump() ) ... Sending signals (SIGSTOP, SIGCONT, SIGKILL, etc.) to the process would also be usefull. You could raise an assertion (BOOST_ASSERT) if this functionality will be invoked by a non-POSIX platform.

1 0

Case study: Boost.Local versus Boost.Phoenix
by Gregory Crosswhite 07 Feb '11

07 Feb '11

Hey everyone, This e-mail is going to be a case study of my personal experience in converting code using Boost.Local to use Boost.Phoenix instead in order to get insight into the similarities and differences in what the libraries have to offer. I do not claim to have perfect understanding of Boost.Phoenix so I acknowledge that it is entirely possible that any negative experience I may have are due to my ignorance rather than a fault in the library itself. To give you some background of where I am coming from, I am a computational scientist working on a code that will let me prove some properties of a space of objects by exhaustive search. Fortunately it turns out that there are redundancies within this space so that I only need to search a subset of it. Thus, what I am working on now is a code which uses the Gecode library to generate solutions within this space that conform to constraints, where the constraints are chosen to only filter out redundant elements of the space. A significant part of this code is a suite of tests to ensure that my constraints work correctly, and it is this portion of the code that makes extensive use of Boost.Local and which I have attempted to convert to use Boost.Phoenix. First, it would have been helpful if I had known that Boost.Phoenix requires version 1.46 of Boost.Proto and Boost.Fusion, since I naively downloaded the sources to Boost.Phoenix into my local repository and discovered (after wading through pages of error messages) that it was missing a header. Since I have version 1.45 installed I concluded it must rely on sources from the trunk so I downloaded Boost.Proto, and then pages of error message later Boost.Fusion. (Incidentally, this contrasts with Boost.Local which had no such problems with installation.) Still, even after doing all of this I ran into a completely incomprehensible error message on my very first attempt, which was to convert the following snippet of code BOOST_LOCAL_FUNCTION( (void) (checkSolution)( (const StandardFormParameters&)(parameters) (const OperatorSpace&)(space) ) ) { checkRegion(Z,space.getOMatrix().slice( parameters.z_bit_diagonal_size ,space.number_of_qubits ,0u ,space.number_of_operators )); } BOOST_LOCAL_FUNCTION_END(checkSolution) forEachStandardFormSolution( number_of_qubits ,number_of_operators ,list_of(EveryColumnHasZ) ,checkSolution ); to forEachStandardFormSolution( number_of_qubits ,number_of_operators ,list_of(EveryColumnHasZ) ,phoenix::bind(checkRegion ,Z ,phoenix::bind(&IntMatrix::slice,phoenix::bind(&OperatorSpace::getOMatrix,arg2) ,phoenix::bind(&StandardFormParameters::z_bit_diagonal_size,arg1) ,phoenix::bind(&OperatorSpace::number_of_qubits,arg1) ,0u ,phoenix::bind(&OperatorSpace::number_of_operators,arg1) ) ) ); (The error message is attached in the file error-1.txt.) I was so overwhelmed that I almost gave up on the whole project, until it suddenly occurred to me that the last line error: no matching function for call to 'get_pointer(const CodeSearch::StandardFormParameters&)' was probably indicating a problem with the member function accessors. I then remembered that I could equivalently replace the above code with forEachStandardFormSolution( number_of_qubits ,number_of_operators ,list_of(EveryColumnHasZ) ,phoenix::bind(checkRegion ,Z ,phoenix::bind(&IntMatrix::slice,phoenix::bind(&OperatorSpace::getOMatrix,arg2) ,phoenix::bind(&StandardFormParameters::z_bit_diagonal_size,arg1) ,number_of_qubits ,0u ,number_of_operators ) ) ); (due to the context in which it appears) and when I did so it compiled just fine. Scratching my head for a moment, I finally realized that the problem was that in my original code I used "arg1" for the last two binds rather than "arg2". For such a simple, easy mistake, the error message is incredibly intimidating. In this example it is hard to say which of the two above versions I prefer. The last version is definitely more compact and feels more "functional" (which is a big plus for me), but it also has a lot of noise. Also, while someone unfamiliar with Boost.Local could look at the first snippet of code and see immediately what it does, I think that even someone who was familiar with Boost.Phoenix would probably need to stare at the second snippet of code for a few moments in order to figure out exactly what it is doing. So while converting to Boost.Phoenix makes the code more compact and more functional, it does also add some obfuscation. I converted a few more snippets of code similar to the above, and then attempted to convert the following from BOOST_LOCAL_FUNCTION( (void) (checkSolution)( (const StandardFormParameters&)(parameters) (const OperatorSpace&)(space) (const bind)((number_of_qubits)(number_of_operators)) ) ) { const unsigned int x_bit_diagonal_size = parameters.x_bit_diagonal_size , z_bit_diagonal_size = parameters.z_bit_diagonal_size ; checkCorrectOrdering( concatenateBoolMatricesVertically( list_of(space.getZMatrix().slice(x_bit_diagonal_size,number_of_qubits,0u,number_of_operators)) (space.getXMatrix().slice(x_bit_diagonal_size,number_of_qubits,0u,x_bit_diagonal_size)) ) ); checkCorrectOrdering( concatenateBoolMatricesVertically( list_of(space.getZMatrix().slice(x_bit_diagonal_size,z_bit_diagonal_size,0u,z_bit_diagonal_size)) (space.getZMatrix().slice(x_bit_diagonal_size,z_bit_diagonal_size,x_bit_diagonal_size,number_of_operators)) ) ); } BOOST_LOCAL_FUNCTION_END(checkSolution) forEachStandardFormSolution( number_of_qubits ,number_of_operators ,column_ordering_only_constraints ,checkSolution ); to forEachStandardFormSolution( number_of_qubits ,number_of_operators ,column_ordering_only_constraints ,phoenix::let (x_bit_diagonal_size = phoenix::bind(&StandardFormParameters::x_bit_diagonal_size,arg1) ,z_bit_diagonal_size = phoenix::bind(&StandardFormParameters::z_bit_diagonal_size,arg1) ,X_matrix = phoenix::bind(&OperatorSpace::getXMatrix,arg2) ,Z_matrix = phoenix::bind(&OperatorSpace::getZMatrix,arg2) ) [phoenix::bind(checkCorrectOrdering ,phoenix::bind(concatenateBoolMatricesVertically ,phoenix::bind( phoenix::bind(list_of ,phoenix::bind(&BoolMatrix::slice,Z_matrix,x_bit_diagonal_size,number_of_qubits,0u,number_of_operators) ) ,phoenix::bind(&BoolMatrix::slice,X_matrix,x_bit_diagonal_size,number_of_qubits,0u,x_bit_diagonal_size) ) ) ) ,phoenix::bind(checkCorrectOrdering ,phoenix::bind(concatenateBoolMatricesVertically ,phoenix::bind( phoenix::bind(list_of ,phoenix::bind(&BoolMatrix::slice,Z_matrix,x_bit_diagonal_size,z_bit_diagonal_size,0u,z_bit_diagonal_size) ) ,phoenix::bind(&BoolMatrix::slice,x_bit_diagonal_size,z_bit_diagonal_size,x_bit_diagonal_size,number_of_operators) ) ) ) ] ); Again I got pages of error messages (included in error-2.txt), and this time I gave up. Even if I could make this compile, the new version is definitely much more obfuscated than the old version. The main reason for this is that the phoenix::bind syntax requires lots of boilerplace when you have chained function calls, i.e. for expressions like A.B().C().D() or f()()()(). In fact, you can see how in the old version I called "space.getZMatrix()" several times (construction is cheap, and this is only a test) rather than creating a local variable Z_matrix to cache the result because I thought it looked nicer, whereas in the second version I cached it in a local variable because to do otherwise would have introduced lots of extra line noise. Also, it is worth mentioning in the documentation that you can't use just any variable names in a "let" block, and that to use the names _a-_z you need to import the namespace boost::phoenix::local_names. I know that this is mentioned in the previous section in the manual, but I had been expecting that all of the information I would need to use "let" would be in the "let" section so I jumped directly there. Having said that, I really do appreciate that one can declare one's own local variable names because otherwise the code above would have been *really* obfuscated. The documentation could be made more clear, though. My first attempt was to put the following lines inside the function just before I needed them: struct x_bit_diagonal_size_key; phoenix::expression::local_variable<x_bit_diagonal_size_key>::type x_bit_diagonal_size; struct z_bit_diagonal_size_key; phoenix::expression::local_variable<z_bit_diagonal_size_key>::type z_bit_diagonal_size; struct X_matrix_key; phoenix::expression::local_variable<X_matrix_key>::type X_matrix; struct Z_matrix_key; phoenix::expression::local_variable<Z_matrix_key>::type Z_matrix; This produced the cryptic error message in error-3.txt. At first I thought that the problem was that I needed curly brackets, but this didn't fix it, so I moved them outside the function, which worked. This was better than nothing, but it was a shame since I had wanted everything that was local to the function (that is, the outer function containing these nested functions) to be inside the (outer) function itself. Also, when I removed the curly brackets (since they were absent in the documentation) I got the even more horrific error message shown in error-4.txt. I then moved on to the following snippet of code: BOOST_LOCAL_FUNCTION( (void) (checkOMatrix)( (const IntMatrix&)(matrix) ) ) { vector<unsigned int> weights; BOOST_FOREACH(const unsigned int row, irange(0u,(unsigned int)matrix.height())) { unsigned int weight = 0; BOOST_FOREACH(const unsigned int col, irange(0u,(unsigned int)matrix.width())) { if(matrix(col,row).val() > 0) ++weight; } weights.push_back(weight); } if(!is_sorted(weights | reversed)) { ostringstream message; message << "Bad weight order:"; for_each(weights,lambda::var(message) << " " << lambda::_1); FATALLY_FAIL(message.str()); } } BOOST_LOCAL_FUNCTION_END(checkOMatrix) forEachOMatrixSolution( number_of_qubits ,number_of_operators ,bind(postWeightRowOrderingConstraintOnRegion,_1,4,_2,BoolVarArgs()) ,checkOMatrix ); I endeavored to translate this into Boost.Phoenix, but it was a bit painful and when I was almost done I realized that there was a macro (FATALLY_FAIL) at the end that probably would not expand into anything that Boost.Phoenix would recognize, so I gave up. At this point I was getting frustrated, and it looked like most of the code would likewise be so painful to translate that I couldn't bring myself to do it for the sake of science. I did, however, stumble on the following code: BOOST_LOCAL_FUNCTION( (void) (checkAllSolutions)( (auto_ptr<OperatorSpace>)(initial_space) (const unsigned int)(start_column) (const unsigned int)(end_column) (const unsigned int)(start_row) (const unsigned int)(end_row) (const bind)((checkSolution)) ) ) { for_each( generateSolutionsFor(initial_space) , bind(checkSolution , _1 , start_column , end_column , start_row , end_row ) ); } BOOST_LOCAL_FUNCTION_END(checkAllSolutions) forEachConstrainedRegion( number_of_qubits , number_of_operators , postConstraint , checkAllSolutions ); If there were ever a case where I wanted something like Phoenix, this was surely it! It was a serious waste to have to write all of that boilerplate code just because I couldn't figure out how to accomplish the same goal using Boost.Bind or Boost.Lambda. So I rewrote it as the following: forEachConstrainedRegion( number_of_qubits , number_of_operators , postConstraint , phoenix::for_each( phoenix::bind(generateSolutionsFor,arg1) ,phoenix::lambda(_a=arg2,_b=arg3,_c=arg4,_d=arg5) [phoenix::bind(checkSolution,arg1,_a,_b,_c,_d)] ) ); Wow, look at how beautiful that is! This is *exactly* the kind of code that I wanted to write, and Phoenix has finally let me write it that way. There's just a little problem... compiling it produces a 7,061 line error message (attached in error-5.txt). Perhaps I just made a simple mistake, but since there was no indication about what I got wrong I simply gave up. Feel free to let me know if you spot my mistake; for your information, my prelude included the lines #include "boost/phoenix/bind.hpp" #include "boost/phoenix/core.hpp" #include "boost/phoenix/scope.hpp" #include "boost/phoenix/stl/algorithm/iteration.hpp" namespace arg_names = boost::phoenix::arg_names; namespace local_names = boost::phoenix::local_names; using local_names::_a; using local_names::_b; using local_names::_c; using local_names::_d; using arg_names::arg1; using arg_names::arg2; using arg_names::arg3; using arg_names::arg4; using arg_names::arg5; so it could be that I made a mistake somewhere in there. In conclusion, I have found that Boost.Phoenix is simply too painful to use in practice for most cases where I have been using Boost.Local. Although it could potentially allow for very elegant code in many cases, it is so hard to figure out what you are doing wrong that it seems to be more trouble than it is worth. I am actually a little sad at having arrived at this conclusion, because the library looked incredibly cool and I was very excited about trying it out, and now I am just walking away from the whole experience feeling incredibly frustrated. Furthermore, even if I were an expert in it I have trouble seeing how in most of the places in my code it would result in code that was either more clear or easier to write. The Boost.Local code has extra noise at the beginning, but when the main body of the nested function contains lots of calls it is far more expressive to write the C++ code directly than to use lots of pheonix::bind functions to accomplish the same thing. This doesn't mean that I think that Boost.Phoenix is a bad library. Reading through the documentation I am absolutely amazed at how it can be used to create very expressive functions; the authors have clearly worked very hard on it and should be proud of their work. However, it simply cannot be treated as invaliding the need for something like Boost.Local, because for one to accomplish many of the same tasks in Boost.Phoenix as one can accomplish in Boost.Local one has to deal with a whole lot of extra mental effort and frustration, and the result at the end is often less expressive and clear (and potentially less maintainable) as it would have been if one had used Boost.Local since the body is no longer expressed in standard C++. I hope that you all find this informative! Cheers, Greg PS: The error-*.txt files are zipped up in error-messages.zip, since unzipped they were ~ 900k which caused this message to be rejected.

18 41

Interest in runtime concepts library.
by Germán Diago 07 Feb '11

07 Feb '11

Hi all. I'm implementing a framework to use runtime concepts for a project of myself. I would like to know the interest in that library. For now, I have a proof of concept working. The goal of the library, for now, is to be able to use objects of differente types without having any inheritance requirements and being nonintrusive. The code has my own standards for naming conventions, but that can be changed later when I have something ready for consumption. Now, to the metal. First, an example. Imagine we have two types of Devices. One of them is a DeviceC (which stands for Device Concept) and another, more refined one is PlugableDeviceC. With my library I can write something like this to create types that can hold classes that model both concepts: //Base concept class IDeviceC { public: virtual std::size_t getCapacityInMB() const = 0; }; template <class T> class DeviceCModel : public MovableModelBase<T>, public IDeviceC { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(DeviceCModel) virtual std::size_t getCapacityInMB() const { return this->getData().getCapacityInMB(); } }; //This is a DeviceC runtime concept typedef MovableConceptBase<IDeviceC, DeviceCModel> DeviceC; //Refined concept class IPlugableDeviceC : public IDeviceC { public: virtual void onOpen() = 0; virtual void onRemove() = 0; }; template <class T> class PlugableDeviceCModel : public IPlugableDeviceC, public MovableModelBase<T> { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(PlugableDeviceCModel) virtual void onOpen() { return this->getData().onOpen(); } virtual std::size_t getCapacityInMB() const { return this->getData().getCapacityInMB(); } virtual void onRemove() { return this->getData().onRemove(); } }; //Create concept class that refines DeviceC, The 3rd parameter is the concept it refines typedef MovableConceptBase<IPlugableDeviceC, PlugableDeviceCModel, DeviceC> PlugableDeviceC; Now we have two classes, DeviceC and PlugableDeviceC which can be used to hold any type that models that concept. Now, in my main program I implemented two classes, one of them modeling a PlugableDeviceC and another one modeling DeviceC: class LegacyDevice : NonCopyable { public: //This class models DeviceC concept typedef DeviceC ModelOfType; std::size_t getCapacityInMB() const { return 10; } }; class IpodDevice : NonCopyable { public: //This class models PlugableDeviceC concept typedef PlugableDeviceC ModelOfType; void onOpen() { std::cout << "Opening Ipod device" << std::endl; } void onRemove() {} std::size_t getCapacityInMB() const { return 32 * 1024; } }; operator-> is used to access the interface functions in an easy way. I also coded a Ref<SomeConcept> type which behaves like a C++ reference. It has implicit conversion to Base concepts. You can also cast to different concept types (more refined, like downcasting with inheritance). The return of a casting with a concept as a parameter always returns a Ref<SomeConcept>. You can use that reference with operator-> to access its members (in C++ I can't overload operator. , so I used operator-> to delegate functions). If you cast to a non-concept type (a concrete one) it will return a regular c++ reference. The result is something like this for now: int main(int argc, char * argv[]) { std::vector<DeviceC> devices; IpodDevice ipod; LegacyDevice legacy_device; devices.push_back(move(ipod)); devices.push_back(move(legacy_device)); //getCapacityInMB() is a function that you can use for DeviceC for (auto & device : devices) { std::cout << device->getCapacityInMB() << std::endl; } /*This is a downcast. Although a class that models plugable device is being * held inside a DeviceC, you can downcast to its right (most-derived) concept */ Ref<PlugableDeviceC> plugable_device = devices[0].castTo<PlugableDeviceC>(); //Implicit conversion to base concept Ref<DeviceC> device = plugable_device; //This is a function that just exists for PlugableDeviceC types. plugable_device->onOpen(); } There's still quite a bit of work to do: -Implement a Ptr<Concept> that behaves like a reference but that accepts null. -Make possible that a class models more than one concept. -Lots of testing. -Look at how runtime concepts behave with shared_ptrs to make a sensible decision about if a custom class like Ref should be implemented or a shared_ptr is good enough. Opinions are welcome. The code is attached. Tested with g++ trunk in linux.

3 8

Precompiled header support for clang is broken
by Bryce Lelbach 07 Feb '11

07 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Precompiled header support for clang-linux is broken (and has been broken for some time, in fact). It uses incorrect flags, among other issues. volodya: is it cool if I fix this? This is preventing clang-linux from compiling parts of Boost.Math. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1PNAkACgkQ9cB/V3/s9Ex+QgCeIRgNl4tK/K2LyrRbYEJmNBCY VwsAn1+ud9/EjPPyIsQEuVkREu/TvSQD =YlXu -----END PGP SIGNATURE-----

2 1

Re: [boost] [Boost-users] TTI library updated in the sandbox
by Dave Abrahams 07 Feb '11

07 Feb '11

At Sun, 06 Feb 2011 17:44:02 -0500, Edward Diener wrote: > > On 2/6/2011 4:14 PM, Dave Abrahams wrote: > > Couple o' things: > > > > On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener<eldiener(a)tropicsoft.com> wrote: > >> 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. > > > > FWIW, passing lambda expressions instead of metafunction classes is a > > trade-off: it's more expressive, but will lengthen compile times. For > > the implementation of a boost library, it's probably better to err on > > the side of speed. > > I could create metafunction classes for use instead of having the end-user use > placeholder expressions. Is that what you are suggesting for better compiler > speed ? It should be easy enough to do. I was influenced by your MPL book and > how easy it is for the end-user to use placeholder expressions. Maybe I misunderstood you. I took you to be saying that you were using placeholder expressions in the library's implementation. Supporting the user who wants to pass placeholder expressions is a good idea. Using metafunction classes in your library's implementation is also a good idea. > >> 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. > > > > Orthogonality in what sense? Duplicating functionality seems like the > > opposite of orthogonality. > > I am certainly willing and comfortable removing from the TTI library the > TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros, which just duplicates the > functionality of the corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF and > BOOST_MPL_HAS_XXX_TEMPLATE_DEF respectively. But let me first argue for why I > included them I don't have any argument with the choice to include them. > and what I mean when I say orthogonality: > > 1) The functionality is complete in a single library for what the library wishes > to do. In this case it is to introspect the inner elements of a type. I have > functionality to introspect member data and functions and static data and > functions, and some new functionality to introspect types ( checking for the > actual type ) and class templates ( specifying the exact template parameters ), > so it seemed natural for me that I should just as well also provide > functionality in general for types and templates, even if it was to provide the > exact same functionality which is in Boost MPL. This is more a situation of > completeness than orthogonality, but I felt that providing all of the > functionality the library promises was more important than duplicating the MPL > functionality. And of course the duplication code-wise is just minimal since I > am not recreating the macros which constitute BOOST_MPL_HAS_XXX_TRAIT_DEF and > BOOST_MPL_HAS_XXX_TEMPLATE_DEF but just using the MPL macros internally and > delegating to their already existing functionality. > > 2) For the nullary type metafunctions in my library I have corresponding type > and template functionality, to be used where the types are nullary > metafunctions. It would have felt odd, in the sense of the nullary type > metafunctions being orthogonal in functionality to the macro metafunctions, not > to also have the same type and template functionality in the macro > metafunctions. > > 3) I wanted the naming I used to be consistent with the other names in the > library. So instead of BOOST_MPL_HAS_XXX_TEMPLATE_DEF I have TTI_HAS_TEMPLATE, > instead of BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF I have TTI_TRAIT_HAS_TEMPLATE, > instead of BOOST_MPL_HAS_XXX_TRAIT_DEF I have TTI_HAS_TYPE and instead of > BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF I have TTI_TRAIT_HAS_TYPE. This sort of ease > of use, because the naming is consistent, is important to me when I think about > design for an end-user. Of course the documentation can tell the end-user to use > the already existing MPL macros to get type and template introspection instead > of providing my own set that does the exact same thing and just reuses the MPL > functionality. But I felt it more natural to provide my own. > > I hope you know that there is no attempt being made to create the TTI_HAS_TYPE > and TTI_HAS_TEMPLATE metafunction macros without acknowledging that I am just > lifting this from the MPL library. It is in the description when I post on this > NG and it is in the documentation in the Acknowledgments section. I would be > glad to put it anywhere else. At the same time I can remove it easily enough > from the TTI library but I think in that case it would be less complete as a > compile-time introspection library if I did. Sorry, that part was tl;dr'd. I'm just pointing out that using the term "orthogonal" doesn't make much sense on the surface here, and if it requires that much explanation to get it to make sense, maybe you should choose a different word. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[Boost.MPI] Native MPI implementation not working with Boost MPI
by Arpan Sen 06 Feb '11

06 Feb '11

Hello Everyone, I have been trying to use Open MPI v1.5.1 with Boost MPI v1.45.0 but there are linkage issues when I am trying to build the final executable. Has anyone used Open MPI with Boost MPI? If yes, what have been your versions? How did you build Open MPI sources -- did you use any specific options? The same problem happens again when I try use Microsoft MPI from their HPC Cluster Pack. Also I keep getting unresolved symbols like _ompi_mpi_char, _ompi_mpi_byte during the linking. Any idea what's causing this? Any help appreciated, Arpan

3 2

Iostreams Code converter bug
by Eddie Carle 06 Feb '11

06 Feb '11

I've been trying to patch up a bug in iostreams::code_converter but have run in to a lot of trouble understanding what a lot of the macros do. First I'll summarize what the bug is. The documentation for iostreams::code_converter states that the constructor code_converter(const Device& dev, std::streamsize buffer_size = default_value); uses the buffer_size parameter to create a buffer that buffers up data before sending it out along its way. What I've noticed is that somewhere inside the macros that generate the constructors the value is discarded or sent somewhere it shouldn't be going. This means that the default value is always used. For my implementation, 128 bytes. Here is what I've tracked down so far. The code_converter constructors are generated at boost/iostreams/code_converter.hpp:275 which calls the BOOST_IOSTREAMS_FORWARD macro at boost/iostreams/detail/forward.hpp:44. The lines 45-56 make sense to me but 57-64 is where I start to get lost. An interesting thing is that if I comment out the stuff on lines 57-64, things work perfectly. The value that I pass to buffer_size is used and the buffer is exactly the size I want it to be. I'm sure some other facility of iostreams gets broken though. What it seems is that the constructors defined on lines 45-48 somehow get "replaced" or something along those lines by the BOOST_IOSTREAMS_FORWARDING_CTOR macro. Although there is commenting explaining what BOOST_IOSTREAMS_FORWARD does, there is no comments explaining what BOOST_IOSTREAMS_FORWARDING_CTOR is and what all that macro code actually does. I can't run it through a debugger so I've hit a wall as far as fixing this. Can anyone offer any insight as to what is going on here? What is this BOOST_IOSTREAMS_FORWARDING_CTOR macro? -- Eddie Carle

2 3

[context] for Mac OS X (and other platforms) via libtask
by Daniel Larimer 06 Feb '11

06 Feb '11

I have put some code up on github that uses libtask's implementation of asm based context switching as a backend implementation of boost::context. I have verified that it allows me to use Boost.Fiber on Mac OS X. I suspect that my changes would allow Boost.Context to work with arm, power pc, and any other platform supported by libtask. The protected_stack allocator does not seem to work on OS X, so I switched to using malloc/free. I wonder if this is the reason why the ucontext implementation was not working on OS X either. Considering ucontext on Mac OS X is deprecated and asm 100x faster, I am not sure it is worth while to get the ucontext implementation working. I suspect that the correct solution would be to modify the code in libs/context/src/libtask to implement the fcontext pattern, but I have no experience with asm. https://github.com/bytemaster/boost_context_osx/tree/master/libs/context/src

3 3

[random] geometric_distribution backwards compatibility
by Steven Watanabe 05 Feb '11

05 Feb '11

AMDG Over the last year I've been (slowly) updating Boost.Random to match the new standard. Unfortunately I just hit a problem that I don't have a good solution for. In the standard, the geometric_distribution is defined as $p(i) = p(1-p)^{i}$, with i >= 0. In the current Boost.Random code it is $p(i) = (1-p) p^{i-1}$, with i >= 1. The definition in the standard makes more sense, but I don't want to introduce a breaking change. I can see two options here: * Leave the implementation alone and put a big warning in the documentation saying that the behavior doesn't match the standard. * Since I'm also moving things into namespace boost::random, I can use the new definition and leave a version with the old behavior in namespace boost instead of having a using declaration. I'd still have to add a warning that boost::geometric_distribution isn't the same as boost::random::geometric_distribution. Neither one is particularly appealing. Any thoughts? Better ideas? In Christ, Steven Watanabe

5 10

Minimal recalculation in formulas, using boost::proto
by remi.chateauneu＠gmx.de 05 Feb '11

05 Feb '11

Hi, I have a program which needs to recalculate a formula of independant arguments (doubles or integers). These arguments can be updated at any time. This math formula is expensive to evaluate, and performance-wise it is worth, depending of which input argument changes, to recalculate only a part of the evaluation tree. Here is a simplistic exemple: z = sin(x+1)*cos(y-3) When the argument x changes, it is not necessary to recompute cos(y-3). I wrote a prototype lib to do this, where expressions are made of cells wrapping operators, input cells and intermediate values, plus the list of depending cells. When the value of an argument, an input cell, changes, the lib just builds the topologically sorted list of dependant cells, and reevaluates them, performing what I think is the minimum recalculation (Excel style). (An alternate strategy is to let each data update invalidate its cell and its descendants - the actual calculation being done only when needed). Instead of reinventing the wheel, my thought was to try to use boost::proto for this. Does it make sense ? Any code change needed please ? Thanks

2 1

[uuid generator]
by Sid Sacek 05 Feb '11

05 Feb '11

I searched for, but did not locate, a GUID generator amongst the library files. Doesn't anybody here have a need for such a utility? I can't possibly be the only C++ coder who needs it. -Sid Sacek

2 2

[type_traits] extension has_operator_xxx - conforming to coding guidelines for ICE
by Frédéric Bron 05 Feb '11

05 Feb '11

I have tried to comply with the coding guidelines for integral constant expressions (http://www.boost.org/development/int_const_guidelines.html) I have been able to comply with most of them but still have the following issue: > Don't use dependent default parameters for non-type template parameters. > For example: > > template <class T, int I = ::boost::is_integral<T>::value> // Error can't deduce value of I in some cases. > struct foobar; > > Rationale: this kind of usage fails for Borland C++. Note that this is only an issue where the default value is dependent upon a previous template parameter, for example the following is fine: Is there any known workaround for this? In my case, int is replaced by bool but I think it is the same issue. Frédéric

8 11

[mpl] Using apply with gcc error
by Edward Diener 04 Feb '11

04 Feb '11

Compiling this code with gcc: #include <boost/config.hpp> #include <boost/mpl/apply.hpp> template < class MF, class T > struct myMF : boost::mpl::apply<MF,T> { BOOST_STATIC_CONSTANT(bool,value=type::value); }; int main() { return 0; } Gives: "gcc.compile.c++ ..\..\..\bin.v2\libs\tti\test\TestMFHasTypeMFC.test\gcc-mingw-4.5.2\debug\TestMFHasTypeMFC.o TestMFHasTypeMFC.cpp:18:5: error: 'type' has not been declared "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -Wno-variadic-macros -I"..\..\.." -I"C:\Programming\VersionControl\boost" -c -o "..\..\..\bin.v2\libs\tti\test\TestMFHasTypeMFC.test\gcc-mingw-4.5.2\debug\TestMFHasTypeMFC.o" "TestMFHasTypeMFC.cpp"" MF is a metafunction with a boost::mpl::bool_ type. Since I am using apply using metafunction forwarding, why does gcc tell me that 'type' has not been declared ? Is this a bug in gcc or in my simple code above ? The error occurs with all flavors of gcc, but VC++ 8,9,10 gives no error.

5 10

Re: [boost] Case study: Boost.Local versus Boost.Phoenix
by Pierre Morcello 04 Feb '11

04 Feb '11

AM, Hartmut Kaiser wrote: > Just my 2c: I find the proposed macro syntax to be > ugly, unreadable and very difficult to associate with > the corresponding function definition. Gregory Crosswhite wrote: > I thought so at first, but it didn't take very long to get > used to it. Hello, I have written the first implementation of the boost local function a year and a half ago, and later send it to Lorenzo, since he began later to work on the subject too. (Please note that he redid everything completely differently than my first implementation. The current Boost.Local is 100% his work as far as I know). Anyway, I made the first implementation with several different macro frontend, one of the simplest call being : void TestBreakable3::example1() { // USAGE : int i = 0; int j = 0; // Seems easiest way to handle 'This' TestBreakable3* This = this; NESTEDFUNCTION((i)(j)(This)) { ++j; // we manipulate a reference to j // I can add another nested function. NESTEDFUNCTION((i)(j)(This)) { j--; i++; // calling private member is working // (I use defect 45, which has a DR status...) This->otherFunction(j); }NESTEDFUNCTION_END if(i == 1) return; ++i; }NESTEDFUNCTION_END; assert(i == 1); assert(j == 15); } Adding the function name, and making it a functor would have been pretty easy too. As a consequence, concerning the current Boost.Local, adding another macro like BOOST_LOCAL_FUNCTION_AUTO((functionName)(i)(j)(k)) { // do what you want here with i,j,k } BOOST_LOCAL_FUNCTION_AUTO_END(functionName) seems very feasible from my point of view. I wanted to wait later (eg the library review) to see if there were any ouside interest for this auto-macro (not only me), and if I could contribute to this element. BTW I consider that writing a local struct is very easy to read, but with a macro like the one I describe, things are also very straight forwards. This can save time and lines if you use a lot of local functions. Concerning the interest for 'macro for local function', one year and a half ago, a few boosters expressed interest towards it. Some other were not interested for the same reasons already expressed in this thread. So there is no need to feel lonely, whatever your point of view is :-) ! Best regards, Pierre PS : I wanted to thank Gregory Crosswhite for the very detailed examples concerning the differences between boost.local and boost.phoenix. It is very interesting.

1 0

new test macros
by Thorsten Ottosen 04 Feb '11

04 Feb '11

Dear Boost.Test Maintainer, I think it would be useful to add the following macros to Boost.Test: #define BOOST_CHECK_EQUAL_RANGE( Rng1, Rng2 ) \ BOOST_CHECK_EQUAL_COLLECTIONS( boost::begin(Rng1), boost::end(Rng1), \ boost::begin(Rng2), boost::end(Rng2) ) And it would also be nice to have BOOST_CHECK_CLOSE_RANGE/COLLECTION. Thanks in advance -Thorsten

2 1

[1.46.0] Release schedule?
by Beman Dawes 04 Feb '11

04 Feb '11

John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes. How long should we allow between the time the beta actually becomes available and closing branches/release prior to release? Should we adjust the 1.46.0 schedule accordingly? --Beman

4 7

Open-MPI with Boost.MPI
by Arpan Sen 04 Feb '11

04 Feb '11

Hi, I would like to know if there is any recommended version of Open-MPI to be used with Boost.MPI. I was looking for existing libraries for Boost.MPI for download but could not find any -- if anyone has any pointers to the same that would be really very appreciated. Currently, I have Open-MPI v1.5.1 in my XP box. Thanks and Regards, Arpan

1 0

Re: [boost] [Git] Moving beyond arm waving?
by Brian Wood 04 Feb '11

04 Feb '11

Belcourt, K. Noel: On Feb 3, 2011, at 1:48 PM, John Wiegley wrote: > >> Part of the reason we're putting this much effort into it is that we >> want a >> process which split Boost up into submodules during the migration >> process, >> while preserving as much history within each separate submodule as >> possible. >> There's just no tool out there that does that right now. So since >> we needed >> to write a tool anyway, why not solve the whole problem. > > > I haven't been following this closely so ignore if you've already > discussed / decided this. > > I'd much prefer to leave the repo structure unchanged and migrate > directly into git "as is". Restructure the repo into submodules after > we've made the transition to git. It will be much easier to > restructure the repo with everything already in git. There's two > upsides, we lose no commit history and it only perturbs one aspect at > a time (first give people chance to use same repo layout using new > tool, followed by a restructure of the repo into submodules using the > new tool). I worry about perturbing too many variables at once. I agree. Attempting what's being proposed is much harder than if it were broken up like this. I hope there will be a patient and experimental spirit regarding these proposals. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

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

04 Feb '11

Argh, I just submitted this but realized that I left a debug line in the code before submitting the patch. Here is everything all over again proper. Terribly sorry for the confusion. 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. ********** OUTPUT BEFORE PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 13 characters. ********** OUTPUT AFTER PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream SinkDev::write(): Recieved 8 characters. main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 5 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. ********** END ********** Notice that input functionality doesn't change but the output functionality does. The one cause for concern to me is that for some reason upon deconstruction the new flush() function is called a bunch of extras times. I'm not entirely sure why this is happening. -- Eddie Carle

1 0

Patch to make code_converter flushable
by Eddie Carle 04 Feb '11

04 Feb '11

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. ********** OUTPUT BEFORE PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 13 characters. ********** OUTPUT AFTER PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream SinkDev::write(): Recieved 8 characters. main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 5 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. ********** END ********** Notice that input functionality doesn't change but the output functionality does. The one cause for concern to me is that for some reason upon deconstruction the new flush() function is called a bunch of extras times. I'm not entirely sure why this is happening. -- Eddie Carle

1 0

[1.46.0][units] Tests failing on all non-Windows platforms
by Beman Dawes 03 Feb '11

03 Feb '11

http://beta.boost.org/development/tests/release/developer/summary.html Please fix or markup immediately. Thanks, --Beman

2 2

Is anyone besides me having trouble uploading to the vault?
by Marshall Clow 03 Feb '11

03 Feb '11

I have been unable to do so for almost a month. -- 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 3

Nonstandard instantiation of std::initializer_list
by Matus Chochlik 03 Feb '11

03 Feb '11

Hi, I'm working on a factory generator tool and I would like to support types with initializer-list constructors, typically containers. There are several possibilities how to do this, but the otherwise most straightforward and generic way, requires non-standard construction of std::initializer_list<T> instances. I have the following working implementation for GCC (a complete, very simplified example showing the usage that can be compiled with g++ 4.5 with --std=c++0x is in the attachment): template <typename Element> class initializer_list_holder { private: typename std::initializer_list<Element>::iterator data; typename std::initializer_list<Element>::size_type size; std::vector<Element> elems; void init(void) { data = elems.data(); size = elems.size(); } public: initializer_list_holder(std::vector<Element>&& tmp) : elems(std::move(tmp)) { init(); } template <typename StdRange> initializer_list_holder(const StdRange& src) : elems(src.begin(), src.end()) { init(); } operator std::initializer_list<Element>() const { return reinterpret_cast< std::initializer_list<Element> const & >(*this); } }; The template above stores the elements to be traversed by the initializer-list's iterators in a vector and depends on the GCC's implementation of the initializer_list. The plan is to do something similar for other implementations of initializer_list by other compilers and switch between them via the preprocessor. (Yes, I know that vector<T>::data() is a non-standard extension, and on platforms where it is not available the array of elements would be managed directly by the initializer_list_holder) My questions are: Is this is good idea ? Do you foresee some reason for any compiler to use another implementation of std::initializer_list, besides the "obvious" listed in n2672 (pair of pointers / pointer + size), that wouldn't work with the reinterpret_cast in the conversion operator ? Should I look at the other possibilities to implement the factory? TIA for your insights. Best, Matus

2 2

[build] Regression tests failing across the board
by Beman Dawes 03 Feb '11

03 Feb '11

The build regression tests are still failing across the board. http://beta.boost.org/development/tests/trunk/developer/summary.html http://beta.boost.org/development/tests/release/developer/summary.html This is not acceptable. Having tests that always fail requires viewers to make an unwanted mental exception and sends the wrong message to other developers. The tests should either be fixed or marked up. If they aren't really tests at all, but are just informational like some in the config library, they should be changed to return 0 and "<test-info>always_show_run_output" should be added to the Jamfile. If the build test failures can't be cleared from the reporting, the tests themselves should be removed. --Beman

2 3

async messaging
by Scott Woods 03 Feb '11

03 Feb '11

Hi, This is a slightly different post. I am hoping for some contact details for a handful of Boosters that showed some interest in a previous thread I started with the same subject line. I have taken that same work and developed it a lot further. I am quite confident that Boost will not be interested and I did not wish to pollute the list with something already rejected. But this list is also the only way to those few that might be interested. If those folks are out there (and its ok with the Boost moderators) and still listening I can be contacted at "scott dot suzuki at gmail dot com". Keywords: zeroconf, auto-detection, advanced connection models, specification language, network APIs, network protocols, state machine dispatch. Regards, Scott

1 0

[1.46.0 beta 1] [SourceForge] Testing beta from SourceForge (was: mirror sync system broken)
by Joachim Faulhaber 02 Feb '11

02 Feb '11

2011/2/1 Beman Dawes <bdawes(a)acm.org>: > On Tue, Feb 1, 2011 at 3:55 PM, Beman Dawes <bdawes(a)acm.org> wrote: >> The SourceForge mirror sync system has broken down. Other projects are >> affected, not just Boost. >> >> The files up there are probably good and the download problems should >> clear once the mirrors are synced again, the S/F folks say. >> >> Some projects say their files are back online, but as of a few minutes >> ago the Boost stuff still seemed broken and/or running so slowly as to >> be effectively broken. > > SourceForge downloads seems to be working much better. I did a > download of the .7z file and got the correct checksum. A second mirror > has come back online and the download speed was reasonable. I have successfully downloaded boost_1_46_0_beta1.7z from sourceforge and built it on ms-windows7 with msvc-9 and 10. I checked the general documentation roughly and ICL docs in more detail and did some tests. Everything worked well so far. The only issue I found was this: The link to "Release History" in boost_root/index.html: http://www.boost.org/users/history/version_1_46_0 does not exist: Error 404 (not found) Joachim

5 6

Re: [boost] [Review] Phoenix V3: mini-review starts February 19th
by Eric Niebler 02 Feb '11

02 Feb '11

(Cross-posting for now, but please follow up on boost-users only.) On 2/3/2011 12:06 AM, Robert Ramey wrote: > I've been studying proto/fusion/phoenix. Becoming familiar with this stuff > takes quite an effort. It's quite interesting though. And it seems ideal > for a project I want to do. But I do have one question: > > phoenix/Function objects > Functional/ > Proto/ > PolymorphicFunctionObject > ? > > All seem to address function objects. There seems to be a lot of > overlap and it's not clear to me which I should be using for what. > That is, each library seems to address function objects from a > different perspective, but there is not summary which contrasts > them. I need a "function object library Decoder Ring". Are > there any documents which would help me out? Lots of libraries define function objects or tools for creating them. That's true for Phoenix and Proto (both tools for creating function objects). Phoenix helps you define general purpose function objects in-place (lambdas). Proto helps you define function objects specifically for manipulating expression trees (grammars w/ semantic actions). PolymorphicFunctionObject is a concept that function objects must model if they are to be usable with boost::result_of. Function objects created by Phoenix and Proto all model PolymorphicFunctionObject. I don't know anything about boost/functional. HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [Git] Moving beyond arm waving?
by Ivan Le Lann 02 Feb '11

02 Feb '11

----- "Beman Dawes" <bdawes(a)acm.org> a écrit : > > Comments? > If some Boost developper find following thoughts useful, he should feel free to add them on this page: As a humble Boost user, I would appreciate to see more or less official distributions. Four examples: Boost + Accepted (pending) + Managed (has a review manager) + Candidates (sandbox pre-review maturation, probably a mess) I think this could make the maturation, review and integration process more structured and visible. I'm not suggesting to change Boost integration process, but only to have VCS be a better mirror of it than current sandbox. I fail to see how current combination of both central VCS and monolithic code base can easily lead to that, without burdening Boost itself. I'm not a VCS expert, but I thought DVCS forks could model this. Ivan

1 0

Process discussions
by Vladimir Prus 02 Feb '11

02 Feb '11

As of recent, we had quite a lot of discussion about process. In true open-source spirit, it was a fairly open discussion, with everybody offering their perspectives and experience. However, while we surely learned many things, it does not seem like we're going anywhere. For a quick experiment, I tried to assess whether the discussion actually reflects the needs of Boost developers, so I created a table of Boost developers sorted by the number of commits in 2010. It is here: http://tinyurl.com/5suwfbn It seems that 5 top Boost comitters did not participate much in recent discussions. And going down the list, it seems like many of active developers did not say anything, while most of discussions is fueled by folks who don't commit much. Of course, everybody can offer valuable thoughts, but if the goal is to fix things for Boost developers, it would make sense if developers say that needs fixing, as opposed to other people doing it for them. Maybe I suggest that for some time, we outright ban freeform discussion about process, and instead, we restrict them to threads started by a Boost developers and saying this: "I am maintainer of X, and had N commits and M trac changes in the last year. I most hate P1, P2 and P3. I would propose that we use T1, T2, and T3 to fix that". Then, everybody could join to suggest better way of fixing P1, P2 and P3 -- without making up other supposed problems. Thoughts? -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

18 53

Kernel-level threads
by Tibor Szaboky 02 Feb '11

02 Feb '11

Does Boost support Kernel-level threads?

3 2

Need help identifying present and past Boost authors
by John Wiegley 02 Feb '11

02 Feb '11

Hello, I'm working on a repository convertor which must translate SVN author ids to fullname/e-mail pairs. This has already been done to some extent by Brad King, but I've found that several authors remain unidentified. I'm sending this e-mail to ask the Boost community if they could identify any or all of the authors at the following URL whose name is Unknown. Also, if you can provide spelling corrections or more updated e-mail information, please let me know by e-mail. The current authors file is here: https://github.com/jwiegley/subconvert/blob/master/doc/authors.txt I'll update the file as corrections are provided. Thank you, John Wiegley BoostPro Computing http://www.boostpro.com

6 6

[Review][Move] Boost.Move Review Results
by Michael Caisse 02 Feb '11

02 Feb '11

---------------------------- Executive Summary ---------------------------- Ion Gaztañagas' Boost.Move library was reviewed from May 10th, 2010 through May 24th, 2010. The original review manager was OvermindDL1 who later went missing. Eleven individuals joined the discussion with the author. Six reviews were submitted: - 5 reviews ACCEPT - 1 review CONDITIONALLY ACCEPT Ion indicated he would meet the "conditional requirements" which easily satisfies a community vote of: Boost.Move library ACCEPTED ---------------------------- Overview ---------------------------- The Boost.Move library is a highly anticipated addition to the Boost collection. The primary motivation is to introduce usable move functionality in "a portable syntax between C++0x and C++03 compilers"; however, as Vicente Botet articulated, "Most people think that this is an emulation library, but it is more than that as it implements most of the C++0x Move semantics classes and functions." Reviewers' comments: - "This library is long overdue!" [Terry Golubiewski] - "The tutorial is well written." [Vicente Botet] - "Compared to my adobe based move implementation, I think yours is superior." [Daniel James] - "There is a lot of ingenuity in making the move emulation work, and Ion has made it very accessible and managed to make differences between C++03 and C++0x vanish behind macros and free functions." [Jeff Hellrung] An active discussion included: - exposing boost::rv<T> publicly - The merits of fully defining requirements of boost::rv<T>& - Duplicated functionality found in MPL and Type Traits - The necessity for two emulation modes - The merits of macros - Library author usage of Boost.Move - Non-throwing move constructors - Various potentially useful type traits - Other move implementations While it is unfortunate that a timely review result was not published, it did provide an opportunity to discuss some of the concerns raised in the review with actual users of the library. One such concern was the "two emulation modes." At some point in the discussions it became classified as "Safe vs. Fast". When coined with that bias "safe" would be the preference; however, further investigation and inquiries of actual users showed the "fast" version is perfectly acceptable as the default. Additionally, "safe" is a misnomer considering that one mode is not any safer than the other. Each mode has benefits and limitations as enumerated by Ion in the documentation and review responses. The past six months of use would indicate that defaulting to the "fast" version, as preferred by Ion, is in practice a good decision. Thank you Ion for this well thought out and excellent submittal. Thank you reviewers for expending time and energy to further Boost. Without those who are dedicated to review submitted libraries, the entire process and Boost itself falls apart. The community will benefit from the effort each of you put into this library. Best regards - Michael Caisse ---------------------------- Summary of changes ---------------------------- The following changes are planned based on discussions from the review: -- Conditional Acceptance -- 1. "Two Emulation Mode" documentation typos must be resolved. The descriptions, requirements and limitations need to be perfectly clear for the end user. -- Other Issues -- 1. The class rv should be public and documented. 2. is_movable should be renamed and the documentation clarified. It should only be enabled in C++03. A possible alternative name is has_move_emulation_enabled. 3. Nearly all reviewers voiced a preference that the move library should use existing functionality from MPL and TypeTraits libraries. While on one hand this creates a dependency between move and other libraries it results in reuse of accepted and well tested libraries. If a non-coupling option is also provided, it should not be the default. 4. Additional traits discussed. Resolution: add to TypeTraits library as actual use-cases are found. 5. Provide a boost/move.hpp that includes boost/move/move.hpp 6. Document the interaction of the two emulation modes. 7. Include example for making a container "movable". 8. Two emulation modes - Ion was hopeful that reviewers would have a uniform opinion that would result in a single mode. The trade-offs identified by Ion in the documentation were apparent to all reviewers; however, different conclusions were drawn and consensus was not met. The granularity of control was a common issue with nearly all reviewers. Therefore, keep both emulation modes with Optimized as the default and the granularity of control at or more "local level" than the macro provides (class level). 9. emulation_limitations.html: s/overaloading/overloading/ 10. Fully qualify enable_if ( ::boost::emable_if ) 11. Optimized version of forward should use identity so it will not try to deduce T. 12. Make sure required headers are mentioned for tutorials. 13. is_class in is_movable template< class T> struct is_movable : mpl::and_< is_class<T>, mpl::not_< is_rvalue_reference<T> >, is_convertible< T, rv<T>& > > {}; - or - another solution to is_movable problems with references. 14. On throwing move constructors, Ion should follow as close to the standard's behaviour as possible. This can be revisited after the initial release since it is a performance optimization. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 7

[1.46.0 beta 1] [SourceForge] SourceForge mirror sync system broken
by Beman Dawes 01 Feb '11

01 Feb '11

The SourceForge mirror sync system has broken down. Other projects are affected, not just Boost. The files up there are probably good and the download problems should clear once the mirrors are synced again, the S/F folks say. Some projects say their files are back online, but as of a few minutes ago the Boost stuff still seemed broken and/or running so slowly as to be effectively broken. --Beman

1 1

Re: [boost] boost::interprocess boost::interprocess xsi_shared_memory
by Ion Gaztañaga 01 Feb '11

01 Feb '11

El 12/01/2011 19:48, Daniel Neuberger escribió: > Hi Ion, > > I saw that you made a commit for XSI shared memory (https:// > svn.boost.org/trac/boost/changeset/67451) Could you confirm whether > it is ready to use? We're using Boost 1.43; do you think applying > that changeset would be sufficient to be able to use XSI shared > memory? Yes, I think it will be enough. > Lastly, do you think these changes will make it into the > upcoming 1.46 release? Yes, I see tests are ok. It seems that in FreeBSD 64 we have some ENOSYS error ("function not implemented"), but there is not much we can do if the platform does not support it ;-) I will merge to release ASAP, please it would be nice if you could test these new XSI functions to get more feedback. Best, Ion

2 3

Re: [boost] [Boost-users] [1.46.0 beta 1] [SourceForge] SourceForge mirror sync system broken
by Dean Michael Berris 01 Feb '11

01 Feb '11

On Wed, Feb 2, 2011 at 5:08 AM, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > Beman Dawes wrote: > >> The SourceForge mirror sync system has broken down. Other projects are >> affected, not just Boost. >> >> The files up there are probably good and the download problems should >> clear once the mirrors are synced again, the S/F folks say. >> >> Some projects say their files are back online, but as of a few minutes >> ago the Boost stuff still seemed broken and/or running so slowly as to >> be effectively broken. > > I am sure we can host 1.46 beta off google for the time being, here: > > http://code.google.com/p/boost/ > > Let me know if you want me to upload packages there, or whether you want > to do that yourself. > Interesting. Has anybody considered moving the current Subversion repository to code.google.com as well? I'm positive that especially now that they accept pretty much any OSI approved-license project there, maybe we can take the SVN administration issue and move that to Google's hands instead? Thinking-out-loudly-as-per-usual-yours'ly -- Dean Michael Berris about.me/deanberris

1 0

Re: [boost] Need help identifying present and past Boost authors
by Oliver Kowalke 01 Feb '11

01 Feb '11

> I'm working on a repository convertor which must translate SVN author ids > to fullname/e-mail pairs. This has already been done to some extent by > Brad King, but I've found that several authors remain unidentified. > > I'm sending this e-mail to ask the Boost community if they could identify > any or all of the authors at the following URL whose name is Unknown. > Also, if you can provide spelling corrections or more updated e-mail > information, please let me know by e-mail. The current authors file is > here: olli Oliver Kowalke k-oli(a)gmx.de

1 0

[trac] The no-spam solution..
by Rene Rivera 01 Feb '11

01 Feb '11

Just thought I'd point out something that at least the people who receive the trac emails may have noticed... A lack of SPAM in the past few days! This the result of various tweaks to the SPAM filtering to the point where it is almost impossible to post automated SPAM. And it's very hard to post manual SPAM. But there is a drawback.. As a result of the tweaking it's also more likely that people will be accosted by a CAPTCHA challenge. Usually this is enough to validate a trac post. But there will be times when even the CAPTCHA is not enough to overcome the preceived SPAMiness of the post. Feel free to post here if you run into one of those cases. Although looking at the logs, I haven't seen one in the past few days either. Enjoy.. The SPAM free experience :-) PS. And of course, if you find some old SPAM please point it out ASAP for quick eradication. -- -- 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 5

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 01 Feb '11

01 Feb '11

[[ whoops! I double tapped the send keyboard shortcut on a foreground message and sent this before I'd finished cleaning it up. Apologies for the near-double post. The last few paragraphs are different ]] I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. As a retired FreeBSD committer (and a boost-digest lurker since 1.33), I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, but the use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage A schedule and handoff of hats/responsibilities for each of the branches is pretty well documented and is now time driven (it used to be feature driven, which didn't work as well as they'd hoped): http://www.freebsd.org/releng/ The way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message, commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html The above has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html A 'Reviewed by' commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag otherwise the commit will fail. If someone commits with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. Unlike boost, FreeBSD uses an abridged commit message that doesn't include the actual diff itself (if you're a committer, then you see the diffs to areas of the tree that you subscribe to). I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list and the diffs can sometimes be massive, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Links to each of the diffs is useful and lets people click through if reviewing the diff is of interest. I can't stress the organizational difference and peer pressure a widely used commit mailing list brings about. There are other bits worth noting, acls apply to different parts of the tree (doc commit bits and a doc-re@ hat vs a src-re@ hat and even ports@), but the mailing list/commit reviews and branching/merging are the biggies that I wanted to point out. Branching trunk in to a boost_1_46_prerelease branch three weeks before the release (or some sane interval) so that people can fix up the code seems like a pretty painless adjustment, then snapping/releasing boost_1_46_0 when the pre-release is ready. Post-1.46 release fixes could go in to 1.46.0 and (heaven forbid), maybe even a micro version with specific fixes for the .46 minor version. PostgreSQL ships with a contrib/ directory of "soon to be" or "possible candidates for being a core component" which serves the same purpose as FreeBSD's ports structure. This gets yet-to-be finalized modules out in the wild and helps garner interest. PostgreSQL's autovacuum went from being a fringe project to a contrib/ module and a core feature in 2 minor releases because of the huge interest in its use/adoption. Boost.Log or Atomic or any of the other "we all really want this but it's not quite finalized" modules seem like ideal candidates for inclusion in such a directory because it could generate additional interest/eyes. A contrib/ or proposed/ would go a long way towards keeping boost lean-ish, too. At present it seems like boost-*.tar.bz2 is on track to including boost/kitchen/sink.hpp and boost/bath/water.hpp and that's something that is a bit concerning to me on the long-term scale. Me personally, I keep running 'svn ls http://svn.boost.org/svn/boost/branches/' to see if a branch pops up for release but I haven't yet. The structure on the server is largely there, but it the svn tree looks pretty disorganized with lots of legacy clutter so it doesn't look like it's being used well. And lastly re: VCSs, lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask on or offline (CC if online since I'm a digest subscriber). Cheers. -Sean -- Sean Chittenden sean(a)chittenden.org

12 46

Trac administration
by Vladimir Prus 01 Feb '11

01 Feb '11

[Apologies in advance if I have asked this question before and forgot the answer.] Suppose I want something to be changed in Trac that requires admin access. Whom do I contact? Can this contact be published somewhere? I've tried to file an issue using "trac/subversion" component, but it got auto-assigned to Doug Gregor, who, I presume, has more interesting tasks right now ;-) Thanks, Volodya

2 1

Functors created by boost::bind and move semantic
by Marat Abrarov 01 Feb '11

01 Feb '11

Hi, Boost Users and/or Developers. Does anybody know why functional objects created by means of boost::bind have no move constructors? It would be rather useful especially when such functional objects consist of some smart pointers (like boost::shared_ptr). For example, move constructor of boost::shared_ptr is very light (comparing to its copy constructor) - it doesn't use any CAS at all (which is the main overhead of boost::shared_ptr). May be someone know the reason of move constructor absence or maybe someone know any plans of implementing it. Regards, Abrarov Marat.

2 1

[context] review manager wanted
by Oliver Kowalke 01 Feb '11

01 Feb '11

I'd like to ask who wants to be the review manager for boost.context? Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

[Review] Phoenix V3: mini-review starts February 19th
by Hartmut Kaiser 01 Feb '11

01 Feb '11

Hi List, Phoenix V3 is nearing its completion. With the port to Boost.Proto we tried to address the outstanding issues of the review and would like to announce that the mini-review will start on February 19th. Feel free to preview the code at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ and the documentation at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html We are currently occupied with code cleanups and finishing of the documentation. The code itself is in a stable condition, feel free to make yourself comfortable with this new library. Regards Hartmut Phoenix V3 Review Manager --------------- http://boost-spirit.com

4 9

Boost Modularization
by Robert Ramey 01 Feb '11

01 Feb '11

I believe that eventually we will want have feel the need to address some issues in directory structure, namespaces etc. However, I'm thinking that it's premature to do anything but set a few policies for new libraries and submissions. The only specific one that comes to mind is: a) libraries should not place any header files directly in the boost directory or in the boost namespace. The only exception would be a "convience header" in the boost directory which would include the headers in the library directory. b) The library name should be the same as the namespace name and the same as the subdirectory name in the boost directory. .... Robert Ramey

6 5

Re: [boost] [string] proposal
by Ivan Le Lann 01 Feb '11

01 Feb '11

----- "Patrick Horgan" <phorgan1(a)gmail.com> a écrit : > On 01/28/2011 09:59 AM, Dean Michael Berris wrote: > > On Fri, Jan 28, 2011 at 7:20 PM, Dean Michael Berris > > <mikhailberis(a)gmail.com> wrote: > >> So the interface I was thinking about (and suggesting) is a lot > more > >> minimal than what rope or std::string have exposed. I think when I > do > >> finish that design document (with rationale) it would be clear why > I > >> would like to keep it immutable and why I would prefer it still be > >> called a string. > >> > >> Let me finish that document -- expect something over the weekend. > :) > >> > > And I stopped before I write too much -- the initial version is > > already up: > https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > -- I'll give it more information and the actual interfaces and > > implementation as soon as I get some Z's. :) > > > You mention that your string is thread safe by design, but you only > solve the problem of mutating the data of a string, your references to > the pieces from which you compose a string are not thread safe, since > they are mutable, right? I don't think so. Isn't the easiest way towards proper composition to consider that the whole is the same as the part? I see the "chain" (I voted for that one!) as an immutable tree of immutable leafs. I think this can be naïvely seen as the following recursive boost::variant: boost::make_recursive_variant < boost::shared_ptr <const std::basic_string <code_unit_type>>, boost::shared_ptr <const std::list <boost::recursive_variant_>> >::type Ivan

3 3

One thing at a time: let's move to Git
by Mathias Gaunard 01 Feb '11

01 Feb '11

Many people wish for Boost to move from svn to git. Other people are fine with svn, but are not opposed to a change to git. So how about we just make it happen? Clearly Ryppl is trying to do too many things at once (modularize Boost, change the build system, the testing system, etc.). I offer we take one step at a time: let's simply move from svn to git, and not do anything else. I think there is already a non-modularized version of Boost on git somewhere. What else needs to be done? Do we just need to set up a scheme to transfer over all accounts and that's it?

8 9

How to specify return policy for object returned as part of a tuple in boost python
by Eddie C. 31 Jan '11

31 Jan '11

Hi all, I have a function that creates a C++ object. Before the refactor, I was returning a pointer from the C++ function, and in the boost python wrapper declaration, I would use boost::python::return_value_policy<boost::python::manage_new_object>. Now I need to return not only just the object, but also some error messages, and the refactor basically changes the C++ function to let it return a tuple: boost::python::tuple create_object_from_description(std::string& description) { ... return boost::python::make_tuple(myObject, errmsg); } How should I specify the return policy with this change? Thanks, Eddie

1 0

[1.46.0 beta 1] Release 1.46.0 beta 1 available
by Beman Dawes 31 Jan '11

31 Jan '11

Boost release 1.46.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains one new library, Interval Containers, 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_46_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 Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

9 13

[Boost Graph Library] larger neighborhood in grid_graph
by Hannes Schulz 31 Jan '11

31 Jan '11

Hi all, i recently discovered grid_graph and found it quite useful so far. However, I would prefer a larger neighborhood in the graph (e.g. 8 instead of 4 for 2D; 26 instead of 6 in 3D). I already started looking into copying and modifying grid_graph.hpp accordingly, but cannot entirely anticipate the complexity of the problem. Therefore I decided to ask here first: - Why did the developers restrict grid_graph to "orthogonal" neighborhoods? - Is a modification of grid_graph worth it, or am I going to throw away everything anyway and should start over anew instead? (without the wrapping overhead, which I do not need) Thank you very much! Hannes

2 1

Git vs SVN - review
by Robert Ramey 31 Jan '11

31 Jan '11

Here's my take on Git vs SVN All VCS systems are an extra layer of hassle. Once I learn enough about them to do the job, I'm happy to forget about them. I'm mostly happy with SVN. I only commit/update occasionally. Most of my time on boost is spent testing on my own machine with windows VC and gcc. I love the windows interface - it's great for someone with my attitude about this. I hate the merging process - it's slow and cumbersome and wastes a lot of my time - when I do it which is only once every three months. So - I don't really have strong feelings about this topic and I'm happy to go along with what ever is decided. I'm just hoping that those who make the decision take into account those of use who are VCS luddites. Robert Ramey

6 9

Testing procedure
by Robert Ramey 31 Jan '11

31 Jan '11

John Maddock wrote: > * I think we could organize the testing more efficiently for faster > turnaround and better integration testing, and much to my surprise I'm > coming round to Robert Ramey's suggestion that we reorganize testing > on a library-by-library basis, with each library tested against the > current release/stable branch. +1 of course, > * I think the release branch is closed for stabilization for too > long, and that beta's are too short. I would hope that implementing the above would make this a non-issue. > Here's a concrete suggestion for how the testing workflow might work: > > * Test machine pulls changes for lib X from version control (whatever > tool that is). > * Iff there are changes (either to lib X or to release), only then > run the tests for that library against current release branch. > * The testers machine builds it's own test results pages - ideally > these should go into some form of version control as well so we can > roll back and see what broke when. > * When a tester first starts testing they would add a short > meta-description to a script, and run the script to generate the test > results index pages. ie there would be no need for a separate machine > collecting and > processing the results. > * The test script should run much of the above in parallel if > requested. > The aim would be to speed processing of testing by reducing the cycle > time (most libraries most of the time don't need re-testing). > +1 to all of the above. Robert Ramey

2 2

[GSoC] Conservancy encourages member projects to apply for 2011
by Dave Abrahams 31 Jan '11

31 Jan '11

This message is forwarded from our umbrella nonprofit, the Software Conservancy:

1 0

[bind] class template 'value' can corrupt compilability of sound code: Ticket #5141
by Joachim Faulhaber 31 Jan '11

31 Jan '11

Hi Peter, list, two days ago I encountered the following situation For a new project I combined some code like: #include <boost/my_lib/my_robust_portable_code.hpp> with some other code #include <boost/malicious/side_effect_code.hpp> #include <boost/my_lib/my_robust_portable_code.hpp> with the effect, that 'my_robust_portable_code.hpp' did not compile anymore. Although I found a fix, applicable to 'my_robust_portable_code.hpp', I think that such a <boost/malicious/side_effect_code.hpp> should generally not be acceptable for independent components of boost. In the concrete case <boost/tread.hpp> has this malicious potential to confuse msvc-[8..10] when it preceded some of my boost/icl code. <boost/tread.hpp> has the potential to break the code of any other boost library and any user code, if those accidentally use certain legal expressions. As the example below shows the corrupted code is not extremely nuts and might occur else were. Fortunately I was able to locate the problem: It's at boost/bind/bind.hpp(112): namespace _bi{ ... template<class T> class value { ... }; ... } //namespace _bi This is a minimal program to demonstrate how 'class value' can confuse msvc: //========================================================= #include <boost/config.hpp> //--- from boost/bind/bind.hpp(112) namespace _bi{ template<class T> class value{}; } //--- affected code --------------------------------------- template <class Type> struct some_attribute { BOOST_STATIC_CONSTANT(int, value = 0); }; template <class Type> struct some_predicate { BOOST_STATIC_CONSTANT(bool, value = ( some_attribute<Type>::value < 0) //error C2059: syntax error : ')' //IF class template value defined before ); }; //========================================================= Although I frankly don't know, how exactly msvc is derailed, it seems to have problems with 'value' in some_attribute<Type>::value < 0 a construction that is extremely frequent due to meta programming conventions introduced by Dave's and Aleksey's boost::mpl. So for a fix I tried to rename 'class value' by something else like 'class _value'. Fortunately this is possible, because the class template is a local implementation object used in boost/bind/bind.hpp only. After renaming, I successfully ran all tests from boost/bind. Find the patch file attached. I have also filed a ticket https://svn.boost.org/trac/boost/ticket/5141 Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 9

Interest in a simple buffer abstraction?
by Boris Kolpackov 31 Jan '11

31 Jan '11

Hi, While working on the Boost profile for ODB C++ ORM[1], I was looking for a Boost type to map the database BLOB type to. I hoped to find something that would encapsulate the memory management and provide basic operations like copy (memcpy), append, set all bytes in a buffer to a specific value (memset), etc. Something that I could use like this: class packet { address to_; boost::buffer payload_; public: packet (const address& to, const void* data, std::size_t size) to_ (to), data_ (data, size) { } const boost::buffer& payload () const { return payload_; } }; class socket { public: void send (const packet& p) { ... s_.send (p.payload ().data (), p.payload ().size ()) } }; I found a number of buffer types in asio (asio/buffer.hpp) but they don't do memory management. I also found auto_buffer in implementation details of signal2 (signal2/detail/auto_buffer.hxx) and buffer in implementation details of iostream (iostream/detail/buffer.hxx). But they appear to be purpose-built for the libraries in question. So, unless I missed something obvious, I would like to propose a simple buffer abstraction for inclusion into Boost. Here are some additional motivations: - Seeing that there is a number of library-specific implementations, it is quite clear that such a class is often needed. - If we have a "top-level" buffer class, various i/o libraries could use it in their interfaces which would lead to better library interoperability (i.e., one could receive data from a socket into a buffer using asio and then pass that buffer to iostream or interprocess without any conversions). - A top-level buffer class will be fairly light-weight (perhaps even header-only). Right now, if I am to use a buffer implementation from say, asio, I need to install and potentially link to that library. If the community believes this is a good idea, I will next send the buffer interface for review/discussion. Let me know what you think. [1] http://www.codesynthesis.com/products/odb/ Boris

7 29

Process discussions
by Christophe Henry 31 Jan '11

31 Jan '11

> As of recent, we had quite a lot of discussion about process. In true > open-source spirit, it was a fairly open discussion, with everybody > offering their perspectives and experience. However, while we surely > learned many things, it does not seem like we're going anywhere. > > For a quick experiment, I tried to assess whether the discussion actually > reflects the needs of Boost developers, so I created a table of Boost > developers sorted by the number of commits in 2010. It is here: > > http://tinyurl.com/5suwfbn > > It seems that 5 top Boost comitters did not participate much in recent > discussions. And going down the list, it seems like many of active developers > did not say anything, while most of discussions is fueled by folks who > don't commit much. > > Of course, everybody can offer valuable thoughts, but if the goal is to fix > things for Boost developers, it would make sense if developers say that needs > fixing, as opposed to other people doing it for them. > > Maybe I suggest that for some time, we outright ban freeform discussion about > process, and instead, we restrict them to threads started by a Boost developers > and saying this: "I am maintainer of X, and had N commits and M trac changes > in the last year. I most hate P1, P2 and P3. I would propose that we use T1, > T2, and T3 to fix that". Then, everybody could join to suggest better > way of fixing P1, P2 and P3 -- without making up other supposed problems. > > Thoughts? *sigh* I usually try to stay out of this kind of discussions like svn vs git for 3 reasons: - I very fast stop following what it is about as it goes into depth without explanations. Actually I have the feeling it is more about "being right" than explaining for dolts like me. - I have no problem with svn - I have no time. Really. I don't. But it seems I have to say my word to avoid being faced with a matter decided without me. So my situation is simple. I have no time (I might have mentioned that already ;-) ). And the time I have is costly because any distraction goes at the cost of MSM. I use all my free time to code or imagine cool new features I can add. So either someone can make me get what I'd gain by investing time in switching to git (I repeat, I have no problem with svn, it does what I need with little cost) or for all practical matters, count me against switching. Right now, all I do is commit my development changes into the trunk, then once every 3 months start a long merge operation (which I do in the background, so no cost). How simpler than that can it be? If all I gain is avoiding getting all of boost on my (big) hard disk, then I will happily prefer paying the 1$ / 10GB and keep the time, thanks.

3 3

template-defined regexp proposal
by Vit Stepanek 31 Jan '11

31 Jan '11

Hi, I've implemented the basic regexp functionality using few simple template classes. Any regexp can be created by inserting the template classes one into another in the required order. Although it's in the design state, I'd like to find out if there's any interest in providing this functionality. Let me present you some short introduction to the topic. Some basic classes include - String Match (full string matching) - Is-in Match (matches any character in the list) - Or Match - Quantity and so on. These are the "building blocks" of the regexp. Each class does a very little bit but when combined in the specific order, you gain a clearly defined string matching algorithm of any kind and any complexity. In addition, it's quite simple to add any missing functionality. You just need to define you're desired algorithm and mix it with the others. I add few examples that should describe how's it all done. Regexp: ^[a-z]+ is implemented as: Quantity< Range< char_a, char_z >, 1 > re; (sorry if you don't like the indentation, but that's just to ease the reading) Regexp: ^0(x|X)[a-fA-F0-9]+ (matching the hexadecimal number) The required strings are hardcoded using macro "STRHOLDER", which generates a simple struct containing the given string (to avoid the need of pushing strings in the runtime and thus splitting the matching logic into two levels). STRHOLDER( 0, "0" ); STRHOLDER( xX, "xX" ); MultiTie< StrMatch< StringHolder_0 >, IsIn< StringHolder_xX >, Quantity< OrMatch< DigitChar, OrMatch< Range< char_a, char_f >, Range< char_A, char_F > > >, 1 > > re; The "MultiTie" ties the match parts to the consecutive sequence. Some other examples I tested include - email address regexp - quoted string matching (containing escaped quoting chars) Currently the implementation counts 21 template classes, which are enough to implement (I hope) almost any regular expression. Each "brick" is called using operator ()(). That allows to pass it as an argument to the standard algorithms (like std::replace_if etc). I've already implemented the availability to push parameters to the regexp in the runtime (but that's not the major feature). Some rationale for the defense: String matching is widely applied part of the coding. Often it's also one of the problematic domains (especially when using self-implemented matching functions without any general solution). Once it's done, it can be hard to change it, because all what can be seen is HOW is the match done, but not WHAT does it do. Even when using some higher-level methods, it still isn't self-descriptive. Template-defined regexp provides one solution for this issue by hiding the HOW under the mask of WHAT, and taking the advantage of compile-time check. Only to mention that - the performance is not touched by any kind of interpreting - everything is prepared after compilation (but I don't want to touch anybody's baby here!). Please don't look at: - the proposed name "template-defined regexp", I use it as the temp. name - the naming of the classes - implementation details (yes, they aren't here, because it's not necessary for now) - term "regexp" - I'm not sure if this can be called so... Your opinions are welcomed! Vit Stepanek ------------

3 7

[date_time] Active Maintainer? Patches on Trac, Cleaned-up, and Tested.
by Dean Michael Berris 31 Jan '11

31 Jan '11

I don't know where to look for this kind of information -- anybody maintaining Boost.Date_Time now? There are a few patches that have been languishing which might be good to look at and/or apply to trunk: https://svn.boost.org/trac/boost/ticket/1574 https://svn.boost.org/trac/boost/ticket/1674 https://svn.boost.org/trac/boost/ticket/1726 I've verified these locally to not cause any regressions with GCC 4.5 on Ubuntu 10.10 64-bit Linux locally. /me doesn't have commit powers on trunk (yet); maybe someone can apply? TIA, HTH -- Dean Michael Berris about.me/deanberris

1 0

Immutable data structure survey results
by Gregory Crosswhite 31 Jan '11

31 Jan '11

Hey everyone, Here are the results of the survey that I ran for the name of a potential immutable byte sequence data structure; each line contains the name that was entered and the number of times that it appeared: chain: 9 boost::text: 3 sequence: 2 string: 2 atomic_buffer: 1 blob: 1 buffer: 1 bytes: 1 chord (from the Latin chorda meaning string): 1 const_buf: 1 const_string: 1 data_block: 1 fixed_sequence<char>: 1 frame: 1 immutable::string: 1 immutable_sequence: 1 imstring: 1 rod: 1 rope: 1 sequence<char>: 1 strand: 1 tier: 1 whole_buffer: 1 wire: 1 yarn: 1 TOTAL: 37 To be transparent, I have also attached the script that I used to generate the above, which includes the raw results pasted inside a multi-line string. (Yes Artyom I included your vote in the tally.) I apologize for any problems you might have had with this service. I considered using another free service online which would be better suited for this purpose, but I wasn't sure of how many responses there would be and most services put a cap on 100 responses for their free services, whereas the service I have access to through my university has no such restriction. Since the actual number of responses was less than half of 100 I will know for future reference that one of the other free services should work just fine for this purpose. Thanks to everyone who responded! Cheers, Greg

3 2

[1.46.0 beta 1] Release candidate files available
by Beman Dawes 31 Jan '11

31 Jan '11

Release candidate files for the 1.44.0 beta 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. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

6 7

[string] Realistic API proposal
by Artyom 31 Jan '11

31 Jan '11

Hello All, I'd like to provide a realistic string API proposal: 1. It is Unicode aware extension of std::string 2. It is fully compatible with std::string giving an ability to be included in C++XYZ 3. It can be implemented today! Basically it extends std::string with a) const_code_point_iterator - for iterating over string - bidirectional b) code_point_iterator - back inserter c) provides Unicode and Locale functionality: - normalization - case handling - comparison - search d) marks non const operator[],at() as deprecated Advantages: ----------- 1. It can be implemented easily (when boost.locale is given) 2. It **is** compatible replacement of std::string 3. It allows to use std::string meanwhile under the hood as storage giving high efficiency when assigning boost::string to std::string when the implementation is COW (almost all implementations with exception of MSVC) 4. It is full unicode aware 5. It pushes "UTF-8" idea to standard C++ 6. You don't pay for what you do not need. Proposed API: ------------- namespace boost { // Fully bidirectional iterator template<typename UnitsIterator> class const_code_point_iterator { public: const_code_point_iterator(UnitsIterator begin,UnitsIterator end); // begin const_code_point_iterator(UnitsIterator begin,UnitsIterator end,UnitsIterator location); // current pos const_code_point_iterator(); // end #ifdef C++0x typedef char32_t const_code_point_type; #else typedef unsigned const_code_point_type; #endif const_code_point_type operator*() const; ... }; /// Output iterator template<typename BackInserter> class code_point_iterator { public: code_point_iterator(BackInserter out); // begin code_point_iterator(); // end #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif code_point_type operator*() const; ... }; template<typename Char,typename Traits=std::char_traits<Char>, typename Alloc=std::allocator<Char> > class basic_string { public: // { boost specific typedef std::basic_string<Char,Traits,Alloc> std_string_type; // } boost specific // All std::string standard functions based // Deprecated interfaces that exist for backward compatibility // as they not Unicode aware value_type &at(size_type indx); value_type &operator[](size_type indx); iterator begin(); iterator end(); // { boost specific compatibility functions with std::string, they would go // as std::string becode extended with boost::string new interfaces // basic_string(std_string_type const &other) : data_(other) {} basic_string(std_string_type const &other,size_type index,size_type len) : data_(other,index,len) {} ... operator std_string_type() const { return data_; } // } boost specific compatibility functions // // Unicode Support // // ------------------------ // // // UTF Codepoint iteration // #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif typedef boost::const_code_point_iterator<const_iterator> const_code_point_iterator; const_code_point_iterator code_point_begin() const { return const_code_point_iterator(begin(),end()); } const_code_point_iterator code_point_end() const { return const_code_point_iterator(begin(),end(),end()); } typedef boost::code_point_iterator<std::back_inserter<basic_string> > code_point_iterator; code_point_iterator back_inserter() { return code_point_iterator(std::back_inserter<basic_string>(*this)); } basic_string &operator+=(code_point_type code_point); basic_string operator+(code_point_type code_point) const; void append(code_point_type code_point); // // Lexical operations on string // // Case handling basic_string upper_case(std::locale const &l=std::locale()) const; basic_string lower_case(std::locale const &l=std::locale()) const; basic_string title_case(std::locale const &l=std::locale()) const; basic_string fold_case() const; // locale independent // Unicode normalization typedef enum { nfc, nfkc, nfd, nfkd } normalization_mode; basic_string normalize(normalization_mode mode = nfc) const; // normalized string constructor basic_string(basic_string const &,normalization_mode mode); basic_string(Char const *,normalization_mode mode); basic_string(Char const *,size_t n,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,normalization_mode mode); void append_normalized(basic_string const &other,normalization_mode mode = nfc); void append_normalized(Char const *,normalization_mode mode = nfc); void append_normalized(Char const *,size_t n,normalization_mode mode = nfc); basic_string concat_normalized(basic_string const &other,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,size_t n,normalization_mode mode = nfc) const; // Unicode validation bool valid_utf() const; typedef struct validate_utf{}; // Unicode validation tag // Create string validating it basic_string(basic_string const &,validate_utf const &); basic_string(Char const *,validate_utf const &); basic_string(Char const *,size_t n,validate_utf const &); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &); // Create string validating and normalazing it basic_string(basic_string const &,validate_utf const &,normalization_mode mode); basic_string(Char const *,validate_utf const &,normalization_mode mode); basic_string(Char const *,size_t n,validate_utf const &,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &,normalization_mode mode); // Search and comparison typedef enum { primary = 0, ///< 1st collation level: base letters secondary = 1, ///< 2nd collation level: letters and accents tertiary = 2, ///< 3rd collation level: letters, accents and case quaternary = 3, ///< 4th collation level: letters, accents, case and punctuation identical = 4 ///< identical collation level: include code-point comparison } level_type; // // search(...) return pair of index and size as string you search for may have different size // std::pair<size_type,size_type> search(basic_string const &other) const; std::pair<size_type,size_type> search(basic_string const &other,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,std::locale const &l) const ; std::pair<size_type,size_type> search(basic_string const &other,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *) const; std::pair<size_type,size_type> search(Char const *,level_type level) const; std::pair<size_type,size_type> search(Char const *,std::locale const &l) const ; std::pair<size_type,size_type> search(Char const *,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level) const; std::pair<size_type,size_type> search(Char const *,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(basic_string const &other) const; int compare_to(basic_string const &other,level_type level) const; int compare_to(basic_string const &other,std::locale const &l) const ; int compare_to(basic_string const &other,level_type level,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other) const; int compare_to(size_t index,size_t size,basic_string const &other,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,std::locale const &l) const ; int compare_to(size_t index,size_t size,basic_string const &other,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(Char const *) const; int compare_to(Char const *,level_type level) const; int compare_to(Char const *,std::locale const &l) const ; int compare_to(Char const *,level_type level,std::locale const &l) const; int compare_to(Char const *,size_t size) const; int compare_to(Char const *,size_t size,level_type level) const; int compare_to(Char const *,size_t size,std::locale const &l) const; int compare_to(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *) const; int compare_to(size_t size,Char const *,level_type level) const; int compare_to(size_t size,Char const *,std::locale const &l) const ; int compare_to(size_t size,Char const *,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size) const; int compare_to(size_t size,Char const *,size_t size,level_type level) const; int compare_to(size_t size,Char const *,size_t size,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size,level_type level,std::locale const &l) const; // UTF validation bool is_valid_utf() const; private: std_string_type data_; }; } // boost

4 8

Re: [boost] [1.46.0 beta 1] Release candidate files available
by Cromwell Enage 30 Jan '11

30 Jan '11

When running "bjam --toolset=gcc stage" on the command line, I get the following message: tools/build/v2/build/configure.jam:145: in builds-raw *** argument error * rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? ) * called with: ( <pbin.v2/libs/regex/build/gcc-4.2.1/debug>has_icu : : ignore-minus-n : ignore-minus-q ) * extra argument ignore-minus-q (builtin):see definition of rule 'UPDATE_NOW' being called It's the same error that's been preventing me from building auto-index. Cromwell D. Enage

3 4

Boost-1.46.0-beta1 fails to build in tools/regression/
by Philipp Reh 30 Jan '11

30 Jan '11

tools/regression expects boost::filesystem to be version 2 but version 3 is now the default. The attached patch fixed the build for me.

1 0

Re: [boost] RE process (prospective from a retired FreeBSD committer)...
by Brian Wood 30 Jan '11

30 Jan '11

Dave Abrahams wrote: >At Sun, 30 Jan 2011 16:43:17 +0300, > Vladimir Prus wrote: > > >> whereas most of the core (which is half-zillion times bigger than >> Boost), lives in two modules, which contain wildly different >> functionality, are updated by multiple people, and then built and >> used and tested by users all the time. So, this proves that Boost >> has a lot of grows ahead before having all code in place place will >> becomes, even in theory, a problem. > > The problem isn't where the code is located, it's: > > a. how much coordination is required to get things done > > b. the mental drag of having to deal with all the parts of Boost that > simply aren't relevant to you. > I've recommended to "chew the meat and spit the bones," when it comes to Boost since at least 2007. This approach sounds like it will make it easier to produce a tasty Boost according to one's understanding. So I'm in favor of it, though I rather expect achieving it will be difficult. This *less taxing* approach (in terms of hard drives, download times, ...) will be a breath of fresh air. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Stack-based vector container
by Gregory Crosswhite 30 Jan '11

30 Jan '11

Hey everyone, In the course of my work as a computational scientist I have written a container that emulates std::vector, but which is backed by an array whose size is fixed at compile time. Concretely, the class looks something like the following: template<typename T,unsigned int buffer_size> class static_vector { ... protected: T data[buffer_size]; T* end_ptr; size_t current_size; } where in the [...] there are methods that emulate (at this time, partially) the interface of std::vector, save that the size of the static_vector is not allowed to grow beyond the buffer_size. The advantage of using a static_vector over vector is performance. In my code I have performed benchmarks that show up to a 30% performance boost of static_vector over vector; the benefit occurs most stongly when working with lots of arrays of small objects, so that the use of dynamic memory rather than stack memory appears to add significant overhead to the computation. (Note that I when running these benchmarks I would use std::vector::reserve() to pre-allocate the array so that std::vector would not perform multiple allocations as the container grew, so that should not have been a source of overhead.) It seems to me that it would be useful to have this functionality generally available as a library, and in particular it might be a good fit for the boost family of libraries. Is there any interest out there for having such a library in boost? If so, I would be happy to do the work of taking what I have and fleshing it out so that it can function as a drop-in replacement for vector, which means modeling the Random Access Container and Back Insertion Sequence concepts as well as adding capacity() and reserve(size_t) (no-op) methods. Thoughts? Cheers, Gregory Crosswhite

17 53

GIL io_new review
by Phil Endecott 30 Jan '11

30 Jan '11

Back in 2006 I had some code that used ImageMagick's Magick++ library to read and write images in various formats and do some basic processing. That library works well and is very feature-full, but is not what you would call "Boost like", so I was excited when GIL came along. I looked at it at the time of its review, and I thought at first that I must have missed a big chunk of the documentation where all the algorithms were described! Of course, it has no image processing algorithms; it's just a layer; if you want to scale or rotate or merge images, you have to do that yourself. I don't think I wrote a review in the end; my feeling was - in comparison with ImageMagick - "come back when you've finished" - but I didn't want to say that in public. So it's great that now, 4 years later!, we are finally getting some GIL extensions. Thank you Christian for - I hope! - getting the ball rolling. I hope we'll see more. Having said that, I suspect that even with lots of extensions GIL might not really be what I need. Here's a typical problem that I will have to address in the next few weeks: I have a 1e12 pixel image - a map - which is supplied as a few thousand 5000x5000 TIFF tiles; I have to join them together, tweak the colours, draw some lines on top, and re-chop it into a few million 256x256 PNG tiles. The issue of course is that that image can't be held in RAM. I will do this with my own wrappers around libtiff and libpng, in rows or chunks. So, do the image concepts (and concrete classes) that GIL defines accommodate that sort of problem? Even if they do, is a "virtual image" of some sort a good way of doing it? I suspect not. But even if the image concept is not useful, presumably other GIL concepts like pixel formats and algorithms in future extensions (pixel format conversion, blending) could still be useful. So, along comes Christian's IO extension. Wrapping the "legacy" image libraries is something that I have done a few times now and it can be painful, not least because of the need to read a lot of documentation; the libraries all differ and it would be great to get a unified set of wrappers that provide a sane C++ interface. But as you can see, I don't really want something that reads and writes complete GIL images, and that is what Christian's extension does. Ideally, this extension would have separated out the wrapping of the libraries from the actual GIL image integration, with the GIL image integration just being a layer on top of the image library wrappers. Since it doesn't do that, it's not much use to me. It is, however, better than what GIL currently has. So for that reason I suggest that it should be accepted. > - What is your evaluation of the design? In addition to my comments above, I note that it's necessary to jump through hoops (using Boost.IOStreams) just to read an image from memory. Surely this should be a fundamental operation; it would be much better to have a ctor that takes begin and end pointers for the encoded image data. > - What is your evaluation of the implementation? When I first looked at the library I noticed that the error handling was clearly broken. Although that seems to have been resolved, it has given me a poor impression of the quality (i.e. likely correctness) of the implementation. It seems that this error handling has received almost no testing. Thorough testing will be difficult for this library because as well as all the usual permutations of platform features, compilers etc. the variations in the image libraries must also be considered. The library version and compiler settings could both affect the correct operation of this code. I have some concerns about the likely performance of the code due to excessive copying of the data both in and out of the image library. Although I've not measured the performance impact, I feel it would be very desirable (and is certainly possible) for this library to have zero copying. > - What is your evaluation of the documentation? Satisfactory. (As a meta-comment - I think libraries being reviewed really should have their docs available online somewhere, and preferably also their source code in a source browser of some sort. In fact, I thought this was already a requirement. Can it be added to the review managers' checklist for future reviews?) > - What is your evaluation of the potential usefulness of the extensions? It's better than what was there before. > - Did you try to use the extensions? With what compiler? Did you have > any problems? No, I've not compiled anything. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Probably half a day during the review, and a similar amount of time a few months ago. > - Are you knowledgeable about the problem domain? I've written a few wrappers for libjpeg, libpng and libtiff. I've never used GIL though I've read extensively about it. > And finally, every review should answer this question: > - Do you think the extensions should be accepted as a part of Boost.GIL > library? On the grounds that this is better than what is currently there, and on the assumption that Domagoj Saric is not imminently going to post something else that would supersede this, I believe that it should be accepted. (I have not looked at the "toolbox" at all, and I've not seen it mentioned in any other reviews yet. My "yes" is just for the io_new functionality.) Regards, Phil.

7 39

[gil][io_ew] performance test
by Christian Henning 30 Jan '11

30 Jan '11

Hi there, I did a little performance test of io_new vs io2. The code is here. http://pastebin.com/eCeFZuMS On my machine io_new runs in 1.15sec for 2658 jpegs. IO2 run in 1.005sec. All jpegs are the same image but they are a different file. This way I'm sure I don't have to convert the image into a different color space. I did that since io2 doesn't support any_image, I believe. Thanks, Christian

3 5

[fiber] Mac OS X
by Daniel Larimer 30 Jan '11

30 Jan '11

I am attempting to use Boost.Fiber on Mac OS X, but it always crashes in makecontext() which is now deprecated on Mac OS X. Is there any plan to get asm working for OS X? include <boost/fiber.hpp> boost::fiber* fi; void fib() { for( int i = 0; i < 10; ++i ) fi->yield(); }; int main( int argc, char** argv ) { boost::fiber f( boost::bind(fib), boost::fiber::default_stacksize, boost::protected_stack_allocator()); fi = &f; f.run(); return 0; } Reason: KERN_INVALID_ADDRESS at address: 0x0000000000010fa0 0x00007fff80820f89 in makecontext () (gdb) bt #0 0x00007fff80820f89 in makecontext () #1 0x000000010001f3a3 in boost::contexts::context::impl_t::impl_t (this=0x100100210, fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, vp=0x100100190, stacksize=65536, nxt=0x1001001c0, alloc_=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:58 #2 0x000000010001f183 in ~auto_ptr [inlined] () at /usr/include/c++/4.2.1/memory:59 #3 0x000000010001f183 in boost::contexts::context::init_ (fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, nxt=0x1001001a0, vp=0x100100190, stacksize=65536, alloc=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:77 #4 0x00000001000017db in boost::contexts::context::create<boost::contexts::protected_stack_allocator> () #5 0x0000000100001a96 in boost::fibers::detail::fiber_base::fiber_base<boost::contexts::protected_stack_allocator> () #6 0x0000000100001b65 in boost::fibers::detail::fiber_object<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0> >::fiber_object<boost::contexts::protected_stack_allocator> () #7 0x0000000100001bdd in boost::fibers::fiber::make_fiber_<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #8 0x0000000100001c54 in boost::fibers::fiber::fiber<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #9 0x00000001000010be in main () Boost 1.45 Boost.Fiber 0.7.0 from Valut i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) Mac OS X 10.6.6

3 2

[CfP] Reminder: 5th Annual BoostCon, Aspen (CO, USA), May 15-20, 2011
by Hartmut Kaiser 30 Jan '11

30 Jan '11

Please note the extended deadline: February 10th, 2011 ------------------ Please distribute. ------------------ 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on research. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing 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 * C++0x and how it changes life for users and library writers * 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 nature of both the on-line Boost community and 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 Boost and Boost users. Panels ------------- Panels feature three or four people presenting their ideas and experiences relating to 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 Boost-relevant skills. 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 Presentations ------------- These were introduced at BoostCon 2008, and were a great 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 Presentations ------------- We actively encourage tool vendors and ISP's to submit 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 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 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 have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon2011. 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 BoostCon website and will be available to attendees. For general information on the BoostCon 2011 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon2011(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 BoostCon. IMPORTANT DATES New proposal submissions due: January 10th, 2011. Proposals decisions sent (tentative program): February 17th, 2011. Fully scheduled program available: February 25th, 2011. Session materials due: April 15th, 2011. Hartmut Kaiser: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

type traits extension: progress status
by Frédéric Bron 30 Jan '11

30 Jan '11

I have been able to make the binary operator traits work with pointers. It has been a hard job but I think it is now working well (thank you Jeffrey for pointing to that particular issue). I still have to do the same for unary operators but this should be much easier. The current list of supported operators (35) is now: * 28 binary operators: . ==, !=, <, <=, >, >=, . +, -, *, /, %, +=, -=, *=, /=, %=, . &, |, ^, &=, |=, ^=, . <<, >>, <<=, >>=, . &&, ||, * 5 prefix unary operators: . ! . -, + . --, ++ * 2 postfix unary operators: . --, ++ Here are the links to the updated code and documentation: * http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… * http://svn.boost.org/svn/boost/sandbox/type_traits/ Frédéric

3 4

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 30 Jan '11

30 Jan '11

>> > // UTF validation >> > >> > bool is_valid_utf() const; >> >> See, that's what makes the whole thing pointless. > >Actually not, consider: > > socket.read(my_string); > if(!my_string.is_valid_utf()) > .... This, and many of these functions, work much better as standalone functions: // with a string-aware function socket.read(my_string); if (!is_valid_utf8(my_string.begin(),my_string.end())) .... // with a C interface std::vector<char> vec; vec.resize(MY_BUFSIZE); int len = recv(socket, vec.data(), MY_BUFSIZE, 0); if (len >= 0) { vec.resize(len); if (!is_valid_utf8(vec.begin(), vec.end())) .... } // conversion for Windows API std::vector<wchar_t> vec; vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); HRESULT hr = WriteFile(handle, vec.data(), vec.size(), &dwBytesWritten, NULL); ... Joe

6 5

One small step for mankind - was Re: What's happened to Ryppl?
by Robert Ramey 30 Jan '11

30 Jan '11

Dave Abrahams wrote: > Robert, great questions. Could you post them to the boost developers' > list? They really don't belong here. > > Thanks. > > On Sat, Jan 29, 2011 at 12:57 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> Dave Abrahams wrote: >>> On Fri, Jan 28, 2011 at 4:35 PM, Robert Ramey <ramey(a)rrsd.com> >>> wrote: >> >> In the interest of moving toward a better modularization of boost >> and decoupling of libraries, I would like to make a suggestion: >> >> Can we change library testing so that each library is tested against >> the current release branch of all the other libraries? >> >> When I test on my own machine, I don't test against the trunk. I >> test against the current release tree. Another way of saying this is >> that on my current machine I have my directory tree set to the >> the boost release branch. ONLY the serialization library directories >> are set to the trunk. So when I test on my local machine I KNOW that >> when I merge >> into the release branch I won't have any unexpected problems. >> >> a) I don't think this would be a huge change. >> b) It would better test what the user does >> c) It would isolate each library from another so that >> errors in the trunk (wild west) in one library don't impact >> on development of other libaries. >> d) It would promote decoupling of libraries. >> e) as an intermediate step, not all testers would have >> to make the change - some could use the old script. >> >> It would be a small, not too difficult step on the path >> we think we want to travel. >> >> Robert Ramey >>

2 1

Re: [boost] [string] proposal
by Ivan Le Lann 30 Jan '11

30 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> a écrit : > > From: Dean Michael Berris <mikhailberis(a)gmail.com> > > > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> > > >> No, it's not obvious. Here's why: > > >> > > >> fd = creat(file.c_str(), 0666); > > >> > > >> What does c_str() here imply? It implies that there's a buffer > > >> somewhere that is a `char const *` which is either created and > > >> returned and then held internally by whatever 'file' is. > > > > > > It implies that const file owns const buffer that holds null > terminated > > > string that can be passed to "char const *" API. > > > > > > > Yes, which is the problem in the first place. Every instance of > string > > would then need to have that same buffer even if that string is > just a > > temporary or worse just a copy. > > > > It would not happen if it holds the data as linear single chunk :-) > > > >> Now let's say > > >> what if file changed in a different thread, what happens to the > buffer > > >> pointed to by the pointer returned by c_str()? Explain to me > that > > >> because *it is possible and it can happen in real code*. > > > > > > I'm sorry but string as anything else has value semantics > > > that is: > > > > > > - safe for "const" access from multiple threads > > > - safe for mutable access from single thread > > > > > > I don't see why string should be different from > > > any other value type like "int" because following > > > > > > x+=y + y > > > > > > is not safe for integer as well. > > > > > > The code I had shown is **perfectly** safe with > > > string has has value semantics (which std::string has) > > > > > > > Now the point I was making was, in the case of a string that is > > immutable, you don't worry about the string changing *ever*, don't > > need a contiguous buffer for something that isn't explicitly > required. > > It's value semantics *plus* immutability. > > > > So you either should forbid > > your_string const &operator=(your_string const &) > > Which makes it even more useless (IMHO) > > Or your statement is wrong because assignment > can happen for example from other thread like > > str = str + " suffux" > > And this would change the string in run time. > Think str as a shared_ptr<const string_beast> with wrappers. This line does not mutate the structure previously pointed to, just like assigning a shared_ptr does not mutate the object previously pointed to. It makes str points to a newly created chain, which here happens to share data with the original chain but that's another story. Of course, this suppose that you got str by value. If you got it by non-const reference, you can have race issues with other threads, just like any assignment, regardless of the type. Ivan

1 0

[string] proposal
by Matus Chochlik 30 Jan '11

30 Jan '11

Dear list, following the whole string encoding discussion I would like to make some suggestions. >From the whole debate it is becoming clear, that instant switch from encoding-agnostic/platform-native std::string to UTF-8-encoded std::string is not likely to happen. Then it was proposed that we create a utf8_t string type that would be used *together* (for all eternity) with the standard basic_string<>. While I see the advantages here, I (as I already said elsewhere) have the following problem with this approach: Using a name like utf8_t or u8string, string_utf8, etc. at least to me (and I've consulted this off the list, with several people) suggests, that UTF-8 is still something special and IMO also sends the message that it is OK to remain forever with the various encodings and std::string as it is today. We should *IMO* endorse the opposite. My suggestion is the following: Let us create a class called boost::string that will have all the properties that a string handling class in 2011+ A.D. should have, basically what std::string should have been. Then there are two alternatives: a) When all the zillions lines of legacy code in FORTRAN, COBOL, BASIC, LOGO, etc. :) are fixed / ported / abandoned, and UTF-8 becomes a true standard for text encoding widely accepted by the whole IT industry and markets, and all the issues that prevent us from doing the transition now are resolved, this string becomes the standard, like many other things from Boost in the past, and replaces the current std::string. b) As some (having much more insight into how the standardizing comitee works than I do) have pointed out, it will never become a true standard. But with the Boost's influence it at least becomes a de-facto standard for strings and it is (hopefully) adopted by the libraries that currently feel the need to invent string-classes themselves (with a good reason). Also I've uploaded into the vault file string_proposal.zip containing my (naive and un-expert-ly) idea what the interface for boost::string and the related-classes could look like (it still needs some work and it is completelly un-optimized, un-beautified, etc.). /me ducks and covers :) The idea is that, let std::string/wstring be platform-specifically- -encoded as it is now, but also let the boost::string handle the conversions as transparently as possible so if in case the standard adopts it, std::string would become a synonym for boost::string. It is only partially implemented and there are two examples showing how things could work, but the real UTF-8 validation, transcoding, error handling, is of course missing. Remember it is aimed at the design of the interfaces at this point. If you have the time, have a look and if my suggestions and/or the code looks completely wrong, please, feel free to slash it to pieces :), and if you feel up to it, propose something better. If this or something completely different and much better that comes out of it, will be agreed upon, we could set up a dedicated git repository for Boost.String and maybe try if the new suggested collaborative development in per-boost-component repositories really works. :) If some of the people that are skilled with unicode would join or lead the effort it would be awesome. Best, Matus

28 233

Re: [boost] [string] proposal
by Artyom 30 Jan '11

30 Jan '11

> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > >> No, it's not obvious. Here's why: > >> > >> fd = creat(file.c_str(), 0666); > >> > >> What does c_str() here imply? It implies that there's a buffer > >> somewhere that is a `char const *` which is either created and > >> returned and then held internally by whatever 'file' is. > > > > It implies that const file owns const buffer that holds null terminated > > string that can be passed to "char const *" API. > > > > Yes, which is the problem in the first place. Every instance of string > would then need to have that same buffer even if that string is just a > temporary or worse just a copy. > It would not happen if it holds the data as linear single chunk :-) > >> Now let's say > >> what if file changed in a different thread, what happens to the buffer > >> pointed to by the pointer returned by c_str()? Explain to me that > >> because *it is possible and it can happen in real code*. > > > > I'm sorry but string as anything else has value semantics > > that is: > > > > - safe for "const" access from multiple threads > > - safe for mutable access from single thread > > > > I don't see why string should be different from > > any other value type like "int" because following > > > > x+=y + y > > > > is not safe for integer as well. > > > > The code I had shown is **perfectly** safe with > > string has has value semantics (which std::string has) > > > > Now the point I was making was, in the case of a string that is > immutable, you don't worry about the string changing *ever*, don't > need a contiguous buffer for something that isn't explicitly required. > It's value semantics *plus* immutability. > So you either should forbid your_string const &operator=(your_string const &) Which makes it even more useless (IMHO) Or your statement is wrong because assignment can happen for example from other thread like str = str + " suffux" And this would change the string in run time. Your statement is false unless I miss something or you want to put a mutex inside a string or some other atomic variable. I don't see any reason to not to treat a string as any other value. > > > > I think we both and 95% of C++ programmers that use STL > > know what is the semantics of std::string::c_str() > > > >> I like this better: > >> > >> char * filename = (char *)malloc(255, sizeof(char)); // I know I > >> want 255 characters max > >> if (filename == NULL) { > >> // deal with the error here > >> } > >> linearize(substr(file, 0, 255), filename); > >> fd = creat(filename, 0666); > >> > > > > Sorry? Is this better then: > > > > fd=create(filename.substr(0,256).c_str(),O_EXCL...) > > > > Which by the way is 100% thread safe as well (but still may throw). > > Even thou I can't see any reason to cut 256 bytes before create > > > > No, not better because std::string's substr() will return a temporary, > which means it will be a copy -- meaning another allocation and a call > to memcpy(...). You don't get the benefit of COW on this one because > you need to cut the string down to a "maximum size". > Actually small notice you will have to copy because C API expects NULL terminated string, so you can't avoid memory copy if the last byte is not NULL. So no difference there > I don't know if you know, but them C APIs from OSes have a defined > maximum on the lengths of filenames and things like that... > Not exactly maximal length is something much more complicated, run-time and specific OS dependent, but this is other story. > >> And then the problem is not addressed then of the unnecessary contiguous > >>buffer. > >> > > > > There is good idea to have some non-linear data storage but > > it should used in very specific cases. > > > > Also what is really large string for you that would have > > performance advantage not being stored lineary. > > > > Talk to me in numbers? > > > > Say on a machine+OS combo that has 4kb pages, a large string would be > something that spans more than one memory page -- i.e. >4kb. > > Now a "short" string is one that can fit within a page. For > concatenated strings, it's fine to compact/copy the substrings into a > growable/shrinkable block. The overhead for a short string would be > constant, as the concatenation tree would be a pointer and a length > with a reference count integer. Actually I actually mean benchmarks how long string should be that it would be more efficient to use as chunks. So you suggest 4k Which: 1. Covers almost all full file path names on every operating system 2. Covers almost all messages in text dialogs around 3. Covers all possible user data etc. So basically a single memory chunk is efficient for 99% of use cases. Now lets take it to extreme: - Longest Wikipedia article: 388k = ~ 39 pages - Book: War and Peace: text size... 3.1MB = 800 pages. How frequent this case? Very rare. See text is basically something quite short, long books were successfully written in days where 640K was more then enough. So the real benefits of non-linear data structure are rare, on the other had they add too much complexity for every day use. So basically: 1. 99% of use cases fit to single page. 2. Very few cases would actually make a use of multi-page architecture. 3. The extreme cases that may benefit of this data structure are very rare and probably should use their own structures. Just to clean up all the things 1. I do think that what you suggest is interesting and fine data structure. 2. I do think that in certain cases it would be very useful. 3. I do think that you have good experience with situations were such structure may be very useful. 4. I know your works (netlib) and I really appreciate what you do . However I still think: 1. Such structure does not give much benefits in main stream cases for string data structure in its text meaning (which what string for 99% programmers is). I mean non-linear memory is not really so useful for common use case. 2. I think you should take a look on major string use cases to decide what is better for "next C++ string" if you want to develop some. Also as you probably know I'm author of several projects most of them are strongly tied to text processing and handing: 1. Boost.Locale - strongly text and Unicode oriented. 2. CppCMS - C++ web framework that deals with strings and networking in most of its code. That by the was was the reason for Boost.Locale to be developed. 3. BidiTeX - bidirectional support for LaTeX/Hebrew which is mostly deals with text. So I do have some basic view on what are the use cases of strings, I don't say I know them all but I developed some "feeling" about what text processing needs and in my opinion you just miss the major use case. I think I'll stop trying to convince you that it is wrong way to look at string just because I think that users would know what to pic in real applications. Best Regards and Good Luck, Artyom

1 0

[1.46] Last few merges needed?
by John Maddock 29 Jan '11

29 Jan '11

I've been sifting through what needs to change on the release branch (for 1.46) in Boost.Config to revert some of the changes made by Bryce which have already been reverted in Trunk. Specifically: The patches to the pathscale config need to be merged to Release (unfortunately it took until now to get these working on Trunk): --- boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 +++ ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" -#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) +#elif defined __PATHSCALE__ // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp" And also the Boost.Config docs need to be merged to release so that the new BOOST_*_NIX macros that were added and then removed are no longer documented in 1.46 (the actual changed headers can wait till 1.47 for merging). Is there likely to be a window when these changes can be merged - maybe between beta and release? Also are there any other pending reverts in Trunk but not release? Regards, John.

7 22

[network] Bagged, Tagged, New Release 0.8.1
by Dean Michael Berris 29 Jan '11

29 Jan '11

Hi Everyone, Just a quick note, there's an update to the 0.8 line which addresses issues that have been identified with the previous 0.8 release. It's recommended that people using the 0.8 release upgrade to 0.8.1. This release is still a header-only release, with some features back-ported from the 0.9-devel branch. You can get the 0.8.1 release at https://github.com/cpp-netlib/cpp-netlib/downloads Have a good day everyone and I hope this helps. PS. The 0.9 release should come out soon, final documentation updates are just getting done; the 0.9 line will be the version that shall be submitted for review, looking for interested review managers at this time. -- Dean Michael Berris about.me/deanberris

1 0

Re: [boost] [string] proposal
by Brent Spillner 29 Jan '11

29 Jan '11

On Jan 29, 2011, at 8:43 AM, David Bergman wrote: >There are four layers in play here: >1. The sequence of characters/symbols, as in CS string; totally abstract but precise... (one such CS string can be represented as Unicode or Latin-1 at #2, for instance.) >2. The sequence of code points, in a given character set. Yes, one CS string (as in #1) can have multiple distinct manifestations at this level. They could be identical in >integral sequences. >3. The sequence of code values, using an encoding form such as UTF-8 or UTF-16 for a Unicode code point. >4. The byte storage representing the code values; could be a contiguous sequence of bytes or chunks, etc. Which, IMHO, is exactly why it's (past) time to radically rethink the standard string interface. Your four layers share the properties that: (a) They can all be physically represented within the same data structure (i.e. layer #4), and (b) For any layer, there already exists a lot of legacy code that conceptualizes passed-in strings at that layer and that makes corresponding assumptions. To me, these facts imply that a 'view'-based approach is the right way to go. Furthermore, views should not be concrete data structures themselves, but simply iterator pairs (ranges) that internally point to some arbitrary data structure, and externally present a model of a linear sequence of atomic characters/codepoints/etc. In software development Nirvana, APIs and algorithms will operate on iterator_ranges at the appropriate conceptual level, rather than intruding into the underlying data structures, and at the interfaces with reality we'll just copy data to and from more concrete representations using the chosen encoding. Some of those interfaces (with low-level device drivers or with memory-mapped hardware itself) might never go away, but many (e.g. a GUI API that accepts a string and returns a texture of its glyphs) would hopefully eventually migrate to the iterator model. For example, one might write std::string underlying_data = obtain_validated_data_from(somewhere); text<ucs4, codept_view, decltype(underlying_data)> codepoints(assume_utf8(underlying_data)); text<utf8, char_view, decltype(underlying_data)> characters(assume_utf8(underlying_data)); if (codepoints.length() > characters.length()) contains_multipoint_characters = true; // converse not necessarily true if there are codepoints for multi-character ligatures const char *byteptr = linear_representation(underlying_data); // may or may not accurately track later changes, especially if the underlying data is non-contiguous, but that's really a usage protocol question and not for the data structure to solve--- anyway, strdup() if you want a snapshot from a given point in time text<utf8, char_view, characters::internal_representation> substring = all_after(characters.begin(), characters.end(), "phrase to match"); std::vector<wide_char_t> char_array; std::copy(substring.begin(), substring.end(), char_array.begin()); etc. When you think your usage pattern favors a rope or a chain over a std::string, you only have to change the declaration of the underlying_data object and the rest works seamlessly. I think Dean favors immutability because that makes it easy for the iterator-adaptors to cache data in the representation they need (or in more local storage in a NUMA environment), but like specifying a particular byte encoding for the underlying data this would be more for convenience and performance optimization than a firm requirement. When the underlying representation is a mutable type, read-only view adapters are still free to cache chunks of data as long as they check for a fingerprint that writable view adapters leave on the underlying structure whenever they commit a change. Consider the underlying data structure as a sequence of arbitrary 'tokens' (bytes, characters, codepoints, variable-length compressed bitstrings... whatever makes sense); a read-only substring cache that depends on tokens i though j (inclusive) of version v of the underlying representation can be described by the tuple r(v, i, j), while a serialized write operation that changes the tokens in positions i though j from version v to version v+1 can be described by the tuple w(v+1, i, j). A write w(v, x, y) invalidates all or part of a read cache r(v', x', y') if and only if v' < v && x' <= y && y' >= x (and if partially invalidated, we know exactly which segment(s) are still OK.) The dereference operator of the read-only iterator then needs to check its cached v' against the underlying data structure's latest version, and if necessary skim through a small ring buffer of recent w(v, x, y) tuples to see if part of its cache must be invalidated (if v' + 1 is less than the earliest v in the ring, the reader can conservatively invalidate its entire cache.) This is a negligible amount of overhead (in the common case, a single fetch, compare, and predictable branch, and in the worst case a new transcoding that you would have had to perform anyway) per character/codepoint/byte access, and when even that is unacceptable you can simply cache a representation of the string in a buffer of known encoding and make everything else adapt to /your/ data layout. I'm intentionally not delving into the details of synchronizing reads and writes between different threads, as std::string and char[] don't provide that either, but if you really need some views to provide their own synchronization this is a (relatively) straightforward place to build it in. >1. Why can't this byte storage type not be used for all kinds of things; is not 'string' a quite bad name for it, since it is neither a string according to most programming >languages (see above) nor according to that CS definition that you are alluding to (unless you consider uninterpreted bytes to be symbols, but be quite aware that those >'symbols' would have nothing - or very little - to do with the symbols of the text represented through your construct.) Wholeheartedly agree; the view should have a name like 'text' (or 'characters', 'codepoints', 'bytes', etc.) and the underlying data structure can be string, rope, vector<char>, or boost::not_invented_yet. Sure, views don't completely solve the problem of legacy APIs that require a persistent, writable reference to a block of text (e.g.a text entry widget that maps its input to a character buffer); if you're lucky to can map the widget to the underlying_representation structure and create the views you need for other parts of the program. If you're not lucky, you might have to make a separate copy for each legacy interface and check periodically or on-demand for changes, but I'd still much rather use a data structure that forces me to make explicit copies than one that encourages me to risk sharing a single buffer between APIs that may not make the same encoding assumptions.

1 0

Survey: What should an immutable byte sequence data structure be named?
by Gregory Crosswhite 29 Jan '11

29 Jan '11

Hey everyone, To gather more data about what the community thinks an immutable byte sequence data structure should be called (given that "string" has already been taken), I have created the following poll: https://catalyst.uw.edu/webq/survey/gcross/123312 If you have an opinion on the matter, please consider visiting the above link and submitting your favorite name. Some names that have been tossed around are istring, immutable_string, chain, rope, yarn, twine, cord, but don't feel limited to these choices. Cheers, Gregory Crosswhite

7 7

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Dean Michael Berris" <mikhailberis(a)gmail.com> wrote : > On Sat, Jan 29, 2011 at 8:07 PM, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > Dean Michael Berris wrote : > > > >> > >> But c_str() doesn't have to be part of the string's interface. > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for > "boost::chain" > > > > And this is precisely my point as well: the one that uses boost::chain > is perfectly suited for this kind of use case in both efficiency and > clear-cut semantics. I for one don't like to make to_string() a member > either -- I much rather make it a conversion operator so boost::chain > (if we're going to call it that) can be used where interfaces take a > std::string. > [Note: I'm all for chains/ropes/etc, only looking for corner cases] I definitely agree for my example, which is a pure rope demo. linearize(chain) can give a c_str at no cost for trivial chains, and is not heavier than std::string::operator+ for non-trivial chains. Cool. Now looking at Artyom example makes me consider the quite common case where the desired output is not c_str but std::string itself. Add move optimizations on top of that: func_taking_std_string ( /*linearize*/ (my_chain_func ())); func_taking_std_string ( (my_string_func ())); No matter the way you put it, you have one unnecessary allocation, because std::string has no move constructor from chain (yet). For people eventually throwing their boost::chain into std::string, we're basically killing all move/RVO optimizations. Am I missing something? Ivan

2 1

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 29 Jan '11

29 Jan '11

Anders Dalvander wrote: > On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: >> // conversion for Windows API >> std::vector<wchar_t> vec; >> vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); > >I spy with my little eye a potential crash waiting to happen. >Code-points != Code-units. Dang, you're right. I used the wrong term. This is why Unicode correctness is so hard. So much for my graceful introduction to the mailing list. :-) Joe

1 0

Re: [boost] Survey: What should an immutable byte sequence data structure be named?
by Andrew Sutton 29 Jan '11

29 Jan '11

I agree with Dave. Buffer. Python uses "frozen" to describe the same (similar?) property for sets. On Jan 28, 2011 3:10 PM, "Dave Abrahams" <dave(a)boostpro.com> wrote:

5 7

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Yakov Galka" <ybungalobill(a)gmail.com> wrote: > On Sat, Jan 29, 2011 at 14:07, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for > std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c > for > > "boost::chain" > > > > Aren't they perform the same? Actually with lazy evaluation the latter > will > be faster. > For this example, I agree. I'm only stressing the marketing issue. Eventually, we'll need figures here. Big-sized font figures. Ivan

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

Dean Michael Berris wrote : > On Sat, Jan 29, 2011 at 5:24 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > > - > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> > >> On Sat, Jan 29, 2011 at 3:02 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > > >> > It would turn away 90% of users. > >> > > >> > >> It might turn you away because you obviously love std::string. > >> Generalizing is a different matter and is largely a hot-air blowing > >> exercise that is futile for convincing anybody. > >> > > > > I would say it more clear: > > > > 1. All users that use C libraries and need c_str() at boundaries > > And this is a huge amount of users that need to communicate > > with modules that are already working and ready but written in C. > > > > And this is about of half of libraries there is C is the lowest > > level API that allows easy bindings to all languages. > > > > But c_str() doesn't have to be part of the string's interface. *My* *guess* is that Artyom think that: os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string is dramatically faster than: os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain" Regardless of the validity of my present guess, I'm quite sure that this concern (and other similar ones) will be shared many developpers. Ivan

3 2

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: > // conversion for Windows API > std::vector<wchar_t> vec; > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); I spy with my little eye a potential crash waiting to happen. Code-points != Code-units. vec has room for N code-units, but 2*N code-units may be written to it if mystring contains non-BMP characters. "Corrected" code: std::vector<wchar_t> vec; vec.resize(count_codeunits<wchar_encoding>(mystring.begin(), mystring.end())); convert<wchar_encoding>(mystring.begin(), mystring.end(), vec.begin()); I think a lot of these potential crashes could be prevented if the iterator of the new string-type (chain,text,tier,yarn) would only expose (const) code-points. Actual code-units would be hidden, and only accessed using a facade/adapter view/iterator. auto u8v = make_view<utf8_encoding>(mystring); auto u16v = make_view<utf16_encoding>(mystring); for (auto codepoint : mystring) {...} for (auto u8codeunit : u8v) {...} for (auto u16codeunit : u16v) {...} I also think there isn't a reason that the new string-type *has* to be UTF-8 internally. It could be UTF-16, UTF-32, SCSU, or CESU-8 internally for that matter. Making a view from the internal encoding to an external encoding when both encodings are the same should be a no-op. Regards, Anders Dalvander -- WWFSMD?

1 0

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 23:04, Artyom<artyomtnk(a)yahoo.com> wrote: >> > // conversion for Windows API >> > std::vector<wchar_t> vec; >> > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); >> > HRESULT hr = WriteFile(handle, vec.data(), vec.size(),&dwBytesWritten, >> > NULL); >> > ... >> > > Notice vector is not string and it requires additional copy If std::string is UTF-8 encoded (as you are suggesting, correct?), then you also requires additional copy: // conversion for Windows API std::string u8s = ...; std::wstring u16s = convert_to_utf16(u8s); HANDLE h = CreateFileW(u16s.c_str(), ...); Regards, Anders Dalvander -- WWFSMD?

2 1

[web] Broken link.
by Mostafa 29 Jan '11

29 Jan '11

FYI: on https://svn.boost.org/trac/boost/ , the following link is broken: "http://svn.boost.org/trac/boost/browser", see "You can browse the Boost Subversion repository online or retrieve Boost via ...". Mostafa

1 0

Re: [boost] [string] Realistic API proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> wrote : > Hello All, > > I'd like to provide a realistic string API proposal: Thanks for your contribution. I do have a naïve question: What happens to your extensions when "Char" template argument is not char? Do they still have a meaning ? Ivan

2 1

Re: [boost] [string] proposal
by Joe Mucchiello 28 Jan '11

28 Jan '11

On Jan 28, 2011, at 12:59 PM, Dean Michael Berris wrote: > > And I stopped before I write too much -- the initial version is > already up: >https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > > -- I'll give it more information and the actual interfaces and > implementation as soon as I get some Z's. :) > Hi, I have a question. You keep saying that the string (or chain) has no encoding the string is "just a sequence of bytes" but that doesn't make sense. The bytes have to have some form of encoding otherwise how do the adapter classes know how to convert the sequence of bytes into an encoded sequence? When you say the string has no encoding do you simply mean the default encoding is implementation dependent? Did I miss where you said this somewhere? Oh, and I see the value in an immutable string. I just think you are still at such a high level that it's hard to see where you are going for some people. Joe

2 1

Re: [boost] [Boost-users] Git vs SVN (was: Re: What's happened to Ryppl?)
by Dave Abrahams 28 Jan '11

28 Jan '11

[moved to developers' list] On Fri, Jan 28, 2011 at 8:48 AM, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > May I suggest that to keep signal/noise ratio on the list to acceptable > level, we don't have a general VC shootout discussion. It will never lead > to anything. +1, but I don't think anyone intended to do that. > Rather, the parties interested in having Boost switch to any > version control system that is not SVN should propose a specific plan, > including hosting, administration, adjustment of all scripts, new workflows > for Boost maintainers and authors of proposed libraries, etc? > > If would be seriously not funny if 1000 messages later we'll find that > git is about to solve every problem on earth, but there's nobody to > do *complete* transition and onging maintenance. I think what you've just said is an important part of the discussion we should be having right here and now. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[mpl] Using transform problem and solution
by Edward Diener 28 Jan '11

28 Jan '11

I have a boost::mpl::vector of nullary metafunctions and I need to transform it into a sequence of the metafunction's inner types. As in: typedef boost::mpl::vector<boost::mpl::identity<int> > tvec; typedef boost::mpl::vector<int> tvecinner; So I try boost::mpl::transform: typedef typename boost::mpl::transform<tvec,_1>::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); But that does not work and the assert fails. Evidently my _1 is not working by itself although it seems as if it should because it is a placeholder expression and its inner type is what I want. So I try: template <class T> struct tself : T { }; and now instead: typedef typename boost::mpl::transform<tvec,tself<_1> >::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); works fine and the assert succeeds. But that 'tself' hack seems like it should be really unnecessary. Have I missed something cleaner and easier ?

3 3

Trac down?
by Beman Dawes 28 Jan '11

28 Jan '11

I'm getting a blank page when I try to access svn.boost.org/trac/boost/ That's a serious impediment to building the 1.46.0 beta. I really need the release manager's checklist from the trac. Are others able to access Trac? --Beman PS: The good news is that SVN seems to be running really well, with none of the slowness and server errors that were a problem several weeks ago.

5 8

[Boost.Algorithm] Proposal for addition of a new algorithm: ThreeWayMerge
by Aleric Inglewood 28 Jan '11

28 Jan '11

Greetings everyone. I don't think that Boost.Algorithm exists: I only saw it refered to on mailinglists. I looked at the existing libraries, but I'm not sure where this would fit in. I'd like to propose the addition of a new algorithm, very much like std::set_union and companions, that I came up with recently. This algorithm does a three-way merge of containers. Comparing it to std::set_union, which needs five iterators to be passed, and a compare functor (two iterators for the range of input 1, two iterators for the range of input 2 and one output iterator), the three_way_merge algorithm takes three iterator ranges and one output iterator, so it takes seven iterators. The algorithm also takes two functors: a compare and an is_equal. The former should be the ordering Predicate used with the containers (they must be ordered containers, like std::set or set::map), while the is_equal functor is usd to compare the "payload" of the data (which is not part of the sorting key). The algorithm applies trivial merge rules in all cases where the merge is trivial, and calls a third functor to perform the three-way merge of the payload in those cases that a three-way merge is not trivial. In it's current form, my algorithm looks as follows: https://github.com/AlericInglewood/contribmerge/blob/master/src/three_way_m… I used it (in that project) to three-way-merge a file with a specific format: a list of contributors, each with a list of contributions. The algorithm is used recursively (which is very neatly showing it's true power, of course). For this usage example, please see https://github.com/AlericInglewood/contribmerge/blob/master/src/contribmerg… Aleric

1 0

Re: [boost] [string] proposal
by Anders Dalvander 28 Jan '11

28 Jan '11

On Thu, 27 Jan 2011 12:51, Nevin Liber <nevin(a)eviloverlord.com> wrote: > I'd like to see this broken up into three discussions: > > 1. Immutable strings. Immutable or not, I don't see a direct use for modification of individual code-units (e.g. char, wchar_t) in a string. Too many things can go wrong. Some kind of manipulation of code-points, yes, but not code-units. Anyway, code-points are not the end either. Multiple code-points may be needed to represent a grapheme, using combining characters. And sometimes a single code-point can represent several graphemes, such as ligatures. > 2. utf8 strings. Although I personally prefer UTF-8 encoded strings, the internal encoding is more or less irrelevant for an implementation based on rope or similar non-contiguous data structure. I believe this is what Dean Michael Berris is suggesting. I think this is especially true if direct access to individual code-units are prevented. For an implementation using a contiguous data structure and providing a constant time c_str member function I'd really want to see some option to set the internal encoding of strings. Performance-wise it may be preferred to use UTF-16 internally when using for example Win32 API, if an extra copy can be avoided. > 3. Unrealistic pipe dream about replacing std::string. Replacing std::string will never happen. Deprecating std::string in favor of std::text/std::unicode/std::xstring may happen in the long run. Regards, Anders Dalvander -- WWFSMD?

2 1

[signals2] -no instance of overloaded function
by Tal Agmon 28 Jan '11

28 Jan '11

Hi All, I get error no instance of overloading ... when using <memory> shared_ptr can anyone explain why? tested on: windows7 vc100 // not working //#include <memory> // fail to compile //using std::tr1::shared_ptr; // works #include <boost/shared_ptr.hpp> // works find using boost::shared_ptr; [code] #include <iostream> #include <boost/signals2/signal.hpp> class Reporter { public: explicit Reporter(const std::string& s) : s_(s) {} void says() const { std::cout<< "news : " << s_ << std::endl; } private: std::string s_; }; class NewsStation{ public: void displayNews(const Reporter& r) const { r.says(); } }; int main() { using namespace boost::signals2; typedef signal<void (const Reporter&) > signal_type; shared_ptr<signal_type> signalPtr(new signal_type); typedef shared_ptr<NewsStation> news_station_ptr; Reporter tal("when using std:tr1::shared_ptr --> no instance of overloaded function, matches the argument list) "); news_station_ptr newsStationPtr(new NewsStation); signal_type sigNews; sigNews.connect( signal_type::slot_type( &NewsStation::displayNews, newsStationPtr.get(), _1).track(newsStationPtr)); sigNews(tal); } [code]

1 1

Re: [boost] [signals2] -no instance of overloaded function
by Ivan Le Lann 28 Jan '11

28 Jan '11

----- "Tal Agmon" <tal.boost(a)gmail.com> wrote : > Hi All, > > > I get error no instance of overloading ... when using <memory> > shared_ptr > can anyone explain why? > > tested on: > windows7 vc100 > > (snip) > sigNews.connect( signal_type::slot_type( > &NewsStation::displayNews, newsStationPtr.get(), > _1).track(newsStationPtr)); > sigNews(tal); > } Just a bet : I suspect the track method exspects a boost::shared_ptr. Or something a boost::shared_ptr can convert to. Ivan.

2 1

[iterator] Unmerged changes
by Daniel James 28 Jan '11

28 Jan '11

Hi, I've been looking through the unmerged changes in the iterator library. I think it should all be merged/fixed/reverted for 1.47. These seem to be the outstanding changes: An old fix from David Abrahams: https://svn.boost.org/svn/boost/changeset/58012 function_input_iterator from Dean Michael Berris: https://svn.boost.org/svn/boost/changeset/62615 https://svn.boost.org/svn/boost/changeset/62710 The result_of changes (partially merged, but will be reverted for 1.46): https://svn.boost.org/svn/boost/changeset/62625 https://svn.boost.org/svn/boost/changeset/68205 Any comments on these? Anyone willing to take charge, or shall I deal with them? Daniel

2 1

[string] --> [text] ?
by Gregory Crosswhite 28 Jan '11

28 Jan '11

Hey everyone, Since there has been a lot of talk about what the name of a new immutable string class should be, may I toss the name "boost::text" into the ring? The advantage of this name is that it explicitly conveys what it is meant for: working with human-readable text encoded in some implementation-specific form. The name "string" would then continue to have its current interpretation as a string of contiguous 8-bit chars. It has also been suggested that different classes be created for different UTF encodings. I propose that boost::text have the internal encoding be an implementation (and potentially platform-specific) detail. Since at the end of a serious of manipulations with the rope-like data structure one will have to do a final transformation to convert the text into a string of bytes anyway, that provides a natural point at which the desired encoding of the string of bytes can be specified. That is, given a boost::text object "t", one could convert it into a UTF-8 string by calling "t.utf8_c_str()", a UTF-16 string by calling "t.utf16_c_str()", and so on, depending on what the underlying API is expecting. Some of these calls might require recoding the text to a different encoding, so the internal encoding of boost::text could be optimized to whatever is most likely to be needed on that platform so that it is least likely to need recoding. Alternatively, the encoding could be specified as a parameter to the constructor and be carried around as a runtime parameter since nobody needs to know what it is until the final encoding of the string. Thoughts? Cheers, Greg

4 3

[Review][GIL] Boost.GIL IO and Toolbox extensions have been ACCEPTED into Boost
by Mateusz Loskot 27 Jan '11

27 Jan '11

Dear All, The formal review of IO and Toolbox extensions for Boost.GIL [1] ended on December 17th, 2010 [2] The review subject was not a standalone library but a part of whole - an extension to existing Boost.GIL. The review result: ACCEPTED Number of received discussion and feedback posts is ~140. I consider most of them in-topic, significant and also insightful. Reviewers pointed issues already known from previous discussions on the mailing list as well as new topics regarding the design and implementation of the extensions. Also, issues related to the library itself (Boost.GIL) were addressed. Some of them could be considered ideas for future works and improvements. It is remarkable, most (if not all) of the discussions were focused on the IO extension. None of the submitted reviews include comments to the Toolbox extension. Formally, the review concluded with 1 NO and 7 YES votes. Some of the YES votes are considered as conditional and number of changes were requested by the reviewers. The following changes should be addressed before the extensions appear in the Boost mainstream: 1. Documentation is adequate, but requires clean-up and fixing of lots of typos. 2. Additional tests are added to exercise currently untested error cases that result in a longjmp should be added. They should pass on all platforms officially supported by Boost. 3. Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. 4. The requirements for adding new file formats / backends to be made more explicit. This means defining concept for a file format reader/writer, etc. and adding new file formats would constitute providing models for these concepts. 5. Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the file name. 6. Support for different backends for the same image formats. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. 7. Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. The reviewers also posted a few suggestions that could improve quality of the two extensions, 1. Name of functions like read_int8, read_int16, read_int32, write_int8 in Device models suggest they return and accept signed integers, but they return and accept unsigned integers. The naming could be improved.. 2. Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. 3. Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. 4. It would be great if Christian and Domagoj could join their efforts to take the best of their libraries (IO extension implementations) to the IO extension included in Boost.GIL and collaborate for the advanced features discussed in reviews. I would like to thank Edd Dawson, Zach Laine, Domagoj Saric, Roland Bock, Lubomir Bourdev, Tom Brinkman, Phil Endecott, Kenny Riddile for reviews and others who participated in discussions. Thanks also go to Christian Henning for great work. I would like conclude recalling short comment Lubomir Bourdev included in his review. In my opinion, it is a good summary of the Boost.GIL IO and Toolbox review and generally all discussions on this subject: *** The problem with I/O is that you can never declare success. All we can hope for is push the boundary as much as we can, and leave the rest for the next update. *** [1] http://lists.boost.org/boost-announce/2010/11/0273.php [2] http://lists.boost.org/boost-announce/2010/12/0279.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 1

[context] other version with stack
by Oliver Kowalke 27 Jan '11

27 Jan '11

I've uploaded another version (0.5.0) which accepts an stack (instead of an stack-allocator) which will be stored (moved) inside boost::context. the implicit interface of the stack looks like: class my_stack { public: void * address() const; std::size_t size() const; }; boost::protected_stack stack( 1024); boost::context ctx( boost::context::create( my_fn, 0, stack) ); Oliver

1 0

[static_assert.hpp] Add BOOST_STATIC_ASSERT_MSG?
by Beman Dawes 27 Jan '11

27 Jan '11

BOOST_STATIC_ASSERT predated C++0x static_assert, so it doesn't take advantage of static_assert's message argument when static_assert is available. It would break too much code to change BOOST_STATIC_ASSERT, but we can add a new macro that does take advantage of C++0x static_assert if available. After adding this to <boost/static_assert.hpp>: + #ifndef BOOST_NO_STATIC_ASSERT + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) static_assert(B, Msg) + #else + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) BOOST_STATIC_ASSERT( B ) + #endif This test program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT_MSG( true, "should never fire" ); BOOST_STATIC_ASSERT_MSG( false, "should always fire" ); return 0; } Compiling with VC++ 10, which supports static_assert, produced: temp.cpp(7) : error C2338: should always fire Compiling with VC++ 9, which does not support static_assert, produced: temp.cpp(7) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] Comments? --Beman

6 6

[mpl] Metafunction to extract type
by Edward Diener 27 Jan '11

27 Jan '11

Does MPL already have a metafunction which takes a type, which is a nullary metafunction, and returns the nullary metafunction's nested type ? As in: template < class T > struct get_type : T { };

2 3

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 27 Jan '11

27 Jan '11

I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. I'm a retired FreeBSD committer, I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage http://www.freebsd.org/releng/ Anyway, the way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message and commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html Reviewed by commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag. The commit will fail without it and if someone commit with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. There are other bits worth noting, acls apply to different parts of the tree (doc-re vs src-re), but I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

----- "Robert Stewart" <Robert.Stewart(a)sig.com> wrote : > > That's a bad analogy. std::auto_ptr was deprecated, but not in favor > of another std::auto_ptr but rather by std::shared_ptr. That's off-topic but I think you meant unique_ptr instead of shared_ptr. Ivan.

2 1

[V1.46] [Iterator] Ask for release notes modification
by Michel MORIN 27 Jan '11

27 Jan '11

Hi, I have some comments on the Boost 1.46 release notes for Boost.Iterator. (http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_…) Here are the release notes for Boost.Iterator: * fixed problem with `implicit_cast` ([@https://svn.boost.org/trac/boost/ticket/3645 #3645]) * added `function_input_iterator` ([@https://svn.boost.org/trac/boost/ticket/2893 #2893]) * `transform_iterator` now uses `boost::result_of` to determine functor result type ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) The first item seems OK :) The second item needs to be deleted, since `function_input_iterator` is not merged into release branch. The third item also needs to be changed. As the release notes say, `transform_iterator` now uses `boost::result_of` to determine functor result type (in prior versions, it uses `result_type`). But there is a bug: it should use `boost::result_of<Iterator::reference>` as the documentation says, but it uses `boost::result_of<Iterator::value_type>`. (This was fixed in trunk a week ago, but it was too late to merged to release.) This bug makes subtle errors and confuses the users. Is it better to mention the bug in the release notes explicitly? Something like: * BUG: `transform_iterator` uses `boost::result_of<Iterator::value_type>` to determine functor result type instead of `boost::result_of<Iterator::reference>` ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) Or simply delete this item? Regards, Michel

6 11

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

Artyom wrote : > > > > So you do not consider the fact the following code compiles (and > runs!) > > cleanly as a painful problem? > > > > std::string s = get_utf8_string(); > > s[42] = '?'; > > > > It is fine code. Why? Because if you assign s[42] you probably > know why you are do it and you most likely know that there is > a some ASCII character there. > I want more safety. And opacity is one way to it. I consider that stating "The code is OK because you know what you're doing" is an offense to all safety efforts put into C++ and its standard library. Sorry for the tone, but I failed to express my views in another way. Non throwing failures somewhat disturb me. Especially if you can design a failsafe interface. > > > I consider that std::string is cool as an internal for a > Boost.Locale > > implementor, not as a standard API for encoded strings that should > be > > used by all C++ developpers. > > > > Seems to me you hadn't seen Boost.Locale code and what does it > does. > I've seen it and toyed with it, and it's great. I have no problem with Boost.Locale, I have a problem with all the mess than can be done with the string type it has to publicly use today. And by the way, you're the one who stated that encoded string processing should be done by a domain expert library. I'm only exspecting you to translate this into : we need a more opaque string. Ivan

1 0

[threads] namespace & externs
by scot shinderman 27 Jan '11

27 Jan '11

Boosters, In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage? When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper. thanks! -s-

3 3

[function_types] Determining whether a type is a function_types tag type
by Edward Diener 26 Jan '11

26 Jan '11

Is there any way to determine at compile-time whether a type is a function_types tag type ? It seems that there are too many possibilities, both the single named tag types and the combination 'tag' template.

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 26 Jan '11

26 Jan '11

----- "Nevin Liber" <nevin(a)eviloverlord.com> wrote : > On 21 January 2011 11:56, Dean Michael Berris > <mikhailberis(a)gmail.com>wrote: > > > No changing arbitrary content in the string. Concatenation is a > > process of creating new strings. > > > > Ultimately the underlying string should be efficient > > > Please describe how you are going to make this efficient, if > concatenation > effectively requires an allocation (once past the small string > optimization) > and a copy. > Isn't rope worth a try here ? Ivan.

4 5

Review request: auto-index tool
by John Maddock 26 Jan '11

26 Jan '11

I'm not sure if we're doing reviews of tools - we haven't in the past - but I thought it would be good to get feedback anyway... Auto-index is a tool for semi-automating the task of adding an index to quickbook/boostbook/doxygen/docbook documentation. Auto-index acts at the docbook level to scan for terms in a concordance script-file, but can also scan headers for classes, typedefs, functions and macros to index and a lot more besides. Auto-index supports multiple indexes (for example class, function, macro and typedef indexes out of the box), and can either delegate the actual index formatting to the XSL stylesheets, or produce the index itself (faster, also better looking for HTML indexes). Code is in the sandbox under tools/auto_index, documentation can be viewed online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html Currently the math, type_traits and spirit libraries are using this tool in trunk to produce indexes - take a look at those libraries to see the sort of indexes produced. Cheers, John.

10 23

[mpi] Naming of Python extension
by Vladimir Prus 26 Jan '11

26 Jan '11

At present, when both mpi and python are configured/detected, Boost.MPI tries to build a python extension which is named, on Linux, mpi.so. When building with --build-type=complete, an attempt to build that file with several properties is made, which Boost.Build detects and complains about. This was the case for several releases, and nobody seemed to care, but it's still not good. So, could Boost.MPI maintainers express their preference for either: - Building one variant of mpi.so, no matter what, in which case what variable (debug/release, single/multi threaded)? - Building several, differently named or installed in different places, variants of mpi.so Thanks, Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

2 2

Intel on Win32 and C++0x support?
by John Maddock 25 Jan '11

25 Jan '11

Can anyone with Intel on Win32 let me know whether the compiler supports any C++0x features in default MSVC compatibility mode, in case it helps the Linux compiler appears to have: static_asserts v11 and later rvalue refs and delctype v12 and later but only when -std=c++0x is set. Thanks, John.

2 1

[process] Arguments and Context concepts
by Vicente Botet 25 Jan '11

25 Jan '11

Hi, Where can I find the concept behind the template parameters Arguments and Context in template<typename Arguments, typename Context> child create_child(const std::string & executable, Arguments args, Context ctx); Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/process-Arguments-and-Context-concepts-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

[V1.46][Spirit] request for late minute changes to release branch
by Hartmut Kaiser 25 Jan '11

25 Jan '11

Hey release managers, With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably. Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid. We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit. What would you suggest? Regards Hartmut --------------- http://boost-spirit.com

7 24

[1.46.0] Beta status
by Beman Dawes 25 Jan '11

25 Jan '11

We are holding for a Boost Build merge. As soon as that's done, and tests cycled, AFAIK we are ready for the beta. If anyone is aware of any other showstoppers, please let us know right away. Thanks, --Beman

2 1

[config][pathscale] Configurations for older versions
by Daniel James 25 Jan '11

25 Jan '11

Looking at the failures for patchscale, they seem to be happening because the configuration is only set for '__PATHCC__ >= 4' and tests are run using Pathscale 3.2. This is a new configuration file so I think we should revert it on the release branch and try to fix it on trunk for 1.47. I don't know anything about the compiler, but for a start I think we should at least set the 'BOOST_NO_' macros for all versions. Does that sound reasonable? Daniel

4 8

GSoC 2011 - Do we need to starting thinking about it?
by Paul A. Bristow 25 Jan '11

25 Jan '11

I recall that last year, Boost didn't start thinking about possible projects to suggest to potential GsoCoders until rather late. Perhaps we should *start* thinking reasonably soon? Is someone going to take on the task of setting up a Google Group to solicit and discuss ideas? Paul PS I'm not volunteering! PPS But I do have an idea ;-) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

9 21

[smart_ptr] Patch submitted for #1113
by Nathan Crookston 25 Jan '11

25 Jan '11

All, I submitted a patch for ticket #1113 [1] which allows statements like the following: boost::shared_array<int> pNonConst; boost::shared_array<const int> pConst = pNonConst; while preventing treating arrays polymophically. It has been tested on windows with VC8, VC10, g++3.X and g++4.X. Additionally it has been tested on solaris with g++3.4. I didn't modify the tests, but running them seems to produce the correct output. I'd appreciate it if someone could take a look at it, perhaps applying it if it looks good. Thanks, Nate [1] <https://svn.boost.org/trac/boost/ticket/1113>

1 0

Re: [boost] What's happened to Ryppl?
by Dave Abrahams 25 Jan '11

25 Jan '11

[Redirecting replies to the boost developers' list; we should have been there nearly from the beginning. Anyone who wants to see the earlier parts of the thread should look to http://groups.google.com/group/boostusers/browse_thread/thread/6d0d01eb3cac…] Hi Robert, Could you please use standard quoting? I am having trouble separating the parts you wrote below from what Eric wrote. Thanks, Dave At Tue, 25 Jan 2011 09:06:19 -0800, Robert Ramey wrote: > > Eric Niebler wrote: > > A lot of work remains --- that is, if it's also our intention to > modularize boost and have a functioning cmake build system, too. > > At least, modularization seems like it would be a good thing to do at the > same time. And nobody is working on a bjam system for modularized boost. > > *** I don't believe there is any reason to couple modularization of boost to > any particular build system. > I use bjam to build and test the serialization library on my local machine. > I just set the current directory to libs/serialization/test and run bjam > with some switches. This builds/updates the prerequisites to the > serialization library, builds the serialization library, then builds and > runs the tests. (and in my case builds a table of test results since i use > library status.sh). I'm would expect that I could the same with CTest. > > The key issue is that the build system permit the building of just one > "module" (and its necessary prerequisites). Bjam (and hopefully ctest) does > this now. Building of "all" of boost is just the building of each module. > Building of some alternative "distribution" is just the building of each of > the component modules (and their prequisites). There isn't even any reason > why each module has to use the same build system. > > <idle speculation> > Is it feasible to have both git and svn development going on > simultaneously? Two-way synchronization from non-modularized svn boost > to modularized git boost? Is that pure insanity? > </idle speculation> > > *** By the same token, a "modularized" boost needn't require that all > modules use the same source control system. Ideally, the build for each > module would use checkout/update the local copy of the module according to > the "configuration file" (...v2 or ctest.?). > > Once the procedure for for building a module is moved to the module rather > than invoked "from the top", modularization can proceed incrementally. > > Robert Ramey > > -- > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[context] new version with stack-allocator
by Oliver Kowalke 25 Jan '11

25 Jan '11

boost vault contains a new version (0.4.0) where the user can provide its own stack allocator (the lib comes with a protected-stack allocator). Oliver

2 3

[context] build issue with context-0.3.5
by Charlls Quarra 25 Jan '11

25 Jan '11

Hi Oliver, First of all, thanks for updating your context library. I might be wrong, but i think yours is currently the only supported coroutine library for c++ which is a candidate for boost. So kudos to you for that effort that you are doing. I'm having a build error on the 0.3.5; (this is on ubuntu linux x86 platform) $ bjam -a -toolset=gcc cxxflags=-std=c++0x architecture=x86 instruction-set=i686 --with-context nBuilding the Boost C++ Libraries.nn ...patience... ...found 230 targets... ...updating 8 targets... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o In file included from libs/context/src/context_uc_posix.cpp:9: ./boost/context/context.hpp:24: error: variable ‘boost::contexts::BOOST_SYMBOL_EXPORT boost::contexts::context’ has initializer but incomplete type ./boost/context/context.hpp:26: error: expected primary-expression before ‘private’ ./boost/context/context.hpp:26: error: expected ‘}’ before ‘private’ ./boost/context/context.hpp:26: error: expected ‘,’ or ‘;’ before ‘private’ ./boost/context/context.hpp:27: error: expected unqualified-id before ‘private’ ./boost/context/context.hpp:27: error: expected constructor, destructor, or type conversion before ‘&’ token ./boost/context/context.hpp:32: error: expected constructor, destructor, or type conversion before ‘;’ token ./boost/context/context.hpp:34: error: expected unqualified-id before ‘public’ ./boost/context/context.hpp:41: error: typedef ‘boost::contexts::unspecified_bool_type’ is initialized (use decltype instead) ./boost/context/context.hpp:41: error: expected primary-expression before ‘)’ token ./boost/context/context.hpp:45: error: variable or field ‘unspecified_bool’ declared void ./boost/context/context.hpp:45: error: expected primary-expression before ‘)’ token ./boost/context/context.hpp:47: error: ‘context’ does not name a type ./boost/context/context.hpp:49: error: ‘context’ does not name a type ./boost/context/context.hpp:52: error: ‘context’ does not name a type ./boost/context/context.hpp:55: error: expected constructor, destructor, or type conversion before ‘;’ token ./boost/context/context.hpp:57: error: expected class-name before ‘(’ token ./boost/context/context.hpp:59: error: expected constructor, destructor, or type conversion before ‘(’ token ./boost/context/context.hpp:61: error: expected constructor, destructor, or type conversion before ‘&’ token ./boost/context/context.hpp:63: error: variable or field ‘jump_to’ declared void ./boost/context/context.hpp:63: error: ‘other’ was not declared in this scope ./boost/context/context.hpp:65: error: variable or field ‘swap’ declared void ./boost/context/context.hpp:65: error: ‘other’ was not declared in this scope ./boost/context/context.hpp:67: error: non-member function ‘bool boost::contexts::operator!()’ cannot have cv-qualifier ./boost/context/context.hpp:67: error: ‘bool boost::contexts::operator!()’ must have an argument of class or enumerated type ./boost/context/context.hpp:69: error: expected type-specifier before ‘unspecified_bool_type’ ./boost/context/context.hpp:73: error: variable or field ‘swap’ declared void ./boost/context/context.hpp:73: error: ‘context’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘l’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘context’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘r’ was not declared in this scope ./boost/context/context.hpp:78: error: ‘contexts’ has not been declared ./boost/context/context.hpp:80: error: expected declaration before ‘}’ token ./boost/context/context.hpp:43: warning: ‘boost::contexts::default_stacksize’ defined but not used "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -march=i686 -pthread -fPIC -std=c++0x -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o" "libs/context/src/context_uc_posix.cpp" ...failed gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o... ...skipped <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>libboost_context.so.1.43.0 for lack of <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>context_uc_posix.o... ...skipped <pstage/lib>libboost_context.so.1.43.0 for lack of <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>libboost_context.so.1.43.0... ...skipped <pstage/lib>libboost_context.so for lack of <pstage/lib>libboost_context.so.1.43.0... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/link-static/threading-multi/context_uc_posix.o gcc.archive bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/link-static/threading-multi/libboost_context.a common.copy stage/lib/libboost_context.a ...failed updating 1 target... ...skipped 3 targets... ...updated 4 targets... - Charles Quarra

2 2

[SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 25 Jan '11

25 Jan '11

Hello, I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I? Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point. For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue. So does it worth the effort? So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily). Regards, Artyom

22 53

[assert][lightweight_test] Quick review of proposed changes
by Beman Dawes 24 Jan '11

24 Jan '11

In reviewing the "[assert] static_assert envy" thread, I agreed with Steven Watanabe: > MHO, the last thing we need is lots of minor variations that > don't add any real utility. KISS was also a factor, as I wanted to add only features that I would personally use right away, or that were needed for BOOST_ASSERT compatibility. It boiled down to the following: [assert] * Added BOOST_ASSERT_MSG(expr, msg) macro. If expr is false, outputs msg, then calls std::abort(). BOOST_DISABLE_ASSERTS behaves the same as in BOOST_ASSERT. BOOST_ENABLE_ASSERT_MSG_HANDLER enables a separate error handler. BOOST_ASSERT_MSG_OSTREAM defaults to std::cerr. User may define to specify a different output stream. * Added BOOST_ASSERT_MSG test cases to libs/utility/assert_test.cpp * Added BOOST_ASSERT_MSG docs to libs/utility/assert_test.cpp <boost/detail/lightweight_test.hpp> has the same Visual Studio output interleaving problem, so it makes sense to apply a similar fix at the same time. * Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM * BOOST_LIGHTWEIGHT_TEST_OSTREAM defaults to std::cerr. User may define to specify the output stream for messages. Updated files: http://mysite.verizon.net/beman/assert.hpp http://mysite.verizon.net/beman/assert.html http://mysite.verizon.net/beman/assert_test.cpp http://mysite.verizon.net/beman/lightweight_test.hpp Let's do a quick review before these get committed to trunk. Say until Monday morning. (They won't go in 1.46.0; far too late for that.) Comments welcome! --Beman

2 6

Boost.Graph Metagraph project
by Fernando J. Iglesias García 24 Jan '11

24 Jan '11

Hi all, I am new in Boost libraries and have heard about Boost.Graph and metaprograms. I think there is an ongoing project related called Metagraph. How can I get in collaboration with the people working on it? Regards, Fernando.

7 13

[container] documentation
by Gordon Woodhull 24 Jan '11

24 Jan '11

Hi Ion, I read over the documentation for Container. Looks like a neat library. I like the idea of a next gen STL in Boost. In the documentation, I think the recursive containers section could spell out what's going on here - I didn't catch it at first. It could just say "Recursive data structures contain elements of their own type." Perhaps with a link to http://en.wikipedia.org/wiki/Recursive_data_type. Pretty cool. Didn't this grow out of Interprocess? I'm wondering if it has somehow an improved contract with the allocator to support shared memory - or is that worth talking about? Cheers, Gordon

2 4

Re: [boost] [1.45][Serialization] fails to cross-compile usingarm-linux-uclibc toolchain
by Alex Potapenko 24 Jan '11

24 Jan '11

Robert Ramey wrote: > BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); > BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == > sizeof(int_least16_t)); These should be investigated. before commenting out. It could be detecting something unexpected in a pre-requisite library. I'm afraid I haven't neither got the knowledge, nor the skills to investigate it myself :( In case you (or someone else) are willing to investigate it for me, here's a relatively simple way to trigger these errors: 1. Checkout the optware trunk: $ svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware 2. Build the toolchain: $ cd optware; make mbwe-bluering-target $ cd mbwe-bluering; make directories toolchain ipkg-utils 3. Replace make/boost.mk from the svn with the one attached to this letter 4. Cross-compile: $ make boost # while remaining in the mbwe-bluering directory Thanks in advance, Alex

1 0

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #5111: BOOST_TR1_STD_HEADER bad on Solaris 11/stdcxx4
by Bryce Lelbach 23 Jan '11

23 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 23 Jan 2011 20:39:12 -0000 "Boost C++ Libraries" <noreply(a)lists.boost.org> wrote: > #5111: BOOST_TR1_STD_HEADER bad on Solaris 11/stdcxx4 > > this is likely because stdcxx4 resides in > /usr/include/stdcxx4/ > /usr/include/stdcxx4/ansi > there, which the config_all.hpp does not take into account and sets > BOOST_TR1_STD_HEADER inappropriately This was fixed for Pathscale - John, could you please modify the fix I made for Pathscale to apply to any toolchain using the apache/rw stdlib? - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk08lxcACgkQ9cB/V3/s9EzcHwCdGCinVPCvyKbGDPs7LHa1DoIQ c3wAn1OO39wYkj1F5BmCSmjR7zW0oaGD =WQvl -----END PGP SIGNATURE-----

2 1

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[Phoenix-3] Is Actor assignable?
by Michel MORIN 23 Jan '11

23 Jan '11

Hi, In Phoenix 3, is Actor assignable? This is necessary for filter_iterator/transform_iterator with Phoenix to be "neat" iterators. (Unfortunately, Actor is not assignable in Phoenix 2.) P.S. After writing this mail, I found this comment (What a coincidence ;-) #4853 (Actor is never assignable regardless of the template parameter) https://svn.boost.org/trac/boost/ticket/4853#comment:2 Comment (by theller): This is fixed in phoenix V3 So the answer to this question is YES. Thank you for great work, Thomas! Regards, Michel

3 18

[asio] cygwin issue
by vicente.botet 22 Jan '11

22 Jan '11

Hi, whiline runnin the asio tests (under cygwin gcc-4.3 Windows XP ) as follows bjam cxxflags="-D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501" I got a compile error ../../../boost/asio/detail/impl/win_iocp_io_service.ipp: In member function â?~void boost::asio::detail::win_iocp_io_service::do_add_timer_queue(boost::asio::detail::timer_queue_base&)â?T: ../../../boost/asio/detail/impl/win_iocp_io_service.ipp:461: error: no matching function for call to â?~boost::asio::detail::posix_thread::posix_thread(boost::asio::detail::win_iocp_io_service::timer_thread_function&, int)â?T ../../../boost/asio/detail/posix_thread.hpp:38: note: candidates are: boost::asio::detail::posix_thread::posix_thread(const boost::asio::detail::posix_thread&) I have changed the prototype as the one for win_thread and now all the tests are OK. posix_thread(Function f, unsigned int = 0); Best, Vicente

1 0

namespace boost?
by Robert Ramey 22 Jan '11

22 Jan '11

I'm doing a toy project which uses a lot of boost libraries. In the course of doing this, I'm reminded of something that has bugged me for a long time. That is the placement of lots of stuff inside the namespace boost. Now that boost is the size that it is, this can become are real barrier to making things understandable. Currently I'm looking at range and iterator libraries - but I'm no there are lots of offenders. Certain names like join, zip, map, copy, etc. ... apear in multiple libraries. I would like to use "using namespace boost" but then I'm afraid that using something like copy will be ambigiuos Could we agree that the boost namespace (and directory structure) only be used for library names. Some time ago, I caught hell for including just a couple of functions in boost/namespace and directory. But I see tons of stuff in there now. Robert Ramey

27 96

[geometry] fusion adapt is missing
by Akira.T 22 Jan '11

22 Jan '11

Hi, follow code in libs/geometry/example/c09_custom_fusion_example.cpp : #include <boost/geometry/geometries/adapted/fusion.hpp> #include <boost/geometry/geometries/adapted/fusion_cartesian.hpp> But, this header file is missing. Please add file to trunk. == Akira Takahashi Blog : http://d.hatena.ne.jp/faith_and_brave/

3 6

[1.44][serialization] Link error with polymorphic archive and BOOST_CLASS_EXPORT
by Wilson Tim-CTW024 21 Jan '11

21 Jan '11

I've run into a conflict between use of the polymorphic archives and the BOOST_CLASS_EXPORT() macro. It doesn't seem possible to use both without getting a link error. The following code illustrates the problem (yes, I know this code doesn't do anything worth doing, but it's the simplest code that demonstrates the problem): ---------------------- # include <sstream> # include <boost/serialization/export.hpp> # include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A); int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } ----------------------- This code compiles OK, but a link error is generated. I've put the full link error at the bottom of this post; the gist is an undefined reference to: boost::archive::detail::archive_serializer_map<boost::archive::detail::p olymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::ar chive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*) I can make the error go away by either: 1) Commenting out the BOOST_CLASS_EXPORT 2) Changing the type of the oarchive from polymorphic_binary_oarchive to binary_oarchive. It really looks like there's something missing from the serialization library related to the polymorphic oarchive. Thanks in advance for any help. Tim Wilson Full link error: ---------------- /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AEC2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AEC5Ev]+0x4f): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::insert(boost::archive::detail::basic_serializer const*)' /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::~pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AED2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AED5Ev]+0x24): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*)' collect2: ld returned 1 exit status

2 2

[1.44][serialization] Link error with polymorphic archive and BOOST_CLASS_EXPORT
by Wilson Tim-CTW024 21 Jan '11

21 Jan '11

(Sorry if this is a duplicate post...I sent it once, didn't see it, so I'm sending again) I've run into a conflict between use of the polymorphic archives and the BOOST_CLASS_EXPORT() macro. It doesn't seem possible to use both without getting a link error. The following code illustrates the problem (yes, I know this code doesn't do anything worth doing, but it's the simplest code that demonstrates the problem): ---------------------- # include <sstream> # include <boost/serialization/export.hpp> # include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A); int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } ----------------------- This code compiles OK, but a link error is generated. I've put the full link error at the bottom of this post; the gist is an undefined reference to: boost::archive::detail::archive_serializer_map<boost::archive::detail::p olymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::ar chive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*) I can make the error go away by either: 1) Commenting out the BOOST_CLASS_EXPORT 2) Changing the type of the oarchive from polymorphic_binary_oarchive to binary_oarchive. It really looks like there's something missing from the serialization library related to the polymorphic oarchive. Thanks in advance for any help. Tim Wilson Full link error: ---------------- /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AEC2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AEC5Ev]+0x4f): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::insert(boost::archive::detail::basic_serializer const*)' /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::~pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AED2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AED5Ev]+0x24): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*)' collect2: ld returned 1 exit status

2 1

[Process] List of small issues
by Artyom 21 Jan '11

21 Jan '11

Hello, I've made a micro review of Boost.Process, there are small issues I've found: - stream buffer implementation: underflow() you need to check the errno if it is EINTR, returning -1 and getting EINTR is not a problem and thus it should retry. sync(); Same as in underflow() - check for EINTR and retry, but also there is a problem that you do not check that you had fully written the data. For example what I write out << std::flush sync() is called and I expect the all data should be written to device, so if return value is less then the size of the buffer you should retry and write again till buffer is empty, you get error or EOF. - Windows and Unicode. You are using CreateProcessA. I would recommend to always use wide API and convert narrow strings to wide similarly to what boost::filesystem::v3 does, so for example where the global locale as utf-8 facet you would convert narrow strings to wide and run it. Notes: 1. You can also always assume that strings under windows are UTF-8 and always convert them to wide string before system calls. This is I think better approach, but it is different from what most of boost does. 2. I do not recommend adding wide API - makes the code much uglier, rather convert normal strigns to wide strings before system call. - It may be very good addition to implement full support of putback. Additional point: ----------------- I've noticed that you planned asynchronous notification and so on but I think it is quite important to add feature that provide an ability to wait for multiple processes to terminate and have timeout. It can be done using sigtimedwait/sigwait and assigned signal handlers for SIGCHLD Artyom P.S.: Good luck with the review library looks overall very nice.

21 144

Re: [boost] [string] proposal
by Ivan Le Lann 21 Jan '11

21 Jan '11

----- "Matus Chochlik" <chochlik(a)gmail.com> wrote : > Also I've uploaded into the vault file string_proposal.zip Not that I have anything against UTF-8, but is there no way to build this utf8 string class out of an encoding generic one ? Keeping your "utils" vocabulary, I see something like : template <typename encoding_utils> class encoded_string; typedef encoded_string <utf8_utils> string; // and/or utf8_string In your code, that would mean to at least move various typedefs into encoding_utils, such as code point and code unit type. And to rename various methods, of course. Regards, Ivan.

2 1

[1.46] Late changes?
by John Maddock 21 Jan '11

21 Jan '11

I've just fixed this nasty bug which manifests itself as the hypergeometric PDF calculating bogus values on certain FPUs: https://svn.boost.org/trac/boost/ticket/5095 Ignoring the new diagnostic code (not normally executed) the change is pretty trivial: https://svn.boost.org/trac/boost/changeset/68346. Is there likely to be a window where this can be merged to 1.46? Thanks, John.

2 1

geometry moved to trunk
by Barend Gehrels 21 Jan '11

21 Jan '11

hi, Boost.Geometry is moved from sandbox to trunk yesterday. Questions: 1) Will I update the two files libraries.htm and maintainers.txt within $/trunk/libs to add geometry there? 2) How will geometry appear in the trunk regression overviews? There are already many unit tests using Boost.Test and jamfiles handling them. Thanks, Barend

4 6

[assert] static_assert envy
by Beman Dawes 20 Jan '11

20 Jan '11

Whenever I write a BOOST_ASSERT macro, I'm envious of C++0x static_assert because of its ability to supply a clear error message. I'd really like to be able to write a variant of BOOST_ASSERT like this: #include <boost/assert.hpp> int main() { BOOST_EXTENDED_ASSERT(true, "This will not assert"); BOOST_EXTENDED_ASSERT(false, "This will assert"); return 0; } And then get debug mode output like this: ***** Internal Program Error - Assertion Failed ***** extended_assert_test.cpp(6): error in int main(void): This will assert Adding the code below at the end of <boost/assert.hpp> will do just that. It isn't totally ready for prime time, but it would be nice to find out if others would like something similar added to<boost/assert.hpp>. --Beman // experimental code #ifndef NDEBUG # include <iostream> # include <cstdlib> # include <boost/current_function.hpp> namespace boost { namespace assertion { namespace detail { inline void extended_assert_failed(char const * msg, char const * function, char const * file, long line) { std::cerr << "***** Internal Program Error - Assertion Failed *****\n"; std::cerr << file << '(' << line << "): error in " << function << ": " << msg << std::endl; std::exit(99999); } }}} // boost::assertion::detail # undef BOOST_EXTENDED_ASSERT # define BOOST_EXTENDED_ASSERT(expr, msg) \ ((expr)? ((void)0): ::boost::assertion::detail::extended_assert_failed\ (msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__)) #else # define BOOST_EXTENDED_ASSERT(expr, msg) #endif

15 39

Are we frozen?
by Marshall Clow 20 Jan '11

20 Jan '11

Is the release branch closed for changes for 1.46.0? If it is, may I have permission to merge change [68291] - which fixes two spelling errors in the parameter library docs? https://svn.boost.org/trac/boost/ticket/4983 -- 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 4

[serialization] de-serialization performance issue
by Brad Higgins 20 Jan '11

20 Jan '11

I have encountered a performance issue with serialization, when used with multi-index followed by a vector<size_t>. I have a reduced program below, which reproduces the issue (using boost 1.44.0). I basically have a class with a multi-index member, and a vector<size_t> member. It serializes OK, but deserialization's performance appears to be O(n^2). It seems to be getting bogged down in basic_iarchive_impl::reset_object_address(), when deserializing the vector. Any thoughts? Thanks, Brad ------------------------------------------- #include <iostream> #include <fstream> #include <sstream> #include <string> #include <vector> #include <boost/multi_index_container.hpp> #include <boost/multi_index/key_extractors.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/serialization/access.hpp> #include <boost/serialization/assume_abstract.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/nvp.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/version.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> struct DummyItem { std::size_t ordered_val_; DummyItem( const std::size_t ordered_val) : ordered_val_(ordered_val) {} DummyItem() : ordered_val_(0) {} /** * Boost serialization hook */ friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::make_nvp("ordered_val", ordered_val_); } }; BOOST_CLASS_VERSION(DummyItem,1) namespace bmi = boost::multi_index; class MultiIndexDummy { public: struct ordered_val_tag {}; typedef bmi::multi_index_container< DummyItem, bmi::indexed_by< bmi::ordered_non_unique< bmi::tag<ordered_val_tag>, BOOST_MULTI_INDEX_MEMBER(DummyItem,std::size_t,ordered_val_) > > > MultiIndexDb; typedef MultiIndexDb::index<ordered_val_tag>::type OrderedVal2Index; bool insert(DummyItem &item) { bool rc = false; OrderedVal2Index &str_idx = db_.get<ordered_val_tag>(); OrderedVal2Index::iterator str_iter = str_idx.find(item.ordered_val_); if (str_idx.end() == str_iter) { std::pair<OrderedVal2Index::iterator,bool> insert_res = str_idx.insert(item); if (insert_res.second) { rc = true; } } return rc; } MultiIndexDb db_; std::vector<std::size_t> vector_ints_; /** * Boost serialization hook */ friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { std::cout << "SERIALIZE db_\n"; ar & boost::serialization::make_nvp("db", db_); std::cout << "SERIALIZE vector_ints_\n"; ar & boost::serialization::make_nvp("vector_ints", vector_ints_); // <- THIS IS SLOW DURING INPUT } }; BOOST_CLASS_VERSION(MultiIndexDummy, 1); int main(int argc, char* argv[]) { const std::string filename("persisted_data.dat"); std::cout << "Start\n"; { MultiIndexDummy mi_map; for (int i=0; i<100000; i++) { DummyItem item(i); mi_map.insert(item); mi_map.vector_ints_.push_back(i); } std::cout << "persist the data\n"; std::ofstream out_file(filename.c_str()); boost::archive::text_oarchive oa(out_file); oa.register_type(static_cast<MultiIndexDummy*>(NULL)); oa << boost::serialization::make_nvp("id", mi_map); } std::cout << "Restore\n"; { MultiIndexDummy mi_map; std::ifstream in_file(filename.c_str()); boost::archive::text_iarchive ia(in_file); ia >> mi_map; // <- THIS IS SLOW } std::cout << "Done\n"; return 0; }

2 2

[fusion] Visual C++ 8.0 compilation errors
by Ralf W. Grosse-Kunstleve 20 Jan '11

20 Jan '11

I'm running nightly local multi-platform builds using the boost trunk. The last two nights the Visual C++ 8.0 build (Windows XP 32-bit) was broken: C:\AUTOBU~3\sources\boost\boost/fusion/sequence/ comparison/less_equal.hpp(48) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2065: 'is_native_fusion_sequence' : undeclared identifier C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected C:\AUTOBU~3\sources\boost\boost/utility/enable_if.hpp(59) : see declaration of 'boost::disable_if' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2988: unrecognizable template declaration/definition C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2059: syntax error : ',' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2039: 'type' : is not a member of '`global namespace'' boost svn rev. 68202 three nights ago still worked, rev. 68221 was the first I noticed that doesn't. VC 9 and 10 are fine, and so are many Linux and Mac builds. The failure is specific to VC 8. Ralf

2 1

[context] new version - support for Win64
by Oliver Kowalke 20 Jan '11

20 Jan '11

I've uploaded boost.context-0.3.0.zip to boost vault. The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler). supported platforms: i386, x86_64, arm, mips, ppc OS: UNIX, Windows (32 bit/64 bit) More details can be found in the documentation (included in the archive).

7 28

[Wiki] Changes in information about gcc warnings.
by Patrick Horgan 20 Jan '11

20 Jan '11

I did a first cut at adding information to the wiki https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines for the changes in GCC that let you suppress warnings locally. It's probably not useful to you, since it's only in gcc version 4.x and the ability to push and pop the current state is very recent, in 4.6. Nevertheless it needed documenting. There's a change to the behavior of #pragma GCC system_header as well. It previously had to be at file scope, and now can be anywhere in the file and affects from that point forward. The new pragma: #pragma GCC diagnostic <ignored|warning|error> "-WASPECIFICWARNINGOPTION" used like: #pragma GCC diagnostic ignored "-Wdeprecated-declarations". Prior to 4.6 this also had to be at file scope. As of 4.6 it can be at any line. With both it affects from that point forward. #pragma GCC diagnostic <push|pop> These two just showed up at 4.6 and can be at any line. Without them, the previous pragma is not that useful because if you affect the users flags they will not like you! lol! With them you can do what you really want: #pragma GCC diagnostic push #pragma GCC diagnostic "-Wunitialized" // your code here #pragma GCC diagnostic pop 4.6 is the current development trunk, so consider this a heads up. I'm trying to get from the gcc guys a good description of what preprocessor checks can be done to determine what's available when. When I get it, I'll add it to the wiki. Of course, almost all of the time warnings represent real issues and it's better to change your code to get rid of the warning and make it more correct, than to change your code to have ugly pragmas that suppress the warning. Patrick

9 25

Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]
by Brent Spillner 20 Jan '11

20 Jan '11

On 1/19/2011 11:33 AM, Peter Dimov wrote: > This was the prevailing thinking once. First this number of bits was 16, > which incorrect assumption claimed Microsoft and Java as victims, then > it became 21 (or 22?). Eventually, people realized that this will never > happen even if we allocate 32 bits per character, so here we are. The OED lists ~600,000 words, so 32 bits is enough space to provide a fully pictographic alphabet for over 7,000 languages as rich as English, with room for a few line-drawing characters left over. Surely that's enough?

6 5

Re: [boost] [1.45][Serialization] fails to cross-compile usingarm-linux-uclibc toolchain
by Alex Potapenko 20 Jan '11

20 Jan '11

Thank you, Robert! Robert Ramey wrote: > > BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); > > BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == > > sizeof(int_least16_t)); > > These should be investigated. before commenting out. It could be > detecting something unexpected in a pre-requisite library. > > Robert Ramey The one thing I'm pretty certain about know is that it is a specifically uclibc issue, since I tried building with four different arm-linux toolchains (two glibc and two uclibc ones), and while the glibc toolchains built fine, both uclibc ones failed the same assertions. How should I proceed with investigation? Thank you, Alex

1 0

Re: [boost] namespace boost?
by Brent Spillner 19 Jan '11

19 Jan '11

On 19/01/11 at 7:58 PM, Dean Michael Berris wrote: >That doesn't make me like the 'lib' name myself. Although cpp-netlib >is there, I'm just not that creative to come up with an alternate name >for it. :D When I first saw the name 'cpp-netlib' I assumed it was a numerical library. ;-)

1 0

Re: [boost] BoostCon 2011 keynote speaker
by Dave Abrahams 19 Jan '11

19 Jan '11

At Sat, 15 Jan 2011 16:56:51 -0600, Hartmut Kaiser wrote: > > Hey all, > > This is to inform you, that Hans Boehm (HP, > http://www.hpl.hp.com/personal/Hans_Boehm/) accepted to give this year's > keynote. I believe this is excellent news for the conference and for all > participants. He will have a lot to say, which directly concerns many C++ > developers. He will give us a topic for his keynote asap at which point we > should add a note to the website. This is awesome news! Hans is a C++ Committee member, probably the primary driving force behind the new C++ memory model that allows concurrency, and is also famous as the developer of a widely-used C++ garbage collector, and a bit less famous for the "rope" data structure. I know he will give a great keynote and I'm eager to hear it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

Distributed Development Process (was Re: Development Practices (Proposal Progress))
by Dean Michael Berris 19 Jan '11

19 Jan '11

On Thu, Jan 13, 2011 at 9:15 PM, Beman Dawes <bdawes(a)acm.org> wrote: > On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave(a)boostpro.com> wrote: >> >> Create a new one... I don't think we want to tweak "the process." I >> think we want to create an alternative process for people who are >> interested in following a more modern, decoupled development model. >> Eventually, if it works, the other one will die of underuse. The >> thing is that you have to make sure that your proposal doesn't clash >> with the way we do things now: for example, it can't create >> significant new work for the release managers. >> > tl; dr; -- feedback on https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess would be very much appreciated! > Excellent points! > > For example, I'd very much like to move both the libraries I maintain and my > release management work to Git. I've been using it for a while now on > various projects, including one very small (three contributors) distributed > project, and find Git preferable by a wide margin. But others will want to > stick with SVN at least for awhile. Because Git can track a Subversion > repository, it is probably possible to use both without undue trouble. > I have the same experience -- and I've worked with larger teams that have been using Git exclusively with wonderful results. It's the difference between a concurrent lock-free queue and one that has a critical section on all the member functions. One invites a lot less friction and enables more fluid workflows while the other, not so much. > While I'm leery of anything that would "create significant new work for the > release managers" on an ongoing basis, I am willing to put in some extra > work during a transition. > Cool. :) > Areas where I personally don't want any big changes yet are the Boost build > and regression testing systems. Alternatives for either of these systems > don't appear anywhere near ready for prime time WRT Boost. > Right, I haven't gotten thinking about that part yet, but I think others are already working on that front. :) > The formal review system needs a drastic rework to make it more parallel and > remove bottlenecks, but I don't have anything beyond vague feelings about > how to do that. > Yes and I intend to address that in this document: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess I haven't gotten to the part on the specifics yet but I think it would be good to get feedback on what's already there. :) -- Dean Michael Berris about.me/deanberris

3 10

review request: addition to type_traits library of has_operator_xxx
by Frédéric Bron 19 Jan '11

19 Jan '11

I would like to propose to your review the following addition to the type_traits library, available at the following addresses: https://svn.boost.org/trac/boost/browser/sandbox/type_traits http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2 The purpose of the addition is to add type traits to detect if unary and binary operators can be applied to given types. For example, is "x<y" or "!x" or "x+y" meaningful? If required, the return type of such an expression is checked to know if it is convertible to a given type. Default behaviour is to not check the return type. The following traits are added: // binary operators: template < typename LHS, typename RHS=LHS, typename RET=void > == has_operator_equal_to != has_operator_not_equal_to > has_operator_greater >= has_operator_greater_equal < has_operator_less <= has_operator_less_equal + has_operator_plus - has_operator_minus * has_operator_multiplies / has_operator_divides % has_operator_modulus && has_operator_logical_and || has_operator_logical_or & has_operator_bit_and | has_operator_bit_or ^ has_operator_bit_xor // unary operators: template < typename RHS, typename RET=void > + has_operator_unary_plus - has_operator_unary_minus ! has_operator_logical_not This new version reflects the discussions we had on the list: http://thread.gmane.org/gmane.comp.lib.boost.devel/194625 In particular about the check or not of the return type. All operators are now included and not only comparison binary operators. Example: has_operator_less<LHS, RHS, RET>::value_type is the type bool. has_operator_less<int> inherits from true_type. has_operator_less<int, int, std::string> inherits from false_type. has_operator_unary_minus<int, long> inherits from true_type. has_operator_unary_minus<double, int> inherits from true_type. has_operator_unary_minus<int, std::string> inherits from false_type. Documentation is accessible at libs/type_traits/doc/html/index.html in the archive. Regards, Frédéric PS: tested with g++ 4.4.5 on i686-linux.

14 53

[1.45][Serialization] fails to cross-compile using arm-linux-uclibc toolchain
by Alex Potapenko 19 Jan '11

19 Jan '11

Building boost 1.45 on Debian using arm-linux-uclibc toolchain fails to compile serialization lib, due to static assertions in basic_binary_?archive.hpp's at: BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(bool)); BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == sizeof(int_least16_t)); It appears to be some uclibc issue, since it builds fine using glibc toolchains. Is it safe to simply comment out these assertions? Thanks in advance, Alex

2 1

Re: [boost] [context] Implementation comments
by Andrzej Krzemienski 19 Jan '11

19 Jan '11

>>> Why is boost::thread implemented with move-semantics? >> Boost.Context is much more low level than Boost.Thread. > why? thread and context are resources - I don't see context more low > level than thread Hold on. I understand that that you are saying that context is the same level as thread. On the other hand in the reply to my question (about using boost::function) you said > boost.context is intended to be the basis of such things like coroutines > (see boost.coroutine) and fibers (see boost.fiber). Which somehow implied that Context is lower-level than Coroutine or Fiber. If you really treat Context the same level as Thread, I would suggest passing function<void()> as trampoline function. If you can afford using pimpl, you can easily change function<void()> to void(*)(void*) and void* parameters: void call( void* arg) { auto ptr = static_cast< function<void()>* >( arg ); ptr->operator(); } function<void()> trampoline = ...; context_impl( call, &trampoline ); Using function<void()> makes it easier to understand for thread users and makes the interface similar to thread, task, etc... Regards, &rzej

2 2

Re: [boost] [Boost-commit] svn:boost r67792 - in branches/release: boost/iterator
by Michel MORIN 19 Jan '11

19 Jan '11

Hi Marshall, It seems there are missing merges in changeset [67792]. <marshall(a)idio.com> wrote: > Author: marshall > Date: 2011-01-08 13:38:08 EST (Sat, 08 Jan 2011) > New Revision: 67792 > URL: http://svn.boost.org/trac/boost/changeset/67792 > > Log: > Merging fixes to release; fixes #2294 fixes #4918 fixes #3645 refs #2823 refs #1427 refs #2893 > Properties modified: > branches/release/boost/concept_check.hpp (contents, props changed) > branches/release/boost/fusion/container/list/detail/build_cons.hpp (contents, props changed) > branches/release/boost/iterator/iterator_facade.hpp (contents, props changed) > branches/release/status/explicit-failures-markup.xml (contents, props changed) > Text files modified: > branches/release/boost/concept_check.hpp | 166 ++++++++++++++++++++------------ > branches/release/boost/fusion/container/list/detail/build_cons.hpp | 3 > branches/release/boost/iterator/iterator_facade.hpp | 28 ++-- > branches/release/status/explicit-failures-markup.xml | 199 ++++++++++++++++++++++++++++----------- > 4 files changed, 261 insertions(+), 135 deletions(-) The log message says that the fixes for tickets #1427 and #2893 (#1427: transform_iterator should use boost::result_of to determine functor result type) (#2893: Function Input Iterator) are merged to release. But this changeset does nothing with iterator/transform_iterator.hpp and iterator/function_input_iterator.hpp. Regards, Michel

2 4

[Locale] Boost Locale looks for review manager:
by Artyom 19 Jan '11

19 Jan '11

Hello All, There had been recently several discussions about review process Unicode etc. I think that Boost.Locale would allow us going forward in all Unicode related stuff in Boost and it would help us to get to some standardization in all related to Unicode handling in Boost. So I'm calling for You boost users and developers to volunteer to be a review manager of Boost.Locale. Thank you very much, Artyom

3 6

[website] running_regression_tests.html
by Jim Bell 19 Jan '11

19 Jan '11

I made changes to the "Running Regression Tests" page, per the list discussions of a few weeks ago. <http://beta.boost.org/development/running_regression_tests.html> Comments welcome. Do I transfer this page to the live website myself? (If so, how? I see </development/website_updating.html>, but that doesn't quite cover it.) Please advise. Thanks in Advance, -Jim

2 1

Boost.Pool - Are you using this library, please can we have your input?
by Paul A. Bristow 18 Jan '11

18 Jan '11

Boost.Pool is the subject of a 'make-over' by Boost.Guild. (This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox). In order to permit any modification, the original (hand-written?) html documentation has been converted to Quickbook (and somewhat revised) at http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/ You can build the html docs using the jamfile.v2 in the normal way, but you will probably find it more convenient to go direct to the pdf version http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf This is fairly fully hyperlinked, and includes a reference section using Doxygen. Doxygen comments have been added to the header files (from the original html docs). (If you are a Doxygen fan, there is also a Doxyfile for generating Doxygen-style docs in the /doc/Doxygen/ folder). We are now considering some better tests, and perhaps some enhancements to the code. We'd like input from users about: 1 Things missing or wrong from the docs. More up to date references? 2 Things missing (or don't work well) from Pool. 3 New things that you would like (this is not a promise!). 4 Examples of your use. Perhaps you built some during your development that could be used? 5 Better tests. Thanks. Paul PS Don't panic - the release version will not be changed without a mini-review. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 2

[1.46.0] [units] test_output failing all release regression compilers
by Beman Dawes 18 Jan '11

18 Jan '11

http://beta.boost.org/development/tests/release/developer/summary.html is looking pretty good for most libraries, but units test_output is failing all release regression compilers. Can we get a fix for this before the beta next week? Thanks, --Beman

4 9

Showstoppers?
by Marshall Clow 18 Jan '11

18 Jan '11

Looking in the Trac, I see 43 bugs marked as "Showstoppers". Are any/all of them worth holding up the release of 1.46 for? [ If not, I suggest that they should not be marked as 'showstopper' ] https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re… -- 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

2 1

1.46 closed for major changes
by Vladimir Prus 18 Jan '11

18 Jan '11

Boosters, per our calendar, 1.46 is now closed for major changes. What constitutes a major change is up to your judgement, but please excercise care with commits. 1.46 will be closed for all changes next Monday. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

Re: [boost] [Boost-commit] svn:boost r68201
by Bryce Lelbach 18 Jan '11

18 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 16 Jan 2011 23:52:02 -0500 (EST) steven(a)providere-consulting.com wrote: > Author: steven_watanabe > Date: 2011-01-16 23:51:54 EST (Sun, 16 Jan 2011) > New Revision: 68201 > URL: http://svn.boost.org/trac/boost/changeset/68201 > > Log: > Revert addition of BOOST_NIX, etc and everything tied to it. ([66696], > [66783], [66804], [66833], and [66834]) Removed: fenv.h is not a part of the C++ standard library; it is specified in ISO/IEC 9899, section 7.6 (the C99 standard). It's implementation is tied not only to the underlying C library in use, but also to a number of other factors, including but not limited to: - The operating system - The kernel - The compiler's method of implementing header search Attempting to detect the presence of the fenv.h header and the toolchains support for using said header cannot be achieved naively by defining a macro if the GNU, vacpp, sgi or stlport standard library implementation is found. The changes you have introduced will break Boost support for (at least) the following compilers and toolchains: - Sun, HP, Pathscale - Clang on linux or darwin using libc++ - Any compiler using the Apache/Roguewave standard library I am sincerely sorry to have stepped on toes here at Boost, especially yours, as you seem to be hellbent in purging Boost of my contributions, instead of helping to improve upon them. You told me last night in an email that you went back and reviewed every commit that I have ever made to Boost. I would appreciate it if you would let me know how much of my work you have in your crosshairs. Anyone here who knows me is aware that I am young and inexperienced at working on a large-scale open source project. I have been a little over-enthusastic and unintentionally inconsiderate, but I have done my best to fit in here and make contributions to Boost. I do not think that reverting my commits without consulting me first encourages the SVN policies that you and others assert that I have blatantly violated. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0z11gACgkQ9cB/V3/s9EyXJQCfesVXrNkhAeNoYCmgWODv0Z7m 6fMAni0Sb7gdtQWHyIj7EVFhrwqvBjCv =Sr5U -----END PGP SIGNATURE-----

5 7

Review Manager Assistant Role (reloaded)
by Joachim Faulhaber 18 Jan '11

18 Jan '11

Dear list, There have been discussions around the review process currently with some positive results and initiatives. There is a general dissatisfaction with the slow speed of processing libraries in the queue, the difficulties to find review managers and the accumulation of "stale" libraries of unclear status. Thanks to the activities of Volodya, Vicente and others this seems to improve currently. I appreciate this very much. Still I think, we should consider changing some of the rules of the review process to make it more efficient in the long run. A few points that are important to me: (1) Public statements on the Boost web page should be true. (Currently at least one is not.) (2) Only libraries that conform *all* requirements for boost libraries should be included into the review schedule. (3) The time a library stays in the review schedule should be as short as possible and it'll be limited to a maximum. (4) The throughput of libraries on the list shall be driven by the contributors activities. (5) The processing of a library contribution can be stopped by rejection (no-votes) and vetoes, but *not by inaction*. The principles that I regard to be most relevant are: (p1) Contribution must not be discouraged by mere inaction. (p2) Harness the motivation where it is: Development and library contribution. Don't expect it to be where it is not: Administration duties of seasoned boosters. I think that we can achieve point (1) to (5), if we shift more of the time consuming work of the Review Manager to the contributers by creating the Review Manager Assistant Role as proposed at BoosCon http://lists.boost.org/Archives/boost/2010/05/166423.php And every *first contributor* has to take on a Review Manager Assistant job once. Since there was reasonable support for those ideas, specifically by Dave Abrahams and Robert Stewart, I would like to come back on them, to see if there is still interest. Specifically I'd like to hear what the Review Wizards think. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[Serialization] can BOOST_ASSERT have method calls?
by Patrick Horgan 18 Jan '11

18 Jan '11

I noticed in serializations basic_iarchive that when you're not building for debug the next line here (317 in basic_iarchive.cpp) has a warning for unused variable new_cid. The BOOST_ASSERT is instantiated as ((void)0) so new_cid really isn't used. Could the register_type call be moved into the assert? class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); int i = cid; cobject_id_vector[i].bpis_ptr = bpis_ptr; BOOST_ASSERT(new_cid == cid); Something like: BOOST_ASSERT(register_type(bpis_ptr->get_basic_serializer()) == cid); Then the new_cid variable wouldn't be needed and the call to register_type would disappear with the BOOST_ASSERT if you aren't building for debug. Or, does the call to register_type have an important side effect that is required? Patrick

3 3

[signals] failure to build with recent gcc
by Patrick Horgan 18 Jan '11

18 Jan '11

I get a number of the same failures when doing a clean build of boost trunk with a recent gcc (4.6.0). libs/signals/src/named_slot_map.cpp:105:23: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: error: call of overloaded ‘erase(std::map<boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair>, boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group> >::iterator&)’ is ambiguous /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: note: candidates are: /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:763:7: note: void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator = std::_Rb_tree_const_iterator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >] /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1490:5: note: std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(const _Key&) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type = unsigned int] Patrick

2 1

[Boost Graph Library] Having trouble constructing necessary parameters for the isomorphism algorithm
by Alexander Bock 18 Jan '11

18 Jan '11

Hi all, First of all, I new to the mailing list, so please excuse me for any beginner's mistakes I may make :) I am also new to the Boost Graph Library. I am having some trouble implementing the Boost Graph Library isomorphism algorithm under MSVC++ 2008 Express Edition. Since I am using MSVC++, I cannot use the named parameter method, as specified in the docs. I am not entirely sure, but I think my problem is the vertex invariants that I pass to the algorithm. I am using Boost 1.43. My graph and relevant typedefs look like this: typedef adjacency_list<listS, listS, undirectedS, VertexProperty, EdgeProperty, no_property, listS> UndirectedGraph; typedef graph_traits<UndirectedGraph>::vertex_descriptor VertexDescriptor; I am using bundled properties: struct VertexProperty { string id; int index; }; struct EdgeProperty { string id; int weight; }; Here's my code that tries to call the isomorphism algorithm: bool BoostGraph::Compare(BoostGraph& comparableGraph) { vector<VertexDescriptor> f(GetNoVertices()); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap1 = get(&VertexProperty::index, uGraph); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap2 = get(&VertexProperty::index, comparableGraph.GetGraph()); return isomorphism(uGraph, comparableGraph.GetGraph(), isomorphism_map(make_iterator_property_map(f.begin(), indexMap1, f[0])), ???, ???, vertex_invariant2.max(), indexMap1, indexMap2); } The two '???' are where I need to pass the vertex degree invariants, but I do not know how to construct them. I hope I have supplied sufficient information for you. Thanks in advance!

2 13

Review manager volunteer
by Edward Diener 18 Jan '11

18 Jan '11

I am willing to be a review manager to help expedite the review of libraries in the review schedule which do not have a review manager assigned to it. Looking at the review process web page it says that the review wizards, whom the page says are currently John Phillips and Ronald Garcia, maintain a list of review manager volunteers. I do not know if that means I should be e-mailing directly the review wizards, so I decided to post this here first instead. I have been a programmer for 33 years, am very good with C++, and have a pretty good understanding of the basic Boost libraries ( MPL, Type Traits, PP, Function Types etc. ) with which other programmers may be working in order to produce a library for Boost. I have also put two libraries in the sandbox and am working on a third which I will eventually upload, so I have gained some experience in producing a potential library for Boost. Whether that qualifies me for being a review manager others can decide. My heart will not be broken if it does not, but if I am accepted as a potential review manager I know I can do a good job. Looking at the documentation of the libraries currently in the queue which do not have a review manager as yet, I believe I am familiar enough with the ideas of some of the libraries to be a review manager for any of these: bitfield conversion join endian string_convert pimpl My own point of view, unlike what others have generally expressed, is that the review wizards should assign reviews to potential review managers, after e-mailing them to see if they would be available for a particular library, rather than the library implementer directly asking someone to review their library. I feel that way because I think there may be too much influence on the review manager to accept a reviewed library when the library implementer and the review manager are joined by the direct asking process. But perhaps I am wrong, especially as many libraries have no review manager and the review wizards do not seem to be assigning review managers to those libraries from some volunteer list which they have. I believe it is important to break the logjam which is the current review schedule without keeping library implementers waiting for a longer and longer period of time to get their libraries reviewed, much less added to a Boost distribution in the future if it is accepted. The lack of review managers seems to be one of the major reason for this jamup and I would like to alleviate it in my own way, especially as I would like to eventually get my own libraries reviewed in the near future when I request it.

3 3

[ratio] Moved to trunk
by vicente.botet 17 Jan '11

17 Jan '11

Hi, I have moved Boost.Ratio to trunk and I have managed with all the requested points. From: "Anthony Williams" > These changes should be addressed before the library appears in a > Boost release. > > * Some of the macros had names with RATIO_RATIO in. These should be > changed to just RATIO DONE > * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates > should derive from the resulting ratio type as well as providing the > nested ::type member, in order to closely emulate the template alias > facility from C++0x DONE. While dreiving solve most of the issues ::type is needed yet to match a template parameter. > * The typos in the documentation should be fixed, and the documentation > reviewed for correctness and clarity (though several of the reviewers > made positive comments on the quality of the documentation). DONE even if there are always some improvements. > * The library needs more tests under the Boost Software License. DONE, thanks to Howard and the LLVM community for changing its license and making it compatible with Boost. > * All references to names from the boost namespace should be qualified > with boost:: to avoid potential name clashes and ambiguity with names > from the global namespace. DONE > * Sections commented out with #if 0 should be removed DONE > * The extensions beyond the facilities required by the C++0x draft > should be able to be enabled or disabled through use of a > configuration macro. DONE, BOOST_RATIO_EXTENSIONS needs to be defined. > * References to the tests, examples and documentation from within the > code should be checked for correctness. > DONE I have tried to solve some of the usual portability issues and even if there are yet some issues on the regression report, I consider that the library is globaly ready. I have added some extensions that Joel requested during the review. The extensions are related to viewing ratio<> as a Rational Constant. Rational constants can be mixed with other MPL Integral Constants when using the MPL numeric metafunctions. Paul A. Bristow has reviewed the documentation and fixed most of the editorial isues. The pdf documentation is available here https://svn.boost.org/svn/boost/trunk/libs/ratio/doc/ratio.pdf. If the html file is needed I can commit it temporarilly. It would appreciate if others can take a look and check if everything is right before moving to release. Thanks, Vicente

1 0

[Boost][BGL] New isomorphism test algorithm contribution
by Carlos Cardeñosa Pérez 17 Jan '11

17 Jan '11

Hi, I have been developing a new implementation for test graphs isomorphism, named conauto <http://sites.google.com/site/giconauto/> algorithm (based on José Luis López Presa thesis). I would like to contribute it to BGL. This is a more efficient algorithm than the current one. You can study all its details from conauto thesis at here<http://www.diatel.upm.es/jllopez/tesis/thesis.pdf> . Once developed the first conauto BGL-style version, I am sure that there are many advises and comments that could help to enhance it and eventually will be acceptable for BGL maintainers. Find attached both the source code and some measurements graphics. Please, do not hesitate ask me for any additional information. Best regards, Carlos Cardeñosa.

2 7

[serialization] Dealing with any tainted types.
by David Sankel 17 Jan '11

17 Jan '11

The serialization library allows for the painless serialization of most data types and even polymorphic types like variants and vectors. There is one type, however, that doesn't have a serialize function that makes sense. That type is any. It is easy to see that if we make an any serialize function, we're going to need to make some assumptions at least about which subset of types it might contain. I have a complex algebraic datatype, lets call it C, that has a member (that has a member...) of type T. T is "tainted" with a member of type any. I'm looking at the possible ways to serialize C with boost.serialization. We can know, at runtime, which subset of types the any member of T can contain and how to serialize each of those types. Lets call the dictionary type that has that information D. Here are the options I've come up with so far... Option 1: Make some global variable of type D, called d. Before calling any serialization of C, I ensure d has the correct value. The serialize function for T uses d to figure out how to serialize the any member. This option would certainly work, but I'm using a global variable as a workaround of the fact that I cannot add arguments to T's serialize function. No points for beauty here. Option 2: Instead of serializing a value of type C, serialize a value of type "struct CWithDict { C c; D d; }". In this serialization function I can use d whenever I need. Unfortunately the contents of this serialize function would need to duplicate most of the functionality of boost.serialize in the first place since T is buried deep within C's structure. Although this option works, it requires rewriting a bunch of serialize which isn't attractive. Option 3: Make an archive wrapper: template< typename Archive > struct DArchive { Archive a; D d; }; DArchive would model the Archive concept by forwarding functionality to a. However, the T serialize function could access DArchive's d member for serialization of the any. This would solve the problem at the expense of extending the meaning of Archive a bit. It seems pretty elegant to me. So, that's what I've come up with. I'm interested in comments. Does anyone know of a better way to do this? Could this possibly lead to a general mechanism for similar problems? TIA, David -- David Sankel Sankel Software www.sankelsoftware.com

2 4

Review communication
by Mateusz Loskot 17 Jan '11

17 Jan '11

Folks, I've been collecting results after the recent review of Boost.GIL extensions and I noticed that some reviewers notified the library author directly about some significant changes in their reviews/votes, without sending CC to ml/review manager. It means, review manager hasn't received those updates what means biased results of review. Dear reviewers, please check To/CC fields carefully while posting your comments during reviews. p.s. Regarding the Boost.GIL extensions review, we're negotiating a few details with Christian and the results will be available very soon. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Is there a way to debug python C++ extensions in Eclipse on Linux?
by Raul Durand 17 Jan '11

17 Jan '11

Hi guys, Is there a way to debug python C++ extensions in Eclipse on Linux? I want to debug a Python script that imports my module mmm.so and be able to step into my C++ code when necessary using Eclipse. I installed CDT and PyDev and tried different configurations but nothing works. Do I need to create different projects? a PyDev project and a CTD project? Do I need to recompile Python with debug symbols? Is there another tool than Eclipse to achieve this? Thanks, Raul Durand

2 1

Re: [boost] Compiler error in gcc3+ involving template template parameter and default parameters
by Brent Spillner 17 Jan '11

17 Jan '11

On 01/16/2011 8:34 AM, Edward Diener wrote: >That is very nice to say, but the library is for Boost which does try to >still support gcc3+. I know it compiles without error in gcc4+. I should >have been more explicit when I notated 'gcc3+' to ex0plain that I meant >gcc3 versions and not gcc4 versions. I would have dropped the '+' ;-) I'm all about supporting the widest possible variety of compilers, but note that the last GCC 3 release was nearly five years ago. I'm sure that there are plenty of other things in Boost that it can't handle. >Those are just specializations of: > >template<class T> >struct eval; > >There is no reason SFINAE should be involved. It's the same principle; rather than attempting to substitute class members, the compiler is substituting the parameters of the template class F. At any rate, I don't know another name for the concept. >> template<class T, class P = noparam> >> struct ptmf { >> typedef int type; >> typedef ptmf<T, P> is_unary; >> }; >> >> template<class T, class P1, class P2> >> struct other { >> typedef int type; >> typedef other<T, P1, P2> is_binary; >> }; >> >> template<template<class> class F, class P1> >> struct eval<F<P1> > : typename F<typename P1::type>::is_unary {}; >> >> template<template<class,class> class F, class P1, class P2> >> struct eval<F<P1, P2> > : typename F<typename P1::type, typename >> P2::type>::is_binary {}; > >I do not follow this. Your is_unary and is_binary are typedefs within >'ptmf' and 'other' templates. The idea was to give g++ a little more information to help resolve the eval<> ambiguity; when 'ptmf' is substituted for 'F', there is no nested ::is_binary and the second specialization cannot apply, but the first specialization resolves and in fact yields the same type that it would have without the '::is_unary'. Unfortunately, that doesn't seem to be enough help for GCC 3.4.6. I did, however, get your example to compile by refactoring a bit: if you change the template parameters for ptmf to 'template<class T, class P = noparam, class Unused = noparam>', then you can eliminate the first specialization of eval<> but provide additional specializations for the cases where P2 is noparam or P1 and P2 are both noparam, e.g. struct nullary_op {}; struct unary_op {}; struct binary_op {}; template <template<class,class> class F, class P1, class P2> struct eval<F<P1,P2> > : F<typename P1::type,typename P2::type> { typedef binary_op category; }; template <template <class,class> class F, class P1> struct eval<F<P1,noparam> > : F<typename P1::type,noparam> { typedef unary_op category; }; template <template <class,class> class F> struct eval<F<noparam,noparam> > : F<noparam,noparam> { typedef nullary_op category; }; where ::category is just a type tag to help you differentiate between the types of eval<> elsewhere in the framework. This compiles as-is under GCC 3.4.6, and requires that you change the first declaration of eval ('template <class F> struct eval;') to a concrete definition ('template <class F> struct eval {};') under GCC 4.4.4 and 4.5.2 (also legal under 3.4.6.) I don't know how well this solution fits into the rest of your library, but I hope it at least provides some ideas.

2 1

[bitfield] documentation does not build
by Edward Diener 17 Jan '11

17 Jan '11

My mistake: it should be the bitfield library, not bitset. Attempting to build the documentation for bitfield, I get a bunch of errors: "C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1079 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p..\..\..\bin.v2\libs\integer\doc\msvc- 10.0\debug\threading-multi>bitfield.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-bitf ield.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-bitfi eld.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: added properties: <preserve-test-targets>on <python-debugging>off <python >2.6 <threadapi>win32 error: removed properties: none C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1078.actualize from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1087.actualize from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1088.actualize from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1092.actualize from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1093.actualize from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:748: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module C:\Programming\VersionControl\sandbox\boost-build.jam:66: in module scope from m odule" The docs need to be buildable for anyone to use the library or be willing to review it.

4 8

[Thread] thread::interrupt of the death
by Gaetano Mendola 16 Jan '11

16 Jan '11

Hi all, I think a thread after getting an interrupt the first think to do before to throw a boost::thread_interrupted (passing or being on an interruption point) has to disable interruption, indeed think what happens if during a stack unwinding the thread passes again on an interruption point and it receives a second interrupt. This scenario is not that hard to happen. Regards Gaetano Mendola

2 5

Re: [boost] [msm] triggering of a transition on a subclass event does not work on sub state machines in case of favor_compile_time policy is used.
by Christophe Henry 16 Jan '11

16 Jan '11

> Hi All > > I have run it to a problem that feature : Event Hierarchy see doc : > http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1108 > > Does not work in case of sub state machine with favor_compile_time > policy. No trans get called on the sub state machine even it has a row > with event type to the event base class. > > This now hit me badly because compiler runs out of heap if > favor_compile_time policy is not used but when it is used I can not > dispatch based on base type and I have about 150 different event so > declare a transition for it is a no go. > > Is there any workaround for this problem ?. Hi Richard, It took a while but I now committed a solution into the trunk (rev. 68194). Could you please give it a try? It passes my tests but double-checking cannot hurt. It's actually a complete reimplementation of the feature, without boost::any. The advantages: - it supports event hierarchy - it compiles slightly faster - it runs much faster - it requires no rtti I hope it solves your problem. Please let me know. It's not a major change so I could merge it into 1.46, but only if you manage to test it until Monday evening. Otherwise, you'll have to use the trunk version until 1.47. Regards, Christophe

1 0

Compiler error in gcc3+ involving template template parameter and default parameters
by Edward Diener 16 Jan '11

16 Jan '11

I am showing this gcc3 bug just in case any other Boost developer has run into it and knows some easy workaround. It will save me some time as the workaround in the actual case, which is more complicated, is very laborious as I envision it ( I have not yet attempted to code up the laborious workaround ). I ran into this type of case as the problem in my tti library which is keeping it from supporting gcc3+. Here is the simplified code, called TestGcc3.cpp. I have removed all Boost dependencies to make it as simple as possible to see: "template<class T> struct eval; template < template<class> class F, class P1 > struct eval<F<P1> > : F<typename P1::type>{}; template < template<class,class> class F, class P1, class P2 > struct eval<F<P1,P2> > : F<typename P1::type,typename P2::type>{}; struct noparam { typedef noparam type; }; template < class T, class P = noparam > struct ptmf { typedef int type; }; template < class T, class P = noparam > struct tkf : eval<ptmf<T,P> >{}; template <class T> struct ATemplate { typedef T type; }; int main() { tkf<ATemplate<int> > aVar; return 0; }" The compiler command line, which is essentially what bjam generates, is: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c "TestGcc3.cpp" The error message is: "TestGcc3.cpp: In instantiation of `tkf<ATemplate<int>, noparam>': TestGcc3.cpp:52: instantiated from here TestGcc3.cpp:42: error: ambiguous class template instantiation for `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:19: error: candidates are: struct eval<F<P1, P2> > TestGcc3.cpp:10: error: struct eval<F<P1> > TestGcc3.cpp:42: error: invalid use of undefined type `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:2: error: declaration of `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp: In function `int main()': TestGcc3.cpp:52: warning: unused variable 'aVar'" I am looking for a workaround for gcc3+ compilers which does not involve getting rid of the default parameters. If I remove the default parameters, and change the instantiation of tkf to: tkf<ATemplate<int>,ATemplate<int> > aVar; the compile is successful and there is no error. This is of course a very simplified illustration of much more complicated code and maintaining default parameters within the more complicated situation is a much cleaner syntax than an alternative, even if I can get an alternative to work correctly without default parameters.

2 2

[interhreads] Could not build the documentation
by Edward Diener 16 Jan '11

16 Jan '11

When I attempted to build the docs for the interthreads library up for review I received: "C:\Programming\VersionControl\sandbox\interthreads\libs\interthreads\doc\interth reads.qbk:1: warning: Invalid attributes for 'article document info': purpose, category reference/act_traits.qbk: error: Could not open input file. reference/fork.qbk: error: Could not open input file. reference/fork_after.qbk: error: Could not open input file. reference/fork_all.qbk: error: Could not open input file. reference/wait_for_all.qbk: error: Could not open input file. reference/wait_for_any.qbk: error: Could not open input file. reference/algorithm.qbk: error: Could not open input file. reference/wait.qbk: error: Could not open input file. reference/wait_until.qbk: error: Could not open input file. reference/get.qbk: error: Could not open input file. reference/is_ready.qbk: error: Could not open input file. reference/has_value.qbk: error: Could not open input file. reference/has_exception.qbk: error: Could not open input file. reference/wait_all.qbk: error: Could not open input file. reference/wait_all_until.qbk: error: Could not open input file. reference/get_all.qbk: error: Could not open input file. reference/are_all_ready.qbk: error: Could not open input file. reference/have_all_value.qbk: error: Could not open input file. reference/have_all_exception.qbk: error: Could not open input file. reference/detach.qbk: error: Could not open input file. reference/joinable.qbk: error: Could not open input file. reference/join.qbk: error: Could not open input file. reference/join_until.qbk: error: Could not open input file. reference/interrupt.qbk: error: Could not open input file. reference/interruption_requested.qbk: error: Could not open input file. reference/detach_all.qbk: error: Could not open input file. reference/join_all.qbk: error: Could not open input file. reference/are_all_joinable.qbk: error: Could not open input file. reference/join_all_until.qbk: error: Could not open input file. reference/interrupt_all.qbk: error: Could not open input file. reference/interruption_requested_all.qbk: error: Could not open input file. reference/basic_threader.qbk: error: Could not open input file. reference/launcher.qbk: error: Could not open input file. reference/threader.qbk: error: Could not open input file. reference/scheduler.qbk: error: Could not open input file. reference/typeof/futures.qbk: error: Could not open input file. reference/typeof/launcher.qbk: error: Could not open input file. reference/typeof/threader.qbk: error: Could not open input file. reference/typeof/basic_threader.qbk: error: Could not open input file. reference/typeof/scheduler.qbk: error: Could not open input file. reference/asynchronous_executor_decorator.qbk: error: Could not open input file. reference/basic_threader_decorator.qbk: error: Could not open input file. reference/launcher_decorator.qbk: error: Could not open input file. interthreads.qbk: error: Error count: 43."

3 5

Re: [boost] [General] Always treat std::strings as UTF-8
by Artyom 16 Jan '11

16 Jan '11

> From: Dave Abrahams <dave(a)boostpro.com> > > Peter Dimov wrote: > > > > Alexander Lamaison wrote: > > > I'm opposed to this strategy simply because it differs from the way > > > existing libraries treat narrow strings. > > > > It differs from them because it's right, and existing libraries are > > wrong. Unfortunately, they'll continue being wrong for a long time, > > because of this same argument. > > Does the "right" strategy come with some policies/practices that can > allow it to coexist with the existing "wrong" libraries? If so, I'm > all +1 on it. > Combining old libraries with new ones: ====================================== It would be simple to combine a library that uses old policies with new ones. namespace boost { std::string utf8_to_ansi(std::string const &s); std::string ansi_to_utf8(std::string const &s); std::wstring utf8_to_wide(std::string const &s); std::string wide_to_utf8(std::wstring const &s); } - If it supports wide strings call boost::utf8_to_wide **under Windows platform** and nothing is lost. - If it supports only narrow strings: a) if it is encoding agnostic: like some unit-test that only open files named with ASCII names, then you can safely ignore and pass UTF-8 string as ASCII and ASCII as UTF-8 as is the subset of it. b) Do following: 1. Fill a bug to library owner on not-supporting Unicode strings under Windows. 2. Use utf8_to_ansi/ansi_to_utf8 to pass strings to this library under Windows. Current State of Using Wide/ANSI API in Boost: ============================================== I've did a small search to find which libraries use what API: Following use both types of API: ------------------------------- thread asio system iostreams regex filesystem According to new policy they should replace ANSI api by wide api and conversion between UTF-8 and UTF-16 Following libraries use only ANSI API -------------------------------------- interprocess spirit test random The should replace their ANSI api by Wide one with a simple glue of utf8_to_wide/wide_to_utf8 Following libraries use STL functions that are not aware of unicode under windows --------------------------------------------------------------------------------- std::fstream - Serialization - Graph - wave - datetime - property_tree - progam_options fopen - gil - spirit - python - regex Need to replace with something like: boost::fstream and boost::fopen that work with UTF-8 under windows. The rest of the libraries seems to be encoding agnostic. Artyom

5 10

Re: [boost] Compiler error in gcc3+ involving template template parameter and default parameters
by Brent Spillner 16 Jan '11

16 Jan '11

On 01/15/2011 10:41 PM, Edward Diener wrote: >I am showing this gcc3 bug just in case any other Boost developer has >run into it and knows some easy workaround. It will save me some time as >the workaround in the actual case, which is more complicated, is very >laborious as I envision it ( I have not yet attempted to code up the >laborious workaround ). I ran into this type of case as the problem in >my tti library which is keeping it from supporting gcc3+. Your sample code compiles for me without errors or warnings (other than the unused variable) under GCC 4.4.4 and 4.5.2. Is there a particular GCC version that you need to support? In my experience GCC versions before 4.4 have badly broken template support and should be avoided if at all possible. >I am looking for a workaround for gcc3+ compilers which does not involve >getting rid of the default parameters. If I remove the default >parameters, and change the instantiation of tkf to: I would start by removing the "template<class>" / "template<class, class>" specifications on the dependent types F. Those may be what sent you into a poorly-tested and bug-ridden corner case in whichever release of GCC you're using, and should be unnecessary--- the compiler will not be able to instantiate the base class F<typename P1::type> when F requires two parameters, nor F<typename P1::type, typename P2::type> when it accepts only one, and should SFINAE to the proper case. If you do need those explicit constraints on F to work around problems in GCC 3 or another compiler, and it's feasible to nest a new typedef into all types that are legal as the F argument of eval<>, you could construct something like template <class T, class P = noparam> struct ptmf { typedef int type; typedef ptmf<T, P> is_unary; }; template <class T, class P1, class P2> struct other { typedef int type; typedef other<T, P1, P2> is_binary; }; template <template<class> class F, class P1> struct eval<F<P1> > : typename F<typename P1::type>::is_unary {}; template <template<class,class> class F, class P1, class P2> struct eval<F<P1, P2> > : typename F<typename P1::type, typename P2::type>::is_binary {}; If you need to support F types to which you can't add typedefs, you'll have to use the template <class F> struct F_traits{} pattern to provide ::is_unary, ::is_binary, etc.

2 1

GIL io_new review
by Lubomir Bourdev 16 Jan '11

16 Jan '11

First I apologize for not being active in the past several years in the Boost community due to time constraints. I only had a few hours to do this review, but I also reviewed Christian's code a couple of years ago. When we introduced GIL to Boost I was hesitant to include the I/O extension in the Boost submission. I felt that doing the I/O right is a major project and it is better to do it right or not at all. However, without any I/O support it would be very hard to use GIL, so we had to include some I/O extension that provides reasonable support for common formats. Christian has been (and still is) very passionate to make the next generation I/O. He started working on this at least four years ago and have been improving and polishing the code ever since. The problem with I/O is that you can never declare success. There are an unlimited number of file formats, back-ends, ways to read and write the image, image representations, compression settings, etc. For each of these one needs to deal with completeness, performance, test cases, failure modes, platform dependencies... All we can hope for is push the boundary as much as we can, and leave the rest for the next update. What is important in the first release is to get the design right. Once we have a solid foundation we can add a lot of functionality quickly and transparently. Domagoj had some constructive criticism so I will start with that. On the issue of using classes vs free functions, I don't think there is a huge difference either way. The the new_io code borrows the style from GIL, which uses free functions as algorithms (if you call I/O "algorithms"). GIL in turn borrows this style from the STL. Using functions one can extend functionality with overloading (but there are ways to do this with classes too) and it is nicer to be able to read/write a file with one line, without having to first construct a reader/writer and then call it. But these are minor quibbles. On the issue of performance, I don't think one test with one file format being 30% slower proves that there are serious performance issues. My guess is that Christian has been focusing on adding functionality and never got around to work on performance improvements, which usually means that we can get a lot of speedup by doing some simple optimizations in the inner loops. On the issue of using/not using streams, I don't have a strong opinion, except that stream support for I/O was one of the highest requested functionalities in GIL's review. Domagoj, you should have been more vocal at that time. Christian simply responds to the wishlist of the Boost community. In general, I feel that performance might be a bit overhyped in recent discussions. The image I/O operations are often dominated by disk access and by compression, etc. I don't think avoiding a copy of the pixels would make much of a difference in the majority of uses. That said, we do want to make sure GIL I/O is as fast as it can be. On the issue of supporting different backends, I agree with Domagoj that this is important and we should make sure to support it. In Christian's design everything is done in reader and writer classes, which are currently specialized for a specific file format and backend. One could imagine creating classes for other backend+file format combinations without much (any?) changes to the current design. The reader/writer files from the same backend could have common base classes or share functionality in other ways as appropriate. - What is your evaluation of the design? The design is fine, but I would like the requirements for adding new file formats / backends to be made more explicit. Specifically we want a concept for a file format reader/writer/etc and adding new file formats would constitute providing models for these concepts. - What is your evaluation of the implementation? It looks fine but haven't played with it much. - What is your evaluation of the documentation? The documentation is adequate, but requires cleanup and fixing of lots of typos. - What is your evaluation of the potential usefulness of the extensions? Very useful. However, there is some missing functinality which in my opinion is important to have: 1. The ability to read an image without specifying the file format at compile time 2. The ability to support multiple back-ends 3. The ability to efficiently read/write an image in parts - Did you try to use the extensions? With what compiler? Did you have any problems? I did not do anything non-trivial with them. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 3 hours looking at the code (but I reviewed a verion about 3 years ago) - Are you knowledgeable about the problem domain? I am familiar with GIL but not very much with file format libraries. - Do you think the extensions should be accepted as a part of Boost.GIL library? Let us consider our options carefully. We could do a "reject" on the basis that there is another alternative libarary (Domagoj's library). I don't think this is a good idea. I looked briefly at his library; there are things I like about it but also things I don't. There are certainly a lot of things that are missing. I will refrain from discussing it because it is not under review but the point is that in its current state it is not superior to what Christian has. Domagoj can improve his library further, but so can Christian, and Christian has been working on this for four years now and had submitted his library for review long time ago. This is a huge effort on behalf of Christian, he produced some great and very useful work and a reject will be demoralizing after so many years of work, and is unjustified given that fundamentally he has the right design. We could do an "accept". I would be ok with this, but there is some important functionality that is missing and adding it will require moderate work and some changes to the interface So my recommendation is "conditional accept" after the above identified must-have functionality has been added, specifically: - Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the filename. - Support for different backends. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. It is not immediately obvious to me why this would be a bad design choice; if someone disagrees they should elaborate. - Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. I'd like to hear the opinion of people who would use this more advanced options. My preference is that Christian joins forces with Domagoj to collaborate on these and take the best of their libraries to gil.io. Looks like Domagoj also spent a lot of time and effort on this problem and has gained a lot of valuable intuition. I don't want to see his efforts go to waste either. Other todo items: - Improve the language in the documentation section. - Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. - Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. - Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. Finally, here is an idea that I like, but may be too much work to do in the current release: I would like to have a GIL virtual image view associated with a given file. That would allow reading/writing to simply be copy_pixels, and reading into a different format to be copy_and_convert_pixels. Reading a given ROI could simply be done by creating a subimage_view. The cool thing about this is one could in theory make changes to images without even loading them in memory. The caviat is that doing this right and efficiently is very hard, requires clever caching, plus a wrong access pattern can result in horribly bad performance. Lubomir

5 20

[ratio] namespace ratios
by vicente.botet 16 Jan '11

16 Jan '11

Hi, Before moving all the classes on Boost.Ratio from boost:: to boost::ratios:: I wanted to signal that Boost.Ratio follows the names on the C++0x standard and that these names where choosen to be used in the std context and that any class is prefixed by ratio_. If a specific ratios namespace were in their minds, I'm sure that they will not use the ratio_add<> but just add<>. Please let me know if I'm wrong here. typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::add<R1, R2> R; If we put all of them in boost::ratios maybe the class names contains redundant information typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::ratio_add<R1, R2> R; Do the Boost community agree with these names or is this one of the special cases that needs consideration? Best, Vicente

3 2

[tools/regression] compiler_status & library_status build error
by KTC 16 Jan '11

16 Jan '11

Executing bjam in tools/ fail to build library_status on trunk or release, and fail to build compiler_status on release. I'm guessing they still need to be fixed for Boost.Filesystem v3. KTC

1 0

[Creasing (Sequence Properties)] where is the documentation
by Edward Diener 16 Jan '11

16 Jan '11

For the Creasing (Sequence Properties) library up for review I do not see how to build any documentation, nor is there any documentation for it in the download.

1 0

[bitset] documentation does not build
by Edward Diener 16 Jan '11

16 Jan '11

Attempting to build the documentation for bitset, I get a bunch of errors: "C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1079 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p..\..\..\bin.v2\libs\integer\doc\msvc- 10.0\debug\threading-multi>bitfield.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-bitf ield.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-bitfi eld.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: added properties: <preserve-test-targets>on <python-debugging>off <python >2.6 <threadapi>win32 error: removed properties: none C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1078.actualize from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1087.actualize from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1088.actualize from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1092.actualize from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1093.actualize from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:748: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module C:\Programming\VersionControl\sandbox\boost-build.jam:66: in module scope from m odule" The docs need to be buildable for anyone to use the library or be willing to review it.

1 0

[1.46] Release notes
by Daniel James 15 Jan '11

15 Jan '11

Hello all, Since the code freeze is coming up, it's time to write your release notes. If you want to add them yourself, you can edit 'boost_1_46_0.qbk' in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. I didn't get the new site building system ready in time for this release, so you should probably leave it to me to generate the html from your changes. Daniel

2 1

[Review] Dead link for Endian on the Review Schedule page
by Edward Diener 15 Jan '11

15 Jan '11

On the review schedule page at http://www.boost.org/community/review_schedule.html the link for Beman Dawes Endian library is dead.

1 0

Re: [boost] [context] new version - support for Win64
by Andrzej Krzemienski 15 Jan '11

15 Jan '11

> I've uploaded boost.context-0.3.0.zip to boost vault. Hi, I am new to the idea of context switching, and the idea seams very interesting. I have gotone question regarding the interface. The two arguments that are passed when creating a new context, of type void(*)(void*) and void* look like a way of providing a callback. I am used to, in Boost libraries and C++0x threads, to see function<void()> as a type of callbcak. Is there a reason for not using it in case of context switching? Regards, &rzej

3 3

Improving review process
by Vladimir Prus 15 Jan '11

15 Jan '11

Recently, there were various comments about current review process, and its possible improvements. However, I wanted to start with a small point. Looking at: http://www.boost.org/community/review_schedule.html it seems that a few libraries have a review manager assigned, but there's no date. This means that: - It looks like our review schedule is full, because the item is there, and - It prevents anybody to volunteer as review manager for such library. I think there might be several reasons why a library does not have a review date: - The library is not actually ready. In that case, it should not be in that table at all. - The library author does not have the time for review. In that case, the library should also be removed from the list, because Boost is not responsible if the author is busy. - The review manager does not have the time for review. In that case, he should not be listed as assigned, and should not block others. Can we set a policy that: - A library can only be added in the review schedule if the author has time in near future to have a review, where near future is, say, 3 months. - A review manager is only assigned if a review date is set at the same time, where the date should be in near future -- say, 3 months again. I think such a policy might not improve our overall review speed too much, but surely will make the situation a bit clear, and allow to understand the real problems with the review system. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

20 52

Re: [boost] [Boost-commit] svn:boost r66696 - in trunk: boost/config boost/config/compiler boost/config/platform libs/config/doc libs/config/doc/html libs/config/doc/html/boost_config
by Steven Watanabe 15 Jan '11

15 Jan '11

AMDG On 11/22/2010 10:33 PM, admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2010-11-23 01:33:35 EST (Tue, 23 Nov 2010) > New Revision: 66696 > URL: http://svn.boost.org/trac/boost/changeset/66696 > > Log: > Added *nix identification macros to Boost.Config; BOOST_NIX, BOOST_GENETIC_NIX, > BOOST_TRADEMARK_NIX and BOOST_FUNCTIONAL_NIX. Bryce, these macros are not used by anything in Boost and I saw no discussion on the mailing list about adding them. Please provide a justification for them, or I will revert this. Boost.Config should not have macros that we don't need. In Christ, Steven Watanabe

2 1

Re: [boost] [pgi-10.1] relocations compiler option
by vicente.botet 15 Jan '11

15 Jan '11

Hi, Sorry for the cross-post. It seems as nobody is posting on the Testing ML. Noel Belcourt is out until the 24th. Could someone check if the modification is needed? Vladimir? Best, Vicente ----- Original Message ----- From: vicente.botet To: Running Boost regression tests Sent: Wednesday, January 12, 2011 7:49 PM Subject: [Boost-testing] [pgi-10.1] relocations compiler option Hi, there are some test in trunck that are failing Test output: Sandia-pgi-10.1 - chrono - xtime_static / pgi-10.1 It seems that the we need to add -fPIC, but -fpic . I don't know the compiler command syntax, but in case this could help, it will be worth to try. Could someone change this on trunk? Best, Vicente Test output: Rev 68033 / Wed, 12 Jan 2011 07:53:19 +0000 Report Time: Wed, 12 Jan 2011 15:19:47 +0000 Compile [2011-01-12 10:41:10 UTC]: succeed "/sierra/Sntools/extras/compilers/pgi/linux86-64/10.1/bin/pgCC" -INLINE:none -Wc,-a --brief_diagnostics --error_limit1 --compress_names --diag_suppress450 --no_using_std --zc_eh -Kieee -fpic -gopt -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_DYN_LINK=1 -D__need_IOV_MAX -I".." -c -o "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o" "../libs/system/src/error_code.cpp" Link [2011-01-12 10:41:10 UTC]: fail "/sierra/Sntools/extras/compilers/pgi/linux86-64/10.1/bin/pgCC" -gopt -fpic --zc_eh -shared -o "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/libboost_system.so" "/scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o" -Wl,-h -Wl,libboost_system.so -Bdynamic -lrt -lrt -Bstatic -Bdynamic /usr/bin/ld: /scratch/boost/results/boost/bin.v2/libs/system/build/pgi-10.1/debug/error_code.o: relocation R_X86_64_PC32 against `__catch_clause_number' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value TinyUrl http://tinyurl.com/6z8ndcg _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/ ------------------------------------------------------------------------------ _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 0

Re: [boost] [Boost-commit] svn:boost r67851 - trunk/boost/asio
by Steven Watanabe 15 Jan '11

15 Jan '11

AMDG On 1/8/2011 8:47 PM, admin(a)thefireflyproject.us wrote: > Author: wash > Date: 2011-01-08 23:47:56 EST (Sat, 08 Jan 2011) > New Revision: 67851 > URL: http://svn.boost.org/trac/boost/changeset/67851 > > Log: > Pathscale 4.0.0's stdlib (rw) has a<streambuf> that doesn't include<iostream>; > added an include to<iostream> here as this file needs it. > > Modified: trunk/boost/asio/basic_socket_iostream.hpp > ============================================================================== > --- trunk/boost/asio/basic_socket_iostream.hpp (original) > +++ trunk/boost/asio/basic_socket_iostream.hpp 2011-01-08 23:47:56 EST (Sat, 08 Jan 2011) > @@ -19,6 +19,7 @@ > > #if !defined(BOOST_NO_IOSTREAM) > > +#include<iostream> > #include<boost/preprocessor/arithmetic/inc.hpp> > #include<boost/preprocessor/repetition/enum_binary_params.hpp> > #include<boost/preprocessor/repetition/enum_params.hpp> This is more than is needed. std::iostream is defined in <istream>. <iostream> contains std::cout, etc. In Christ, Steven Watanabe

1 0

the <boost/detail/iomanip.hpp> header (please use it)
by Bryce Lelbach 15 Jan '11

15 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Linux, both clang and icc use GNU's C++ standard library by default. As of version 4.5 of GNU's stdlib, a new implementation of the <iomanip> header has been added, which makes use of C++0x features which only GCC supports (the latest versions of clang, e.g. a very recent nightly build, might work; intel certainly won't). The refactored <iomanip> header in GNU's stdlib does not detect C++0x support and fallback on the old C++98 friendly code, which unfortunately leaves clang-linux and intel-linux users in a bit of a bind. In particular, this plagues clang users on Linux as clang will use the latest available version of the GNU stdlib by default, meaning most users cannot have both gcc-4.5 and clang installed without problems. I have implemented the <iomanip> header in <boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system <iomanip> headers that users/other code might include). The implementation conforms to the C++03 standard (at least, I'm fairly confident it is standard compliant - reviews and feedback would be welcome). I just committed (r68140) a patch which replaces the use of <iomanip> with <boost/detail/iomanip.hpp>. I've tested on a few different compilers, and I'm pretty sure there are no regressions. If it does cause any problems, please let me know. This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library. P.S. For maximum portability, please use <boost/detail/iomanip.hpp> in Boost code in the future! - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0vurkACgkQ9cB/V3/s9Exh0gCdF5vcDD0DfyONhrob4YFVBZzO 2KwAoIqFS06nk5TV98K0jea1rTj6FkHF =QGJS -----END PGP SIGNATURE-----

6 16

Section on suppressing gcc warnings complete in boost warning guidelines
by Patrick Horgan 14 Jan '11

14 Jan '11

I added a section to the boost warnings guidelines page about suppressing warnings with GCC. I think it's pretty good bringing together information I got on the gcc-help list, from reading the source and from browsing through the documentation for various releases of GCC. If anyone wants to check it for correctness and/or style I would be very appreciative. I would in particular like to thank Jonathan Wakely for his willingness to help and for the great help he gave me on the gcc-help list. https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines If you scroll to the bottom directly you'll see the end of the section on suppressing GCC warnings. I moved it after the sections on turning on warnings and on how to deal with some common warnings to reflect the viewpoint of the document that suppressing should be the last resort. I have some improvements to make to the section on strict aliasing to reflect the better work I did in my white paper on the subject, and I know the common warnings section needs information on more common warnings. The way I picked the ones that are in there originally was by turning on warnings for an earlier version of boost, saving the output of building the whole tree, then checking to see what the most common warnings were that indicated real bugs. That was without running tests or any program that used boost. Just building boost. It's been a long time and much good work has been done in the tree to get rid of those, so I should take a look at that again by turning on the -Wsystem-headers -Wall -Wextra and maybe -Wpedantic and seeing what warnings pop up in boost code that indicate real problems again. Wouldn't it be great if there were none? The most painful one is -Wsystem-headers which tells GCC to report warnings even in files considered system files, but since many of the boost files include the #pragma GCC system_file it will be necessary to see the warnings. Unfortunately, that means that I'll see warnings from real system files as well. In boost there are 21 headers that include the pragma, 15 of them in boost/exception. It's possible that they all really have spurious warnings you can't code around. Those certainly exist. I hope they're documented as to why they use the pragma to save me time looking at them. Perhaps I'll find real bugs in them. Probably not though. Thank you, Patrick

1 0

[context/fiber] new version
by Oliver Kowalke 14 Jan '11

14 Jan '11

issues related to boost.move (msvc) and DLLs are fixed.

1 0

[ratio][mpl] static metafunctions
by vicente.botet 14 Jan '11

14 Jan '11

Hi, during the Boost.Ratio review as requested to push some of the static integer metafunctions as static_abs, static_sign, static_gcd, static_lcm to a public library. At the begining I has the impression that these functions should be added to Boost.Integer or Boost.Math, but after reflexion I think that these static metafunctions could be better integrated into Boost.MPL with the existing integral functions. I have prepared a patch for 3 of them. Do you think that these can be added to Boost.MPL if I provide the needed documentation and tests? Best regards, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 7

[announce] mirror-lib 0.5.2 released
by Matus Chochlik 14 Jan '11

14 Jan '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.2/ Since version 0.5.0, Mirror is being developed outside the boost namespace, but the directory linked above contains also a 'boostified' version of the sources with Jamfiles etc. Besides the docs package, the documentation is also hosted online here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ To get the idea what the library can do you can look at the examples. http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/examples.html 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

2 4

Files only in release branch
by Marshall Clow 14 Jan '11

14 Jan '11

As of revision 68145, there are a bunch of files that exist only in the release branch, and not in the trunk. Is this on purpose? boost/graph/kolmogorov_max_flow.hpp boost/pending/integer_range.hpp boost/smart_ptr/enable_shared_from_this2.hpp libs/functional/hash/test/container_fwd_test.cpp libs/functional/hash/test/container_no_fwd_test.cpp libs/graph/doc/kolmogorov_max_flow.html libs/serialization/vc7ide/polymorphic_derived2.vcproj libs/serialization/vc7ide/readme.txt libs/serialization/vc7ide/test_recusion.vcproj libs/test/example/cla/Jamfile libs/test/example/est_example1.cpp libs/test/example/est_example2.cpp libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/test/CMakeLists.txt tools/build/v2/doc/src/v1_vs_v2.xml tools/build/v2/engine/doc tools/build/v2/example/customization/jamfile.jam tools/inspect/run_inspect.sh -- 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

boost_thread-vc80-mt-1_43.dll "the application failed to inialize properly"
by Clark Sims 14 Jan '11

14 Jan '11

I can link to boost_thread-vc80-mt-1_43.lib with no problem, but when I try to run the executable, I et an error The application failed to initialize properly )0xc0150002) Clico on OK to terminate the application. Does anyone know how to fix this?

1 0

TTI library in the sandbox
by Edward Diener 14 Jan '11

14 Jan '11

I have uploaded to the sandbox 'tti' directory version 1.0 of the TTI library. 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. 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 which other template metaprogrammers can use in their code. There is a readme.txt in the top-level sandbox tti directory, for anyone browsing the sandbox for interesting libraries, which 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. There is a list of todo items in the sandbox on which I will be working for the next release, but the library is already feature rich. The library has been tested and works with gcc 4.30, 4.4.0, 4.5.0-1 and VC++ 8.0, 9.0, and 10.0. It may also work with other compilers. There is a bug in versions of gcc prior to version 4 for which I will attempt to find a workaround if it is deemed important, which prevents it from working with the library. Questions, comments, suggestions, and bug reports are all welcome.

2 2

[ASIO] Compilation error on NetBSD
by Marek Dopiera 14 Jan '11

14 Jan '11

Hello everybody, this is my first post to this list. Recently I got an error when compiling a program which uses ASIO on NetBSD. It is related to kqueue. From what I see it is caused by passing descriptor_state* to EV_SET. Under NetBSD it should be intptr_t. Moreover, the udata field of kevent is implicitly cast to void* later on, which also causes an error. Explicit casts solve the issue. Maybe it's worth adding? Could someone with commit access check it and eventually correct it, please? I don't know how it is under FreeBSD, maybe an ifdef is needed to support both. The relevant compilation error (boost-1.44.0, NetBSD 5.1, i386, gcc 4.3.1) In member function 'void boost::asio::detail::kqueue_reactor::start_op(int, boost::asio::detail::socket_type, boost::asio::detail::kqueue_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool)': asio/detail/impl/kqueue_reactor.ipp:132: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp:136: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp:142: error: invalid conversion from 'boost::asio::detail::kqueue_reactor::descriptor_state*' to '__intptr_t' asio/detail/impl/kqueue_reactor.ipp: In member function 'void boost::asio::detail::kqueue_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&)': asio/detail/impl/kqueue_reactor.ipp:237: error: invalid conversion from '__intptr_t' to 'void*' [...] Regards

2 1

status of type traits addition (has_operator_xxx)
by Frédéric Bron 14 Jan '11

14 Jan '11

Here is the status of the type-traits addition: - I added the following operators: +=, *=, -=, /*, %=, &=, |=, ^=, <<, >>, >>=, <<=, prefix ++, prefix --, postfix ++, postfix -- so that the covered operators are now: - I added in the doc. the fact that private operators are not covered and lead to compile time errors - for operators on built-in types that require integer arguments (%, bitwise op.): I replaced a long list of specialiazation by an automatic detection Remaining work: 1. check what happens for pointer arguments, 2. implement trait for: . operator= . has_address_of_op<T> . has_dereference_op<T> . has_member_access_op<T> . has_subscript_op<T1 [,T2]> . has_pointer_to_member_op<T1 [,T2]> . has_comma_op<T1 [,T2]> . has_function_call_op<T,R [,P1, ...]> 3. have an MPL predicate for return value As I have only little time (full time work and 3 young children...), I will: - certainly do 1., - I will certainly leave 3. to somebody else in the future because I am not enough agile with MPL, - as for 2., 3 possibilities: (i) I do it but it will probably postpone the addition for a long time, (ii) I just leave it and I know is is a shame not to provide all operator detection (nobody's perfect) or (iii) somebody else agrees to add them and have them reviewed at the same time. Frédéric

3 2

[build]problems
by Matthias Schabel 13 Jan '11

13 Jan '11

Clean default install on OSX system with OpenMPI installed claims MPI is building, but does not build MPI component by default - it's a little confusing... ./bjam Building the Boost C++ Libraries. ...found 14 targets... ...updating 8 targets... common.mkdir bin.v2 common.mkdir bin.v2/libs common.mkdir bin.v2/libs/regex common.mkdir bin.v2/libs/regex/build common.mkdir bin.v2/libs/regex/build/darwin-4.2.1 common.mkdir bin.v2/libs/regex/build/darwin-4.2.1/debug darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o libs/regex/build/has_icu_test.cpp:12:30: error: unicode/uversion.h: No such file or directory libs/regex/build/has_icu_test.cpp:13:28: error: unicode/utypes.h: No such file or directory libs/regex/build/has_icu_test.cpp:14:27: error: unicode/uchar.h: No such file or directory libs/regex/build/has_icu_test.cpp:15:26: error: unicode/coll.h: No such file or directory libs/regex/build/has_icu_test.cpp: In function ‘int main()’: libs/regex/build/has_icu_test.cpp:23: error: ‘UErrorCode’ was not declared in this scope libs/regex/build/has_icu_test.cpp:23: error: expected `;' before ‘err’ libs/regex/build/has_icu_test.cpp:24: error: ‘UChar32’ was not declared in this scope libs/regex/build/has_icu_test.cpp:24: error: expected `;' before ‘c’ libs/regex/build/has_icu_test.cpp:25: error: ‘err’ was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -no-cpp-precomp -gdwarf-2 -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I"." -c -o "bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o" "libs/regex/build/has_icu_test.cpp" ...failed darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o... ...skipped <pbin.v2/libs/regex/build/darwin-4.2.1/debug>has_icu for lack of <pbin.v2/libs/regex/build/darwin-4.2.1/debug>has_icu_test.o... ...failed updating 1 target... ...skipped 1 target... ...updated 6 targets... Performing configuration checks - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam ...found 7 targets... ...updating 5 targets... common.mkdir bin.v2/libs/math common.mkdir bin.v2/libs/math/config common.mkdir bin.v2/libs/math/config/darwin-4.2.1 common.mkdir bin.v2/libs/math/config/darwin-4.2.1/debug darwin.compile.c++ bin.v2/libs/math/config/darwin-4.2.1/debug/has_gcc_visibility.o ...updated 5 targets... - ../config//has_gcc_visibility builds : yes ...found 47 targets... ...updating 1 target... darwin.compile.c++ bin.v2/libs/math/config/darwin-4.2.1/debug/has_long_double_support.o ...updated 1 target... - ../config//has_long_double_support builds : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - wave : building

2 1

[1.46.0] Unmerged changes to boost/detail
by Beman Dawes 13 Jan '11

13 Jan '11

The following files in boost/detail have not been merged to trunk. If appropriate, these should be merged. container_fwd.hpp wash 28 Dec 2010 endian.hpp johnmadddock 26 May 2010 extended_integer.hpp dwalker 24 Jul 2008 iomanip.hpp wash 08 Dec 2010 Thanks, --Beman PS: Who is "wash"?

6 13