July 2006 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Feature Requests-1527717 ] [program_options] Allow unrecognized options in configfile
by SourceForge.net 24 Jul '06

24 Jul '06

Feature Requests item #1527717, was opened at 2006-07-24 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1527717&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: Enrico Scholz (ensc) Assigned to: Nobody/Anonymous (nobody) Summary: [program_options] Allow unrecognized options in configfile Initial Comment: It would be nice when the config-file parser would have a similar mechanism to allow and collect unregistered options like the command-line parser. E.g. with the command-line parser I can use the allow_unregistered() method, but config-file parser throws always a boost::program_options::unknown_option exception. I want this feature e.g. to express things like | module = A | module = B | [A] | foo = X | [B] | bar = Y where the options in the [A] and [B] sections are unknown at the first pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1527717&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Quan was [PQS] Roadmap
by Andy Little 24 Jul '06

24 Jul '06

Hi, Since I ultimately intend to resubmit Quan to boost and in light of the recent PQS review, I hope that this message isnt O.T. Note also the Quan mailing list. ( I guess it would be wise to take any followups off the boost developers list) *** Quan Draft Roadmap *** Please note that the views expressed here are my personal views (and possibly ramblings) on the direction that Quan should take. They arent set in stone, so please feel free to argue any points and suggest other directions that the library should take. Also please feel free to add anything else. I have set up a Quan mailing list at quan-matters(a)lists.sourceforge.net. I hope that can be the main vehicle for discussion related to Quan. You can subscribe at: https://lists.sourceforge.net/lists/listinfo/quan-matters Alternatively you can mail me at andy attt servocomm dottt freeserve dottt co dottt uk (Please put something obviously not spamlike as the subject line!) Unfortunately the Quan roadmap isnt as detailed or finished as I would like , but I thought it better to get it out in its current state that not at all. **Personal Philosophy for Quan** Quan is designed simply to make the programmers life easier. The quan::fixed_quantity, available in the Alpha quan release available at: http://sourceforge.net/project/showfiles.php?group_id=170593 is intended to be an example of that philosopy. IMO it wraps up some complicated functionality in a simple entity. The latest state of fixed_quantity is also available via CVS at: http://quan.cvs.sourceforge.net/quan/ (my latest code and docs is currently in the concept_08_July_2006-branch.) The Quan library firstly needs good documentation. Unfortunately good documentation is extremely hard and time consuming to write, but it has to be done for a public library. I hope that the Quan library will be useful for advanced uses, but at the same time I want a library that is designed for use by mere mortals like me too. It may be difficult to reconcile simplicity with advanced Maths, but nevertheless that should be one of Quan's goals. The library also needs to be correct, so alongside documentation there need to be a comprehensive set of Unit tests for any functionality. The library is intended one day to become part of the Boost distro http://www.boost.org, therefore the code, documentation and tests should be written with boost compatibility in mind. ****The Quan project status**** The Quan project uses the boost license: http://www.boost.org/more/license_info.html Quan is dependent on the latest version of the Boost distro http://www.boost.org, which can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=7586 Quan is currently using the CVS version control system. A useful page about using CVS is available here: http://cvsbook.red-bean.com/cvsbook.html If you are interested in working on the Quan project then a reasonable knowledge of CVS will be necessary. The best way to learn the system is to set up a local database and practise on that. (It might also be a good idea to download the Quan code and try it out, to see if you like it!) If boost moves to SVN then Quan will follow after watching their progress, but meanwhile Quan should stay in step with Boost IMO. ** Full functionality ** Quan will need a lot of associated functionality to be useful in real world projects. This to me means it needs firstly vectors and point vectors, and secondly some way to transform them in 2D and 3D. the discussion during the review of PQS on the boost developers list should be a source of inspiration. Maybe 3rd party libraaies can be used, but I havent found them yet and I reckon they will need to be written for Quan. There is an obvious dependence of such functionality on the Concepts of what a Quantity is, so work on the Quan Concepts documentation needs to be considered high priority. ****Quan parts needing immediate attention **** *** quan::fixed_quantity aka pqs::t1_quantity *** Its probably time to stop changing the interface of fixed_quantity for trivial reasons, so fixed_quantity should basically stay as it is unless major issues are found. I believe that the fixed_quantity interface (ie quan::length::mm) is quite stable in overview and has been for some time in its previous incarnation pqs. I have been doing some work on Concepts, docs and improving the low level scaling /unit conversion code, which are currently in CVS on concept_08_July_2006-branch (merged to main trunk today 17/July/2006) . ***The Quan units database*** I have a local database and associated application used for generating the Quan headers and units html. Ideally the database would be on the Sourceforge database system and CGI scripts used to generate headers remotely and possibly add (after human vetting) quantities to the database. My local database application was only designed to generate headers on my own system. Ideally it would be rewritten using maybe DTL http://dtemplatelib.sourceforge.net/ or SOCI http://soci.sourceforge.net/ library. DTL says it provides cross-platform access including Access2000 (my local database) and MySQL (sourceforge database)), which would suit me but, whatever way its achieved, the database should be upgraded and moved into MySQL on Sourceforge. Needs investigating. If anyone is interested I will put the source for my local acccess in the Quan CVS. It is however raw source for Windows without any docs. Once up on Sourceforge the database needs to be filled with quantities and units (and constants). Then it can go about its business of generating headers and documentation. There is also work on a Units database and XML schema by NIST http://unitsml.nist.gov/ The idea of being able to communicate physical quantities across applications is intended to be embodied in UnitsML. This should be taken into consideration in design of the database. The philosophy of UnitsML looks very close to Quan , so compatibility with UnitsML should be mandatory. I think it is also worth getting in touch with the authors of UnitsML and UnitsDB soon too to let them know about the Quan project as a potential application. *** Unit tests ** The unit tests are improving, but still need work. Firstly to be more comprehensive. Some are still just empty functions waiting to be filled in. Another issue is portability. For example in using various Quan default real types, where double is often hard coded, and second in mirroring the exact expression used in the implementation calculation, in the comparison test calculation. The detailed semantics of the fixed_quantity need sorting out so that it should be as predictable as possible. Floating point control and predictability is an important goal and the current release is slightly loose in this respect. It would be nice to take advantage of the Sourceforge compile farm for unit tests. *** Addition of the multiunit_quantity and the uni_quantity to the library*** (Alternative Name suggestions please :-) ) Work on the other 2 quantity types needs to be started. **For the multiunit_quantity** The one that can change its units at runtime. Uses of the multiunit_quantity are intended to be for User I/O Dialog Boxes (or Widgets) and the like. The multiunit_quantity should play well with the fixed-quantity of course. I have a prototype at http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip which I was reasonably happy with and if I write it that will be the approach I will take. Again in http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip there are some examples of this type of use. Working on multiunit_quantity may be tricky until the fixed_quantity implementaion and low level code is more stable however as (at least how I did it) it made much use of the fixed-quantity unit conversion code. **For the uni_quantity** The one that can change its dimension and units at runtime Potential uses for this type are in testing inside matrices, where the type can be switched in for Dimensional Analysis checking and anywhere that a quantity must be created at runtime, maybe for reading from XML or a database for example. I did a quick prototype for a uni_quantity, . The main problem is the size in the obvious implementation. IIRC it used around 60 bytes of memory per object. Maybe that is acceptable, maybe not. An alternative approach might be providing a handle to a hash map of dimensions and units. Anyway this needs to be investigated. ***Quan space*** After the discussions of PQS on Boost the vect <quan/three_d/vect.hpp> needs to be rewritten to cater for 2D 3D etc e.g vect<N,T>. The rationale is to write code that can be used in N dimensional space. I am very keen to get 2D and 3D entities in Quan. Including vectors, homogeneous transform matrices and quaternions. The classic use case for me is representing the airflow around a wind turbine. There are have been various suggestions that third party libraries can be used, but I dont see the libraries and I think Quan will have to provide its own at least to show it can be done. *** Complex quantities*** Again in http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip there is code for a complex quantity. This needs to be ported to Quan. The issues of infinities caused problems in the previous version IIRC, so this needs to be addressed. (Partly my poor maths to blame there) and (as with everything else) a tight spec written, maybe even trying to sort out some of the problems that exist in std::complex, though I dont quite understand what those are. Maybe should be coupled to Quaternions in 3D too... ***Performance testing*** I have done some some very limited performance tests consisting basically of running the <quan_matters/examples/particle.cpp> in VC8 both using quan::fixed_quantities and doubles and comparing the assembler output. It appears that the quan::fixed-quantity version has a couple of extra instructions (mainly when dealing with constants), though the code overall is otherwise nearly identical. Performance tests need to be done on other compilers too of course. The whole area of performance versus inbuilt types needs to be started and documented using as many compilers as possible. *** Checking of calculations for integer overflow, inf etc. *** Because Quan fixed_quantity encapsulates an inbuilt type, it would be a good idea to enable the library also to perform optional runtime checks that calculations arent overflowing or dividing by zero etc. This would make Quan into a more comprehensive suite of error checking capabilities. *** Visualisation *** Visualisation is the IMO the best way to show off Quan library. Maybe a port of yade http://yade.berlios.de/. Anyway Quan needs some sort of 3D/GUI application to show it off. Other useful items are GUI Unit widgets for users to be able to set their own units and so on. Care needs to be taken over licencing issues. *** Stability, Modularity *** At some point When the version changes to Non_zero_x_x, whatever mistakes have been made in the interface spec should be considered embedded, so that the code base for any users is stable. Before that consider the code Alpha only. This will probably mean releasing Quan in modules at least once anything gets into a finished state. IOW fixed_quantity module etc. **What platforms should Quan run on** Wherever possible, the library should be designed to allow for (say) the possibility that an int is 16 bits and so on. I don't think it costs much to do so. **Can Quan be used on large systems?*** The kind of problems Quan is designed to solve get worse in large systems. Again only theoretically currently, but the idea is that it will work well because of the error checking and code documentation features. However quite what happens in large matrices, higher level maths and so on, and so on I don't know and support for these features needs to be written. I think this is an unanswered research question frankly and should be approached with an open mind. It may transpire that such use is impractical. If that turns into a proof that inbuilt types work better then so be it. ***High Performance systems ** Often there is a high performance requirement. For example Geoffrey Irvings work http://graphics.stanford.edu/~irving/ and uJanek Kozickis work http://yade.berlios.de/. Unfortunately Quan is in a no win situation here. It is never going to beat inbuilt types, but there is an underlying requirement that Quan needs to be as good as it possibly can. Even in high performance systems the error checking ability and (hopefully) increased productivity from that may outweigh the cost (if any) in performance. Work also needs to be done on working out how Quan can be switched in for testing and switched out for release too. Work also needs to be done on Quans performance versus inbuilt types with test, results and documentation. *** Documentation Format *** Currently the docs use QuickBook. Other html documentation can be linked in, but Quickbook can produce pdf format and things get sticky if relative links are used. Ideally docs will be in QuickBook but other html formats can be used I guess. It may be desirable to write any Units and contant html into the Quickbook document in Quickbook format (or as XML). (Currently I am using Quickbook 1.1 which is monolithic, but in the boost_1.34.0 distro this should change). ** Website ** Currently the website consists just of the fixed_quantity docs. It should probably provide more general information about the project. If there is any part of the project that you are interested in helping with then please get in touch. If you have any points you would like to make, please feel fee to get in touch with me personally or post to the quan-matters mailing list., regards Andy Little

2 2

[test] --catch_system_errors=no is not working
by Felipe Magno de Almeida 24 Jul '06

24 Jul '06

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! -- Felipe Magno de Almeida

3 3

Changes to the inspect tool
by Gennaro Prota 24 Jul '06

24 Jul '06

Hopefully these are improvements over the status quo. I've added check for unnamed namespaces used in included files. The corresponding switch is '-unnamed' and the suppression tag 'boostinspect:nounnamed'. Moreover I've tightened the license check so that it now detects if the reference text correctly starts with "Distributed under the" instead of "Use, abuse and misuse is regulated by..." etc. etc. The changes are in the CVS head only. I'll leave to Rene to decide if they are worth merging into the RC_1_34_0 branch. Maybe he wants to revert the second change as it generates *a lot* of errors. On the other hand it shouldn't be difficult to setup a script, do the change automatically, and say goodbye forever to this die-hard problem. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

2 1

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

23 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Friday, July 21, 2006 9:30 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] ANN: POCO - C++ Portable Components > > Even though I have used boost libraries for a while, this was > the first time > I read about ACE and POCO. > > > > I've used Java's and C#'s libraries for years wishing > something similar > existed for C++ and POCO seems to be a step in this direction. > > > > Regarding ACE, I haven't read that much. The site kept me > jumping from page > to page and it looked kind of "academic" if you ask me. Yeah we've been looking at POCO since it was mentioned here, and it really does look very good compared to ACE. I think if you wanted more of a framework, you might go with ACE.

4 4

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

23 Jul '06

Boost Regression test failures Report time: 2006-07-23T09:16:10Z 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… 388 failures in 30 libraries algorithm/string (1) concept_check (1) conversion (1) filesystem (5) graph (5) integer (3) io (1) iostreams (33) iterator (1) lambda (2) mpl (17) numeric/conversion (4) numeric/interval (2) numeric/ublas (7) optional (2) parameter (33) pool (3) program_options (19) python (97) random (1) rational (5) serialization (42) signals (16) spirit (11) test (8) tr1 (55) typeof (9) utility (2) utility/enable_if (1) wave (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |conversion| lexical_cast_test: sun-5.8 |filesystem| fstream_test: sun-5.8 mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 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| auto_close_test: sun-5.8 buffer_size_test: sun-5.8 bzip2_test: msvc-7.1 msvc-8.0 sun-5.8 code_converter_test: sun-5.8 component_access_test: sun-5.8 compose_test: borland-5_6_4 sun-5.8 counter_test: sun-5.8 example_test: vc-6_5-stlport filtering_stream_test: sun-5.8 vc-7_1-stlport finite_state_filter_test: cw-9.4 sun-5.8 flush_test: sun-5.8 gzip_test: msvc-7.1 msvc-8.0 sun-5.8 line_filter_test: sun-5.8 newline_test: sun-5.8 pipeline_test: msvc-8.0 sun-5.8 regex_filter_test: sun-5.8 restrict_test: sun-5.8 seekable_file_test: sun-5.8 seekable_filter_test: sun-5.8 stdio_filter_test: sun-5.8 symmetric_filter_test: sun-5.8 tee_test: sun-5.8 wide_stream_test: sun-5.8 zlib_test: msvc-7.1 msvc-8.0 |iterator| is_lvalue_iterator: sun-5.8 |lambda| extending_rt_traits: sun-5.8 operator_tests_simple: sun-5.8 |mpl| apply: sun-5.8 count: sun-5.8 count_if: sun-5.8 equal: sun-5.8 erase: sun-5.8 find: sun-5.8 insert: sun-5.8 insert_range: sun-5.8 lambda_args: sun-5.8 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 partition: sun-5.8 stable_partition: sun-5.8 vector_c: sun-5.8 |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| det: sun-5.8 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 |optional| optional_test: sun-5.8 optional_test_ref: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 sun-5.8 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 sun-5.8 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 sun-5.8 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: sun-5.8 cmdline_test_dll: cw-9.4 sun-5.8 options_description_test: sun-5.8 options_description_test_dll: cw-9.4 sun-5.8 parsers_test: sun-5.8 parsers_test_dll: cw-9.4 sun-5.8 positional_options_test: sun-5.8 positional_options_test_dll: cw-9.4 sun-5.8 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test: sun-5.8 variable_map_test_dll: borland-5_8_2 cw-9.4 sun-5.8 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-4.1.1_sunos_i86pc sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-4.1.1_sunos_i86pc msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-4.1.1_sunos_i86pc sun-5.8 pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-4.1.1_sunos_i86pc sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-4.1.1_sunos_i86pc sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 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_demo_fast_archive: sun-5.8 test_demo_fast_archive_dll: sun-5.8 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_shared_ptr_132_binary_archive: sun-5.8 test_shared_ptr_132_binary_archive_dll: sun-5.8 test_shared_ptr_132_text_archive: sun-5.8 test_shared_ptr_132_text_archive_dll: sun-5.8 test_shared_ptr_132_text_warchive: sun-5.8 test_shared_ptr_132_text_warchive_dll: sun-5.8 test_shared_ptr_132_xml_archive: sun-5.8 test_shared_ptr_132_xml_archive_dll: sun-5.8 test_shared_ptr_132_xml_warchive: sun-5.8 test_shared_ptr_132_xml_warchive_dll: sun-5.8 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 |spirit| bug_fixes: sun-5.8 bug_fixes_debug: sun-5.8 char_strings_test: sun-5.8 char_strings_test_debug: sun-5.8 epsilon_tests: sun-5.8 epsilon_tests_debug: sun-5.8 file_iterator_tests: sun-5.8 file_iterator_tests_debug: sun-5.8 if_p_as_parser_tests: sun-5.8 mix_and_match_trees: sun-5.8 while_p_as_parser_tests: sun-5.8 |test| basic_cstring_test: sun-5.8 boost_check_equal_str: sun-5.8 foreach_test: sun-5.8 ifstream_line_iterator_test: sun-5.8 output_test_stream_test: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport token_iterator_test: sun-5.8 |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 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-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_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 std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 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-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_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 test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 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 template_tpl_emulation: sun-5.8 |utility| addressof_test: sun-5.8 operators_test: gcc-3.4.5_linux_x86_64 |utility/enable_if| lazy: sun-5.8 |wave| test_re2c_lexer: sun-5.8

1 0

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