- Boost-users - lists.boost.org

invalid itialization of reference of type boost::thread&& from expression of thread 'boost::thread'
by Carla Strembicke 30 Sep '10

30 Sep '10

Hello I am having a problem compiling with boost thread. I have installed gcc 4.5.1 on my linux platform recently. I am using boost libraries 1.42. I do understand that this library has not been tested with this compiler. My question is, I see that 1.44 version of boost has been tested with gcc 4.5.1 on redhat. Is this issue, that I provide a link to, resolved in 1.44 or will I still see the same problem? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915 regards carla CONFIDENTIAL INFORMATION NOTICE: The information contained in this e-mail is privileged, confidential and intended solely for the use of the addressee named above. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you received this in error, please contact the sender and destroy all copies of this e-mail. Thank you.

2 1

Making boost::any play nice in function overloads
by dakatz＠akamai.com 30 Sep '10

30 Sep '10

Hi - I've got a method which should take a variety of types and with the exception of taking a function pointer it shouldn't care about which types it's getting, so I thought that a boost::any would be a nice way to achieve this. Here's a simplified prototype: ------------------------------------------------------------------------ class Table { public: // Base case void doSomething(const boost::any& input); // Special overload for function pointers for some special reason. // // Has logic to interpret NULL pointer as integer 0 and pass to // "base" boost::any case. void doSomething(void (*f)(void)); }; ------------------------------------------------------------------------ When I tried to call doSomething with a string literal argument (i.e. table.doSomething("Hello")), it of course failed since boost:any can't be initialized with an array. Okay - no problem. Another overload should do the trick, right? So I added an overload like this: ------------------------------------------------------------------------ class Table { public: void doSomething(const boost::any& input); // Supposed to take a const char*, convert it to a string, and // pass off to boost::any case. void doSomething(const std::string& input); void doSomething(void (*f)(void)); }; ------------------------------------------------------------------------ on the theory that a const char* would convert to a std::string. I couldn't add an overload for const char* directly since that would conflict with the overload for the function pointer (i.e. table.doSomething(0) would be ambiguous between the function pointer and the const char*). Unfortunately, this didn't work. When I called this with "Hello.": ------------------------------------------------------------------------ $ g++ -W -Wall -Werror -ansi any_overload_problem.cpp any_overload_problem.cpp: In function 'int main()': any_overload_problem.cpp:32: error: call of overloaded 'doSomething(const char [7])' is ambiguous any_overload_problem.cpp:8: note: candidates are: void Table::doSomething(const boost::any&) any_overload_problem.cpp:19: note: void Table::doSomething(const std::string&) ------------------------------------------------------------------------ I admit that I didn't foresee this, although I suppose I should have. Even though a boost:any can't be initialized with a const char*, that signature is still participating in the overload resolution. So does anyone have any suggestions for how to deal with this sort of thing? Is there a good way to get the boost::any conversions to match "less well" than something like the std::string conversion? Or am I just way off-base in trying to use boost::any here at all? Thanks! Dan Katz

2 2

[asio] promiscuous mode?
by Ryan McConnehey 30 Sep '10

30 Sep '10

If winpcap or some such library is installed on a machine is it possible to have asio read from the Ethernet card in promiscuous mode? Ryan

3 3

[iostreams] tellg not supported on devices / filters that aren't seekable
by Sebastian Karlsson 30 Sep '10

30 Sep '10

I find it inconvenient that tellg isn't supported on filters / devices that isn't seekable, since tellg doesn't really seek but simply reports the current read head position. Here follows some example code that will throw due to this: #include <ostream> #include "boost/iostreams/categories.hpp" #include "boost/iostreams/filtering_stream.hpp" #include "boost/iostreams/filter/zlib.hpp" int main() { boost::iostreams::filtering_stream< boost::iostreams::input > strm( ( boost::iostreams::zlib_decompressor() ) ); char sourceArr[512]; strm.push( boost::iostreams::array_source( sourceArr, sourceArr + sizeof( sourceArr ) ) ); strm.tellg(); } The problem is that, at least on windows, and I assume other platforms due to the somewhat lackluster interface of stream_buf, is implemented in terms of pubseekoff( 0, ios_base::cur, ios_base::in ). This call doesn't really alter the read head and should in this instance be supported, but isn't.

1 0

Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file
by Chris Yuen 30 Sep '10

30 Sep '10

Robert Ramey wrote: > These functions are not explicity called from the library. > But they ARE called as part of the serialization process. Its > just that MSVC doesn't see them. So when you compile > for release, The MSVC Linker strips them out and the > program won't work anymore. In order to work around > this, these functions are explicitly exported. This prevents > MSVC from stripping them out. For more information > see force_include.hpp Thanks for the pointer! I'm trying to circumvent the issue by replacing force_include.hpp with 2 lines: #define BOOST_DLLEXPORT #define BOOST_USED I'm not examining or not whether the resultant program will crash or not, yet. But still, even with force_include.hpp (supposedly) out of the way, I still see the swamp of exported symbols. How can I experiment with disabling this DLL export thingie? Do I need to recompile boost::serialization for this change? I assumed not since the exported symbols are template instantiations which should only have happened when the client code compiled. Is there any other ways around this? These exported symbols add a hideously huge amount of overhead to the final exe. I did the dumpbin and the output (which only contains the plain text names of the exported symbols) is 6MB! Best regards, Chris Yuen

2 1

Re: [Boost-users] boost serialize - stack overflow for largeproblems
by "Jörg F. Unger" 30 Sep '10

30 Sep '10

>> Consider a triangulated surface, made up of nodes. Each node has an >> ordered list of its neighbors (nodes) that implicitly defines all the >> triangles having the node as an apex. >> >> The surface "owns" the nodes (in a vector let's say). The neighboring >> nodes of a node are not owned OTOH, yet the connectivity info (the >> topology) they represent must still be persisted for each node. And >> that info happens to be a vector of pointers of other nodes of the >> same surface. >> >> When you serialize the surface, you must serialize all its nodes, and >> all those nodes' topology too. >> If you do it depth first, you end up blowing up the stack indeed. >> >> I see two possible solutions: >> >> 1) save all the nodes *without* their topology info on a first pass of >> the vector, thus recording all the "tracked" pointers for them, then >> write the topology info for each, since then you don't "recurse", you >> only write a "ref" to an already serialized pointer. > That's my suggestion. > This has the problem that I totally change the existing serialization routines. Since I have to go twice through my structure (in the first pass serializing the nodes and in the second pass their topology information) I would need two serialize routines. Since the library supports only a single method for each class (the serialize method), I'd have to implement at least parts of the serialization library myself. >> 2) have the possibility to write a "weak reference" to a pointer, >> which only adds the pointer to the "tracking" map with a special flag >> saying it wasn't "really" written yet, such that writing the topology >> of a node that wasn't yet written is akin to "forward references" to >> those neighboring nodes. Either the node will really be written later >> on, or it never will, and I suppose serialization should handle that >> gracefully. > I'd have to think about this. > This idea seems to be very appealing and if there is a possibility to implement that into the serialization library that would be great.

2 1

Program Options - positional arguments?
by John Dlugosz 29 Sep '10

29 Sep '10

I see in the documentation the class positional_options_description is used to list names for positional options. But nowhere in the documentation does it say how to pass this to the parser! Given the code based on the documentation samples, po::store(po::parse_command_line(argc,argv,opt),vm); po::notify(vm); and po::positional_options_description pd; pd.add("output-file", 2).add("input-file", -1); where do I tell parse_command_line about pd? = TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

2 1

Re: [Boost-users] [serialization] can I serialize concrete types that are not acessible where the archive is created
by Massaro Alessio 29 Sep '10

29 Sep '10

ADDENDUM (NB I'm using release boost 1.44 with Visual C++ 2008 SP1 with the latest patches) test_dll_plugin in the serialization test suite seems to suffer from the same problem I'm having I've created two standard empty win32 console projects in Visual Studio: * one to build a DLL with polymorphic_base.cpp and polymorphic_derived2.cpp * one to build an EXE client for the above DLL containing only test_dll_plugin.cpp The assert at line 82 of test_dll_plugin.cpp fails at runtime, showing the EXE does not have registered ETI for the polymorphic_derived2 type linked into the DLL. What could be the problem here? -----Original Message----- From: Massaro Alessio Sent: 29 September 2010 18:06 To: boost-users(a)lists.boost.org Subject: RE: [Boost-users] [serialization] can I serialize concrete types that are not acessible where the archive is created Thanks for the pointer Robert I trawled up the following 2 items of doc, but made little process http://www.boost.org/doc/libs/1_44_0/libs/serialization/doc/special.html#dl… http://www.boost.org/doc/libs/1_44_0/libs/serialization/doc/special.html#pl… If I follow the documentation I get a "derived class not registered..." at runtime. So I looked at the unit tests. The one for my case seems to be test_dll_plugin.cpp. In that test polymorphic_base (the interface type known statically at the poiont of serialization) uses the extended_type_info_no_rtti ETI scheme. This is in contrast to polymorphic_derived2 (the concrete type UNknown statically at the poiont of serialization) using the extended_type_info_typeid ETI scheme. Do I *have to* use no_rtti for my abstract interface types? If I use the typeid scheme everything builds but I get "derived class not registered..." at runtime. If I follow the test_dll_plugin.cpp pattern, then the code STATIC_ASSERTS extended_type_info_no_rtti.hpp(87) at the point of serialization. The STATIC_ASSERT comment says // if your program traps here - you failed to // export a guid for this type. the no_rtti // system requires export for types serialized // as pointers. Adding BOOST_CLASS_EXPORT_KEY(boost::shared_ptr<I_DoSomething>) or BOOST_CLASS_EXPORT_GUID(boost::shared_ptr<I_DoSomething>, "xyz") to serialize.cpp will make no difference. I really can't figure out what's wrong. I hope someone out there can spot the problem! ##################### DLL/MODULE 1 ##################################### -------------------------------------------- interface.hpp #include <boost/shared_ptr.hpp> struct DLL_EXPORT I_DoSomething { virtual const char * get_key() const = 0; virtual void doIt() = 0; static boost::shared_ptr<I_DoSomething> create(); // static factory private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & /* ar */, const unsigned int /* file_version */); } #include <boost/serialization/assume_abstract.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/type_info_implementation.hpp> #include <boost/serialization/extended_type_info_no_rtti.hpp> BOOST_SERIALIZATION_ASSUME_ABSTRACT(I_DoSomething) BOOST_CLASS_EXPORT_KEY(I_DoSomething) BOOST_CLASS_TYPE_INFO(I_DoSomething, boost::serialization::extended_type_info_no_rtti<I_DoSomething>) -------------------------------------------- ConcreteType.cpp #include "interface.hpp" class ConcreteType : public I_DoSomething { virtual const char * get_key() const { return "ConcreteType"; } ... ..... private: void serialize(Archive & ar, const unsigned int /*version*/) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(I_DoSomething); ar & ... } } boost::shared_ptr<I_DoSomething> I_DoSomething::create() { return new ConcreteType(); } #include <boost/serialization/export.hpp> #include <boost/serialization/extended_type_info_typeid.hpp> BOOST_CLASS_EXPORT_KEY(ConcreteType) BOOST_CLASS_TYPE_INFO(ConcreteType, boost::serialization::extended_type_info_typeid<ConcreteType>) BOOST_CLASS_EXPORT_IMPLEMENT(ConcreteType) #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> template DLLEXPORT void ConcreteType::serialize(boost::archive::xml_oarchive & ar, const unsigned int version); template DLLEXPORT void ConcreteType::serialize(boost::archive::xml_iarchive & ar, const unsigned int version); #include <boost/serialization/factory.hpp> BOOST_SERIALIZATION_FACTORY_0(ConcreteType) ##################### DLL 2 which linked with DLL 1 ##################### -------------------------------------------- serialize.cpp #include "interface.hpp" #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/shared_ptr.hpp> BOOST_CLASS_EXPORT_KEY(boost::shared_ptr<I_DoSomething>) ... boost::shared_ptr<I_DoSomething> obj = I_DoSomething::create(); boost::text_oarchive oa; oa << obj; // <-------- STATIC_ASSERTS at extended_type_info_no_rtti.hpp(87) ...

1 0

[serialization] can I serialize concrete types that are not acessible where the archive is created
by Massaro Alessio 29 Sep '10

29 Sep '10

Hi there! Does boost::serialization work with interfaces and static factory methods? (shown below) Note how the Concrete type is not actually known at the point where the archive is instantiated, and the two are actually in two different modules. In fact, I have indeed tried the following line in ConcreteType.cpp but the registration is not seen by the text_oarchive in DLL 2 BOOST_CLASS_EXPORT_GUID(ConcreteType, "ConcreteType") Perhaps using a singleton archive on which I register every type (from Multiple DLLs) and that I use to serialize every object? But how would I provide access to register_type on such a singleton? And how would I use it on different stream instances? (a clone?) I m trawling through the boost::serialization code, and cannot find a way to make it work. Thanks in advance for any pointers/help! ##################### DLL/MODULE 1 ##################################### ### interface.hpp struct DLL_EXPORT I_DoSomething { void doIt() = 0; static I_DoSomething* create(); // static factory } ### ConcreteType.cpp #include "interface.hpp" class ConcreteType : public I_DoSomething { ... } I_DoSomething* create() { return new ConcreteType(); } ##################### DLL 2 which linked with DLL 1 ##################### ### serialize.cpp #include "interface.hpp" #include <boost/archive/text_oarchive.hpp> ... I_DoSomething* obj = I_DoSomething::create(); boost::text_oarchive oa; oa << obj; ...

2 2

SUN CC 5.2 support in Boost 1.43?
by Max S. Kaznady 29 Sep '10

29 Sep '10

Hi, I wrote a C++ project using OpenMP, GCC and Boost. When I enable nested parallelism (omp_set_nested(1)), repeated runs of the same piece of code produce different results, which suggests that there is a race condition somewhere, but I do not see anything wrong with the logic of my code, so I decided to use Sun Studio's Thread Analyzer to analyze my code. This requires me to build my project with Sun's CC 5.2, which fails with the following warning message from Boost: "/h/96/g4max/local/boost64/include/boost/numeric/ublas/detail/config.hpp", line 170: Error: #error Your compiler and/or configuration is unsupported by this verions of uBLAS. Define BOOST_UBLAS_UNSUPPORTED_COMPILER=0 to override this message. Boost 1.32.0 includes uBLAS with support for many older compilers.. Is it even possible to compile Boost 1.43 with Sun's CC? I tried setting user-config.jam and then build with: ./bootstrap.sh --prefix=/install_dir ./bjam --user-config=user-config.jam -j16 toolset=sun ./bjam install where user-config.jam is: using sun : 5.2 : /my_sun_location/CC : -library=stlport4 -features=tmplife -features=tmplrefstatic ; I get a lot of warnings and error messages... So, my questions are: 1) What is the best way to check parallel code for race conditions using some free tool? 2) If one such free tool is Sun Studio, then how can I get Boost working with it? 3) If someone here knows OpenMP, could it be that omp_set_nested() produces a race condition within a Boost library? My codes run fine with omp_set_dynamic(1), but as soon as I enable nesting I get race conditions. Thanks! Max

3 5