February 2009 - Boost-users - lists.preview.boost.org

Hi
by Can T. Oguz 10 Feb '09

10 Feb '09

Hi, New to boost, glad to get here. Any book recommendations? Can

11 20

[phoenix] compile error using arg1
by Paul Heil 10 Feb '09

10 Feb '09

While expanding my horizons to include functional programming, I've run in to a problem with boost::phoneix lambda functions. I'm trying to use a for_each() command with an overloaded<< operator, but I can't seem to get they types right, and I get a compile error: test.cpp(147) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const boost::phoenix::actor<Eval>' (or there is no acceptable conversion) I've seen example code that's very similiar to this using "cout" instead of the overloaded << operator I have, so I tend to think this is possible. My code is below, can anybody suggest what I could do to fix this? using namespace boost::phoenix; using namespace boost::phoenix::arg_names; class A { public: friend MSXML2::IXMLDOMNode* operator <<( MSXML2::IXMLDOMNode* node, const A& a ); private: // ... }; MSXML2::IXMLDOMNode* operator <<( MSXML2::IXMLDOMNode* node, const A& a ) { // Add stuff from A to 'node' return node; } int main() { MSXML2::IXMLDOMElementPtr pElem; // MSXML2 DOM doc creation removed for brevity std::list< A > theList; // add items to the list... // copy items from the list to the XML element // This does not compile (C2679) std::for_each( theList.begin(), theList.end(), pElem << arg1 ); return 0; } I realize I could write a proxy function like: void A::Print( MSXML2::IXMLDOMNode* t ) const { t << *this; }; and use the bind() within the for_each() std::for_each( theList.begin(), theList.end(), bind( &A::Print, arg1, pElem ) ); but, I'd like to avoid that if possible. If anybody can suggest how to get this done, I would appreciate it. Thanks, PaulH

2 2

[serialization] removing excess XML tags
by Paul Heil 10 Feb '09

10 Feb '09

I'd like to use the boost::serialization library to generate XML that must be read by a third party application. Unfortunately, this application does not like the extra stuff that the serialization library generates. The code below generates XML that looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <MYTAG class_id="0" tracking_level="0" version="0"></MYTAG> </boost_serialization> What I need is XML that looks more like this: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <MYTAG></MYTAG> What can I do to eliminate the extra stuff? Thanks, PaulH class MyClass { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version){}; public: MyClass(){}; friend std::ostream & operator<<(std::ostream &os, const MyClass &gp); virtual ~MyClass(){}; }; int main( int argc, _TCHAR* argv[] ) { MyClass mc; std::ofstream ofs("MyFile.xml"); boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp( "MYTAG", mc ); return 0; }

7 9

[thread] C++/CLI C# mixed code: linking to libthread yields runtime exception
by Markus Werle 10 Feb '09

10 Feb '09

Hi! I am pretty sure this is an issue beyond boost, rather one of those numerous pitfalls on the way to the M$-promised land called CanUseOldCodeAndCppInDotNet. OTOH I have hope that someone knows about some workaround, OK, here the facts: Win32, XP SP3, using Visual Studio 2008 SP1 with boost_1_37_0 I create a solution containing a C++/CLI project and a C# project, which references the C++/CLI project. Now if the C++/CLI project simply links to libboost_thread*, either via autolink or via explicit configuration, the compiler creates an executable which fails to start in both configurations, Debug and Release. The debugger catches a System.BadImageFormatException. Something went plain wrong. OTOH adding the source files contained in \libs\thread\src\win32 to the project, defining BOOST_ALL_NO_LIB and adding --- #pragma managed(push, off) extern "C" void tss_cleanup_implemented(void) {} #include <boost/thread/thread.hpp> #pragma managed(pop) --- in a cpp file yields a working executable. Scratching my head. Do you have any hint why linking to libboost_thread leads to this weird behaviour? Any idea what I might try? I can provide a stripped down project solution as zip-file on request. regards, Markus [keywords C# C++/CLI CSharp mixed thread boost System.BadImageFormatException]

3 11

[solved] Using Boost in C++/CLI and C# mixed code environment
by Markus Werle 10 Feb '09

10 Feb '09

Hi! With the help of Anthony Williams and Hansi plus a step by step fiddling with the Visual Studio settings I finally managed (sic!) to get C++ and Boost playing nicely in a mixed C++/CLI plus C# code setting. Phew. Went to hell and came back again. Disclaimer: This document was written in order to be useful and published in the hope that it is helpful to others. There is no guarantee that this information really helps in all similar settings. Maybe things are still broken deep inside, but my little demo application at least does not choke on startup or finalization anymore. If you have additional insight, please share this information. Contact me by mail and/or followup to this post. So here is a summary of what I found out: I create a solution containing a C++/CLI project and a C# (Google: CSharp) project, which references the C++/CLI project. The C++/CLI project is a DLL-project which uses the Boost libaries. Without any further settings, the autolink features of Boost are configured such that the Boost libraries are statically linked to the C++ DLL (which IMHO normally is fine and exactly what I want: no extra libraries to ship with my software). Note that some libaries may be used implicitly: Spirit for example includes Boost.Threads when BOOST_SPIRIT_THREADSAFE is defined. Alas, the default compiler settings may lead to trouble: Statically linking to Boost libraries may yield an executable which chokes on startup with a System.BadImageFormatException, even if the compiler and linker run without warning (a bug, IMHO). Explanantion: <cite author="Anthony Williams" date="2009-02-04 15:54:40 GMT"> The problem is that the static boost thread library tries to hook the native win32 PE TLS callbacks in order to ensure that the thread-local data used by boost thread is cleaned up correctly. This is not compatible with a C++/CLI executable. </cite> Solution: In Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions add BOOST_ALL_DYN_LINK in order to force the usage of the DLLs. In addition copy the necessary DLLs to the directory where the executable resides. E.g. copy boost_thread-vc90-mt-gd-1_XX.dll to MyApp/bin/Debug. It also helps to #define BOOST_LIB_DIAGNOSTIC in the Preprocessor Definitions to find out from the compiler output which libraries are to be included. The .NET framework throws a System.IO.FileNotFoundException on missing libraries without further information about which files are missing (The classical Mirosoft way to handle these things since Windows 98: "An error has occurred.") Setting these compiler flags should yield an application that does not fail on startup. Enters the next bug of Visual Studio: The C++/CLI compiler deliberately chooses to ignore the #pragma managed(push, off) / #pragma managed(pop) PREPRO directives for files which are compiled with /clr command line flag. You obtain a plethora of warnings of the form warning C4793: 'boost::[..]::`vcall'{0}'' : function compiled as native : For the executable this means that on termination another exception is thrown, which adds to the confusion: Unhandled exception at 0x7c812a7b in XXX.exe: 0xC0020001: "Die Zeichenfolgenbindung ist unzulässig." or in english: Error 1700 "The string binding is invalid" or RPC_S_INVALID_STRING_BINDING. Solution: Put managed (CLI) and unmanaged C++ code into different compilation units. For unmanaged code files change the compiler settings this way: In "Configuration Properties -> C/C++ -> General -> Compiler with Common Language" support choose "No Common Language Support". Now things should work fine. best regards, Markus

1 0

Re: [Boost-users] boost and std collisons in c++0x
by Daniel Lidström 10 Feb '09

10 Feb '09

_____ From: Sergey Sadovnikov [mailto:flex_ferrum@artberg.ru] Sent: Thursday, February 05, 2009 10:02 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] boost and std collisons in c++0x MF> If you want to use boost, use boost::. If you want to use the STD MF> library, use std::. Perfectly! What you can say about following pieces of code: std::vector<std::shared_ptr<SomeClass>> vec; std::for_each(vec.begin(), vec.end(), std::bind(&std::shared_ptr<SomeClass>::get, std::placeholders::_1, std::bind(&SomeClass::foo, std::placeholders::_1, 10))); and vector<shared_ptr<SomeClass>> vec; for_each(vec.begin(), vec.end(), bind(&shared_ptr<SomeClass>::get, _1, bind(&SomeClass::foo, _1, 10))); Here's what I do, for every class that's put in shared_ptr's (I'm very disciplined in this way): // SomeClassFwd.h: class SomeClass; typedef std::shared_ptr<SomeClass> SomeClassPtr; typedef std::vector<SomeClassPtr> SomeClassCollection; Now, your code becomes: SomeClassCollection vec; std::for_each(vec.begin(), vec.end(), std::bind(&SomeClassPtr::get, std::placeholders::_1, std::bind(&SomeClass::foo, std::placeholders::_1, 10))); I would agree C++ can be very verbose. Using typedef can limit this a lot though. /Daniel Lidström

1 0

Is bimap swappable?
by Adam Badura 10 Feb '09

10 Feb '09

The documentation for Boost.Bimap does not mention that bimap is swappable (but it does not warn explicitly that it is not - which it should IMHO if it is not). When compiling the code (under VC 2008, Boost 1.38) a.swap(b) compiles for a and b being bimap of the same type. How is it then? Adam Badura

1 0

[proto] problem with templated recursive transform
by Daniel Oberhoff 10 Feb '09

10 Feb '09

Hi, I have gotten my hands pretty dirty with my array expression DSEL, and hove gotten surprisingly far (surprisingly considering the amounts of black template magic involved :) ). Now I am stuck with a templated recursive transform, that I cant seem to get right. Here is a stripped down version: template<typename T, typename IndexSet> struct ExpressionIteratorBuilder : proto::or_< proto::when< cpudata_indexing_grammar< proto::_ > , TerminalIteratorBuilder<T, IndexSet>( proto::_ ) > ,proto::when< proto::unary_plus< cpudata_grammar > , ExpressionIteratorBuilder<T, IndexSet>( proto::_left ) > > {}; so what does work is when I have the first case (i.e. the expression is just an indexed array terminal), but the second case, where it recurses breaks on instantiation. I have tried all the tricks from the proto docs, i.e. adding a dummy callable template parameter, specializing boost::proto:::is_callable, and wrapping the recursion in proto::call, always the same long error. It also works when ExpressionIteratorBuilder is not a template, though that would not make it very useful. Any ideas? Otherwise I am beginning to love proto, and am looking forward to c++0x when the error messages might become readable through concepts :). Best Daniel -- --- Daniel Oberhoff Fraunhofer FIT Schloss Birlinghoven 53754 Sankt Augustin, Germany Tel.: +49-(0)-2241-14-3486 Fax.:+49 (0) 2241/14-2080

4 9

Boost 1.38.0 released
by Beman Dawes 10 Feb '09

10 Feb '09

Boost 1.38.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes three new libraries: Flyweight, ScopeExit, and Swap. Updated Libraries: Accumulators, Any, Asio, Config, Date_Time, Exception, Filesystem, Graph, Hash, Interprocess, Intrusive, Lexical Cast, Math, Multi-index Containers, Proto, Regex, Thread, TR1, Type Traits, Unordered, and Xpressive. Other Changes: Experimental CMake build system. You can read the full release announcement here: http://www.boost.org/users/news/version_1_38_0 The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. --Beman Dawes

1 0

Data_Time - Exception: could not convert calendar time to UTC time
by Bruno Dutra 09 Feb '09

09 Feb '09

Hello folks, Today I downloaded the new version of Boost, 1.38, and tried to compile and run the Source listing for Timer.5<http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/tutorial/tuttimer5…>example from Asio, but it was throwing the exception: "could not convert calendar time to UTC time" (Note that i'm building it under windows vista using MinGW GCC, which I believe is not on the "tested compilers list of boost 1.38") After some time traking the culprit, I got to the function time_type microsec_clock::create_time(time_converter converter) from the boost\date_time\microsec_time_clock.hpp header in which the variable 'std::time_t t' was strangely assuming a negative value, probably due to an overflow. Then I realized that changing the type of the variable 'micros' from uint64_t to std::time_t on that same function, could solve the problem. I just want to know if that's a known issue and if applying that small fix other issues may appear. Thanks in advance Bruno

1 0