- Boost - lists.boost.org

using lu_substitute
by arun.s 23 Jul '06

23 Jul '06

Hello, Iam trying to use lu_factorize and lu_solve for solving a linear system Ax= B where matrix A has entries of type double and vector B entries of type point ( a simple class wrapping double [3] ) but I get compiler errors in in_place_solve ( all of the overrides have this problem) BOOST_UBLAS_CHECK (e1 () (n, n) != value_type (0), singular ()); apparently this expects that "double" and "point" are comparable using != operator. The problems disappear if I change the line to BOOST_UBLAS_CHECK (e1 () (n, n) != E1::value_type (0), singular ()); but I leave it for the experts to give me the correct solution. PS : I tried to switch to MTL after this, but it too, had the same problem. Thanks, Arun

1 0

Naming integer, real and either template types
by Paul A Bristow 23 Jul '06

23 Jul '06

I am writing template math functions. Some can take integral types (only) Some can take real (both built-in floating-point - float, double.. AND User Defined real types) And some can take either integral OR real. Real : Floating-point types Integer : Integral types Arithmetic : Either Integral OR Floating-point types Arithmetic is a bit long - other ideas? So to write a function something like template <class RealType> RealType students_t(ArithmeticType degrees_of_freedom, RealType t) { ... } Using just T is not an option because there are three (at least) possibles. What names should I use for the types? RealType, real_type, RealT, or RT, or ??? IntType, int_type, IntT, IT, or ??? ArithmeticType, arithmetic_type, ArithType, arith_type, AT ??? Suggestions for names please. Rationales? Prior art? Precedents? Standards? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

3 3

Re: [boost] Please don't define a fake "operator<"justfor orderedcontainers
by Martin Bonner 22 Jul '06

22 Jul '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 11 July 2006 12:21 To: boost(a)lists.boost.org Subject: Re: [boost] Please don't define a fake "operator<"justfor orderedcontainers > Martin Bonner wrote: >> ----Original Message---- >> From: boost-bounces(a)lists.boost.org >> [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov >> >>> Daryle Walker wrote: >>> >>>> [1] If you make a fake order for "std::complex<>", would you >>>> compare real components then imaginary components, or would you use >>>> magnitude then angle? >>> >>> Real, then imaginary. Compare with: >> >> Interesting. I would have chosen magnitude and then angle. Why >> components. > > There are two reasons for that. First, composite types use > lexicographical ordering by default, and std::complex is > (de facto) a (real, imag) pair. > Second, the magnitude/angle ordering has the property that if you > have three numbers a, b, c, where a and b are very close to one > another but not to c, it is possible to have a < c and c < b. That is true for your comparison too. Consider a=-1, b=+1, c=10000i. >>> "If you make a FAKE order for std::string, would you compare left to >>> right or right to left?" >> >> I don't think that is a legitimate comparison. In my world view, >> strings have a natural order but complex numbers don't. > > Possibly. So you define "fake" as "unnatural", and define "natural" as > "feels natural to me". > This approach can work but it's a bit subjective, isn't it? Yes. > Consider the progression: > > complex<double> > struct { double x, double y; } > pair<double, double> > tuple<double, double> > vector<double> > vector<char> > string > > If we take the "feel" of operator< out of the equation, where should > we draw the line, and based on what? complex<double> should not have an operator <() because it models a mathematical concept (complex number) for which "less than" does not make sense. struct, pair, and tuple should not have an operator < because they are essentially unordered collections of data (I know that the elements of pair are called first and second, but it seems to me that they are essentially arbitrary labels). vector is an interesting case. Some vectors are used to store lists of things (in which case ordering makes sense), but others are used to model things like mathematical vectors (in which case we are back to the complex case, and < does not make sense). string definitely should have operator <() because it models the real world concept (string of letters and other characters) for which "less than" definitely makes sense. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

6 13

[integer] endian-0.6 posted w/ names changed
by Beman Dawes 22 Jul '06

22 Jul '06

endian-0.6.zip has been posted in the integer directory of the file vault at http://boost-consulting.com/vault/ The only important change is that I finally came around on the names, and changed from byte-count oriented names to bit-count oriented names. What finally swayed me was some code I wrote that mixed endian typedefs with cstdint typedefs. It was jarring to see both naming conventions intermixed in the same source files. Yet this will be the most common use pattern. So the change has been made. --Beman

1 0

Boost regression notification (2006-07-22 [RC_1_34_0])
by Douglas Gregor 22 Jul '06

22 Jul '06

Boost Regression test failures Report time: 2006-07-22T08:12:13Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 216 failures in 23 libraries algorithm/string (1) concept_check (1) filesystem (2) graph (4) integer (3) io (1) iostreams (10) mpl (7) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (30) pool (3) program_options (9) python (25) random (1) rational (4) serialization (30) signals (16) test (2) tr1 (47) typeof (7) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport |graph| adjacency_matrix_test: vc-7_0 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_tru64 hp_cxx-71_006_tru64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_tru64 hp_cxx-71_006_tru64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport tr1_has_trivial_destr_test: borland-5_6_4 tr1_has_virtual_destr_test: borland-5_6_4 tr1_tky_function_type_test: borland-5_6_4 tr1_tky_incomplete_type_test: borland-5_6_4 borland-5_8_2 tr1_tricky_add_pointer_test: borland-5_6_4 |typeof| function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] ANN: POCO - C++ Portable Components
by Sohail Somani 22 Jul '06

22 Jul '06

> This is something that could be part of boost.process which > is an SOC project > in the works now: > > https://boost-consulting.com:8443/trac/soc/wiki/process > > > Julio and I have at least discussed that this could either be > part or an > extension of the core library -- see the bottom of: > > https://boost-consulting.com:8443/trac/soc/wiki/process/Design > Thoughts/Discussion > > If you really want to see this functionality it would be good > to say so. > > Jeff Personally, I think boost should refrain from the bloat that is inevitable from "Hey this library does XYZ, we should have a boost library that does it". I'm happy with the direction boost is going in (if that counts for anything). I look to boost to solve data structure related problems for me where C++ lacks, less so for other things that a full library like POCO can provide. Sohail

3 2

CVS notification e-mails
by Gennaro Prota 22 Jul '06

22 Jul '06

Hi, I currently follow CVS activity through gmane.comp.lib.boost.cvs. Unfortunately for two days now it is completely stopped, and last message I can see there is: RCS file: boost/libs/date_time/xmldoc/exclusive_date_time.xml,v (...) diff -u -d -r1.1 -r1.2 --- exclusive_date_time.xml 8 May 2005 18:55:39 -0000 1.1 +++ exclusive_date_time.xml 20 Jul 2006 15:55:16 -0000 1.2 I wonder if the problem concerns gmane or the mailing list itself (or my news server, or...?). Any clue? Is anyone else experiencing the same issue? -- [ Gennaro Prota, C++ developer for hire ]

1 0

Re: [boost] ANN: POCO - C++ Portable Components
by Sohail Somani 22 Jul '06

22 Jul '06

My colleague just showed me a very concise example of how he created a service that can be registered with Windows. The same code works for Unix as well. I don't think there are any boost libraries that can do this yet. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Cliff Green > Sent: Friday, July 21, 2006 3:10 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] ANN: POCO - C++ Portable Components > > I've only quickly scanned the POCO web page, but it > appears that there is quite a bit of overlap with Boost > (and will be even more overlap in the future). In > particular: > > - Threading (existing in Boost, with upcoming > enhancements) > - Network programming (Asio, in upcoming release) > - Streams, Filesystem (FS and Iostreams already in Boost) > - Shared libraries, loading (talked about but not in > Boost) > - Logging, error reporting (submitted but rejected, > promised for future Boost review) > - Security (not sure if any overlap with Boost) > - XML parsing (talked about, urgently needed in Boost, > IMO) > - Configuration file, options handling (Program Options > already in Boost, Property Tree in future release) > > It might be interesting to compare interfaces, > functionality, and semantics, however. Or see if parts of > the POCO components should be reworked as needed and > submitted for review to be part of Boost. > > ACE is a very mature, capable, and well-tested set of > libraries (despite the initial appearance of some web > pages). It has some real advantages (and some > disadvantages, mostly dealing with it's age, since it's > vintage is close to 15 years). I and others have made > comments and given short overviews of ACE in previous > Boost postings, so a search through the Boost archives > would help. ACE and Boost are quite different in > interfaces and approach, so there's not much (if any) mix > and match between the two (parallel co-existence works > just fine, as I can attest to from experience). > > Cliff > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

4 3

[BGL] Is it a doc error?
by Wang Weiwei 22 Jul '06

22 Jul '06

Hello, In the BGL doc @ http://www.boost.org/libs/graph/doc/graph_coloring.html There's a function with name 'smallest_last_ordering', in which there's a line of code: degree_buckets.push(*v); but I cannot find where is 'degree_buckets' declared. What's wrong? By the way, is there any sample code that is using this function? Thanks Max

1 0

Re: [boost] [test] --catch_system_errors=no is not working
by Sohail Somani 22 Jul '06

22 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Janek Kozicki > Sent: Friday, July 21, 2006 5:33 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [test] --catch_system_errors=no is not working > > > Hi, > > > > I cant make --catch_system_errors=no to work at all! Not even > > disabling asynch-exceptions I could make it to call a debugger. My > > debugger configuration is fine, I tested it with naked > programs and it > > works ok! > > If it works with naked, then add clothes until it stops working ;p *throws tomatoes*

1 0