- Boost-users - lists.boost.org

[function] Which function is adressed?
by Matthias Dondorff 21 Jun '10

21 Jun '10

Hi, I have searched the web a bit for some debugging aid when using boost::function objects. The best I found, was a little aid for a little less step into calls on Visual Studio ("F11 Hell", http://askldjd.wordpress.com/2009/09/22/some-relief-in-debugging-boost-func…) What I'm about to digg depper into, is to get to know at runtime which (member) function is adressed. I'm not believing that there is a platform or compiler independent way of doing so, but I think that it should be possible for a given compiler / platform. What I'm thinking about is some sort of symbol lookup on the adressed function and possibly some virtual table and whatsoever. Has anyone tried something like that and can give me some pointers? Best wishes, Matthias

1 0

[Test] Problem with expected failures in test suite
by Maria Kozinska 21 Jun '10

21 Jun '10

Hello, I tried to write a test suite with one expected failure, however it is not working. Probably I'm doing something wrong. The idea is that I have a function that can be implemented in few ways, thus there are few possible correct results. Depending on the implementation, I want to test it with different set of test cases. I don't want to check at the beginning of each test case which option is valid, I would prefer to skip unnecessary test cases. Is it possible? The simplified code is below: bool xxx = ...; // opt1 and opt2: two exclusive options // one of them always passes and one always fails void opt1(){ BOOST_CHECK(xxx); } void opt2(){ BOOST_CHECK(!xxx); } void test1_1(){ } test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_case* opt1_case = BOOST_TEST_CASE(&opt1); test_case* opt2_case = BOOST_TEST_CASE(&opt2); test_suite* dichotomic_test = BOOST_TEST_SUITE( "dichotomic test" ); framework::master_test_suite().add(dichotomic_test); dichotomic_test->add( opt1_case ); dichotomic_test->add( opt2_case ); // I want exactly one of them to fail dichotomic_test->increase_exp_fail(1); test_case* case1_1 = BOOST_TEST_CASE(&test1_1); case1_1->depends_on(opt1_case); framework::master_test_suite().add(case1_1); } I'll be thankful for help, Maria

3 3

does boost has some traits for container inner types which doesn't instantiate the container.
by Abir Basak 21 Jun '10

21 Jun '10

I have the code given below #include <boost/array.hpp> #include <boost/foreach.hpp> #include <vector> struct parent; struct child; typedef boost::array<child,5> childs_t; typedef std::vector<parent> parents_t; //typedef boost::array<parent,6> parents_t; //1) typedef parent* parent_pointer; //typedef parents_t::pointer parent_pointer; //2) struct child { parent_pointer par; }; struct parent { childs_t childs; }; int main() { parents_t all(6); BOOST_FOREACH(parent& p,all) { childs_t& ch = p.childs; BOOST_FOREACH(child& c,ch ) { c.par = &p; } } } I want to use the parent_pointer in a generic way as nested typedef of parents_t so that if needed I can have a different pointer type than parent* as the commented code shown in 2) .That is probably not permitted as vector of incomplete type is illegal, though it actually might work. But the same is not possible with boost::array as in 1) , as it needs complete type parent. This is because compiler tries to instantiate boost::array while accessing inner type pointer (Though actually boost::array doesn't have pointer , I can replace it by iterator, probably c++0x has pointer typedef ). On the other hand my requirement is only pointer/iterator which may not depend on complete type parent, and none of parent or child otherwise has even problem with vector, array or any other container. Is it possible (or boost has) some portable wrapper over the inner typedef of the containers which doesn't tries to instantiate the container which might depend on completeness of the type, so that I can just change the typedef of container / allocator in one location and rest will "just work". Assumption is container nested types like value_type, pointer, reference, size_type, difference_type, iterator and const counterparts doesn't depend on completeness f the parametre T. Though this question is not entirely boost related, it may not be entirely uncorrelated. Thanks abir -- Abir Basak B. Tech , IIT KGP Research Engineer & Technology Lead, Read Ink Technologies

1 0

preprocessor metaprogramming question
by Nathan Ridge 20 Jun '10

20 Jun '10

Hello, Here's a question for the preprocessor metaprogramming experts out there. I have some classes that need to have write() methods that look like this: template <typename output> bool write(output& out) const { return utils::write(out, member_1) && utils::write(out, member_2) && ... utils::write(out, member_n); } where member_1, member_2, ..., member_n are the member variables of the class. (These write() methods are used as part of a serialization framework). Since I have quite a few classes that need write() methods that look like this, and the structure of each write() method is uniform (the only thing that varies is the names of the class members), I figured that it would be neat to somehow generate the code for these write() methods. What I came up with is macros that look like this: #define MEMBERS1(m1) \ template <typename output> \ bool write(output& out) const \ { \ return utils::write(out, m1); \ } #define MEMBERS2(m1, m2) \ template <typename output> \ bool write(output& out) const \ { \ return utils::write(out, m1) && \ utils::write(out, m2); \ } // and so on for MEMBERS3, MEMBERS4, etc. Then, instead of declaring and defining the write() methods explicilty, I would just call the appropriate MEMBERS# macro in the class definition, e.g. for a class with 3 members named a, b, and c, I'd write MEMBERS3(a, b, c) in the class definition. While this is definitely an improvement over writing the write() methods explicitly for each class, there are two issues with it: 1) The number of lines of code needed to write the macro definitions is quadratic in the maximum number of parameters supported. It would be nice if it could be constant instead. 2) The user of the macros needs to match the macro name to the number of member variables in the class, and to change the macro name whenever the number of member variables changes. I'm wondering if there is a way to improve on this generation scheme that solves one or both of these issues. If I were allowed to use C++0x, I could have a variadic macro MEMBERS(...) and inside it pass the parameters to a variadic template function which unpacks its parameters and calls utils::write() on each. This would solve both issues. Unfortunately, however, I am not allowed to use C++0x features, since our code needs to be able to compile on our servers, which run Ubuntu 8.04, which runs g++ 4.2, which does not support C++0x features. So I thought I'd turn to some more preprocessor magic to solve these issues. I looked at examples in Boost.Preprocessor that generated repetitive code using preprocessor metaprogramming. However, all the examples there generated repetitive *code*, whereas what I seem to need is to be able to generate repetitive *macro definitions*. Is there a way to do that? If not, can anyone recommend other ways of improving the way I generate the code for the write() functions? Thanks in advance, Nate. _________________________________________________________________ Learn more ways to connect with your buddies now http://go.microsoft.com/?linkid=9734388

3 7

contiguous Boost.Multimap revisited
by anony 20 Jun '10

20 Jun '10

>From a post by Mathias Gaunard: > Who claimed such a thing? > An array is always stored contiguously; an array of arrays is no > different in that regard. I need to direct you to the controversy that my old post has caused: [Boost-users] Boost.Range fancify please In any case, Patrick Hogan claimed an array of arrays may not be stored contiguously (i.e. that it is not required by the standard): anony wrote: > What I see in > > vertices[][3] = { ... }; > > is an a array object of array objects. Nowhere in the standard did I > ever see multidimensional arrays specifically mentioned. It's in: 5.3.4 New section 5 (which notes: the type of new int[i][10] is int (*)[10]), and 6 8.3.4 Arrays sections 2, 3, 4, 7, and 8 8.5.1 aggregates sections 10 and 11 on array initialization, 13.1 Overloadable Declarations section 3 which notes that Parameter declarations that differ only in a pointer * versus an array [] are equivalent. That is, the array declaration is adjusted to become a pointer declaration (8.3.5) 20.5.6.4 Array modifications, Table 39. and on and on in many more places, all consistently saying the for a multidimensional array, all but the final dimensions are pointers. > Since the > elements of this array are arrays, these arrays must be contiguous in > memory. What you're missing, is that it's required in the standard (8.3.4 section 6), to consider an array as a pointer to it's first element, so an array of arrays is an array of pointers (well explained in 8.3.4 section 7 and 8). For example in gcc, this code: #include <iostream> int main() { int array[2][2]; std::cout << std::hex << array[0] << std::endl; std::cout << array[1] << std::endl; std::cout << &array[0][0] << std::endl; std::cout << &array[1][0] << std::endl; std::cout << std::dec << sizeof(array[1]) << std::endl; std::cout << sizeof(array[1][1]) << std::endl; } prints out 0xbff3519c 0xbff351a4 0xbff3519c 0xbff351a4 8 4 on one particular run, showing that array[0], and array[1] are just the addresses of their first elements, their elements are 8 byte pointers to 4 byte ints. The pointers are the elements of the array, and as you pointed out, have to be contiguous. There's nothing in the standard that requires that the rows pointed to have to be contiguous, because they aren't the elements of the array, the pointers to them are. So, the contents of the rows have to be contiguous, and the pointers to the rows have to be contiguous, but the rows themselves don't have to be. There's nothing in the standard that requires it. You get away with it with one set of data on one compiler, because it's easy for the compiler with this data to allocate memory for all the rows at once, but nothing guarantees that it will work. Liking it, or wishing that it was the way the spec has it, doesn't help. You're relying on undefined behavior. Patrick

2 2

[PTree] Failed to compile simple code
by Klaim 20 Jun '10

20 Jun '10

Hi! I'm trying to use boost::property_tree but can't compile this simple code on VC10 : #include <string> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/info_parser.hpp> const std::string CONFIG_FILE = "game.cfg"; int main() { using namespace boost::property_tree; ptree properties; // compilation error here //read_info( CONFIG_FILE, properties ); return 0; } The compilation log : Main.cpp d:\sdk\boost\boost_1_43_0\include\boost-1_43\boost\property_tree\detail\ptree_implementation.hpp(30): error C2440: 'specialization' : cannot convert from 'const std::string std::_Pair_base<_Ty1,_Ty2>::* ' to 'const std::basic_string<_Elem,_Traits,_Ax> std::pair<_Ty1,_Ty2>::* ' with [ _Ty1=const std::string, _Ty2=boost::property_tree::basic_ptree<std::string,std::string> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>, _Ty1=const std::string, _Ty2=boost::property_tree::basic_ptree<std::string,std::string> ] Standard conversion from pointer-to-member of base to pointer-to-member of derived is not applied for template arguments d:\sdk\boost\boost_1_43_0\include\boost-1_43\boost\property_tree\detail\ptree_implementation.hpp(159) : see reference to class template instantiation 'boost::property_tree::basic_ptree<Key,Data>::subs' being compiled with [ Key=std::string, Data=std::string ] d:\sdk\boost\boost_1_43_0\include\boost-1_43\boost\property_tree\detail\ptree_implementation.hpp(159) : while compiling class template member function 'boost::property_tree::basic_ptree<Key,Data>::basic_ptree(void)' with [ Key=std::string, Data=std::string ] d:\tests\test_ptree\test_ptree\main.cpp(11) : see reference to class template instantiation 'boost::property_tree::basic_ptree<Key,Data>' being compiled with [ Key=std::string, Data=std::string ] As I'm using a default ptree typedef that is already used in the tutorial, I think I might be doing something stupid but I can't find what. I tried that with boost 1.42 and 1.43, both failed. Any idea? Thanks Joël Lamotte

2 3

Boost.Wave crippling
by anony 20 Jun '10

20 Jun '10

I need Boost.Wave preprocessing functionality, but without it doing any macro expansion or substitution, only #including other header files. I'd greatly appreciate any help.

3 6

[boost] [chrono] v0.4.1 + thread_clock implementation on Windows
by vicente.botet 20 Jun '10

20 Jun '10

Hi all, As suggested by Roland Bock on the Boost Users ML, I have implemented the thread_clock on Windows using FILETIME creationTime, exitTime, kernelTime, userTime; GetThreadTimes(GetCurrentThread (), &creationTime, &exitTime, &kernelTime,&userTime); I don't know Windows well, it would be very kind if someone of you can inspect the implementation. The implementation of thread_clock for Mac is still missing. I don't know even if thread cloks are provided on this platform. In addition, I have added also the function prototypes to Boost.Thread using Boost.Chrono as well as updated the tests. This could be used as a base for a possible Boost.Thread update using chrono (standard C++0x proposal), if the library is accepted, of course. Note the modifications of Boost.Thread have been done on the base of 1.43. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. Anthony Williams has accepted to manage the review. We have not yet fixed a date, but I expect we could communicate one soon. I will be very thankful, if people using the library already or that could be interested in, can do a review even before the date. Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 7

generating a derived class from a base class
by Hicham Mouline 20 Jun '10

20 Jun '10

Hello, I have a base class with a number of pure virtual functions. I will have to write a large number of derived classes and I wish to generate the derived class definitions programmatically as containing the list of all pure virtual functions present in the base class. class Base { public: function decl 1 pure virtual function decl 2 ... function decl n private: ... }; I'd like to generate the following header file content programmatically: class Derived1 : public Base { private: <list of pure virtual functions from Base> }; The implementation file would also be generated programmatically as it only varies slightly for each new derived. How would one proceed? Regards,

1 0

call_once
by seweryn＠habdank.pl 20 Jun '10

20 Jun '10

Dears, I had observed dead lock in call_once (posix code). How to understand what causes this dead lock?Windows code works well - my usage of call_once runs normally on windows, but ported to Linuxhangs. Below I had marked where the code is waiting (endless) - see line with '// ***'. I understand that condition "flag.epoch==uninitialized_flag" is not fullfilled, but"flag.epoch==being_initialized" is passed. So it seems that: pthread_cond_waitis waiting, but I have no clue for what it is waiting. Especially that I haveno real access to "detail::once_epoch_cv" - seems to be private member of thenamespace. Also I observed that there is single hit to that function. The whileloop is done once - program is entering while and stops on the first pthread_cond_wait. template void call_once(once_flag try { pthread::pthread_mutex_scoped_unlock relocker( f(); } catch(...) { flag.epoch=uninitialized_flag; BOOST_VERIFY(!pthread_cond_broadcast( throw; } flag.epoch=--detail::once_global_epoch; BOOST_VERIFY(!pthread_cond_broadcast( } else { while(flag.epoch==being_initialized) { BOOST_VERIFY(!pthread_cond_wait(&detail::once_epoch_cv, // *** first hit here causes dead lock } } Best regards,Seweryn Habdank-Wojewodzki.

1 0