- Boost - lists.boost.org

Boost.Test doc bug.
by Hubert Holin 17 Feb '05

17 Feb '05

Somewhere in the E.U., le 17/02/2005 Bonjour It looks as though the Boost.Test doc has a slight sync issue. The BOOST_CHECK_PREDICATE macro is described (in file boost/libs/test/doc/components/test_tools/reference/index.html) as having to be used thus: 8>< ------------------------------------------- ><8 int test.cpp( int, char* [] ) { int i = 17; BOOST_CHECK_PREDICATE( std::not_equal_to<int>(), 2, (i,17) ); // ^^^^^^^^^^ return 0; } 8>< ------------------------------------------- ><8 whereas Boost.Test's test uses (in file boost/libs/test/test/test_tools_test.cpp) the following form: 8>< ------------------------------------------- ><8 using std::not_equal_to; CHECK_TOOL_USAGE( BOOST_CHECK_PREDICATE( not_equal_to<int>(), (i)(17) ), // ^^^^^^^^^ output.is_equal( CHECK_PATTERN( "error in " TEST_CASE_NAME ": test not_equal_to<int>()( i, 17 ) failed for ( 17, 17 )\n", 2 ) ) 8>< ------------------------------------------- ><8 Of course the later compiles while the former does not. Merci Hubert Holin

2 1

multi_index_container issue
by David Gruener 17 Feb '05

17 Feb '05

Hello, i just started using the boost::multi_index_container and ran into some trouble. I'm using boost version 1.32. Well, i tried a slightly modified version of Example 6 ("complex searches and foreign keys"). This is the code: -------------------------------------------------------------------------- #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/mem_fun.hpp> #include <string> using namespace std; using namespace boost; using namespace boost::multi_index; template<class KeyExtractor1,class KeyExtractor2> struct key_from_key { public: typedef typename KeyExtractor1::result_type result_type; key_from_key( const KeyExtractor1& key1_=KeyExtractor1(), const KeyExtractor2& key2_=KeyExtractor2()): key1(key1_),key2(key2_) {} template<typename Arg> result_type operator()(Arg& arg)const { return key1(key2(arg)); } private: KeyExtractor1 key1; KeyExtractor2 key2; }; struct person { string get_name() const { return "GM"; } // XXX }; struct car_manufacturer : public person // XXX { }; struct car_model { string model; car_manufacturer* manufacturer; int price; }; multi_index_container< car_model, indexed_by< ordered_unique< key_from_key< const_mem_fun<person,std::string,&person::get_name>, member<car_model,car_manufacturer*,&car_model::manufacturer> > > > > mic; -------------------------------------------------------------------------- As one might see, the change i made is that the key get_name() of the car_manufacturer now comes from a base class called person. However, this code wont compile because the compiler argues that there is no '*' operator for car_manufactuerer. I found out that the problem is the handling with the so called chained pointers in the mem_fun structs. template<typename ChainedPtr> Type operator()(const ChainedPtr& x)const // [1] { return operator()(*x); } Type operator()(const Class& x)const // [2] { return (x.*PtrToMemberFunction)(); } In the example the compiler calls [1] for car_manufacturer*, which seems right. After that, it can chose (among other methods) between [1] and [2] (Class = person) with argument type car_manufacturer and choses the better matching [1] with the followed error. However, maybe things could be done better here. The mem_fun structs could be smart enogh to deal with classes derived from template argument Class. That means [2] should be called in the case of operator() with a "Class"-derived argument. I dont know much about metaprogramming, but the following diff for const_mem_fun (as an example) of file mem_fun.hpp seems to work with a compiler supporting full template specialisation at class scope. Unfortunately gcc up to 3.4 doesn't seem to support this, while icc 8.0 does. I'm pretty sure there is a better sollution than mine, assumed that a "problem" even exists, which is my question to you. :] ------------------------------------------------------------------------------- *************** *** 12,17 **** --- 12,18 ---- #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/mpl/if.hpp> #include <boost/type_traits/remove_reference.hpp> + #include <boost/type_traits/is_base_and_derived.hpp> namespace boost{ *************** *** 45,54 **** { typedef typename remove_reference<Type>::type result_type; ! template<typename ChainedPtr> ! Type operator()(const ChainedPtr& x)const { ! return operator()(*x); } Type operator()(const Class& x)const --- 46,58 ---- { typedef typename remove_reference<Type>::type result_type; ! template<typename MaybeChainedPtr> ! Type operator()(const MaybeChainedPtr& x)const { ! return dispatch_cptr< typename mpl::if_< ! is_base_and_derived<Class, MaybeChainedPtr>, ! Class, ! MaybeChainedPtr>::type > (x); } Type operator()(const Class& x)const *************** *** 65,70 **** --- 69,87 ---- { return operator()(x.get()); } + + private: + template<typename MaybeChainedPtr> + Type dispatch_cptr(const MaybeChainedPtr& x)const + { + return operator()(*x); + } + + template<> + Type dispatch_cptr<Class>(const Class& x)const + { + return operator()(x); + } }; ------------------------------------------------------------------------------ Would some type handling like this make sense? If not, whats the best way to use dervied member function of a (pointer)member of the container type as key? If yes, are there similar issues in other extractors like member extractor? --David

2 1

wave works on simple_fun fails in pp_enum_params
by Larry Evans 17 Feb '05

17 Feb '05

I got wave to work on this: <----------------- #define DOUBLE(X) X,X #pragma wave trace(enable) DOUBLE(aaa) #pragma wave trace(disable) >----------------- but it tops out the cpu and finally aborts when BOOST_PP_ENUM_PARAMS is used. Heres the output from make: <----------------- cd /home/evansl/prog_dev/boost-release/boost_1_32_0/wave/wave/tools/wave/build/ make wave cat pp_enum_params.cpp #include <boost/preprocessor/repetition/enum_params.hpp> #pragma wave trace(enable) BOOST_PP_ENUM_PARAMS(3, class T) #pragma wave trace(disable) date Wed Feb 16 19:19:41 MST 2005 wave --traceto pp_enum_params.trace.out --output pp_enum_params.pp.out -S /usr/include/c++/3.3 -S /usr/include/c++/3.3/i486-linux -S /usr/include -S /home/evansl/prog_dev/boost-release/boost_1_32_0 pp_enum_params.cpp make: *** [wave] Killed Compilation exited abnormally with code 2 at Wed Feb 16 19:23:55 >----------------- Has anyone had success on non-trivial cases?

2 1

singleton template template parameters
by Jason Hise 16 Feb '05

16 Feb '05

In my singleton code, I have been using a template template parameter in my lifetimes for the creator[1], so that client code does not need to duplicate writing the type when specifying the creation policy. The drawback to this is that the creators which provide additional policies need to use a nested struct to avoid breaking the template signature that creators are required to have. A perfect example is the bool_creator[2]: template < bool Value > struct bool_creator{ template < typename Type > class creator { // pass Value to Type's ctor in create method }; }; If I wanted to be consistent, I would be tempted to do the same with my lifetime policies, separating the Type template parameter from the rest and having the singleton use a template template parameter for the lifetime. However, I suspect this would just make client code really ugly when it tried to specify the lifetime it wanted to use. In addition, I am willing to bet that a lot of compilers choke on template template parameters. As an alternative, I am thinking of switching the creator policy to a non template template policy. Although this would make client code have to plug the name of their class into the base singleton template yet a third time, I am thinking that in the end it would be more portable and cleaner. Thoughts? -Jason [1] Yes, I made the name change from allocator to creator in my code. The change has not yet been uploaded though, so keep in mind that creators in this message refer to allocators in the current online code, and bool_creator is really bool_alloc at the moment. [2] I'm thinking of dropping bool_creator from the library. Instead of providing it directly, I'll develop it in the documentation as an example custom creator and go on to show how it can be used to implement a zombie singleton. Of course, if you think it should stay in the library let me know, I can be persuaded to keep it.

2 3

problem with boost::variant and borland
by Robert Ramey 16 Feb '05

16 Feb '05

I have a program which consists on one line: #include <boost/variant.hpp> If I try to compile this using the main CVS tree, I get the following with borland 5.51 and 5.64 compilers: Error E2401 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Invalid template argument list Error E2041 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Incorrect use of default Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Declaration terminated incorrectly Error E2394 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too few arguments passed to template 'substitute<T,Dest,Source,Arity>' Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Declaration terminated incorrectly Error E2228 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too many error or warning messages What can be done to fix this? Robert Ramey

2 2

[repost][multi_index][hash][rfc] Hashed indices preview + Boost.Hash
by Joaquín Mª López Muñoz 16 Feb '05

16 Feb '05

Allow me to repost this message from a couple of days ago, since nobody responded :( In another situation, I could proceed according to my own judgement, but point (6), in particular, necessitates a public discussion, IMHO. Thank you, Hello all, You can find a preview version of Boost.MultiIndex including hashed indices plus Daniel James' Boost.Hash library at the Sandbox Files area: multi_index_140205_plus_hash_part_1.zip multi_index_140205_plus_hash_part_2.zip (split in two for maximum size reasons.) There are a number of things we'd like to ask you feedback about: 1. Hashed indices are modeled according to the latest TR1 draft, with some significant diversions: 1.1. erase() does not throw ever, even it the user-provided Hash object throws. This is imposed by the general framework of Boost.MultiIndex. This goodie does not come for free: if the Hash object throws, erase() decays to a linear search. Not that there's any alternative, but I'd like to point it out. 1.2. insert() has strong exception safety (TR1 only requires basic.) Again, the way Boost.MultiIndex is designed forces this. 1.3. hash indices iterators are bidirectional. 1.4. Usual implementations use one pointer per bucket, whereas Boost.MultiIndex has two pointers per bucket. This addresses potential performance problems of insert() and erase() under low load conditions, as discussed in http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf issue 6.14. Is this convenient? 2. The material is complete except for a section in the tutorial and possibly one more example (example 8 already exercises hashed indices.) Tests fully sport hashed indices. The reference is also updated. 3. All in all, I'd greatly appreciate your comments on this: suitability, documentation, performance, etc. I plan to commit this to the CVS if nobody objects in a reasonable amount of time (a couple of weeks.) I'm open to all kind of suggestions --I'm eager to recieve them, as it happens :) 4. As for Boost.Hash, this library by Daniel James' implements the ideas for std::tr1::hash (albeit in boost namespace) proposed by Peter Dimov in the aforementioned paper, issue 6.18. The idea is to provide a general purpose hash<> utility for use by * Boost.MultiIndex * TR1-based unordered containers (Daniel is working on this.) * Eventually, wrapping by Boost.TR1. 5. The library comes fully documented and tested, and in our view well prepared for uploading to the CVS. 6. Yet, this hasn't undergone any formal review, so some of you might (with reason) object to its being commited to the CVS. From our point of view, we have three valid alternatives: * Boost members agree to have it in CVS without more ado. * As this is used by Boost.MultiIndex, Boost.Hash is suitable for fasttrack review. * This is untolerable and the library should be push_back()'ed to the review queue. Meanwhile, Boost.Hash should live as an impl detail of Boost.MultiIndex. We hope you find the material useful and look forward to knowing your opinions about the issues brought forward. Best, Joaquín M López Muñoz Daniel James

4 4

[boost] [Important] Mailing list downtime this Saturday, February 19
by Doug Gregor 16 Feb '05

16 Feb '05

The Open Systems Lab, which hosts most of the Boost mailing lists, will be migrating to new hardware this Saturday. The outage will be this Saturday, February 19 starting at noon Eastern Standard Time and should not last more than 8 hours. lists.boost.org will be unavailable during the outage as will the mailing lists themselves. Thanks, Doug Gregor

1 0

RE: [boost] Re: Re: Profiling Library suggestion
by Brian Braatz 16 Feb '05

16 Feb '05

Christopher, Just wanted to send out a note so you know I have not lost interest in the profile library. I was fairly active in this conversation up until the weekend. My main computer died and had to be reinstalled. I am back running again (and back on mail). I am re-arranging the project I am working on so that I can spend the next 5 days to actually use your library as is to profile a million line application. I will keep you posted as to my progress. (considering the structure of the application, the "hard part" here is going to be adding the library in after the fact). This should be a fairly useful experience. Thank you for staying with this library and responding to all of the suggestions from myself and others. Brian

2 1

void * with boost::python
by Preston A. Elder 16 Feb '05

16 Feb '05

I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg: std::string str("This is a test"); hexdump(str.data(), str.length()); std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t)); I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it). Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class). Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures. Also, on another note, is there somewhere that has all of boost already pythonized? I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 8

Wave review
by Joel de Guzman 16 Feb '05

16 Feb '05

Hi Hartmut, I wanted to try out the examples. I encountered some problems: + Read the quikstart to get me started immediately. "Do not instantiate the main, preprocessing iterators yourself." --> not enough context here. "main" is undefined at this point. + when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good. + Now, I'm able to build the samples using bjam V2. A little hickup: bjam complains: error: Unable to find file or target named error: '/boost/program_options//boost_program_options' error: referred from project at error: 'cpp_tokens/build' Looking at program_options, it seems that the library name is program_options (without the boost_ prefix). + Got this fixed and. Now got into a link error: gcc.link ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.exe ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\release\ cpp_main.o(.text+0x50):cpp_ ain.cpp: multiple definition of `_main' ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.o(.text+0x7eb0):ins ect.cpp: first defined here Any clues? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 12