- Boost-users - lists.boost.org

Errors compiling Boost.Python library on Solaris
by chris botos 15 Nov '06

15 Nov '06

Hi, I'm new to this list and to Boost. I'm interested in using Boost to wrap C++ objects in Python. The environment is Solaris 10, x86. I did the following: Downloaded boost_1_33_1.tar and extracted it to /opt/boost. >setenv PYTHON_ROOT /usr/local > cd to /opt/boost/boost_1_33_1/libs/python/build > bjam I get lots of error messages, repeated throughout the compile and tend to be grouped and refer to the same line: '->' cannot appear in a constant-expression '&' cannot appear in a constant-expression template argument 1 is invalid value is not a member of '<declaration errors>' ...failed gcc-C++-action ... is also associated with the above If I "bjam" from /opt/boost/boost_1_33_1, I get the same errors when it gets to the python library. I would most appreciate any help with this! Regards, Chris Botos

3 5

comparing map's key and sorted vector
by Maitre Bart 15 Nov '06

15 Nov '06

Suppose I have a map (m) and a sorted vector of strings (v). The map's key is a string, and the map's value is foobar. I wish to compare map's keys with the vector's values and detect if they all match: (*mit).first == *vit and wish to do it with STL/Boost algo and functors. So I am starting with this: equal(m.begin(), m.end(), v.begin(), boost::bind(std::equa_to<string>(), std::select1st<std::pair<string,foobar> >(_1), _2)); I know 2 parameters are past to bind: *mit and *vit . However, before the equality, I want to extract the key from the map iterator (i.e. (*mit).first) before the comparison. That is this part I have difficulty to concretise. Btw, is there any equivalent to select1st (SGI extension) in Boost? Does anyone have any idea? I must be close to the solution...

2 1

[OT] Strange Subject Line Problem with this Mailing List
by Wu Yinghui, Freddie 14 Nov '06

14 Nov '06

Hi all, Sorry for this post, as it is not related to Boost, but to this mailing list instead. I've been seeing subject lines in a mess for "Re:" posts as illustrated below: ==== snip ==== > Today's Topics: > > 1. BGL: Bundled Properties in subgraphs (Greg Reynolds) > 2. Re: [Serialization] a couplacrashesfromhiearchycomplexity > (Reusser, Edward) ==== snip ==== As seen above, the subject line of the second post was unreadable to me without spending a fair amount of efforts. Has anyone checked out what was the cause of this problem yet? Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

2 1

[serialization] Richer "tagged" fields and polymorphic archive types
by Caleb Epstein 14 Nov '06

14 Nov '06

Robert, First let me start off by thanking you for the excellent Boost Serialization library. I'm planning to use it as part of a new system I'm building at my place of work as a more flexible replacement for Rogue Wave's "saveGuts/restoreGuts". I've been able to implement my own archive types without too much of a struggle, and have been overall very impressed with the functionality of the library and its documentation. Now some background and then on to the questions :) I'm not sure if you are familiar with TIBCO's "Rendezvous" messaging middleware product (http://tibco.com/) or with the FIX protocol (http://fixprotocol.org/) but these are both commonly used in financial services applications. Rendezvous as a messaging transport and FIX as a general message convention and data dictionary. FIX also specifies a "session" layer used for communication, but thats out of scope here. Both Rendezvous (RV) and FIX support the concept of numeric field identifiers in their messages. In FIX, serialized messages look like TAG=VALUE\x01TAG=VALUE\x01... where TAG is an integer field ID and VALUE is the value associated with that tag and \x01 is an ASCII SOH character. In RV messages, fields may be given a name and/or an integer field ID. So it is pretty straightforward to represent a FIX message as an RV message (or vice-versa) if you always use these numeric IDs. Also, these "tagged" message formats facilitate interchange of data between different systems because they do not place stringent requirements on field ordering or even field presence in some cases. In the system I'm working on, the fundamental object types can all be mapped more or less directly to messages in the FIX specification. OK, so now onto the meat of the question. What I'd like to use in this application is something akin to NVP serialization for my objects, but which I'll call FIELD serialization. Every member of an object can be associated with a FIELD ID which would contain both a name and an integer ID (e.g. "Price" and 44). The universe of field IDs is more or less static and well-known. To this end I've created two utility classes called field_id and field. The field_id class is a std::pair<int, const char*> and the template field class is a std::pair<const field_id*, T*> not unlike the nvp class. It provides methods to get the field's name, id, and value. There is also a template utility function "make_field(const field_id&, T&)" that creates a field object in the same way "make_nvp" creates an nvp. I have implemented a "tibco_oarchive" that provides a template "save_override(const field<T>&, int)" method, and this works fine if I am using template<typename Archive> serialization methods with my archive definition in scope, and if I write my serialization code using "make_field" instead of "make_nvp". But this, naturally, does *not* work if I try to use polymorphic archives, since the base classes here do not know anything about my "field" template, only "nvp". Additionally, my template-based serialization code will fail to compile with archive types that don't provide "save_override"s for my "field" template, which is all of the "standard" archive classes. What I'd like is to figure out some way to implement this tagged-field serialization scheme in a way that would be compatible with the polymorphic archive interface and that would (ideally) still compile with the existing archive implementations that don't know about my "field" class. This latter requirement is less important. The reason I'm leaning toward the polymorphic archive interface is that I'm sure we will need to adopt new wire-formats and middleware interfaces in the future. Keeping all the object serialization code in a library that doesn't require recompilation will make this process very easy. So, do you think you could offer any suggestions on how I might go about achieving this? Let me know if you need more information or clarification, and thanks for your help. -- Caleb Epstein

2 1

Sequence of Types, What For?
by Terry G 14 Nov '06

14 Nov '06

I've just finished reading C++ Template Metaprogramming again. I just don't get it. Why would someone use a type container? I have used enable_if, along with some of the logic functions for managing an overload set. Otherwise, I'm clueless. I'd really like a reference to an MPL primer or some case studies. Too much pain with very little gain. Time to ask for help. Rereading this, it sounds negative. Really, I think the MPL is really cool! terry

13 30

Re: [Boost-users] Serialization problem on 64-bit Windows release
by Sergey Filippov 14 Nov '06

14 Nov '06

Robert Ramey <ramey <at> rrsd.com> writes: > This doesn't seem to be the case in your situation. Anyway, thank you for the information. I'll keep trying to reproduce an issue in test lab. Sergey

2 2

Minor ublas issue
by Daniel Krügler 14 Nov '06

14 Nov '06

Hello, I stumbled about the current cvs HEAD version of exception.hpp, where I found one remaining throw under *_NO_EXCEPTIONS conditions in "singular". Here the proposed fix: Index: exception.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/ublas/exception.hpp,v retrieving revision 1.19 diff -u -r1.19 exception.hpp --- exception.hpp 2 Feb 2006 19:27:23 -0000 1.19 +++ exception.hpp 13 Nov 2006 18:54:27 -0000 @@ -175,7 +175,6 @@ explicit singular (const char *) {} void raise () { - throw *this; std::abort (); } #endif I also would like to recommend, that the current exception text of struct non_real should be changed as follows (The prefix "exception:" seems redundant): Index: exception.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/ublas/exception.hpp,v retrieving revision 1.19 diff -u -r1.19 exception.hpp --- exception.hpp 2 Feb 2006 19:27:23 -0000 1.19 +++ exception.hpp 13 Nov 2006 19:01:45 -0000 @@ -185,7 +185,7 @@ #if ! defined (BOOST_NO_EXCEPTIONS) && ! defined (BOOST_UBLAS_NO_EXCEPTIONS) // Inherit from standard exceptions as requested during review. : public std::domain_error { - explicit non_real (const char *s = "exception: non real") : + explicit non_real (const char *s = "non real") : std::domain_error (s) {} void raise () { throw *this; Greetings from Bremen, Daniel Krügler

1 0

BJam can't find arguments to gcc-spawn
by Charles Broderick 14 Nov '06

14 Nov '06

I am having problems running even a basic Jamfile consisting only of: Main : main.c ; When running bjam with debugging on, I receive this output (truncated). I looked at allyourbase.jam and gcc-tools.jam, and it looks like OK jam code to me... why won't main.c get passed in as the target? /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1136:>>>>|>>>>|>> switch .c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1139:>>>>|>>>>|>> Cc : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:624:>>>>|>>>>|>>>> DEPENDS : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:626:>>>>|>>>>|>>>> Cc-platform-specifics : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:593:>>>>|>>>>|>>>>|> local _h = /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:634:>>>>|>>>>|>>>> Cc-action : main.c /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:489:>>>>|>>>>|>>>>|> gcc-spawn /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:489: in Cc-action *** argument error * rule gcc-spawn ( targets + ) * called with: ( ) * missing argument targets /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:402:see definition of rule 'gcc-spawn' being called /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:634: in Cc /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1139: in Object /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1207: in Objects /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:969: in Main Jamfile:2: in load-jamfiles /local/apps/boost/1.33.1/tools/build/v1/bootstrap.jam:21: in boost-build /local/apps/boost/1.33.1//boost-build.jam:16: in module scope

2 1

Re: [Boost-users] [Serialization] a couplacrashesfromhiearchycomplexity
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, After more analysis, I am getting evidence that this error might be on my end (something seems to corrupt the XML text itself). More to follow... Ed ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 2:22 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a couplacrashesfromhiearchycomplexity it would seem to me that a stack trace would be interesting to see. I'm wondering if its just a stack that is too short (I would have expected to see this sooner if it was) or some error somewhere which creates an unterminated recurssion. With VC its easy to see the stack trace. With the Gnu Debuger, one has to back trace from the right point. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA233@SV-MSG-01.amer.actel.com.. . Robert, I would need permission to send you the exact library code. I am reluctant to do this primarily because recreating my exact build environment would be a hassle (we are using gnumake on the PC). I also would need to do this directly to you, as I could not post this code into a public forum. Having said that, any recursive descent parser has complexity limits based on stack size. It would be pretty easy to create test cases that probe these complexity limits for the various archive types. I would like to see how much (approximately) stack space is allocated in the runtime for each level of xml hierarchy, and also for the text archives. The main complexity seems to be because I am using shared_ptr's extensively at all levels of the hierarchy. Thus, I have 2 levels nested for each class, the <px> data </px> and the actual data, which is in turn being represented by a collection of shared_ptr's, etc. I am also using std::map of shared pointers, and std::set of shared_ptr's. I also use enable_shared_from_this<T> for my base classes, then statically cast the resultant shared pointers internally for the derived classes. This is to get around a Linux problem which I can describe more fully if you like (would take a few pages of explanation). So for example: class Base : public boost:enable_shared_from_this<Base> { virtual boost::shared_ptr<Base> GetSharedFromThis() { return shared_from_this(); } }; class Derived1 : public Base { public: virtual boost::shared_ptr<Derived1> GetSharedFromThis() { return static_pointer_cast<Derived1>( shared_from_this() ); } }; class Derived2 : public Base { public: virtual boost::shared_ptr<Derived2> GetSharedFromThis() { return static_pointer_cast<Derived2>( shared_from_this() ); } }; I am assuming that I do not need to call boost::serialization::base_object<boost::enable_shared_from_this<Base> >( *this ); When I serialize the base class. Could that be the problem? I think what I am going to do is go back into the program and simply eliminate all of the shared_ptr serializations. I can serialize to raw pointers, and then just create the shared_ptr's from those pointers explicitly in my case. I simply do not ever have any shared_ptr's with multiple reference counts to worry about. I will let you know what happens. ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:30 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity I would be curious to see your particular case. The fact that different archives give problems that seem related to nesting depth suggest along with the fact that this hasn't been reported suggests that there is some sort of use case or error which hasn't been considered. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA059@SV-MSG-01.amer.actel.com.. . I am using the serialization library in boost 1.33.1. I am compiling on windows using the VC 7.1 compiler. The problem I am having is that when I use xml_iarchive and xml_oarchive, everything works just fine for simple cases, but if the xml gets very deep ( same exact class hierarchy, just more data organized a little more complexly) I am getting runtime stack overflow crashes in the spirit parser. I figured I could solve that by simply substituting text_iarchive and text_oarchive. Please note that I am simply substituting in these archive types instead of using the xml archive headers, which work. There are no other code changes anywhere. Now I am getting the following compiler error: \boost\mpl\eval_if.hpp(40) : fatal error C1204: compiler limit : internal structure overflow Any suggestions? I can try increasing the stack size of my current application to eliminate the xml runtime stack overflow problem, but I am uneasy doing this until I understand how to calculate the stack sizes required, and why it is happening. Furthermore, I would prefer using the text archives, since the data is more compact than the xml ones. Ed Reusser Principal Software Engineer Actel Corporation (408) 318-4972 ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

1 0

Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, I would need permission to send you the exact library code. I am reluctant to do this primarily because recreating my exact build environment would be a hassle (we are using gnumake on the PC). I also would need to do this directly to you, as I could not post this code into a public forum. Having said that, any recursive descent parser has complexity limits based on stack size. It would be pretty easy to create test cases that probe these complexity limits for the various archive types. I would like to see how much (approximately) stack space is allocated in the runtime for each level of xml hierarchy, and also for the text archives. The main complexity seems to be because I am using shared_ptr's extensively at all levels of the hierarchy. Thus, I have 2 levels nested for each class, the <px> data </px> and the actual data, which is in turn being represented by a collection of shared_ptr's, etc. I am also using std::map of shared pointers, and std::set of shared_ptr's. I also use enable_shared_from_this<T> for my base classes, then statically cast the resultant shared pointers internally for the derived classes. This is to get around a Linux problem which I can describe more fully if you like (would take a few pages of explanation). So for example: class Base : public boost:enable_shared_from_this<Base> { virtual boost::shared_ptr<Base> GetSharedFromThis() { return shared_from_this(); } }; class Derived1 : public Base { public: virtual boost::shared_ptr<Derived1> GetSharedFromThis() { return static_pointer_cast<Derived1>( shared_from_this() ); } }; class Derived2 : public Base { public: virtual boost::shared_ptr<Derived2> GetSharedFromThis() { return static_pointer_cast<Derived2>( shared_from_this() ); } }; I am assuming that I do not need to call boost::serialization::base_object<boost::enable_shared_from_this<Base> >( *this ); When I serialize the base class. Could that be the problem? I think what I am going to do is go back into the program and simply eliminate all of the shared_ptr serializations. I can serialize to raw pointers, and then just create the shared_ptr's from those pointers explicitly in my case. I simply do not ever have any shared_ptr's with multiple reference counts to worry about. I will let you know what happens. ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:30 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity I would be curious to see your particular case. The fact that different archives give problems that seem related to nesting depth suggest along with the fact that this hasn't been reported suggests that there is some sort of use case or error which hasn't been considered. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA059@SV-MSG-01.amer.actel.com.. . I am using the serialization library in boost 1.33.1. I am compiling on windows using the VC 7.1 compiler. The problem I am having is that when I use xml_iarchive and xml_oarchive, everything works just fine for simple cases, but if the xml gets very deep ( same exact class hierarchy, just more data organized a little more complexly) I am getting runtime stack overflow crashes in the spirit parser. I figured I could solve that by simply substituting text_iarchive and text_oarchive. Please note that I am simply substituting in these archive types instead of using the xml archive headers, which work. There are no other code changes anywhere. Now I am getting the following compiler error: \boost\mpl\eval_if.hpp(40) : fatal error C1204: compiler limit : internal structure overflow Any suggestions? I can try increasing the stack size of my current application to eliminate the xml runtime stack overflow problem, but I am uneasy doing this until I understand how to calculate the stack sizes required, and why it is happening. Furthermore, I would prefer using the text archives, since the data is more compact than the xml ones. Ed Reusser Principal Software Engineer Actel Corporation (408) 318-4972 ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

2 1