March 2009 - Boost-users - lists.boost.org

Testing algorithms don't use more than a concept provides
by athor 12 Mar '09

12 Mar '09

I'm trying to verify an algorithm doesn't use more than a certain concept provides. For example, if the algorithm checks for an ForwardIterator it must not use the i-- operator. I'm currently testing this by creating a minimal abstract class for each concept and then testing if the algorithm compiles using only the minimal as input. I have a few issues with this approach. 1. I have to maintain two definitions, one concept and one minimal implementation. 2. I have to write minimal implementations for all the boost/stl containers/concepts I want to use. I guess someone must have had the same problem before, is there a better way to do this? Maybe even some existing boost functionality I am unaware of? In code: ------------------------ #define CONCEPT_USER(function, call, targ1) \ struct ConceptUser_##function##_##targ1 \ { \ targ1& _1; \ void Check() \ { \ function##call; \ } \ }; struct Interface { virtual void Foo() const = 0; }; template<typename T> void f(int n, const T& t) { t.Foo(); } CONCEPT_USER(f, (47, _1), Interface); // Compiles template<typename T> void g(double x, const T& t) { t.Foo(); t.Bar(); } CONCEPT_USER(g, (3.14, _1), Interface); // Compile Error. g also uses the function Bar. ------------------------ -- View this message in context: http://www.nabble.com/Testing-algorithms-don%27t-use-more-than-a-concept-pr… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[preprocessor] error: macro "BOOST_PP_SEQ_ELEM_III"
by Reimund Klemm 12 Mar '09

12 Mar '09

I'm having a problem with the preprocessor and currently I'm stuck. I tried to reduce the problem from my program as far as possible. Why does this example compile with an error?: #include <boost/preprocessor/seq/subseq.hpp> #include <boost/preprocessor/seq/seq.hpp> #include <boost/preprocessor/control/if.hpp> #define SEQ (b)(o)(o)(s)(t) #define i 0 int main( int argc, char* argv[]){ BOOST_PP_IF(i,BOOST_PP_SEQ_HEAD(BOOST_PP_SEQ_SUBSEQ(SEQ, 0, i)),0); return 0; } The error is the following: ./test.cxx:23:1: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given I'm using gcc 4.3.1 under Linux. As the condition is 0, the preprocessor shouldn't expand BOOST_PP_SEQ_HEAD(BOOST_PP_SEQ_SUBSEQ(SEQ, 0, i)). The preprocessed file (g++ -P -E) has expands to 0; but the preprocessor still throws an error. Could also someone give me a hint how to debug efficiently such a problem, as I'm a newbie to boost. --- Reimund

2 2

[multi-index] runtime indices
by Neil Hunt 12 Mar '09

12 Mar '09

Hi all, I have been using multi-index with great success, but have struck a requirement that sort of fits into the remit of multi-index, but isn't catered for. Here's what I want to do (pseudocode) typedef multi_index<MyClass> MyIndex; MyIndex mi; int index_id = 0; mi.add_sorted_index( index_id++, MyIndex::sorted_index_predicate_type( &some_predicate ) ); mi.add_sorted_index( index_id++, MyIndex::sorted_index_predicate_type( &some_other_predicate ) ); So basically, add indices at runtime, to take advantage of multi_index's great features, such as projection, index updating on modification, etc. My use case, if it's relevant, is to expose multi_index behaviour on objects from a dll. Where obviously the calling module can't specify at compile time the required indices. Is this a sensible addition to multi-index, or is it best implement using other mechanisms. (Having to re-implement many of the great features of multi-index doesn't seem desireable.) Neil

2 1

[bind][factory] Nested binds with functional/factory
by Rutger ter Borg 12 Mar '09

12 Mar '09

Dear all, I'm trying to use boost::bind in combination with boost/functional/factory.hpp (and value_factory) this works fine, boost::bind( boost::factory<T*>(), arg1, _1 ) with arg1 not being an lvalue (e.g., 2.0). however, with nested binds it is not accepted, boost::bind( boost::factory<T*>(), boost::bind( f, _1 ), _2 ) the compiler complains that it needs an lvalue for the nested bind. Is this desired behaviour? Is there some trick around this? Many thanks, Kind regards, Rutger ter Borg

1 0

opinions about a clean c++ ".net style" property system
by Isaac Lascasas 12 Mar '09

12 Mar '09

I have been strugling the past weeks designing a system to add ".net style" properties to my library. After some experiments like wrapping the class members inside member<type> m_member stuff I realized that I was wrong about what exactly a property is. So I rewrote everything again with the following idea in mind: A property is nothing more that a pack of some accessor functions and maybe some data. My objective was to support properties while keeping the class size the same and without any speed impact or weird requeriment in the get/set functions. The code is working right now but I think it can be more compact for the user, but unfortunately my c++ skills are insuficient to polish some things. Here is an example: This block shows how the system actually works: { rectangle_i r(1,2,3,4); size_i sz = get_property<size_i>(r, L"size"); get_property(sz, r, L"size"); set_property(r, L"size", size_i(10,20)); bool IsEmpty; get_property(IsEmpty, r, L"IsEmpty"); rectangle_i r2(10,1,1,1); get_property(r2, r, L"empty"); } And this section of a common rectangle class (ripped from .net api) shows how to register this "properties": template <class T_> class rectangle { // ... const point<T_>& get_location() const {return m_location;} void set_location(const point<T_>& value) {m_location = value;} static void initialize_property_pool(property_pool& out) { out.add<rectangle<T_>, point<T_>>(L"location", &rectangle<T_>::get_location, &rectangle<T_>::set_location); out.add<rectangle<T_>, size<T_>>(L"size", &rectangle<T_>::get_size, &rectangle<T_>::set_size); out.add<rectangle<T_>, T_>(L"height", &rectangle<T_>::get_height, &rectangle<T_>::set_height); out.add<rectangle<T_>, T_>(L"width", &rectangle<T_>::get_width, &rectangle<T_>::set_width); out.add<rectangle<T_>, T_>(L"bottom", &rectangle<T_>::get_bottom, &rectangle<T_>::set_bottom); out.add<rectangle<T_>, T_>(L"left", &rectangle<T_>::get_left, &rectangle<T_>::set_left); out.add<rectangle<T_>, T_>(L"right", &rectangle<T_>::get_right, &rectangle<T_>::set_right); out.add<rectangle<T_>, T_>(L"top", &rectangle<T_>::get_top, &rectangle<T_>::set_top); out.add_read_only<rectangle<T_>, bool>(L"IsEmpty", &rectangle<T_>::get_is_empty); out.add_static_read_only<rectangle<T_>, rectangle<T_>>(L"empty", &rectangle<T_>::get_empty); } // ... }; I want to know if there is a way of deducing the template parameters to reduce this verborreic initialize_property_pool function and to simplify things to the user and to replace "add_read_only" and "add_static_read_only" with just another pair of plain "add" functions. Any observation will be apreciated, thanks, Isaac Lascasas.

1 0

[thread] call_once question
by Agustín K-ballo Bergé 12 Mar '09

12 Mar '09

Is the following code supposed to work (instead of resulting on a stack overflow)? If so, what I'm doing wrong? I'm using Boost 1.37.0 on MS Visual Studio 2008, Windows. #include <boost/thread/once.hpp> boost::once_flag initialization_flag = BOOST_ONCE_INIT; void call_me_once() { boost::call_once( initialization_flag, call_me_once ); } int main( int, char*[] ) { boost::call_once( initialization_flag, call_me_once ); return 0; } Additionaly, - Can a once_flag be safelly used in a class or local static? - Is BOOST_ONCE_INIT guaranteed to statically initialize the flag? Agustín K-ballo Bergé.-

2 2

how to detect if a type is among a know list inside enable_if
by Claude Brisson 12 Mar '09

12 Mar '09

Hi, I need to enable only if a type T is among a specific known list. I tried to build an operator is_one_of< T, list of known types > condition that could be used within an enable_if (like others type_traits operators), like this: or< is_same< T, type1 >, or< is_same< T, type2>, ... > so I searched for an or< condition1, condition2> construct and didn't find anything... Thanks for your suggestions! Claude

2 1

[thread] thread_specific_ptr interface
by Agustín K-ballo Bergé 12 Mar '09

12 Mar '09

Is there a reason why thread_specific_ptr does not offer boolean evaluation as pointers do? Agustín K-ballo Bergé.-

1 0

Boost.date_time compilation error Debian GCC 4.3 Boost 1.35
by Joost Kraaijeveld 11 Mar '09

11 Mar '09

Hi, I cannot get this short program to compile with GCC 4.3.2: #include <iostream> #include <boost/date_time/gregorian/gregorian.hpp> #include <boost/date_time/gregorian/formatters.hpp> int main(int argc, char** argv){ boost::gregorian::date date = boost::gregorian::day_clock::local_day(); std::cout << boost::gregorian::to_sql_string_type(date) << std::endl; return 0; } The error is: g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"Main.d" -MT"Main.d" -o"Main.o" "../Main.cpp" ../Main.cpp: In function ‘int main(int, char**)’: ../Main.cpp:18: error: no matching function for call to ‘to_sql_string_type(boost::gregorian::date&)’ I cannot find any solution anywhere hence my question: what am I doing wrong, and more important, how can I get it working? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl

4 3

C++03 unique_ptr emulation
by Howard Hinnant 11 Mar '09

11 Mar '09

I've put up a new version of an C++03 emulated unique_ptr here: http://home.roadrunner.com/~hinnant/unique_ptr03.html This is a "boost-ized" emulation (uses boost tools and is in boost namespace), though I have reason to believe it may not work well on VC+ +05 unless the /Za option is used (I've tested only on gcc 4.0). I'm aware of Ion's interprocess version (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_sma… ), and thank Ion for his support over the years. This new version is not meant to replace Ion's version. It is simply my current best shot at emulating the unique_ptr behavior as specified in the C++0X CD1 draft. Booster's are welcome to take parts of this implementation and use them in places like interprocess/unique_ptr. Or to just use this unique_ptr directly. It consists of only one header: unique_ptr.hpp, and requires only boost headers, not boost cpp files. Basic documentation is included at the link. -Howard

5 8