- Boost - lists.boost.org

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