September 2005 - Boost - lists.preview.boost.org

Boost regression notification (2005-09-28 [HEAD])
by Douglas Gregor 28 Sep '05

28 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-28T05:00:20Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 124 failures in 11 libraries: concept_check (12) graph (2) mpl (1) parameter (12) python (3) serialization (30) spirit (8) thread (4) tuple (1) typeof (50) wave (1) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-4_0-darwin macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| back_reference: vc-7_1 slice: vc-7_1 virtual_functions: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ptr_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ref_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 lvalue_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 member_function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 noncopyable_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 std_emulation: cw-9_4 std_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_dependent_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_enum_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_multiword_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_tpl_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 |wave| testwave: gcc-3.3.6-linux

1 0

[Boost-bugs] [ boost-Bugs-1307106 ] extended_type_info crash on global dtors (arm)
by SourceForge.net 28 Sep '05

28 Sep '05

Bugs item #1307106, was opened at 2005-09-28 09:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1307106&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: extended_type_info crash on global dtors (arm) Initial Comment: Hello, i'm struggling with boost::serialization lib again ... I am using RC0_1.33 which has fixed some serialization stuff for me (1.33 was totally unusable for me due to that bugs). Now i seem to have encountered another problem... I am using the boost framework in cross platform projects: gcc 3.4.4: cygwin (win32), linux x86, linux arm gcc 4.0.1: cygwin (win32), linux x86, linux arm msvc 7.1: win32 After upgrading to 1.33/RC0 i get crashes on linux "ARM" processor platform (binaries). "pure virtual function call " -> SIGABRT The cross compiler is verified to work fine (3.4.4). After endless hours of debugging (thanks to that gdb/gdbserver 6.3 trash) i tracked it down to a specific serialization problem? Attached is a shortened gdb/server session (target = arm7tdmi)... It only occurs on arm platform (little endian), the same compiler on x86 (gcc 3.4.4) produces valid code. No crashes. Boost 1.32 worked flawlessly on all platforms with same compilers but it doesnt count because serialization has changed much between 1.32 and 1.33 (= could be anything) >From what i can see, the "return less_than(rhs); " operation is called on"boost::serialization::extended_type_info" object, resulting in pure virtual function call. I have no clue where to search/begin for error ... i can only debug on target (arm processor bord) with gdbserver which make it a mess (global dtors). I verified the "extended_type_info_typeid.cpp" code is linked in and the function: BOOST_SERIALIZATION_DECL(bool) extended_type_info_typeid_0::less_than(const extended_type_info &rhs) const { return 0 != get_eti().before( static_cast<const extended_type_info_typeid_0 &>(rhs).get_eti() ); } does exist in code. This is the offending snippet: ------------------------------------------------- BOOST_SERIALIZATION_DECL(bool) extended_type_info::operator<(const extended_type_info &rhs) const { int i = type_info_key_cmp(rhs); if(i < 0) return true; if(i > 0) return false; return less_than(rhs); <---- pure virtual function call !!! } ------------------------------------------------- The object instance itself seems ok, though i dont know how to validate vtable stuff because im not gdb expert. What gives? Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1307106&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Are we seriously planning to release 1.33.1 in a few days?
by David Abrahams 28 Sep '05

28 Sep '05

The regression reports for RC_1_33_0 are still showing 78 failures. Can we get rid of those in time? Is it working to alert developers to regressions in their libraries? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

'noncopyable' : base class undefined
by Jing-Hsuan 28 Sep '05

28 Sep '05

Hi, I attempt to port program from x86 to arm, so I move the code from vc7.1 to evc4. But I encounter some problem.... By include <boost/utility.hpp>, I use class noncopyable to a base class, and derive my own class from noncopyable. In vc7.1 it works fine, while evc4 doesn't. Error message: error C2504: 'noncopyable' : base class undefined Any suggestion? Best Regards.

2 1

[serialization] a pattern for serialization and plugins
by Thomas Conway 28 Sep '05

28 Sep '05

Hi all, I'm trying to use the serialization library for the first time and I'm wondering if there is an extant solution for the problem I'm trying to solve. I have an application which has dynamicly loaded plugin modules. The application structure is something like: main app: ---- class base { ... template <class Archive> void serialize(Archive& pAr, unsigned int pVer) { ... } ... }; class baseFactory { shared_ptr<base> create(...) = 0; }; ---- plugin: ---- class myPluginN : public base { ... template <class Archive> void serialize(Archive& pAr, unsigned int pVer) { ... } }; class myPluginNFactory : public baseFactory { shared_ptr<base> create(...); }; extern "C" { void* makeFactory(); } ---- Now the problem is that by my reading of the serialization library documentation, the registration of derived classes is going to present difficulties. If I understand things correctly, derived classes need to be registered, and the archive contains a "tag" for each derived class. Now in this instance the set of derived classes is dynamic, and I don't want to require the set of derived classes to be the same in order to be able to load a structure. Of course, all the derived classes that are used in the structure must be loaded (of course, I'd like to serialization code to attempt to load any that are required but not already loaded), but I don't want the archive to depend on any derived classes that are not used. So the question really is: is this a solved problem? And if so, what is the solution? Also, the structures contain pointers to members of other structures (e.g. class Foo { .... }; class Bar { Foo foo; }; class Baz { Foo* fooPtr; }; ... shared_ptr<Bar> bar(new Bar); shared_ptr<Baz> baz(new Baz); baz->fooPtr = &(bar->foo); ) Will the obvious serialization code Bar::serialize(...) { ar & foo; } Baz::serialize(...) { ar & fooPtr; } do the right thing? thanks to anyone who can shed some light, Tom

2 1

[BGL] compile error in python bindings
by Georg Baum 28 Sep '05

28 Sep '05

Hi, when I try to compile the python bindings of Boost.Graph (current CVS) I get the compilation errors shown in the attached log file. This is with gcc version 3.3.4 (pre 3.3.5 20040809) on Linux. The errors are introduced with the recent changes related to named parameters of biconnected_components.hpp: http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/graph/biconnected_c… Does anybody have a clue what to do? Should the python bindings be converted to the named parameter version? If yes, how? Georg

2 2

[serialization docs] Ping?
by Kim Barrett 28 Sep '05

28 Sep '05

This is in regard to the discussion of the "equivalence" of a serialized object and the deserialized counterpart. It also touches on the Serializable concept and some recent discussion of how classes without default constructors can be handled, and a few other things besides. (Sorry about the entanglement, but I'm not sure how to separate some of these issues.) (Note that I also haven't read *all* of the mail on this subject yet.) The Common Lisp committee (X3J13) needed to deal with essentially the same problem. First, a bit of background. Because CL supports programmatic construction of code which can then be passed to the compiler, and the code "syntax" supports a quoting form for referring to a literal constant, there was a need to address what it meant for various kinds of objects to appear in such a context. And the resulting objects may be referred to in code will be compiled to a file for later loading into the same or some completely different runtime environment. Earlier versions of the language simply listed all the cases for the "built-in" types, and a simple mechanism for the simple record type provided by the language (things defined with defstruct, if you care). But with the addition of OO concepts in various implementations that eventually led to CLOS (the CL Object System), it was realized that this wasn't sufficient. The term that was eventually adopted was "similar" or "similar as constants" where further disambiguation was needed. I think that would be a good term for the serialization library to adopt, as it avoids an implications related to operator== and the ambiguity around the word "equivalent". A protocol was designed to permit instances of arbitrary user-defined classes to be saved and loaded. (Sound familiar? Note that support for different data formats for that saving and restoring was only addressed to the extent that different CL implementations likely had different compiled file formats and were not required to be compatible; something like the idea of binary / text / XML / whatever archives was not addressed, and never even came up, so far as I can recall. A missed opportunity there.) The relevant part of the specification is Section 3.2.4, "Literal Objects in Compiled Files", which can be found at: http://www.lisp.org/HyperSpec/Body/sec_3-2-4.html and in the definition of make-load-form, found here: http://www.lisp.org/HyperSpec/Body/stagenfun_make-load-form.html#make-load-… (Let me know if / where translation between CL terminology and C++ terminology would be helpful and I'll give it a shot.) The CL term "externalizable object" corresponds to the Serializable concept for the serialization library. Corresponding to the Save / Load Archive compatibility concept, CL says: "The \term{file compiler} must cooperate with the \term{loader} in order to assure that in each case where an \term{externalizable object} is processed as a \term{literal object}, the \term{loader} will construct a \term{similar} \term{object}." Substituting serialization library terminology into that quote: The saving archive must cooperate with the loading archive in order to assure that in each case where a serializable object is saved, the loading archive will construct a similar object. I think it should be reasonably straightforward to massage this into a statement about whether a saving archive and a loading archive are compatible. The CL protocol for loading involved a two step process. First, a constructor is called with some arguments. Then, optionally, an initialization form is called called, which contains references to the constructed object in order to perform additional modifications to it. I *think* this protocol is strictly more powerful than that presently specified by the serialization library. An example of a class that I don't know how to "serialize" is a "symbol" lazily constructed on named lookup; the save/load_construct_data mechanism is inadequate for this. (There are also object graphs containing reference cycles that might not be serializable but are CL externalizable, because the reference cycle can be broken by using the two stage protocol. I haven't looked to see whether the serialization library installs an object in the "pointer table" (whatever it is called) at allocation time or only after it has been initialized via deserialization.) Attempting to translate the CL protocol into C++ terminology, I think it would consist of first calling a static factory function associated with the type, passing it the archive as an argument, and then calling a member function on the object, again passing the archive as an argument.

4 9

Re: [boost] [vacpp] Problems porting to z/OS - was Errors compiling multi_index hashed.cpp
by Christopher Cambly 27 Sep '05

27 Sep '05

David Crayford wrote: > Sean Perry <perry <at> ca.ibm.com> writes: > >> >> What version of the compiler are you using. It appears that you are >> using >> the v1r2 compiler. I suggest trying the v1r6 compiler. >> > Sean, > > I'm using the V1R6 compiler, unless the build is bad. I've copied the > boost libraries into HFS files in USS and compiling on z/OS using a path > option. If you guys in Toronto can help in any way it will be a very big > help. > The reason we ask is that the message: "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: CCN5431 (S) The declarator cannot be qualified with the enclosing namespace "mpl_". seems to be a V1R2 specific message. Our RCS shows the message was removed from the compiler prior to the V1R6 release. The compiler macros on zOS are __IBMCPP__ == 41020 for V1R2 and __IBMCPP__ == 41060 for V1R6. Could you please verify the compiler version for us by compiling the following: //begin t.C #if (__IBMCPP__ == 41020) #error Using V1R2 #endif #if (__IBMCPP__ == 41060) #error Using V1R6 #endif //end t.C We are a little confused as to the source of this message. Thanks, Chris IBM XL Compiler Development

1 0

Sourceforge bug database
by Peter Dimov 27 Sep '05

27 Sep '05

We still have hundreds of open bug reports in the SF database. Is this acceptable for an organization of Boost's caliber? Don't we need a 'QA wizard'? -- Peter Dimov http://www.pdimov.com

5 5

Re: [boost] What is Boost?
by Jost, Andrew 27 Sep '05

27 Sep '05

> From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > We really need a section at the top of the page titled "What > is Boost?" Are you thinking of a section to replace "Welcome to Boost.org", or perhaps just a new subheading? Something like this: WELCOME TO BOOST.ORG! What is Boost: ... Getting started: ... Background: ... > * Boost is a collection of C++ libraries > - Free for any use > - Extensively peer-reviewed > - Extensively Tested (replace first sentence with the following) What is Boost: Boost is an organization of developers dedicated to the advancement of C++. Boost provides a collection of C++ libraries that improve the utility and portability of C++. Boost uses a highly collaborative, peer-reviewed development process. Boost libraries are completely free for any use, and are thoroughly tested on several platforms. "We emphasize libraries that work..." (possibly make further edits to existing passage) > * When you download Boost, you get the whole collection > > * There are some dependencies among libraries, but they are not > tightly coupled > > * There is a tool (bcp) for extracting the parts you want and their > dependencies. > > * Many boost libraries can be used just by putting the library > collection's top directory in your #include path. Complete > instructions for getting started are at: ___ > > * The important features of the Boost directory structure are: > - boost > - libs > - more > - tools > (with rough descriptions of each) Perhaps this could be added under the "Getting started:" subheading? That is, unless it would make that section too long. The current page is nicely formatted into digestible chucks -- I would be wary of breaking up the visual flow. -Andy

1 0