- Boost-users - lists.boost.org

[Boost.Test} exit codes
by Christoph 13 Nov '06

13 Nov '06

Hi, I am experimenting with the Boost.Test framework. I have stumbled upon the exit code of the test program. I have not found the documentation on the exit code (maybe I have overlooked it) and am somewhat baffled how to interpret it: i) what is the semantic of the exit code? It seems to be 0 when all tests are passed (as expected), but I get 201 if some tests fail. What does 201 mean? Are there further possibilities? ii) is it possible have the exit code return the number of failed test cases? Thank you Christoph

2 1

[enable_if][type_traits] Overload resolution question
by Michael Marcin 13 Nov '06

13 Nov '06

Hello, I have a fixed point math class and I want to enable some optimized operator overloads. for instance: fixed& fixed::operator /= ( const fixed &rhs ); fixed& fixed::operator /= ( int n ); it seems however to me that what I really want is an overload like: template< typename T > fixed& operator /= ( typename boost::enable_if<boost::is_integral<T>,T>::type n ); However I can't seem to get that function considered for overload resolution instead it goes through the following constructor and calls the /= that takes a const fixed &. template< typename T > fixed::fixed( T n, typename boost::enable_if< boost::is_integral<T> >::type* = 0 ); Speaking of which I don't understand why the following doesn't work in place of the previous constructor. template< typename T > fixed::fixed( typename boost::enable_if< boost::is_integral<T>,T>::type n ); Finally I'm using this class to replace a lot of hardcoded / macro logic and often as an optimization the code uses binary shifts to represent power of 2 multiply/divides. Going forward these divides need to work with both fixed and floating point types so f >> 1 needs to change to f / 2. Is it possible to create an overload for the / and * operators that determine if the operand is an integral constant and is a power of 2 and use a binary shift internally? Thanks, Michael Marcin

3 5

Re: [Boost-users] [Serialization] unexpected assert registeringclasses
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, Thanks for the quick response. I have ensured that the serialization for each type is located in exactly one place. The header files where the serialization code resides for the derived classes are not global, that is, our build system is set up to ensure that no other library or DLL can reference them. I believe that I can make the serialization completely independent and contained inside the DLL without much difficulty. However, unless I statically link the serialization library, I don't think I can prevent the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) from initializing the global table inside the serialization DLL (which is dynamically linked). I noticed that when I tried to use the other registration technique you describe, register_type<T>(), this also calls the registration code in the serialization DLL on load, so that doesn't solve the problem. It doesn't seem very practical to serializing in/out a prototype of each derived class into the archive initially because it would increase the archive size by a lot. Too bad there isn't a mechanism for creating a registration table specific to the DLL where the classes are serialized. If the global table was of the following structure: using namespace std; map< HMODULE, map<string, ETI*> >; Then the above macro would simply use AfxGetInstanceHandle (in the case of windows, I am unsure what the corresponding calls in other OS's would be), to pass the HMODULE handle. Ed -----Original Message----- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:24 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] unexpected assert registeringclasses Having serialization code in DLLS has raised some stick issues. The basic problem is the existence of a global table of information about types being serialized. Among other thngs, this global type table contains the export string name (GUID) that is shared among programs to identify the type. This table also points to functions via a virtual function mechnamism to implementations required by serialization. Entries are added to this table when code is loaded and deleted when code is unloaded. in version 1.33 I included the indicated assert - as it seemed to me that this must be unique. I was concerned that multiple entries in the table might point to different function implementations - as indeed they will. So I included this assertion. This started to create problems as you have found. Also I've now come to thnk that the having multiple entries for the same type is harmless - and difficult to avoid in the presence of dynamically loaded/unloaded DLLS. So in 1.34 - I commmented out the assertion. In addition, I've augmented the code to make sure that the correct entry in the table is deleted when the corresponding DLL is unloaded. So I believe that starting in 1.34 this problem will be resolved. I really don't know for sure because its very hard to come up with a good test for this. So, I think this problem is addressed. But in the face of dynamically loaded DLLs - which are not all guarenteed to be in sync ( some could have older versions of code), I think that the best policy would be to be sure that serialzation code for a particular type should be found in one and only one place. Also, doing this will result in smaller DLLS and applications. Doing this requires that one explicitly orgranize his code so to achieve this. This means avoiding instantiation of serialization code in applications and by explicitly instantiation such code in the DLLS. The closest guide I have for doing this is demo_pimpl which shows how to do this. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA054@SV-MSG-01.amer.actel.com.. . I am using the boost 1.33.1 distribution, and the xml_iarchive and xml_oachive to serialize a rather deep and complex data structure to xml. I am using make_nvp directly in all cases (not the macro). I am sometimes getting the following assert (line 71 in extended_type_info.cpp) when I load previously serialized data: assert( lookup(eti) == m_self->m_map.end() ); It seems obvious that what is happening is that somehow I am calling self_register more than once for a specific class. Tracing through the code however I am puzzled exactly how this could happen, since the registration should only happen once when the libraries are loaded. This never happens on save by the way, only on load. It also never happens if I do the save, followed by a load immediately. It only happens if I do the save, shut down the application, then load the data. I have verified that the loaded data is a bit by bit equivalent in both cases. The best that I can come up with is that I am loading the serialization library as a side effect of calling LoadLibrary at runtime. So I am linking in the serialization library after everything else has been loaded and is running. But again, none of the libraries are ever unloaded, and the load sequence should always be the same. The actual situation is that I have a library . call it Library A, which is linked to libraries B, and C. The library A is being linked using the LoadLibrary call, each of libraries B are C are linked to the boost serialization library. In each of libraries B, and C, I have used the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) To define all of my classes I am serializing, including all classes that I am serializing using shared_ptr's. I was thinking originally that the problems were all shared_ptr's of classes that are derived from enable_shared_from_this<T>, but I am no longer confident that has anything to do with it. In fact, truth be told, I have no idea if any of the above has anything to do with the problem. When I commented out the assertion, everything seems to work just fine, except now I am getting a stack overflow on very complex hierarchies in the spirit parser (again, load only), but the simpler ones seem to work repeatedly without any problems. I have no doubt that the assertion was added there for a reason, so I hate to comment it out without finding out what else I might have broken. Edward Reusser Principal Engineer Actel Corporation (650) 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

2 1

[Serialization] a coupla crashes from hiearchy complexity
by Reusser, Edward 13 Nov '06

13 Nov '06

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.

2 1

[Serialization] unexpected assert registering classes
by Reusser, Edward 13 Nov '06

13 Nov '06

I am using the boost 1.33.1 distribution, and the xml_iarchive and xml_oachive to serialize a rather deep and complex data structure to xml. I am using make_nvp directly in all cases (not the macro). I am sometimes getting the following assert (line 71 in extended_type_info.cpp) when I load previously serialized data: assert( lookup(eti) == m_self->m_map.end() ); It seems obvious that what is happening is that somehow I am calling self_register more than once for a specific class. Tracing through the code however I am puzzled exactly how this could happen, since the registration should only happen once when the libraries are loaded. This never happens on save by the way, only on load. It also never happens if I do the save, followed by a load immediately. It only happens if I do the save, shut down the application, then load the data. I have verified that the loaded data is a bit by bit equivalent in both cases. The best that I can come up with is that I am loading the serialization library as a side effect of calling LoadLibrary at runtime. So I am linking in the serialization library after everything else has been loaded and is running. But again, none of the libraries are ever unloaded, and the load sequence should always be the same. The actual situation is that I have a library ... call it Library A, which is linked to libraries B, and C. The library A is being linked using the LoadLibrary call, each of libraries B are C are linked to the boost serialization library. In each of libraries B, and C, I have used the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) To define all of my classes I am serializing, including all classes that I am serializing using shared_ptr's. I was thinking originally that the problems were all shared_ptr's of classes that are derived from enable_shared_from_this<T>, but I am no longer confident that has anything to do with it. In fact, truth be told, I have no idea if any of the above has anything to do with the problem. When I commented out the assertion, everything seems to work just fine, except now I am getting a stack overflow on very complex hierarchies in the spirit parser (again, load only), but the simpler ones seem to work repeatedly without any problems. I have no doubt that the assertion was added there for a reason, so I hate to comment it out without finding out what else I might have broken... Edward Reusser Principal Engineer Actel Corporation (650) 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.

2 1

Iterater for subset extraction?
by Thom DeCarlo 12 Nov '06

12 Nov '06

I have a couple of n00b questions. I have constructed a BGL graph that uses the edge_name_t property to road names. I want to change the weights of some of the roads based on input from the user. Is there a way to set up an iterator to step through edges that have names which match elements of a set? (e.g., "A,B,B1,L,M") In a related question, I need to extract a vertex whose vertex_index_t value matches a specific value. The vertices were not entered in any specific order, so the "vertex(1, g)" function returns the first vertex to have been entered into the graph, but not necessarily the one whose index value is "1". Thanks, Thom -- this sig intentionally left blank

2 3

format un-debuggability
by Drumheller, Michael 12 Nov '06

12 Nov '06

If you don't pass enough arguments to a boost::format you get this: "boost::too_few_args: format-string refered to more arguments than were passed" Unfortunately there is, as far as I can tell, no way to figure out where the error happened, other than building a debug version of your app and breaking into the debugger on that error. Needless to say that can be very inconvenient. Would it be possible to fix boost::format (which, by the way, is IMHO one of the most wonderful of all the Boost libraries!!) so that its exceptions carry a little more information about their origins (e.g., embedding the format-string itself in the message)? Thank you. Michael Drumheller Boeing Phantom Works Mathematics and Engineering Analysis 425.373.2703 michael.drumheller(a)boeing.com This email may contain proprietary information. If you are not the intended recipient please delete it and notify the sender that you received it in error.

1 0

Boost crosscompilation
by Vinh 12 Nov '06

12 Nov '06

Hi everyone, I'm new to boost and have successfully installed it on my debian sarge system. For a particle Filter using the Bayes++ Library, I would need to crosscompile the boost library for an ARM processor. Does anyone know whether that is possible? (I already have a crosscompiler installed, but don't know whether boost supports crosscompilation?) Vinh

2 2

iterating over arbitrary python object in c++
by Augusto Callejas 12 Nov '06

12 Nov '06

hi- i'm writing a C++ class that i want to expose as a python class. one method in my class has an argument that takes in a python object that "implements" the iterator interface (that is the python object has defined "__iter__" and "__next__" and can be used in a "for x in y" loop). how do i go about iterating over that python object in my C++ code? for example: void my_class::method(object my_iterable_obj) { // iterate over "my_iterable_obj" } one method i tried was calling the "__next__" method explicity: my_iterable_obj.attr("__next__")() however, "__next__" raises a StopIteration exception when there are no more objects in the iterator. i could not find any examples in the boost python tutorials for handling python exceptions from c++. is there another way i can go about this? thanks, augusto.

3 2

[Boost.Signals] in Multithreaded Environment
by Terry G 11 Nov '06

11 Nov '06

Hello again everyone! Boo ST == (Scarey signals & threads) Signals/slots are just too good not to use in a multi-threaded environment. Someday, this will be fixed, I know. But for now... I'm trying to serialize access to boost.signals using Bjarne Stroustrups "wrapper" concept. Here's what I'm doing. Is this likely to cause problems? Sorry about the length. If this is too dangerous, what's a better alternative? I typed this from memory and didn't try to compile. Please disregard any typos or syntactic blunders. // Implements Bjarne Stroustrup's "wrapper" concept using boost::shared_ptr. template <typename T> class Wrapper { T* p; public: explicit Wrapper(T& obj) : p(&obj) { } boost::shared_ptr<T> get() const { p->prefix(); return boost::shared_ptr<T>(p, boost::mem_fn(&T::suffix)); } // get boost::shared_ptr<T> operator->() const { return get(); } }; //Wrapper // Provides signals through "safe" wrapper. (?) class TiePoint { public: class Events { Mutex lock; // Provided elsewhere. void prefix() { lock.acquire(); } void suffix() { lock.release(); } friend class Wrapper<Events>; public: boost::signal<void (Signal1Args)> signal1; boost::signal<void (Signal2Args)> signal2; // etc... template <class Iter> void disconnect(Iter begin_, Iter end_) { std::for_each(begin_, end_, boost::mem_fn(&boost::signals::connection::disconnect); } // disconnect }; // Events private: Events _events; public: Wrapper<Events> events; TiePoint() : _events(), event(_events) { } }; // TiePoint // Demonstrates use of TiePoint class. class UsesSignals { private: void handle1(Signal1Args) { ... } void handle2(Signal2Args) { ... } std::vector<boost::signals::connection> conns; // Be very careful with these. public: void connect(TiePoint& tiePt) { boost::shared_ptr<TiePoint::Events> events = tiePt.events.get(); conns.push_back(events->signal1.connect(Handle1)); conns.push_back(events->signal2.connect(Handle2)); } // connect void disconnect(TiePoint& tiePt) { tiePt.events->disconnect(conns.begin(), conns.end()); conns.clear(); } // disconnect void signalJustOne(TiePoint& tiePt) { tiePt.events->signal1(signal1args); } // signalJustOne void signalMany(TiePt& tiePt) { boost::shared_ptr<MyClass::Events> events = tiePt.events.get(); events->signal1(signal1args); events->signal2(signal2args); ... } // signalMany }; // UsesSignals

1 0