- Boost - lists.boost.org

Re: [boost] [1.33.1 Beta] Release is imminent
by BRIDGES Dick 02 Nov '05

02 Nov '05

Maybe we should wait until Thursday or Friday if we can. Regards, Dick "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: Tuesday, November 01, 2005 10:20 AM > To: boost(a)lists.boost.org > Subject: [boost] [1.33.1 Beta] Release is imminent > > > We now have zero failures on the RC_1_33_0 branch. The > RC_1_33_0 is now > closed for all commits: write to me *directly* if there is something > that absolutely must go into the 1.33.1 release. I will be > rolling the > release tarballs shortly. > > Doug > > On Nov 1, 2005, at 12:00 PM, Douglas Gregor wrote: > > > Boost regression test failures > > ------------------------------ > > Report time: 2005-11-01T14:47:09Z > > > > This report lists all regression test failures on release platforms. > > > > Detailed report: > > > > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ > > developer/issues.html > > > > 0 failure in 0 library: > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Proposal: XML APIs in boost
by Shawn Halpenny 02 Nov '05

02 Nov '05

On 11/1/05, Suman Cherukuri <suman(a)cherukuris.net> wrote: > Xerces has good C++ support. I'm not sure if this discussion is about > extending 'C' based XML parsers like libxml2 and Expat to provide C++ > interface or to have a whole new XML parser within Boost. If it is later, > Why? I agree with Doug Gregor, that something like parsing can be offloaded onto another library like Xerces/libxml2/etc, so I think the value of discussion is in the manipulation and navigation within an XML document. That's where modern C++ techniques could really be applied to great effect. My 2 cents worth regarding the XML libs I've used: Xerces has a bunch of C++ classes ensconced in namespaces, but it feels like a C API dressed up in C++. There is zero in the way of common C++ abstractions for manipulating or accessing a document. It just felt laborious to use--I couldn't escape the thought of "if you're going to write it in C++, how about actually using C++?" With libxml2 I didn't have the "C++ expectations" because it's an all-C API. I still found myself doing the same lower-level node memory-management stuff I had to deal with in Xerces, but I wrote a few brain-dead simple wrapper classes for just the functionality I needed and everything felt so much easier. I suppose the difference is that I expected a whole suite of well-designed wrapper classes along with Xerces and felt let down that they didn't exist. (Plus, I needed RelaxNG schema and XPath support, neither of which Xerces had). -- Shawn Halpenny

1 0

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