May 2005 - Boost - lists.boost.org

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

Lambda just faild in VC8
by Victor A. Wagner Jr. 25 May '05

25 May '05

my latest run shows Lambda failing in trying to build (that old manifest again) the last part Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Test library] wide_string test and wputenv
by Doug Gregor 25 May '05

25 May '05

The test library's wide_string tests are failing on any platform because "wputenv" does not exist. Googling around a bit, I don't see much mention at all of "wputenv". There is a _wputenv on Microsoft compilers, but it takes wchar_t pointers, not char pointers. This is part of a much larger problem... a quick count in the regression tests shows about 300 failures coming from the test library. Most of these are on compilers we usually consider rather broken, but we need someone to look at these failures and either fix them or mark them. The Boost.Test library is one of the core libraries, on which every other library depends. It needs to be solid, stable, and portable, or we cannot release 1.33.0. Doug Gregor 1.33.0 Release Manager

6 10