August 2005 - Boost-users - lists.preview.boost.org

shared_ptr & polymorphic_iarchive in 1.33.0
by Sergey Skorniakov 29 Aug '05

29 Aug '05

Has anybody tested loading of shared_ptr with polymorphic archives? All that I manage to achive is just a couple of errors: c:\boost_1_33_0\boost\archive\detail\interface_iarchive.hpp(73) : error C2039: 'basic_iarchive' : is not a member of 'boost::archive::polymorphic_iarchive' c:\boost_1_33_0\boost\archive\polymorphic_iarchive.hpp(52) : see declaration of 'boost::archive::polymorphic_iarchive' c:\boost_1_33_0\boost\archive\detail\interface_iarchive.hpp(72) : while compiling class-template member function 'void boost::archive::detail::interface_iarchive<Archive>::lookup_helper(const boost::serialization::extended_type_info *const ,boost::shared_ptr<T> &)' with [ Archive=boost::archive::polymorphic_iarchive, T=void ] c:\boost_1_33_0\boost\archive\polymorphic_iarchive.hpp(54) : see reference to class template instantiation 'boost::archive::detail::interface_iarchive<Archive>' being compiled with [ Archive=boost::archive::polymorphic_iarchive ] c:\boost_1_33_0\boost\archive\detail\interface_iarchive.hpp(73) : error C2662: 'boost::archive::detail::basic_iarchive::lookup_basic_helper' : cannot convert 'this' pointer from 'boost::archive::polymorphic_iarchive' to 'boost::archive::detail::basic_iarchive &' Reason: cannot convert from 'boost::archive::polymorphic_iarchive' to 'boost::archive::detail::basic_iarchive' Conversion requires a second user-defined-conversion operator or constructor

3 6

Re: [Boost-users] [typeof] question: BOOST_TYPEOF_COMPLIANT
by Bulygin, Sergey 29 Aug '05

29 Aug '05

>>#include <boost/typeof/typeof.hpp> >>#define BOOST_TYPEOF_COMPLIANT >Just move define before the include, otherwise it has no effect. >Regards, >Arkadiy I tried that before, but it didn't give an effect. Now I discovered the problem - that was "#include <boost/typeof/typeof.hpp>" in the precompiled header file. That way typeof.hpp in the cpp was ignored, and BOOST_TYPEOF_COMPLIANT definition didn't make its job. Thanks! Sergey

1 0

Re: [Boost-users] [typeof] question: BOOST_TYPEOF_COMPLIANT
by Arkadiy Vertleyb 29 Aug '05

29 Aug '05

Hi Sergey, >#include <boost/typeof/typeof.hpp> >#define BOOST_TYPEOF_COMPLIANT Just move define before the include, otherwise it has no effect. Regards, Arkadiy

1 0

[mpl] looping over a list of types inside a function
by Geoffrey Irving 29 Aug '05

29 Aug '05

Hello, I would like to be able to write code like this: int i; for F in LIST_OF_TYPES complicated_function<F>(i); where this code is inside some other function which is inside a class templatized over LIST_OF_TYPES. Given the lack of nested functions and classes in C++ functions, am I correct in thinking that it's impossible to do this sort of thing inside another function? In my particlar case, all the complicated code has already been factored into complicated_function, and there are only ever two LISTS_OF_TYPES, so my current solution is just to manually specialize over LISTS_OF_TYPES. However, this kind of construct often appears several times (with different complicated_functions) in a given outer function, so it would be very nice to only have to write down the high level structure once. Thanks, Geoffrey

3 6

Re: [Boost-users] Using MPL for conditional compilation
by JOAQUIN LOPEZ MU?Z 29 Aug '05

29 Aug '05

----- Mensaje original ----- De: "Alan M. Carroll" <amc(a)network-geographics.com> Fecha: Martes, Agosto 23, 2005 8:52 pm Asunto: [Boost-users] Using MPL for conditional compilation > I am building a templated container class C. Normally it acts just > like an stl::map. However, if the mapped_type of a container > C<key1, value1> is also a specialization of C (value1 = C<key2, > value2>) then the key types of the containers are merged in to a > tuple yielding a container that acts like C< <key1, key2>, value2 >. > > Obviously the MPL has been quite useful for this but I'm not clear > on the best style / usage for a particular effect. > > Inside C, the insert method has two parts, the part that's the > same regardless of whether C is merged container and the part that > isn't. How should I arrange to have different code executed > depending on whether C is a merged container or not? I have a > class static const bool IS_OUTER that is set to true for merged > containers and false otherwise. > [...] > > 5) Use traits classes keyed by IS_OUTER to provide the differing > implementations. If the *syntactic* differences between both flavors can be reduced to only different definitions for key_type and mapped_type, I'd use something like your option 5) : template<typename Key, typename Value> class your_container { static bool const IS_OUTER=...; typedef typename boost::mpl::if_c< IS_OUTER, struct outer_tag, struct inner_tag >::type flavor; public: typedef typename boost::mpl::if_c< IS_OUTER, boost::tuple<Key,typename Value::key_type>, Key >::type key_type; typedef typename boost::mpl::if_c< IS_OUTER, typename Value::mapped_type, Value >::type mapped_type; // example of memfun with alternate implementations const_iterator find(const key_type& k)const { return find_impl(k,flavor()); } // shared menfuns do not need any special machinery private: // alternate implementations of find const_iterator find_impl(const key_type& k,outer_tag)const { ... } const_iterator find_impl(const key_type& k,inner_tag)const { ... } }; With this scaffolding set up, it is guaranteed that only the appropriate *_impl memfuns are compiled in each case, and the runtime penalty should be optimized away to zero. OTOH, if the number of memfuns with alternate implementations is very large with respect to shared memfuns, you might want to go for fully separated classes. HTH, Joaquín M López Muñoz Telefónica, Investigaión y Desarrollo

4 3

Regex boost 1.33 - (mingw/w32) linking problem
by Arno Mauhourat 29 Aug '05

29 Aug '05

Hi, I compiled the regex library with: bjam.exe -sTOOLS=mingw -sMINGW_ROOT_DIRECTORY=D:\Dev-Cpp When linking my project with the generated library (libboost_regex-mgw-d-1_33.lib), I get: ../sources/cmdline.o(.text+0x6fe9): In function `_tcf_1': d:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_string.h:257: undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::init()::null_string' ... etc.... Does that mean I should try using STLPort or ? Regards, Arno

3 2

[typeof] question: BOOST_TYPEOF_COMPLIANT
by Bulygin, Sergey 29 Aug '05

29 Aug '05

Evaluating Boost.Typeof library with MSVC 7.1 compiler. Since this compiler has native typeof trick, BOOST_TYPEOF and BOOST_AUTO work fine by default. But with regard to future upgrade to MSVC 8.0, I want to have my TYPEOF-related code portable, i.e. registering all those user types for proper TYPEOF emulation. When I "#define BOOST_TYPEOF_COMPLIANT", nothing happens and the code proceeds working even without registering my types. I would expect BOOST_TYPEOF_COMPLIANT definition to cause compiler errors for not registered types. Here's the code snippet that I am trying to compile: #include <boost/typeof/typeof.hpp> #define BOOST_TYPEOF_COMPLIANT struct X {}; template<typename A, bool B> struct Y {}; typedef std::pair<X, Y<int, true> > Pair_t; Pair_t a; BOOST_AUTO(b, a); BOOST_AUTO(pp, Pair_t()); What do I miss here? Thank you, Sergey Bulygin

1 0

Boost.Algorithm: Functors must be CopyConstructible
by Daniel Krügler 29 Aug '05

29 Aug '05

Several functors in Boost.Algorithm do not fulfill CopyConstructable requirements, e.g. case_conv.hpp: to_lowerF, to_upperF formatter_regex.hpp: regex_formatF I propose to replace their reference members by either corresponding pointers or by boost::reference<>'s. Greetings from Bremen, Daniel Krügler

2 2

strange filesystem dll behaviour
by Paul 28 Aug '05

28 Aug '05

Hi, I'm having killer problems with the filesystem library. I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc. Then I wrote this simple program: #include <boost/filesystem/path.hpp> #include <iostream> using namespace std; using namespace boost::filesystem; int main() { try { path p("c:",native); } catch (exception & e) { cerr << "Error: " << e.what() << endl; return 1; } cerr << "Ok" << endl; return 0; } and compiled it with the Makefile: test: test.cpp Makefile g++ -g -I../boost/boost-compiled -I. -Wall -c test.cpp g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test.exe test.o libboost_filesystem-mgw-d-1_32.lib g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test-dll.exe test.o -L. -lboost_filesystem-mgw-d-1_3 (adjust for your paths, I copied the dlls and libs into the local dir Just To Be Sure). The output of running the two programs is as follows: paul@xyz ~/test $ ./test Ok paul@xyz ~/test $ ./test-dll.exe Error: boost::filesystem::path: invalid name "c:" in path: "c:" Why does it behave differently depending on the linkage? If I must use a .lib, what if it needs to be used in multiple .dlls of mine? Help? Thanks Paul

3 10

[Test] typo in auto_unit_test.hpp
by Takeshi Mouri 28 Aug '05

28 Aug '05

Hello, line 198: BOOST_AUTO_TC_REGISTRAR( test_nase )( This may cause the redefinition of test_nase_registrar(). I think that it is not "test_nase" but "test_name". Regards, Takeshi Mouri

2 1