- Boost - lists.preview.boost.org

RE: [boost] Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

Doug Gregor wrote: > On Jul 14, 2004, at 9:06 AM, Klaus Nowikow wrote: > > This leads to the question: are different versions of the boost > > libraries compatible with each other? Can I use a newer version of > > boost > > in future additions to our system and expect them to work > together or > > will > > we have to rebuild the whole system when we decide to use a > new version > > of boost? > > We typically try to retain source-level compatibility between Boost > versions, but make little or no effort to retain the binary > compatibility that you would need. The basic problem is that merely > breathing on a template metaprogram breaks binary compatibility, and > nearly every Boost library requires some form of metaprogramming. You > will probably have to standardize on a particular Boost version, > compiler, and standard library :( I thought so. I will have to discuss this with my co-workers, but I think we will be able to deal with this -- by staying with one version for several boost release cycles. The real problem is that every new boost version brings interesting new features, and it's terribly hard to keep my hands off them ;-) -- Klaus

1 0

RE: [boost] Re: method deduction (on vc?)
by Max Khesin 14 Jul '04

14 Jul '04

But not (from your phrasing) function members? thanks. > > You can detect type members on vc6. See mpl/aux_/has_xxx.hpp. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

My company is currently developing a new set of software packages (applications, static and dynamic libraries) that are all expected to work together (i.e., the libraries will be linked to more than one of the applications, and the libraries will interoperate and depend on one another). In addition, the system has to be extensible, i.e. new DLLs will be added in the future without requiring to rebuild the other components. I use many parts of the boost libraries, not only for the implementation details, but also in the interfaces of the libraries (e.g. the iterator adaptors, type_traits, call_traits, variant, mpl...). This leads to the question: are different versions of the boost libraries compatible with each other? Can I use a newer version of boost in future additions to our system and expect them to work together or will we have to rebuild the whole system when we decide to use a new version of boost? I don't expect a definite answer to this complex question, but is it possible to estimate how likely it is that newer versions of boost will require us to rebuild all? Best regards, Klaus

3 2

Re:[boost] [1.32 release] TODO list synchronization
by Robert Ramey 14 Jul '04

14 Jul '04

Aleksey Gurtovoy wrote: >As we are coming closer to the branch-for-release date, I'd like to inquire >developers working towards the release about the current status of their >corresponding TODO items below. Simply replying to this message and saying >"Done", "Not done, will be done by date X", "Abandoned" or whatever you >wish to say on each of the items would be more than fine. >> Serialization >> ///////////// > >> Robert Ramey writes: > > a) post version compatible with 1.31 next week. Done > b) build and test against the CVS tree on my computer. Done > c) check in Done I've tested against the latest CVS on my own machine with satisfactory results. The compilers I've tested are: 1) MSVC 7.1 2) MSVC 6.0 3) Borland 5.51 4) Borland 5.60 5) gcc 3.3 under cygwin 6) gcc 3.4 on linux (draft #20) has been tested on linux with good results I haven't seen any test results from boost test servers for the serialization library - I expect to see some soon. If past experience is any guide - any platform NOT on the above list will have at least a few issues. d)? marking platforms to skip. I expect to mark Commeau as not useable due to a problem I have pending. I might revisit it if I have time. I would also expect to mark gcc 2.95 as not worth the effort as 3.3+ is a free upgrade. I'm still undecided about this - I'm a little burned out on this sort of stuff after addressing MSVC 6.0 and Borland. As to whether or not you want to include it in the branch, I would withhold judgment pending outcome of the first rounds of "official" test. The you can decide whether or not it should be included. There are no new features to add or document for this release. Anything not in there now would be slated for a subsequent release. This includes autolib, boost.book among other things. Robert Ramey

4 4

RE: [boost] Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

Michiel Salters wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org]On Behalf Of Klaus Nowikow > > Sent: woensdag 14 juli 2004 16:07 > > To: boost(a)lists.boost.org > > Subject: [boost] Compatibility between boost versions > [SNIP] > > > I don't expect a definite answer to this complex question, but is it > > possible to estimate how likely it is that newer versions of boost > > will require us to rebuild all? > > It's in the FAQ: D'oh! Thank you. -- Klaus

1 0

RE: [boost] Compatibility between boost versions
by Michiel Salters 14 Jul '04

14 Jul '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Klaus Nowikow > Sent: woensdag 14 juli 2004 16:07 > To: boost(a)lists.boost.org > Subject: [boost] Compatibility between boost versions [SNIP] > I don't expect a definite answer to this complex question, but is it > possible to estimate how likely it is that newer versions of boost > will require us to rebuild all? Expect rebuilds. It's in the FAQ: --- How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the CVS repository. --- Regards, -- Michiel Salters Consultant Software Engineering LogicaCMG RTSE1, the Netherlands Michiel.Salters(a)logicacmg.com This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[1.32 release] Regressions clean-up
by Aleksey Gurtovoy 14 Jul '04

14 Jul '04

According to http://tinyurl.com/25ar3, the following libraries appear to be in a particularly untidy state: - Date/time, http://tinyurl.com/563b7 - Filesystem, http://tinyurl.com/4kshr - UBLAS, http://tinyurl.com/3vwcz - Thread, http://tinyurl.com/4s58j Also, most of the new libraries, namely - algorithm/string - numeric/conversion - range - program_options are either missing explicit markup, or unexpectedly failing. I'd appreciate if the corresponding library authors / maintainers (or simply volunteers) looked over these failures and cleaned things up a little, brigning us closer to the sacred "all green" field. Thank you, -- Aleksey Gurtovoy MetaCommunications Engineering

5 6

re [1.32 release] TODO list synchronization
by Michael Stevens 14 Jul '04

14 Jul '04

> uBLAS Done Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 4

Regression testing goes horribly wrong! (+ patch)
by Guillaume Melquiond 14 Jul '04

14 Jul '04

Hi, If you take a look at the regression logs [1], you will see a few problems. First, a lot of test types [2] are missing. The "bind" or "date-time" libraries don't have any value in the test type column. Other libraries like the "array" library do have values in this column, however. Second, the name of some "nested" libraries are wrong. For example, the "algorithm/string" is shown as "algorithm", the "numeric/conversion" and "numeric/interval" libraries are both mixed under "numeric". But the "numeric/ublas" is correctly named. Third, expected failures are not correctly shown in the advanced regression logs [3] since some library names are wrong. Fourth, some libraries are compiled in the wrong directories. Instead of being compiled in "bin/boost/libs/whatever/test/something.test", they are directly compiled in "bin/boost/status/something.test" [4]. If you run the regression tests, you will see what I mean. It's quite possible that the problems for the first three points are related to the fourth. Indeed, it seems only libraries wrongly compiled in "bin/boost/status/something.test" get to be correctly identified. It's the case for the "array" and "numeric/ublas" libraries for example. I don't understand how regression testing takes place into Boost. From my humble point of view, it is quite a mess. I didn't understand why some libraries were compiled in the wrong place; I suppose it has to do with bjam and their Jamfiles. I did however find a way to correct the first two bugs (and probably the third). The test_log.xml are indeed wrongly generated by process_jam_log. So here is a patch to process_jam_log.cpp so that it correctly generates the test_log.xml files. Unfortunately I don't understand at all some parts of this program, so I only corrected what seemed obviously wrong to me. But maybe the bugs were somewhere else and I only designed a lame workaround? Could the author of these lines shed some light on what their purpose was supposed to be? In the meantime, maybe the regression testers could clear their "bin" directory (so that all the test_log.xml are created from scratch) and apply the patch? Since Boost 1.31 is supposed to ship in less than 20 days, it would be great if the regression logs were correctly generated. Thanks. Best regards, Guillaume [1] For example, a small regression log: http://boost.sourceforge.net/regression-logs/cs-AIX.html All recent regression logs are affected. [2] "run", "compile", "compile_fail", etc [3] Some of the yellow cells should actually be gray in this log: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/su… [4] For example, look at the compile line used for: http://boost.sourceforge.net/regression-logs/cs-AIX-links.html#lambda-bll_a… Index: process_jam_log.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/process_jam_log.cpp,v retrieving revision 1.25 diff -u -r1.25 process_jam_log.cpp --- process_jam_log.cpp 28 Jun 2004 03:04:21 -0000 1.25 +++ process_jam_log.cpp 9 Jul 2004 17:38:59 -0000 @@ -241,11 +241,11 @@ } test_info info; - test2info_map::iterator itr( test2info.find( library_name + "/" + test_name ) ); + test2info_map::iterator itr( test2info.find( test_name ) ); if ( itr != test2info.end() ) info = itr->second; - if ( library_name.empty() ) + if ( !info.file_path.empty() ) library_name = test_path_to_library_name( info.file_path ); if ( info.type.empty() ) @@ -511,8 +511,6 @@ line.find( "\"", pos+3 )-pos-3 ); convert_path_separators( info.file_path ); if ( info.file_path.find( "libs/libs/" ) == 0 ) info.file_path.erase( 0, 5 ); - if ( test_name.find( "/" ) == string::npos ) - test_name = "/" + test_name; test2info.insert( std::make_pair( test_name, info ) ); // std::cout << test_name << ", " << info.type << ", " << info.file_path << "\n"; }

5 17

Functors and Boost::MPL
by Dan 14 Jul '04

14 Jul '04

It occurs to me that it should be possible to manage an mpl::vector of types which are actually functors. One could add functors to this list with compile time complexity and likewise call all the functors in the list with compile time complexity. Requiring none of the function pointers, class templates, or virtual functions typically used for this purpose. I think it should be easy to create the vector, but how does one construct an object of each type and call operator() on it? -Dan "The only impossible task is the task you never start"

2 1