November 2006 - Boost-users - lists.preview.boost.org

Re: [Boost-users] [lambda] if-then-else construct gets broken bylambda-lib
by Nat Goodspeed 07 Nov '06

07 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Sebastian Weber > Sent: Tuesday, November 07, 2006 12:41 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [lambda] if-then-else construct gets broken > bylambda-lib > > I'm trying to store a reference to a function depending upon a condition > within a function object like this: > > boost::function< double (std::size_t) > wf = (sIndex < m_maxIndex+1) ? > ( boost::lambda::bind(boost::ref(m_cf), sDeg, boost::lambda::_1) ) : > ( boost::ref(*m_wf) ); [Nat] Does it work better if the 'else' clause is something more like: ( boost::lambda::bind(boost::ref(*m_wf)) ) ? This is a wild guess, but boost::ref() isn't by itself a lambda bind expression -- is it? Both halves of the ternary operator are convertible to boost::function -- but they're not the same type. I don't know whether two different boost::lambda::bind expressions are going to be compatible either. You may have to explicitly instantiate boost::function objects on both sides of the : -- which would end up being less terse than writing the if/else statement. But it seems worth a try.

2 1

Serialization with polymorphic_*_archive and BOOST_CLASS_EXPORT
by Anders Wang Kristensen 07 Nov '06

07 Nov '06

Hi, I'm having trouble serializing through the a pointer to the base as shown below. If I manually register class B with template register_type<B>() it works, but I would rather use the BOOST_CLASS_EXPORT macros since that is more convenient. Unfortunately BOOST_CLASS_EXPORT assumes you are using the templated version of serialize, and not polymorphic_iarchive/oarchive, that I'm using. Anyone know how to get around that problem? Thanks! -- wang Example: #include <boost/archive/polymorphic_text_iarchive.hpp> #include <boost/archive/polymorphic_text_oarchive.hpp> #include <boost/archive/polymorphic_xml_iarchive.hpp> #include <boost/archive/polymorphic_xml_oarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/export.hpp> struct A { void serialize(boost::archive::polymorphic_iarchive & ar, const unsigned int file_version); void serialize(boost::archive::polymorphic_oarchive & ar, const unsigned int file_version); int data; bool operator==(const A & rhs) const { return data == rhs.data; } A() : data(0) {} virtual ~A() = 0 {} }; void A::serialize( boost::archive::polymorphic_iarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_NVP(data); } void A::serialize( boost::archive::polymorphic_oarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_NVP(data); } struct B : public A { void serialize(boost::archive::polymorphic_iarchive & ar, const unsigned int file_version); void serialize(boost::archive::polymorphic_oarchive & ar, const unsigned int file_version); int foo; bool operator==(const B & rhs) const { return data==rhs.data && foo==rhs.foo; } B() : foo(2) {} }; void B::serialize( boost::archive::polymorphic_iarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(A); ar & BOOST_SERIALIZATION_NVP(foo); } void B::serialize( boost::archive::polymorphic_oarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(A); ar & BOOST_SERIALIZATION_NVP(foo); } BOOST_CLASS_EXPORT(B) int main(int argc, const char* argv[]) { boost::shared_ptr<A> a(new B); boost::shared_ptr<A> b; { std::stringstream ss; { boost::archive::polymorphic_text_oarchive oa(ss); //oa.template register_type<B>(); oa << BOOST_SERIALIZATION_NVP(a); } { boost::archive::polymorphic_text_iarchive ia(ss); //ia.template register_type<B>(); ia >> BOOST_SERIALIZATION_NVP(b); } } B* x = dynamic_cast<B*>(a.get()); B* y = dynamic_cast<B*>(b.get()); assert(*x == *y); return 0; }

2 4

Re: [Boost-users] Serialization problem on 64-bit Windows release
by Сергей Филиппов 07 Nov '06

07 Nov '06

Robert Ramey <ramey <at> rrsd.com> writes: > > Is it possible that this might be related to the recently discovered fact > (at least by me) versions of the serialization library are, contrary to > intention, not thread safe? That is, conflict occurs when multiple threads > are using serilization even with different archive instances due to the fact > that they share the same gobal extended_type_info table. This has been > addressed - and hopefully remedied in 1.35. > > Robert Ramey What does it mean that the serialization library is "not thread safe"? Does it mean that the serialization must be used in one thread only or the serialization can be used in different, non-concurrent threads? I'm not familiar with the serialization library internals so it's hard to me to make a guess where it is related to my case. My application is an RPC server that supports only one client connection. The client establishes connection, makes some calls to the server and exits. Each call can generate "events" that are stored on the server in a vector. After a call the client may call the server's function SerializeEvents which serializes the vector into buffer and transmits the buffer to the client. Actual serialization code is straightforward. void CEventLogger::Serialize(std::vector<BYTE>* pBuffer) { std::stringstream stream; boost::archive::text_oarchive ar(stream); ar & m_Events; std::string str(stream.rdbuf()->str()); if(str.length()) { BYTE *pBuf = reinterpret_cast<BYTE*>(const_cast<char*>(str.c_str())); pBuffer->assign(pBuf, pBuf + str.length()); } else pBuffer->clear(); } The client communicates with the server in one thread only. So the functions that are populating m_Events and CEventLogger::Serialize are called in different threads, but these calls are serialized. What you think? Can "not thread safety" be a reason in my case? Thanks, Sergey (Sorry, I forget to mention I'm using boost 1.33.0.)

2 1

fpclassify
by Johan Råde 07 Nov '06

07 Nov '06

Ignore my last message. It was sent by mistake. --Johan

1 0

fpclassify
by Johan Råde 07 Nov '06

07 Nov '06

Olivier, Håkan, Kan ni testa den här? Fungerar den här, så får den bli den slutgiltiga versionen. --Johan

1 0

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 07 Nov '06

07 Nov '06

Hi, thank you all for your help. It was a basically missunderstanding of join() on my side. The message of Nat Goodspeed helped me to discover that. So, lets close this thread. Torsten -----Ursprüngliche Nachricht----- Von: Ovanes Markarian [mailto:om_boost@keywallet.com] Gesendet: Dienstag, 7. November 2006 00:29 An: boost-users(a)lists.boost.org Betreff: Re: [Boost-users] [Threads] Problem with starting a sub thread An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Serialization] Need help resolving problem putting serialization code into static library
by Mark Melton 07 Nov '06

07 Nov '06

All, I am hoping someone can help me resolve a problem I am having putting serialization code into a static library. If I am lucky, it will be simple user error. Here is a quick synopsis of the code: a.hpp class A { virtual ~A() { } ...} b.hpp class B : public A { virtual ~B() { } ... } with classes A and B both having the standard serialization functions defined in a.cpp and b.cpp respectively along with the necessary BOOST_CLASS_EXPORT statements. Now, compiling a single program like this works fine and the program is able to serialize objects of types A and B through pointers of type A without any problems. Life is good. g++ -o my_prog my_prog.cpp a.cpp b.cpp -lboost_serialization However, compiling a static library and then linking the same program like this produces a my_prog that gets an unregistered_class exception when trying to serialize an object of type B through a pointer of type A. Not what I expected because the only difference is in the linking phase where code is now coming from the library instead of the object files. g++ -o a.o -c a.cpp g++ -o b.o -c b.cpp ar cru a.o b.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Now, combining a.cpp and b.cpp and building the library produces a working program. Confusion reigns. g++ -o ab.o -c a.cpp b.cpp ar cru ab.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Any ideas would be greatly appreciated. I have tried several incantations, but I cannot make any headway. I am working under the assumptions that it has something do to with the initialization code difference between using the object files and the library. I am using boost 1.33.1 on intel OS X 10.4.8 with g++ in 64 bit mode. If it would be useful, I can run experiments in 32 bit mode or on Ubuntu, but I have yet to find any differences with this issue. Thanks, mark

2 1

Global Mutex
by Daher 07 Nov '06

07 Nov '06

Hi, How do I create a global mutex in boost.threads ? Dee

3 3

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Ovanes Markarian 06 Nov '06

06 Nov '06

An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 06 Nov '06

06 Nov '06

Thanks for the quick answers. I understood and experienced that the main thread blocks. But how can it join other threads, if it is blocked? That doesn't seem consistent to me. Torsten > > > Hi! > > join cause a calling thread to block until the second one is finished. This is also stated in the > docs: > 1.void join(); > Requires: *this is joinable. > !!!!!Effects: The current thread of execution blocks until the initial function of the thread of > execution represented by *this finishes and all resources are reclaimed. > Notes: If *this == thread() the result is implementation-defined. If the implementation > doesn't detect this the result will be deadlock.

2 1

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Nat Goodspeed 06 Nov '06

06 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other.

1 0

Compiling error in windows VC8: unrecognized posix_time:: microsec_clock
by Cheng, Victor S 06 Nov '06

06 Nov '06

I'm testing the boost 1_33_1 date_time library, but run into a strange compilation problem. In the following code, second_clock::local_time() is fine, but microsec_clock::local_time() will not compile. I'm using XP and visual studio 2005 and VC8. Am I missing anything in my build? compiler messages: 1>.\t2.cpp(18) : error C2653: 'microsec_clock' : is not a class or namespace name 1>.\t2.cpp(18) : error C3861: 'local_time': identifier not found the code: #include "boost/date_time/posix_time/posix_time.hpp" #include <iostream> int main() { using namespace boost::posix_time; ptime now = microsec_clock::local_time(); std::cout << now << std::endl; return 0; } ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

3 2

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Ovanes Markarian 06 Nov '06

06 Nov '06

Hi! join cause a calling thread to block until the second one is finished. This is also stated in the docs: 1.void join(); Requires: *this is joinable. !!!!!Effects: The current thread of execution blocks until the initial function of the thread of execution represented by *this finishes and all resources are reclaimed. Notes: If *this == thread() the result is implementation-defined. If the implementation doesn't detect this the result will be deadlock. There is a good article on boost threads at Dr.Dobbs site: http://www.ddj.com/dept/cpp/184401518 With Kind Regards, Ovanes Markarian On Mon, November 6, 2006 14:17, Torsten wrote: > Hi, > > im trying to initiate a sub thread for checking some variables during the main program is running: > > ...do sth... > > boost::thread checkT(&check); > checkT.join(); > > ...do sth... > > As I understand boost::threads the second "do sth" should be performed during the thread is running. Well, it doesn't seem so. After experimenting some time it came up that starting two threads like that: > > boost::thread checkT(&check); > boost::thread stopCheckT(&stopCheck); > checkT.join(); > scheckT.join(); > > does work, but that: > > boost::thread checkT(&check); > checkT.join(); > boost::thread stopCheckT(&stopCheck); > scheckT.join(); > > does not. I really don't understand why. Either .join() stops executing the code (so the scheckT.join() in the first example shouldn't be called) or it doesn't (than the second scheckT should be called too). > > Where am I wrong? Has anybody an idea? > > Torsten > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > With Kind Regards, Ovanes Markarian

1 0

[Threads] Problem with starting a sub thread
by Torsten 06 Nov '06

06 Nov '06

Hi, im trying to initiate a sub thread for checking some variables during the main program is running: ...do sth... boost::thread checkT(&check); checkT.join(); ...do sth... As I understand boost::threads the second "do sth" should be performed during the thread is running. Well, it doesn't seem so. After experimenting some time it came up that starting two threads like that: boost::thread checkT(&check); boost::thread stopCheckT(&stopCheck); checkT.join(); scheckT.join(); does work, but that: boost::thread checkT(&check); checkT.join(); boost::thread stopCheckT(&stopCheck); scheckT.join(); does not. I really don't understand why. Either .join() stops executing the code (so the scheckT.join() in the first example shouldn't be called) or it doesn't (than the second scheckT should be called too). Where am I wrong? Has anybody an idea? Torsten

2 1

dynamic-bitset: reversing bits.
by chun ping wang 06 Nov '06

06 Nov '06

Hey i have a quick question regarding dynamic bits. Is there a quick and effective way to reverse bits. (if so how)... i try swapping.. but i get compile time error. so that i can calculate iterative-fft since it requires bit-reverse-copy for (i = 0; i<num_bits/2; ++i) swap(b[i], b[i+numbits/2]);

3 2

Re: [Boost-users] [filesystem] unable to parse file path
by Nat Goodspeed 06 Nov '06

06 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Küppers, Ben > Sent: Monday, November 06, 2006 2:59 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [filesystem] unable to parse file path > > Ongoing development now warrants that we interact with the Windows > apps from Linux and vice versa. In the midst of all this it becomes > inevitable to run into the occasional Windows file path on Linux (or Linux > path on Windows)(usually through file IO). I use portable paths wherever I > can but I don't have control over all the input. [Nat] I see. But it should work to convert to forward-slashes everywhere. Sorry for being terse earlier. When I said a character-substitution pass is "cheaper" than reimplementing any significant part of boost::filesystem, I was really thinking of coding/maintenance time. > I am disappointed that the library eliminates the code to treat > backslashes as directory separators at compile-time on non-Windows systems > and doesn't provide me with an option to explicitly enable this code for > the few file paths that I know will have a Windows syntax. [Nat] That could be a useful enhancement. If you're interested enough, you might submit a code and documentation patch. Until then, maybe you could introduce a path subclass for your own use that replaces all '\' with '/' before passing the input path string to the base class.

1 0

[mpl::map] generating map for 150 types
by Ovanes Markarian 06 Nov '06

06 Nov '06

Hi! I need to define a map with int_<1...150>->Type1...150 pairs. Im source file I define: #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_MAP_SIZE 150 #include <boost/mpl/map.hpp> When compiling I get an error in the file: ...\boost\include\boost-1_33_1\boost\mpl\map.hpp on line: 36 fatal error C1083: Cannot open include file: 'boost/mpl/map/map150.hpp': No such file or directory Development environment is Visual C++ 8 Express Edition The help states: BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS is an boolean configuration macro regulating library's internal use of preprocessed headers. When defined, it instructs the MPL to discard the pre-generated headers found in boost/mpl/aux_/preprocessed directory and use preprocessor metaprogramming techniques to generate the necessary versions of the library components on the fly. In this implementation of the library, the macro is not defined by default. To change the default configuration, define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS before including any library header. I did what is written here and get this compiler error. Can someone suggest smth? With Kind Regards, Ovanes Markarian

3 6

Re: [Boost-users] [filesystem] unable to parse file path
by Küppers, Ben 06 Nov '06

06 Nov '06

> [Nat] I guess I have a couple of comments. > > One is that a character substitution pass is still cheaper than the > directory parsing and other goodies that boost::filesystem gets you. Speed is not a concern. > The other is to ask why your *nix requirements include backslashes as > directory separators? Backslashes have other significance everywhere but > Windows, which is presumably why boost::filesystem::path wasn't written to > treat '\' and '/' interchangeably on all platforms. Backslashes (and > forward slashes) work on Windows, forward slashes work elsewhere, all per > convention. I work on a large application that runs on Windows and Linux and interacts with various 3rd party applications on either platform, all of them designed with only the dedicated platform in mind and thus using native syntax. Ongoing development now warrants that we interact with the Windows apps from Linux and vice versa. In the midst of all this it becomes inevitable to run into the occasional Windows file path on Linux (or Linux path on Windows)(usually through file IO). I use portable paths wherever I can but I don't have control over all the input. > You seem disappointed that boost::filesystem::path doesn't treat > backslashes as directory separators on non-Windows systems. Not quite, I am disappointed that the library eliminates the code to treat backslashes as directory separators at compile-time on non-Windows systems and doesn't provide me with an option to explicitly enable this code for the few file paths that I know will have a Windows syntax. Note that because Windows supports either directory separator it is possible to parse a Linux relative file path on Windows (with minimal limitations). This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[variant] trouble using recursive_variant with MSVC ...
by Andy Wu 06 Nov '06

06 Nov '06

Hi all, I'm trying to use the recursive variant as following: typedef boost::make_recursive_variant< int, std::vector<boost::recursive_variant_>, std::map<std::string, boost::recursive_variant_> >::type var_t; ... var_t var(34); ... VC 8.0 can not compile with error C2079: 'std::pair<_Ty1,_Ty2>::second' uses undefined struct 'boost::recursive_variant_' Struct recursive_variant_ is declared but not implement at all. But GCC works well. I'm confused how to solve the problem. Here is the whole program: #include "boost/variant.hpp" #include <iostream> #include <sstream> #include <vector> #include <map> struct vector_printer : boost::static_visitor<std::string> { template <typename T> std::string *operator*()(const std::vector<T>& vec) const { std::ostringstream ost; ost << "( "; typename std::vector<T>::const_iterator it = vec.begin(); *for* (; it != vec.end(); ++it) ost << boost::apply_visitor( vector_printer(), *it ); ost << ") "; *return* ost.str(); } template <typename T> std::string *operator*()(const std::map<std::string, T>& m) const { std::ostringstream ost; ost << "( "; typename std::map<std::string, T>::const_iterator it = m.begin(); *for* (; it != m.end(); ++it) ost << it->first << '\t' << boost::apply_visitor( vector_printer(), it->second ); ost << ") "; *return* ost.str(); } template <typename T> std::string *operator*()(const T& operand) const { std::ostringstream ost; ost << operand << ' '; *return* ost.str(); } }; int main(int , char* []) { typedef boost::make_recursive_variant< int, std::vector<boost::recursive_variant_>, std::map<std::string, boost::recursive_variant_> >::type var_t; std::vector<var_t> vec; vec.push_back(3); vec.push_back(5); vec.push_back(vec); vec.push_back(7); var_t var(vec); std::string result( boost::apply_visitor( vector_printer(), var ) ); std::cout << "result: " << result << '\n'; *return* 0; } And the compile error from VC8 is : test_map_variant.cpp D:\Program\boost\boost_1_33_1\boost/type_traits/is_base_and_derived.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/type_traits/is_base_and_derived.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\vs8\VC\INCLUDE\utility(54) : error C2079: 'std::pair<_Ty1,_Ty2>::second' uses undefined struct 'boost::recursive_variant_' with [ _Ty1=const std::string, _Ty2=boost::recursive_variant_ ] D:\Program\vs8\VC\INCLUDE\vector(1083) : see reference to class template instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=const std::string, _Ty2=boost::recursive_variant_ ] D:\Program\vs8\VC\INCLUDE\vector(1082) : while compiling class template member function 'void std::vector<_Ty>::_Destroy(boost::variant<T0_,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18,T19> *,boost::variant<T0_,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18,T19> *)' with [ _Ty=var_t, T0_=boost::detail::variant::recursive_flag<int>, T1=std::vector<boost::recursive_variant_>, T2=std::map<std::string,boost::recursive_variant_>, T3=boost::detail::variant::void_, T4=boost::detail::variant::void_, T5=boost::detail::variant::void_, T6=boost::detail::variant::void_, T7=boost::detail::variant::void_, T8=boost::detail::variant::void_, T9=boost::detail::variant::void_, T10=boost::detail::variant::void_, T11=boost::detail::variant::void_, T12=boost::detail::variant::void_, T13=boost::detail::variant::void_, T14=boost::detail::variant::void_, T15=boost::detail::variant::void_, T16=boost::detail::variant::void_, T17=boost::detail::variant::void_, T18=boost::detail::variant::void_, T19=boost::detail::variant::void_ ] test_map_variant.cpp(63) : see reference to class template instantiation 'std::vector<_Ty>' being compiled with [ _Ty=var_t ] -- B. R. Andy

1 0

[asio] doc directory not present in cvs?
by Andrew Schweitzer 05 Nov '06

05 Nov '06

I assume this is on purpose? Because doc isn't updated to latest changes? Doc is included if I download 0.3.7

2 2

Any interest in a separate Boost.TR1 release/download?
by John Maddock 05 Nov '06

05 Nov '06

I wonder if people would find a separate download for the Boost TR1 components useful ? At present this is vapourware: I'm not sure how easy it will be to sort out documentation and build issues when extracting the TR1 subset, but I'm prepared to put together a preliminary (alpha) release of such a beast if there's demand, and from there we can at least see how viable releasing such a Boost subset would be. Thought? Thanks, John.

4 3

Re: [Boost-users] [mpl::map] generating map for 150 types
by Ovanes Markarian 05 Nov '06

05 Nov '06

Dave, Sorry for my misleading words, the meaning was: As more as I can pre-calculate code at compile time (means slower compilation times) and substitute runtime calculation the more speed I get at runtime. Hope that was what you were meaning in the MPL book. I also understand, that I can bloat compiler with unnecessary calculations without any gain in speed, but my initial sentence was a thank to you an Aleksey for such a nice lib, which can boost the runtime speed if used properly ;) Thanks, Ovanes. -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Saturday, November 04, 2006 7:18 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [mpl::map] generating map for 150 types "Ovanes Markarian" <om_boost(a)keywallet.com> writes: > Aleksey, > > Many thanks for your detailed reply. I think the second scenario with > pre-generated headers convinces me more, since our compilation times > are not optimal at all :(. But as you stated in the book: more work > for compiler means less work at runtime. In this case you won't get any runtime speedups by using the method that's slower at compile time. > These were not exactly the words, but I can remember the meaning. I'm not sure you got the meaning exactly right either ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[Boost.python] Converting python file object to std::istream.
by Dan 04 Nov '06

04 Nov '06

I am exposing a C++ class to python that takes a reference to a std::istream object and operates on it. It looks something like this: class StreamReader { public: StreamReader(std::istream& strm); private: std::istream& strm_; } I would like to expose this class to python allowing a python client to pass in any python file type object (regular file object, StringIO object, stdin, etc.), as a C++ client would be able to pass any std::istream derived object. Now it seems to me that someone must have encountered this problem before, but I haven't seen any references as to how to make this work. Any ideas on the best way to proceed would be appreciated. thanks, Dan

2 1

[mpl::map & mpl::transform] Problems using mpl::map in mpl::for_each
by Ovanes Markarian 04 Nov '06

04 Nov '06

Hello, I have some slightly different code, which is presented in C++ Template Metaprogramming book to use the mpl::for_each function: mpl::for_each< mpl::transform<seq, wrap<_1> >::type >(dispatcher_type()); The deviation from the book is that my seq it not mpl::vector<...>, but mpl::map<...> In the docs is written, that mpl::transform operates on Forward Sequence. In the doc of forward sequence is stated that mpl::map is a model of it. Unfortunately this code does not compile. I could transform the map to vector, but I would not like doing it, since that would cost compile time and slow down the compilation. Is it a known issue or should not I expect map to work with transform? I also tried using itertors on seq, but that did not help. With Kind Regards, Ovanes Markarian

2 6

Re: [Boost-users] Building boost with icl 9
by Sohail Somani 03 Nov '06

03 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock > Actually you can ignore that message as it happens: it's a > compiler message > and the lib's should still build OK. It was inserted in > because we hadn't > tested the last release with Intel 9 (it didn't exist then), > however there > are no configuration changes required compared to previous > Intel versions, > so you can just ignor the message if you want. If it's > annoying, then > comment out the line in boost/config/compiler/intel.hpp that > generates it. Ok, I did ignore it and it seemed to work fine. Thanks.

1 0