- 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