- Boost - lists.boost.org

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