- Boost - lists.boost.org

[iostreams] test/Jamfile.v2
by Vladimir Prus 26 May '05

26 May '05

Hi Jonathan, if I to to libs/iostreams/test and run "cvs log Jamfile.v2", I get this: revision 1.3 date: 2005/05/02 21:20:04; author: turkanis; state: dead; lines: +0 -0 obsolete What does that mean? The log message says next to nothing, and the file removal basically breaks my V2 testing. Not to mention that it took me a while to realize the file is removed in CVS. If you modified Jamfile in some way and did not want to update Jamfile.v2 (and you don't have to, until V2 is official), you could simply drop me a note. Or you could do nothing, since as soon as I'll do another V1 vs. V2 test results comparison I'll see the difference and update Jamfile.v2 myself. Where there any specific reason for removal? - Volodya

2 2

RE: [boost] Customer Friendlier Boost Installation
by Victor A. Wagner Jr. 26 May '05

26 May '05

At 14:30 2005-05-25, Bennett, Patrick wrote: >[delete] >[Bennett, Patrick] Personally, I think the pragma 'link' options are an >absolute disaster for large projects. apparently you've worked with different folks than I. Likely, different kinds of "large projects", too. >It's far, far too easy to end up with lots of libraries getting linked >in with users having no idea how or why they're being linked against. >Since many developers tend to be rather over-eager in #including headers >(bah, just include it all!) sounds like "many developers" need to be re-edcuated. or, perhaps, you need better code walkthroughs. > it's quite common for library x to include >library y which happens to include library z. Users then wonder why >their application is suddenly dependent on libraries they never even >'use'. >Libraries linked against should always be completely explicit IMO yeah, I woulda bought that right up until Microsoft introduced incompatible options in their silly "see 8 things at a time" _GUI_ option settings (property pages). BTW, those are a perfect example of why I dislike GUI for most things, it gets abused horribly (yeah I know, let's just educate people how to write them correctly). > (or >managed by a build system that documents the dependencies). When the >linkage is explicit, the cases where libraries have too many >inter-dependencies (usually incorrect) tend to get fixed pretty quickly. > >Patrick Bennett > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

RE: [boost] Customer Friendlier Boost Installation
by Bennett, Patrick 25 May '05

25 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Victor A. Wagner Jr. > Sent: Wednesday, May 25, 2005 3:42 PM > To: boost(a)lists.boost.org; boost(a)lists.boost.org > Subject: Re: [boost] Customer Friendlier Boost Installation > > At 04:13 2005-05-25, Stuart Dootson wrote: > >[deleted] > >One final point - whoever came up with the autolinking scheme (think > >it was John Maddock?) - thank you very much - that makes life *so* > >much easier! > > Yes, it does! > It's a wonder that the committee didn't insist long ago that there be a > directive in the language which would pass a name(file?) to the linker for > processing. It's not like we haven't been fighting this problem since the > late 1970s and it's still a compiler specific thing. Kinda makes you > wonder exactly what things the committee deems important, and why (we > STILL > don't have #pragma once as a "standard" requirement). [Bennett, Patrick] Personally, I think the pragma 'link' options are an absolute disaster for large projects. It's far, far too easy to end up with lots of libraries getting linked in with users having no idea how or why they're being linked against. Since many developers tend to be rather over-eager in #including headers (bah, just include it all!) it's quite common for library x to include library y which happens to include library z. Users then wonder why their application is suddenly dependent on libraries they never even 'use'. Libraries linked against should always be completely explicit IMO (or managed by a build system that documents the dependencies). When the linkage is explicit, the cases where libraries have too many inter-dependencies (usually incorrect) tend to get fixed pretty quickly. Patrick Bennett

1 0

Re: [boost] Re: [repost][serialization] autolinking
by JOAQUIN LOPEZ MU?Z 25 May '05

25 May '05

Hello Robert, ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Mayo 25, 2005 6:02 pm Asunto: [boost] Re: [repost][serialization] autolinking > Its not a policy that including serialization trigger autolinking. > If it > currently does, it contravenes my intention. When I last looked > at this I > wasn't convinced this was actually happening. I took precautions > to avoid > this and felt it was addressed. Your detailed investigation > motivates me to > look again and more carefully. It is also helpful for showing me > where to > look. I'll do this. Thanks for sheding light on this. > > I've been a little bogged down in this area as now the auto- > linking of DLLS > on vc6 and vc7 stopped working. I'm not sure why this is. Its > only a > problem on with these compilers. I'm still bogged down on this. > Good to know you're on it. If you need to do some fast testing on MSVC++ 6.0, I've got that environment available --just drop me a line and I'll try to lend a hand. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[test] Confusion about BOOST_CHECK_CLOSE
by Jody Hagins 25 May '05

25 May '05

I have re-read everything I can find about BOOST_CHECK_CLOSE, and the doc on floating point comparison algorithms (i.e.close_at_tolerance). However, I am still confused about how to use BOOST_CHECK_CLOSE. Could we have some clear examples of comparisons that pass/fail with different tolerance settings, and some explanation as to how changing the tolerance may affect the test? Currently, I have a test, using BOOST_CHECK_CLOSE() which passes, no matter how big/small I set the tolerance; yet the values are different. Thanks!

3 5

[repost][serialization] autolinking
by Joaquín Mª López Muñoz 25 May '05

25 May '05

Allow me to repost a digest of my last two messages about the issue of autolinking in Boost.Serialization. If the final decision is to *not* adhere to my proposed policy, I'd be grateful to know asap, so that I can hack my way in my own source code. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----------------------- I humbly request that you reconsider your design so that the following guarantee is honored: * (A) Any code including *only* boost/serialization/*.hpp headers won't trigger autolinking of Boost.Serialization. The following is a rationale for this policy: a 3rd party library that provides *intrusive* serialization capabilities will most likely need to include some of boost/serialization/*.hpp. If those headers trigger autolinking, the user will face the annoying fact that Boost.Serialization is autolinked even if she didn't explicitly try to use serialization at all. Granted, if the serialization capabilities of the 3rd party library are not taking advantge of, autolinking will ultimately have no effect on the final binary, but the point is that the user will be forced nonetheless to have the Boost.Serialization lib built and available. This is most unfortunate in the case the 3rd party library is a header-only lib, since the user may very well be using it without having built anything from Boost. This is exactly what's happening now with Boost.MultiIndex. Autolinking is triggered by the (implicit) inclusion of boost/serialization/config.hpp. This header is in turn included by void_cast.hpp and extended_type_info.hpp, and if you pull out from this thread it turns out virtually any boost/serialization/*.hpp header will trigger autolinking. To honor (A), you just have to remove the inclusion of boost/serialization/config.hpp by the aforementioned void_cast.hpp and extended_type_info.hpp. From what I can see, the inclusion is done so as to bring in the definition of BOOST_SERIALIZATION_DECL, so in principle having this macro defined in a separate header would suffice. If (A) is honored, autolinking will be triggered only when including boost/archive/*.hpp headers, which IMHO is just fine, since these are a sure sign that the user (not the 3rd party library) is explicitly requesting serialization capabilities and will welcome the autolinking stuff. I have inspected the source code and looks like autolinking is triggered in three points: boost/serialization/config.hpp boost/archive/detail/auto_link_archive.hpp boost/archive/detail/auto_link_warchive.hpp So, it seems like my proposal boils down to removing autolinking from the first header. As a proof of concept, I've done so (see attached modified source); with this changes in place, my local tests seem to indicate that: * Autolinking does not kick in if including only boost/serialization/*.hpp headers. * Autolinking still works if including any of boost/archive/*.hpp. boost/serialization/config.hpp has a local macro named IMPORT whose semantics escapes me, so I might be missing something.

2 1

RE: [boost] Re: Customer Friendlier Boost Installation
by Martin Bonner 25 May '05

25 May '05

----Original Message---- From: Jason Earl [mailto:Jason@hybd.net] Sent: 25 May 2005 14:37 To: boost(a)lists.boost.org Subject: Re: [boost] Re: Customer Friendlier Boost Installation > After all anyone with experience with > Unix will realise how much of an advantage a shell is So? What about the very large number of professional programmers who have no experience of Unix, and are too young to have had to wrestle the user-hostile environment that was the DOS command line. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[Program options] Borland, VC7 failures?
by Doug Gregor 25 May '05

25 May '05

The majority of the program_options tests on these compilers are failing. I see that other similarly-broken configurations (VC6, VC6 with STLport) are marked unusable. Will program_options work on these compilers or should it be marked unusable? Doug

2 1

[integer] patch for MSVC++ 6.0
by Joaquín Mª López Muñoz 25 May '05

25 May '05

There's currently a test case for Boost.Integer failing in MSVC ++ 6.0 with a LNK1179 error: http://tinyurl.com/8rpuu This bug in MSVC++ 6.0 shows when the compiler emits different symbol names with a very long common prefix: in this particular case, the offending symbol names are generated by a couple of BOOST_CHECK instantiations. The proposed patch works around the problem and only affects to the test code, not the library, so I guess it's safe enough. OK to commit? Joaquín M López Muñoz Telefóinca, Investigación y Desarrollo 56a57,63 > #if defined(BOOST_MSVC) && (BOOST_MSVC <= 1200) > // MSVC++ 6.0 issues a LNK1179 error (duplicate comdat) when the compiler > // generates different symbol names with a very long common prefix: > // the dummy "&& true" disambiguates between the symbols generated by this > // BOOST_CHECK instantiation and the preceding one. > BOOST_CHECK(traits::is_integer && true); > #else 57a65 > #endif

2 1

[date_time] minor warning fix
by Christophe Prud'homme 25 May '05

25 May '05

Dear Booster I have attached a trivial patch for date_facet.hpp to avoid unnecessary warnings in date_facet.hpp with g++ -Wall/-Wunused Best regards C. -- Christophe Prud'homme Office MA B2 534 CMCS-IACS EPFL CH-1015 Lausanne, Switzerland Tel: +41 (0)21 693 25 47 Fax: +41 (0)21 693 43 03

2 1