- Boost - lists.boost.org

[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

[1.33.0] Final destination for 1.33 test results?
by JOAQUIN LOPEZ MU?Z 24 May '05

24 May '05

index.htm as currently in the CVS has the following URL http://www.meta-comm.com/engineering/boost-regression/1_33_0/index.html under the name "Release". Currently, the link fails. Is this the stable URL where 1.33 final results will be stored? I'd like to include this in some of my docs and I guess I'll have to do it "blindly" i.e before the URL gets any actual contents, so I want to make sure. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[test] Turning off signal traps
by Jody Hagins 24 May '05

24 May '05

I have a test that is failing, and I am using the auto tests... #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include "foo.hpp" BOOST_AUTO_UNIT_TEST(blarg) { BOOST_CHECK_EQUAL(do_something(), 0); } However, somewhere a SEGV is happening. How can I turn off the test signal catching for this test so that I can get a core file for debugging?

2 1

Big Integer uploaded to sandbox, volunteer seeked for submission to boost
by christopher diggins 24 May '05

24 May '05

I just uploaded a very simple arbitrary precision unsigned integer class to the sandbox ( http://boost-sandbox.sourceforge.net/vault/index.php ). The class is implemented using naive algorithms and is based on std::vector<bool>. Efficiency was absolutely not a concern, the priority was placed on correctness. Without meaning to undermine the impressive work on the expression template big_integer class I thought perhaps programmers would generally prefer a more portable and quickly compiled class. The interface of the type I posted is: class big_uint { typedef big_uint self; public: big_uint(); big_uint(const self& x); big_uint(const std::vector<bool>& x); big_uint(int x); self& operator=(const std::vector<bool>& x); self& operator<<=(int n); self& operator>>=(int n); self operator++(int); self operator--(int); self& operator++(); self& operator--(); self& operator+=(const self& x); self& operator-=(const self& x); self& operator*=(self x); self& operator/=(const self& x); self& operator%=(const self& x); self operator~() const; self& operator&=(self x); self& operator|=(self x); self& operator^=(self x); bool operator[](int n) const; int size() const; unsigned long to_ulong(); friend self operator<<(const self& x, unsigned int n); friend self operator>>(const self& x, unsigned int n); friend self operator+(const self& x, const self& y); friend self operator-(const self& x, const self& y); friend self operator*(const self& x, const self& y); friend self operator/(const self& x, const self& y); friend self operator%(const self& x, const self& y); friend self operator^(const self& x, const self& y); friend self operator&(const self& x, const self& y); friend self operator|(const self& x, const self& y); friend bool operator==(const self& x, const self& y); friend bool operator!=(const self& x, const self& y); friend bool operator>(const self& x, const self& y); friend bool operator<(const self& x, const self& y); friend bool operator>=(const self& x, const self& y); friend bool operator<=(const self& x, const self& y); }; For acceptance into Boost I would guess that this class would have to be much more efficient (though my view is that something that works is better than nothing that runs fast). Unfortunately I can not spend any significant amount of time optimizing it nor doing a proper submission (I would not have time available until around August), so if someone would like to volunteer to take it over, I would appreciate it. Any comments would be most welcome. -- Christopher Diggins http://www.cdiggins.com

1 0