- Boost - lists.boost.org

[thread] new & improved tss_hooks.cpp
by Peter Dimov 24 Jul '06

24 Jul '06

I've attached a proposed simplification of libs/thread/src/tss_hooks.cpp that eliminates the one-time allocation that's been bugging people because their tools report it as a leak. If there are no objections, I'll commit this change to the CVS HEAD.

2 7

program_options windows assertion
by Ryan, Paul L. 24 Jul '06

24 Jul '06

I'm working on a program with which we are using the boost::program_options module and ran into an odd assertion in the xstring library used by said module. The program was compiled using VC++ 8 and the Platform SDK Windows Server 2003 SP1. The assertion occured when the total string length (spaces + options + arg defaults + description) was over about 80 characters and was not formatted with a \n or the like. The assertion was xstring:173 ("_Myptr + _Off <=(((_Mystring *)this->_Mycont)->_Myptr()+((_Mystring *)->_Mycont)->_Mysize)&&+_Off >= ((_Mystring *)this->_Mycont)->_Myptr()", 0). and a call stack on one of the programs this occurred on can be seen below. This has occurred for a number of applications we have that all have the same condition. Thank you in advance for your assitance > IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator+=(int _Off=-1) Line 171 + 0x78 bytes C++ IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator-=(int _Off=1) Line 188 C++ IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator-(int _Off=1) Line 193 + 0xc bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_paragraph(std::basic_ostream<char,std::char_traits<char> > & os={...}, std::basic_string<char,std::char_traits<char>,std::allocator<char> > par="Used to specify the debugged namespaces", unsigned int first_column_width=41, unsigned int line_length=79) Line 381 + 0x28 bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_description(std::basic_ostream<char,std::char_traits<char > > & os={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & desc="Used to specify the debugged namespaces", unsigned int first_column_width=41, unsigned int line_length=79) Line 453 + 0x34 bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_one(std::basic_ostream<char,std::char_traits<char> > & os={...}, const boost::program_options::option_description & opt={...}, unsigned int first_column_width=41, unsigned int line_length=80) Line 489 + 0x1a bytes C++ IMNManager.exe!boost::program_options::options_description::print(std::basic _ostream<char,std::char_traits<char> > & os={...}) Line 522 + 0x1e bytes C++ IMNManager.exe!boost::program_options::operator<<(std::basic_ostream<char,st d::char_traits<char> > & os={...}, const boost::program_options::options_description & desc={...}) Line 289 C++ Paul Ryan SAIC

1 0

[asio] Modified SSL client to reproduce error
by Scott 24 Jul '06

24 Jul '06

> Can you please try the diffs included below and let me know how > it goes. Thanks! > > Cheers, > Chris Thanks for the update Chris. Is there a way I can just download the changes? I don't have a tool that can take your diffs and recreate the file. And I'm not sure I actually have the same version of the file you are diffing against. I wouldn't mind downloading the latest and greatest ASIO for Boost, if you could point me to that. :) Thanks, Scott

2 1

[system] - std::terminate() called after throw system_error
by Oliver.Kowalke＠qimonda.com 24 Jul '06

24 Jul '06

Hi, I tried boost::system-0.2.1 out. If I execute: int main( int argc, char *argv[]) { ... sys::error_code ec( EINTR, sys::errno_ec); sys::system_error se( ec); printf("%s\n", se.what() ); throw se; // terminate() called ... } std::terminate() and std::set_unexpected are called. What is going wrong? regards, Oliver

1 0

Changing the arrangement of files within our SCM
by Daryle Walker 24 Jul '06

24 Jul '06

Maybe this could be done when/if we move to Subversion, because of SVN's superior directory management. A lot of our testing and other management of Boost code is done on a per library basis. However, the product delivered to users is in a consolidated file hierarchy. The current CVS archive of the code is kept in that same hierarchy. I propose changing the version of Boost kept in our SCM system to be library based. The hierarchy could be like: General any array ... config conversion crc date_time ... variant wave Where each directory would have its own "boost" and "libs" subdirectories. (And maybe a "src" directory if we use this opportunity to move mandatory source code to a higher level.) The "General" directory is for all the administration and other files that are not part of any library. We could move each tool (e.g. BCP, Quickbook, inspect, build, etc.) to this level too. We would have to rename the directory for the Wave tool to "wave-tool" to minimize confusion. For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed. Building changes radically for developers _of_ Boost code, though. They have to add the include directories for each library separately into their compiler/IDE search list. It sounds like harder work, but it's actually a good thing because it forces us to consider dependencies between libraries. It allows us to analyze each library separately. Each library can also be downloaded separately (with CVS/SVN), like we used to do a long time ago with ZIP files. I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

5 9

License reference text
by Gennaro Prota 24 Jul '06

24 Jul '06

Hi, just a quick note to remind you that the preferred text to refer to our license is not "Use, modification, and distribution are..." but // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) The "distributed under" incipit avoids any mention of what actions are subject to license and what not, which is a specification belonging to the license itself. Bibliography ;-) - <http://lists.boost.org/Archives/boost/2004/02/61200.php> -- [ Gennaro Prota, C++ developer for hire ]

4 10

[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