November 2005 - Boost - lists.boost.org

preferred idiom for "occasional properties"
by joel reed 02 Nov '05

02 Nov '05

I've been exploring what a cross platform process library would look like and have a question about whether there is a preferred idiom for what I'll call an occasional property for lack of a better term. Given a process, I'd like to be able to query the parent process. Posix has such a notion, but win32 doesn't. On posix, afaik, every process has a parent except for "init." I can't decide whether I should say class process { public: process parent(); static const process nprocess; // like std::string's npos }; where parent() != nprocess when the process has a parent. or class process { public: typedef std::pair<process,bool> parent_type; parent_type parent(); }; where parent_type.second == true when the process has a parent. I also considered a "parent_iterator", since on posix, you could keep walking backwards up the hierarchy till you get to init, e.g. class parent_iterator; class process { public: parent_iterator parent(); }; but conceptually, I couldn't see a good "end()" Anyone care to offer an idea for the best way to handle this? jr

3 4

Thread-safe Boost.Signals
by Ashok Thirumurthi 01 Nov '05

01 Nov '05

Dear Boost, Doug hinted in the signals FAQ that it is possible to make a thread-safe version of the library. While such a beast may not be in the works, I was wondering if I could write my own layer to serialize calls to the signals library. Typically, we wrap signals using a class as simple as: class NKNEF_ENTRY CImageLoadedEvt : public CImageEvt { typedef boost::signal<void(const ImageLoadData&)> sigNotify_ImageLoaded; public: NKNEF_CALL CImageLoadedEvt(); virtual NKNEF_CALL ~CImageLoadedEvt(); void NKNEF_CALL Connect(const sigNotify_ImageLoaded::slot_type& slot); void NKNEF_CALL Notify(ImageLoadData& data); private: sigNotify_ImageLoaded signal; }; void NKNEF_CALL CImageLoadedEvt::Connect(const CImageLoadedEvt::sigNotify_ImageLoaded::slot_type& slot) { signal.connect(slot); } void NKNEF_CALL CImageLoadedEvt::Notify(ImageLoadData& data) { signal(data); } Can a wrapper be designed to achieve thread-safe use of the signals library? For instance, a critical section could guard concurrent operation of the Connect and Notify methods as well as the destructor... Thanks in advance for your advice, - Ashok Thirumurthi

2 1

[parameter] - arg_list vs. tagged_argument
by Daniel Earwicker 01 Nov '05

01 Nov '05

If width and titlebar are instances of unique specializations of keyword<> then this expression yields an instance of a type that conforms to the "argument pack" concept: (width=10, titlebar=false) However, this expression does not: (width=10) In practise users probably take advantage BOOST_PARAMETER_FUN to declare forwarding functions, so passing a single parameter normally works fine. So this isn't necessarily a problem, but it might cause trouble where users attempt to use a raw argument pack without using boost::parameters<> as a forwarding mechanism. Assignment to a keyword yields a tagged_argument<>, whereas the comma operator yields arg_list<>. The latter is a conforming argument pack. The necessary members could be added to tagged_argument to make it into a conforming argument pack. Or a simpler solution might be to remove tagged_argument altogether and just have the assignment return an arg_list with empty_arg_list as its successor. --Daniel.

1 0

[foreach] something strange is happening ...
by Sascha Seewald 01 Nov '05

01 Nov '05

Hi Boosters! I've been playing around with BOOST_FOREACH a little and got some unexpected results. The following program crashes when I try to iterate a const map with BOOST_FOREACH. That's really strange because for the non-const map everything works fine. Please take a look at the source. What's wrong here? Did I miss something? This is the version in cvs on vc-8_0. Cheers Sascha ----------------------------------------------------------------- <source> #include <boost/foreach.hpp> #include <map> class foo { public: typedef std::map<int, float> map_type; /// return copy of map map_type map() const { return _map; } /// return const copy of map map_type const map_c() const { return _map; } private: map_type _map; }; void main() { foo f; // iterate copy ... ok BOOST_FOREACH( foo::map_type::value_type i, f.map() ) {} // iterate const copy ... crashes here! :-( BOOST_FOREACH( foo::map_type::value_type i, f.map_c() ) {} } </source>

2 3

Boost regression notification (2005-11-01 [HEAD])
by Douglas Gregor 01 Nov '05

01 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-01T06:00:26Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 300 failures in 14 libraries: bind (12) concept_check (12) graph (2) io (1) mpl (1) python (1) serialization (30) spirit (8) thread (4) tr1 (147) tuple (1) type_traits (58) typeof (18) xpressive (5) |bind| bind_dm3_test: 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 intel-win32-9_0 bind_stateful_test: 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 intel-win32-9_0 |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 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |python| exec: intel-win32-9_0 |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 |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_array: gcc-2.95.3-linux std_test_array_tricky: 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 intel-win32-9_0 vc-7_1 std_test_bind: 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 intel-win32-9_0 std_test_bind_tricky: 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 intel-win32-9_0 vc-7_1 std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_function: gcc-2.95.3-linux std_test_function_tricky: 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 intel-win32-9_0 vc-7_1 std_test_hash: gcc-2.95.3-linux std_test_mem_fn: gcc-2.95.3-linux std_test_mem_fn_tricky: 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 intel-win32-9_0 vc-7_1 std_test_random: gcc-2.95.3-linux std_test_reference_wrapper: gcc-2.95.3-linux std_test_reference_wrapper_tricky: 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 intel-win32-9_0 vc-7_1 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_shared_ptr: gcc-2.95.3-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple_tricky: 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 intel-win32-9_0 vc-7_1 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_array_tricky: 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 intel-win32-9_0 vc-7_1 test_bind: 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 intel-win32-9_0 test_bind_tricky: 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 intel-win32-9_0 vc-7_1 test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_function_tricky: 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 intel-win32-9_0 vc-7_1 test_functional: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_mem_fn_tricky: 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 intel-win32-9_0 vc-7_1 test_memory: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_reference_wrapper_tricky: 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 intel-win32-9_0 vc-7_1 test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple_tricky: 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 intel-win32-9_0 vc-7_1 test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |tuple| tuple_test_bench: gcc-3_4_3-sunos |type_traits| tr1_add_const_test: gcc-2.95.3-linux tr1_add_cv_test: gcc-2.95.3-linux tr1_add_pointer_test: gcc-2.95.3-linux tr1_add_reference_test: gcc-2.95.3-linux tr1_add_volatile_test: gcc-2.95.3-linux tr1_aligned_storage_test: gcc-2.95.3-linux tr1_alignment_of_test: gcc-2.95.3-linux tr1_extent_test: gcc-2.95.3-linux tr1_has_nothrow_assign_test: gcc-2.95.3-linux tr1_has_nothrow_constr_test: gcc-2.95.3-linux tr1_has_nothrow_copy_test: gcc-2.95.3-linux tr1_has_trivial_assign_test: gcc-2.95.3-linux tr1_has_trivial_constr_test: gcc-2.95.3-linux tr1_has_trivial_copy_test: gcc-2.95.3-linux tr1_has_trivial_destructor_test: gcc-2.95.3-linux tr1_has_virtual_destructor_test: gcc-2.95.3-linux tr1_is_abstract_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin tr1_is_arithmetic_test: gcc-2.95.3-linux tr1_is_array_test: gcc-2.95.3-linux tr1_is_base_of_test: gcc-2.95.3-linux tr1_is_class_test: gcc-2.95.3-linux tr1_is_compound_test: gcc-2.95.3-linux tr1_is_const_test: gcc-2.95.3-linux tr1_is_convertible_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_empty_test: gcc-2.95.3-linux tr1_is_enum_test: gcc-2.95.3-linux tr1_is_floating_point_test: gcc-2.95.3-linux tr1_is_function_test: gcc-2.95.3-linux tr1_is_fundamental_test: gcc-2.95.3-linux tr1_is_integral_test: gcc-2.95.3-linux tr1_is_member_func_test: gcc-2.95.3-linux tr1_is_member_obj_test: gcc-2.95.3-linux tr1_is_member_pointer_test: gcc-2.95.3-linux tr1_is_object_test: gcc-2.95.3-linux tr1_is_pod_test: gcc-2.95.3-linux tr1_is_pointer_test: gcc-2.95.3-linux tr1_is_polymorphic_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_reference_test: gcc-2.95.3-linux tr1_is_same_test: gcc-2.95.3-linux tr1_is_scalar_test: gcc-2.95.3-linux tr1_is_signed_test: gcc-2.95.3-linux tr1_is_union_test: gcc-2.95.3-linux tr1_is_unsigned_test: gcc-2.95.3-linux tr1_is_void_test: gcc-2.95.3-linux tr1_is_volatile_test: gcc-2.95.3-linux tr1_rank_test: gcc-2.95.3-linux tr1_remove_all_extents_test: gcc-2.95.3-linux tr1_remove_const_test: gcc-2.95.3-linux tr1_remove_cv_test: gcc-2.95.3-linux tr1_remove_extent_test: gcc-2.95.3-linux tr1_remove_pointer_test: gcc-2.95.3-linux tr1_remove_reference_test: gcc-2.95.3-linux tr1_remove_volatile_test: gcc-2.95.3-linux |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

Alternative solution to intermediate results problem of expression templates.
by Korcan Hussein 01 Nov '05

01 Nov '05

Hi I'm not sure if this has already been explored or even in current use but I think I may have come up with an alternative solution to the type deduction of intermediate results from expression templates. Instead of using automatic type erasing technique, take the compile-time parse tree of an intermediate expression and create an exact runtime replica of the expression tree using recursive variant types (using Boost.Variant in C++). The creation of the expression tree can be completely automated. I have tried this myself with promising results. The only (minor) downside is in order to avoid redundant copies of operands the types of the operands must be given but not the structure of the compile-time expression tree itself. Leaf nodes of the recursive variant hold constant references to there elements. I've done quick profile of this against the traditional eager evaluation of overloaded operators and it still is more efficient but tree creation does cost in time slightly. If people are interested I can post code the code for this.

4 20

[serialization] fast array serialization (10x speedup)
by Matthias Troyer 01 Nov '05

01 Nov '05

Hi Robert, Over the past week I got around to doing what I wanted to do for a long time, and implemented an improved serialization of contiguous arrays of fundamental types. The motivation was two-fold: i) to speed up the serialization of large data sets by factors of up to 10 ii) to allow implementation of serialization by MPI The problem with the serialization of large contiguous arrays of fundamental types (be it a C-array, a std::vector, a std::valarray, boost::multi_array, ...) is that the serialization function is called for each (of possible billions) elements, instead of only once for the whole array. I have attached a suite of three benchmark programs and timings I ran on a PowerbookG4 using Apple's version of the gcc-4 compiler. The benchmarks are a) vectortime: reading and writing a std::vector<double> with 10^7 elements to/from a file b) arraytime: reading and writing 1000 arrays double[10000] to/ from a file c) vectortime_memory: reading and writing a std::vector<double> with 10^7 elements to/from a memory buffer The short summary of the benchmarks is that Boost.Serialization is 5-10 times slower than direct reading or writing! With the fast array serialization modifications, discussed below, this slowdown is removed. Note that the codes were compiled with -O2. Without -O2 I have observed another factor of 10 in slowdown in some cases In order to implement the fast array serialization, I made the following changes to the serialization library: i) a new traits class template <class Archive, class Type> has_fast_array_serialization<Archive,Type>; which specifies whether an Archive has fast array serialization for a Type. The default implementation for this traits class is false, so that no change is needed for existing archives. ii) output archives supporting fast array serialization for a given Type T provide an additional member function save_array(T const * address, std:;size_t length); to save a contiguous array of Ts, containing length elements starting at the given address, and a similar function load_array(T * address, std:;size_t length); for input archives iii) serialization of C-arrays and std::vector<T> was changed to use fast array serialization for those archives and types where it is supported. I'm still working on serialization for std::valarray and boost::multi_array using the same features. iv) in addition, to support an MPI serialization archive (which is essentially done but still being tested), and to improve portability of archives, I introduced a new "strong" type BOOST_STRONG_TYPEDEF(std::size_t, container_size_type) for the serialization of the size of a container. The current implementation uses an unsigned int to store the size, which is problematic on machines with 32-bit int but 64 bit size_type . To stay compatible with old archives, the serialization into binary archives converts the size to an unsigned int, but this should be changed to another type, and the file version number bumped up to allow containers with more than 2^32 elements. The second motivation was MPI serialization, for which I need the size type of containers to be a type distinct from any other integer. The explanation is lengthy and I will provide the reason once the MPI archives are finished. v) also the polymporphic archives were changed, by adding save_array and load_array functions. Even for archives not supporting fast array serialization per se this should improve performance, since now only a single virtual function call is required for arrays, instead of one per element. The modifications are on the branch tagged "fast_array_serialization", and I have attached the diffs with respect to the main trunk. I have performed regression tests under darwin, using Apple's version of gcc-4. None of the changes should lead to any incompatibility with archives written with the current version of the serialization library, nor should it break any existing archive implementation. Regarding compatibility with non-conforming compilers the only issue I see is that I have used boost::enable_if to dispatch to either the standard or fast array serialization. We should discuss what to do for compilers that do not support SFINAE. My preferred solution would be to just disable fast array serialization for these compilers, to keep the changed to the code minimal. The other option would be to add another level of indirection and implement the dispatch without using SFINAE. Robert, could you take a look at the modifications, and would it be possibly the merge these modifications with the main trunk once you have finished your work for the 1.33.1 release? Best regards Matthias

6 42

[MPL.Math] rational_part or fractional_part?
by Cromwell Enage 01 Nov '05

01 Nov '05

--- Daryle Walker wrote: > Is BOOST_MPL_MATH_RATIONAL_PART_OF_RATIONAL a > re-statement of the rational number itself? No. > Or is it supposed to be the remainder after taking > out the "whole" part? Yes. > If the latter, then the name should have "FRACTIONAL" > replacing the first "RATIONAL", since "fractional" > and not "rational" better describes a left-over bit. For consistency this part of the macro name is lexically the same as the template name whose specialization the macro creates, i.e. rational_part. > (Rational numbers are a generalization of fractions > that include values with absolute values greater than > one, i.e. a numerator larger than its denominator [in > absolute value].) I have no qualms about changing the name, as long as all interested parties agree. Andy Little? Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

5 8

[MPL.Math] numeric concepts
by Cromwell Enage 01 Nov '05

01 Nov '05

--- Andy Little wrote: > BTW, I have found that the ability to convert a > rational to an integral_constant if possible is a > useful utility too, though I'm not quite sure > what purists would make of it as the resulting > ::type may be an integral_constant or maybe a > rational constant. I currently call it > "simplify_rational_or_numeric". The resulting ::type > works ok if accessed using the numerator and > denominator functions, and this allows me to make > lists of dimensions using both integral_constants and > rationals. Maybe there is room for such a concept as > an "mpl rational or numeric concept"? In my yet-to-be-submitted documentation, I have the following numeric metatype hierarchy: Numeric Constant | +--Real Numeric Constant | | | +--Discrete Constant--Bitwise Constant | | | | | | +--Integral Constant------+ | | | | | | +--Big Integral Constant--+ | | | +--Continuous Constant | | | +--Rational Constant | | | +--Mixed Numeric Constant | +--Complex Numeric Constant Each concept is defined in terms of the metafunctions that can operate on it, and their semantics. In this scheme, both Integral Constants and Rational Constants are Real Numeric Constants. Not only do the arithmetic metafunctions (negate, plus, minus, times, divides), a few comparison metafunctions (equal_to, not_equal_to), and a few numeric metafunctions (is_zero, zero, real_part, imaginary_part) work on them as they do on other Numeric Constants; but all the other comparison metafunctions (less, greater, less_equal, greater_equal) and all the other numeric metafunctions (is_negative, abs, numerator, denominator, whole_part, fractional_part) work on them as well. A few metafunctions have different semantics for Discrete Constants; e.g. the numerator or whole_part of an Integral Constant is itself, its denominator is always one, and its fractional_part is always zero. To obtain the corresponding run-time values, use the runtime_value facility, which is required to operate on all Numeric Constants. Let me know of any details that need to be fleshed out for you. Cromwell D. Enage __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

2 2

Re: [boost] VC++ 7.1 build options lead to AV
by Ashok Thirumurthi 01 Nov '05

01 Nov '05

> > Ashok Thirumurthi wrote: > > Dear Boost, > > > > The following call stack leads to an access violation when I link a VC 7.1 DLL > > to the release build of the boost signals 1_33_0 DLL. In comparison, > > there is no access violation when I link to the debug build of the same > > library. Similarly, when I add the signals source to my own release > > DLL, there is no access violation. I attempted to disable all compiler > > optimizations in msvc.jam as follows. However, after running bjam -a > > in signals\build and installing the output, the AV still occurs. > > You were commenting out BBv2 code. Boost.Signals is being build with > BBv1 (if you were building it from the boost root), use "bjam -a --v2" > to build with BBv2. Also, you can use: > > bjam -a --v2 optimization=off > > to turn off the optimization? > Thanks. Disabling all optimizations prevents the access violation. > > How can I alter the release build to avoid the access violation? > > > > Access violation reading location 0x00000004 > > (*((k2).content)).__vfptr is 0x00000000 > > > > bool operator()(const any& k1, const any& k2) const > > { > > if (k1.type() == typeid(front_type)) > > return !(k2.type() == typeid(front_type)); > > if (k1.type() == typeid(back_type)) > > return false; > > > >> if (k2.type() == typeid(front_type)) > > This looks to be an issue with either Boost.Any or your code. What is > any::type() returning? Actually, the () operator is crashing with the access violation. When I run without optimizations, k1.type is front_type and k2.type is back_type. If I optimize for speed (/O2), k1.content is null and k2.content.__vfptr is null. So, type() cannot be evaluated. If I optimize for size (/O1), I observe an invalid lock sequence exception (0xC000001E) when constructing a _Tree_ptr. > Have you made sure that RTTI is enabled for everything (including your > own project -- is there a difference in the vcproj Configurations?) Yes. > > Are you doing something in the Debug version that is not in the Release > version? > > Are you linking with the right variant of the boost libraries? Is there > a conflict with the run-time library being used? I can reproduce the problem and the work-around by compiling the boost source into a DLL using a VC++ 7.1 project. Initially, I had used the bjam scripts without any modification after installing the full 1_33 source. I was able to reproduce the problem with boost 1_32. However, I'm not sure how to determine if a conflict exists. Thanks to your advice regarding bjam, I have a work-around in hand, - Ashok > > - Reece > > > > ------------------------------ > > Message: 4 > Date: Sat, 29 Oct 2005 10:43:59 +0100 > From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> > Subject: Re: [boost] Documentation Wizard > To: <boost(a)lists.boost.org> > Message-ID: <E1EVnFw-0007Bf-Oz(a)he304war.uk.vianw.net> > Content-Type: text/plain; charset="us-ascii" > > > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > | Sent: 27 October 2005 23:21 > | To: boost(a)lists.boost.org > | Subject: [boost] Documentation Wizard > | > | Quite some time ago, Dave Abrahams announced that I was the new > | Boost Documentation Wizard. I said I'd write something on the > | subject and that is long overdue. Herewith, I describe what I > | think the DocWiz should do and what is needed from volunteers to > | make it happen. That is, I'm trying to document the new DocWiz > | role and solicit your help. > > My first impression is that this is a bit over-bureaucratic. You obviously > need this sort of style managing 8 offspring ;-) , but Boosters are all > volunteers and we have to be greatful for all the help we can get. > > Authors are severely handicapped when writing documentation by knowing too > much. > > And they are often exhausted by the process of getting the code to work on > the myriad of inconsistent platforms and versions. > > So _any_ documentation editing is likely to be an improvement. > > So I think you should just ask for someone (usually only one - we don't have > _common_ tools for handling versioning and changes well) willing to > contribute to editing each library. The code author and the editor will have > to try to agree: only if they are uncertain should theygo out to the wider > Boost audience. > > Since I have the advantage of having English as my first language (and not > the corrupted version of those renegage ex-colonials ;-), and I have enough > knowledge of other languages to greatly admire those whose first language is > not English struggling with the erudite esoteric elite Boost discussions, I > may offer to edit some documentation. > > HTH > > Paul > > PS And I've read Eats, Shoots and Leaves. > > -- > Paul A Bristow > Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB > Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 > mailto: pbristow(a)hetp.u-net.com www.hetp.u-net.com > > > > > > ------------------------------ > > Message: 5 > Date: Sat, 29 Oct 2005 12:01:29 +0100 > From: "Marcin Kalicinski" <kalita(a)poczta.onet.pl> > Subject: [boost] How to run boost regressions? > To: boost(a)lists.boost.org > Message-ID: <djvkq7$ej5$1(a)sea.gmane.org> > > Hi, > > How can I run boost regression tests at home? > > cheers, > Marcin > > > > > > ------------------------------ > > Message: 6 > Date: Sat, 29 Oct 2005 05:57:41 -0700 > From: "SourceForge.net" <noreply(a)sourceforge.net> > Subject: [boost] [Boost-bugs] [ boost-Bugs-1341560 ] crach build bjam > from mingw 3.4.4 > To: noreply(a)sourceforge.net > Message-ID: <E1EVqHF-00048m-K1(a)sc8-sf-web2.sourceforge.net> > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1341560, was opened at 2005-10-29 19:57 > 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=1341560&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: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Alexandr Zamaraev (shura_zam) > Assigned to: Nobody/Anonymous (nobody) > Summary: crach build bjam from mingw 3.4.4 > > Initial Comment: > OS:Windows XP pro rus + sp2 > gcc: (GCC) 3.4.4 (mingw special) > ld: GNU ld version 2.16.91 20050827 > Source: latest csv > > Command line: > >build.bat mingw > Output (last 3 line): > don't know how to make mingw > ...found 1 target... > ...can't find 1 target... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1341560&group_… > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/boost-bugs > > > ------------------------------ > > Message: 7 > Date: Sat, 29 Oct 2005 06:12:26 -0700 > From: "SourceForge.net" <noreply(a)sourceforge.net> > Subject: [boost] [Boost-bugs] [ boost-Bugs-1341568 ] crach build bjam > from mingw 3.4.4 with python > To: noreply(a)sourceforge.net > Message-ID: <E1EVqVW-0005Zb-Rw(a)sc8-sf-web1.sourceforge.net> > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1341568, was opened at 2005-10-29 20:12 > 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=1341568&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: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Alexandr Zamaraev (shura_zam) > Assigned to: Nobody/Anonymous (nobody) > Summary: crach build bjam from mingw 3.4.4 with python > > Initial Comment: > OS: Windows XP pro rus + sp2 > gcc: (GCC) 3.4.4 (mingw special) > ld: GNU ld version 2.16.91 20050827 > Python: Python 2.4.2 > Source: latest csv > > I try build bjam with python. > Bat I have crach in linking. > > Command line: > >bjam -f build.jam --toolset=mingw > --with-python=C:\Lang\Python24 > > Output (latest 8 lines) > C:\TEMP\Shura/ccaSyaaa.o:builtins.c:(.text+0x334e): > undefined reference to `_imp__PyCallable_Check' > C:\TEMP\Shura/ccaSyaaa.o:builtins.c:(.text+0x337c): > undefined reference to `_imp___Py_NoneStruct' > collect2: ld returned 1 exit status > > "gcc" -o bin.ntx86\bjam.exe -DNDEBUG > -DOPT_HEADER_CACHE_EXT -DOPT_GRAPH_DEBUG_EXT > -DOPT_SEMAPHORE -DOPT_FIX_TARGET_VARIABLES_EXT > -DOPT_IMPROVED_PATIENCE_EXT -DNT -DYYSTACKSIZE=5000 > -DHAVE_PYTHON -s -O3 -finline-functions > -IC:\Lang\Python24\include > "C:\Lang\Python24\libs\python24.lib" command.c > compile.c debug.c expand.c glob.c hash.c hcache.c > headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c > make.c make1.c newstr.c option.c parse.c regexp.c > rules.c scan.c search.c subst.c w32_getreg.c > timestamp.c variable.c modules.c strings.c filesys.c > builtins.c pwd.c class.c native.c modules/set.c > modules/path.c modules/regex.c modules/property-set.c > modules/sequence.c modules/order.c execnt.c filent.c > pathunix.c > > ...failed [COMPILE] bin.ntx86\bjam.exe... > ...failed updating 1 target... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1341568&group_… > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/boost-bugs > > > ------------------------------ > > Message: 8 > Date: Sat, 29 Oct 2005 09:40:28 -0500 > From: Douglas Gregor <doug.gregor(a)gmail.com> > Subject: Re: [boost] How to run boost regressions? > To: boost(a)lists.boost.org > Message-ID: <66D002ED-12FC-40F7-A0AC-BD3AE3A8CA0C(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Oct 29, 2005, at 6:01 AM, Marcin Kalicinski wrote: > > How can I run boost regression tests at home? > > There are some instructions here: > > http://www.boost.org/tools/regression/xsl_reports/runner/ > instructions.html > > Doug > > > > ------------------------------ > > Message: 9 > Date: Sat, 29 Oct 2005 09:51:08 -0500 > From: Douglas Gregor <doug.gregor(a)gmail.com> > Subject: Re: [boost] [GCC 2.95.3] Boost regression notification > (2005-10-28 [HEAD]) > To: boost(a)lists.boost.org > Message-ID: <C805154E-5675-42B4-A0D9-2F42C8920BF1(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Oct 28, 2005, at 5:11 PM, Beman Dawes wrote: > > A lot of these failures are for gcc-2.95.3-linux. Do we care enough > > about > > 2.95.3 nowadays to consider it a release platform? > > I vageuely remember trying to kill GCC 2.95.3 support at one point, > but was convinced otherwise. We could just mark it as unusable on new > libraries/tests that support it but retain backward compatibility on > those libraries that do. > > Doug > > > ------------------------------ > > Message: 10 > Date: Sat, 29 Oct 2005 17:04:16 +0100 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: Re: [boost] [range][1.33.1] last few regressions. > To: <boost(a)lists.boost.org> > Message-ID: <015001c5dca2$7118cab0$6f2e0d52@fuji> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > > In that case we might as well just roll-back the changes from the RC > > branch to > > the main branch. > > There haven't been any changes to the test itself, and the only changes in > the headers appear to be: > http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/range/end.hpp?r1=1.… > and related changes. > > I'd still rather see this fixed than just rolled back (I presume these > changes were in there for a reason?), or we could disable them for broken > compilers if that works (but we need to know why they were in there in the > first place, this could be a fix for VC6/7 for all I know). > > BTW I don't have a Boost source tree (or compiler) to work with at present > to test this out, since I've just replaced my hard drive! > > Hopefully this narrows the problem down a bit? > > John. > > > > ------------------------------ > > Message: 11 > Date: Sat, 29 Oct 2005 12:24:53 -0400 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: Re: [boost] [GCC 2.95.3] Boost regression notification > (2005-10-28 [HEAD]) > To: boost(a)lists.boost.org > Message-ID: <uy84cl296.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > Douglas Gregor <doug.gregor(a)gmail.com> writes: > > > On Oct 28, 2005, at 5:11 PM, Beman Dawes wrote: > >> A lot of these failures are for gcc-2.95.3-linux. Do we care enough > >> about > >> 2.95.3 nowadays to consider it a release platform? > > > > I vageuely remember trying to kill GCC 2.95.3 support at one point, > > but was convinced otherwise. We could just mark it as unusable on new > > libraries/tests that support it but retain backward compatibility on > ^ > don't?? > > > those libraries that do. > > If not "don't," how will we know we're retaining backward > compatibility? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 1260, Issue 1 > ************************************** >

1 0