December 2004 - Boost - lists.preview.boost.org

STLPort linking error
by Kenny Chamber 17 Dec '04

17 Dec '04

I am in the middle of moving our development from the std STL to STLPort and I am having a problem with two Athlon boxes. SuSE Linux 9.0 gcc 3.3.1 STLPort 4.6.2 Boost 1.31 I am changing an existing application to use STLPort and I have successfully completed the transition on a number of Intel boxes. When I try to build on an Athlon box I get the following error message: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I'm linking against libboost_thread-gcc-mt-p-1_31 and libboost_date_time-gcc-mt-p-1_31. I can't see an obvious solution so I'm hoping someone has solved this problem already. ----------------------- Kenny Chamber http://gem-hs.org/contact.html

4 3

[BGL] Patch for detail/adjacency_list.hpp
by Jürgen Hunold 17 Dec '04

17 Dec '04

Hi ! The last commit from Doug Gregor (Revision 1.130) broke compilation with gcc-3.4.1 for me. The attached patch fixes this by moving the implementation of remove_directed_edge_dispatch to a place _before_ it is used. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

3 4

PhD position (generic software libraries)
by Sibylle Schupp 17 Dec '04

17 Dec '04

*** PH.D. POSITION (GENERIC SOFTWARE LIBRARIES) *** Boost inside your Volvo?! In a joint project between Chalmers University and industrial partners from the automotive industry, there is an opening for a Ph.D. position specifically in the area of generic library design. The successful candidate will have the rare opportunity to earn a Ph.D. with a dissertation in which software is not just of "academic" value and interest, but really matters. Booster are encouraged to apply, to get back to me with recommendations, or to pass this advertisement on to others---this project is a big chance to implant generic programming in the (not just Swedish) car industry! Note that PhD positions in Sweden are regular jobs, with social benefits, paid vacation, parental leave, etc. I attach the entire announcement below; CEDES/4 is the position of interest. For further details, please get in touch with me. Sibylle ------- Sibylle Schupp, Assoc. Prof. Dept. Computing Science Chalmers Univ. of Technology SE-41296 Gothenburg http://www.cs.chalmers.se/~schupp ========================================================================= Open Ph.D. positions at Chalmers University of Technology (Sweden) Chalmers University of Technology is seeking outstanding Ph.D. candidates for 5 open Ph.D. positions within the newly started CEDES (Cost-Efficient Dependable Electronic Systems) initiative. CEDES is a joint project of Chalmers Univ. of Technology, Volvo Car Corporation, AB Volvo, Autoliv, and the Swedish National Testing and Research Institute, sponsored by the Swedish Road Authority. All Ph.D. positions are in the School of Computer Science and Engineering. Successful applicants hold a degree in computer engineering or computer science and can demonstrate their capability to conduct research. Additional requirements and deadlines vary among the different positions. Knowledge of the Swedish language is not required; both the School of Computer Engineering and Computing Science and the City of Gothenburg, Sweden's second-largest city, are characterized by a friendly, international atmosphere. Applicants should state explicitly for which of the positions they apply. -------------- Ref.Nr CEDES/1-2 (Software processes) Application: See http://chalmersnyheter.chalmers.se/chalmers03/svensk/ext_ledigatjansterarti… Deadline: Dec. 31, 2004 Contact: Peter Ohman, X(a)ce.chalmers.se, where X=peter.ohman -------------- Ref.Nr CEDES/3 (Fault tolerance) Deadline: Feb. 15, 2005 Contact: Johan Karlsson, X(a)ce.chalmers.se, where X=johan -------------- Ref.Nr CEDES/4 (Generic software libraries) Application: See http://www.cs.chalmers.se/Cs/Grad/ Deadline: Feb. 15, 2005 Contact: Sibylle Schupp, X(a)cs.chalmers.se, where X=schupp -------------- Ref.Nr CEDES/5 (Verification and validation) Application: See http://www.cs.chalmers.se/Cs/Grad/ Deadline: Feb. 15, 2005 Contact: Reiner Hahnle, X(a)cs.chalmers.se, where X=reiner

1 0

Boost 1.32.0/SUN CC shared_ptr/weak_ptr test failure in shared_ptr_basic_test.cpp
by Timo Geusch 17 Dec '04

17 Dec '04

Ah yes, the neverending saga of the SUN C++ compiler, version 5.5 in this particular case. My apologies if this information is already well-known, I have been off the list for a couple of months, but a quick check of the mailing list archive didn't show any discussion regarding this subject. I had been trying to figure out what's breaking the simple shared_ptr to weak_ptr assignments and copies on this particular compiler. The code shown below is based on the code in the above file, around line 260. Anyway, for reference, the following test fails using the default settings for sunpro-tools.jam: weak_ptr<X> wp2 = static_pointer_cast<X>(p5); BOOST_TEST(wp2.use_count() == 1); as the reference count is 2, not 1 as expected. After looking at the source code for static_pointer_cast<> and a bit of experimentation with different types of scoping produced the following code instead: weak_ptr<X> wp2; { wp2 = static_pointer_cast<X>(p5); } BOOST_TEST(wp2.use_count() == 1); Interestingly, this code works as expected - it appears that this particular compiler doesn't clean up the temporary shared_ptr<X> that's being generated inside static_pointer_cast<> until it hits a closing '}'. Digging around the web confirmed that originally the SUN C++ compilers destroyed temporaries as described above and the newer compilers are still backward-compatible. In order to get standard-compliant behaviour one needs to specify -features=tmplife. One updated boost jamfile and the compiler appears to be much happier - all the smart_ptr appear to pass now, apart from shared_ptr_assign_fail.cpp which I assume isn't supposed compile in the first place. A quick test suggests that the 5.3 also supports the above compiler flag so it may be worth including this setting in the sunpro-tools.jam file, however I haven't tested this yet.

1 0

[multi_index] announce: added serialization support
by Joaquín Mª López Muñoz 16 Dec '04

16 Dec '04

The version currently commited to the CVS includes serialization support, docs, examples, etc. I'll be happy to know about your usage experience, as well as general comments on the new feature. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 16 Dec '04

16 Dec '04

In-Reply-To: <BAY101-F20FDD5860C530B8D6ADE17A0AC0(a)phx.gbl> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > struct position{ float x; float y; }; > struct size{ float dx; float dy; }; > struct area > { > float top; float left; > float width; float height; > }; Why float rather than double? I'd want to avoid unnecessary conversions, so I'd want to use the same units all the way through. At the moment my document model uses integers, scaled not to 96 dpi pixels but to logical units which are 72,000 dpi. With 32-bit ints that gives a drawing area of about 30,000 inches. Using floats would give only 23 bits of precision, which reduces the drawing area to around 60 inches, which is getting a bit small. I'd prefer to avoid using fractional units because of exactness issues with 1/3 etc. I don't have a strong opinion on floating point generally. Sometimes I want to use pixel rounding, and sometimes I want to transform coordinates without losing accuracy. Adobe's PDF is an example which uses a floating point coordinates, albeit at 72 dpi rather than 72,000. I do know that most of the time, using integers works fine. You don't lose precision because you only ever transform the coordinates once. For bounding box transforms you round left/top with floor and right/bottom with ceil. For anti-aliasing you transform, eg, from 72,000 dpi to 384 dpi to get 1/4 pixel precision. -- Dave Harris, Nottingham, UK

1 0

MPL Book is on the way!!!
by Jody Hagins 16 Dec '04

16 Dec '04

I recieved notification that it shipped yesterday, and according to the UPS website, it will be here tomorrow, Dec 15!

6 6

[Boost-bugs] [ boost-Bugs-1086305 ] incorrect conditions to #define DISABLE_WIDE_CHAR_SUPPORT
by SourceForge.net 16 Dec '04

16 Dec '04

Bugs item #1086305, was opened at 2004-12-16 11:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1086305&group_… Category: lexical_cast Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergej Zagursky (seza) Assigned to: Kevlin Henney (kevlin) Summary: incorrect conditions to #define DISABLE_WIDE_CHAR_SUPPORT Initial Comment: I think absence of BOOST_NO_INTRINSIC_WCHAR_T isn't a requirement for DISABLE_WIDE_CHAR_SUPPORT definition. Suggested fix: //old code #if defined(BOOST_NO_STRINGSTREAM) || defined(BOOST_NO_STD_WSTRING) || defined(BOOST_NO_STD_LOCALE) || defined(BOOST_NO_INTRINSIC_WCHAR_T) #define DISABLE_WIDE_CHAR_SUPPORT #endif //new code #if defined(BOOST_NO_STRINGSTREAM) || defined(BOOST_NO_STD_WSTRING) || defined(BOOST_NO_STD_LOCALE) #define DISABLE_WIDE_CHAR_SUPPORT #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1086305&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Cross Builder, v1.0
by John Torjo 16 Dec '04

16 Dec '04

Dear boosters, I thought this might be of interested in this, even if it's Windows-only for now. I'm happy to announce the first version of "Cross Builder": http://www.torjo.com/cb/ In short, Cross Builder allows you to build C++ projects very easy. In addition to that, it allows you to modify various compiler settings in a simple and straightforward way. Cross Builder's purpose is to make it as easy as possible for you to build your projects with *any* C++ compiler. Or, put in other words, *one click*. Compiler settings apply hierarchically. This is a very powerful mechanism, and once you see it at work, you'll simply love it! When you modify a setting, you modify it for: * a HDD directory or file * a configuration (such as "Debug", "Release", etc.) * a compiler (such as "All compilers", "MSVC" (all MS compilers), "VC 7.1", etc) From then on, this setting will apply to all: * it sub-configurations * its sub-compilers * its HDD sub-directories ...until it's overridden. Screenshots and possibility to download: http://www.torjo.com/cb/ As a side-node, in the near future, I will also post the source-code for the first version of CB. Feedback is welcome. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- http://www.torjo.com/cb/ - Click, Build, Run!

8 17

program_options & VC6: internal compiler error?
by Olaf van der Spek 16 Dec '04

16 Dec '04

Hi, I was trying to use the program_options library and used the following example. However, I got an internal compiler error. I reduced the example to this minimum. The library build fine, so I assume it's compatible with VC6. What went wrong? Code: #include "stdafx.h" #include <boost/program_options.hpp> #include <iostream> int main(int ac, char* av[]) { boost::program_options::variables_map vm; std::cout << vm["compression"].as<int>(); // line 8 return 0; } Output: Configuration: Program Options Test - Win32 Release Compiling... StdAfx.cpp Compiling... Program Options Test.cpp C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : error C2679: binary '<<' : no operator defined which takes a right-hand operand of type '' (or there is no acceptable conversion) C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : error C2062: type 'int' unexpected Error executing cl.exe. Program Options Test.exe - 2 error(s), 0 warning(s) Configuration: Program Options Test - Win32 Debug Compiling... Program Options Test.cpp C:\VC\temp\Program Options Test\Program Options Test.cpp(8) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Error executing cl.exe. Program Options Test.exe - 1 error(s), 0 warning(s) -- Olaf van der Spek http://xccu.sf.net/

2 2

Re: Nasty bug in Boost 1.32.0 bind]
by Peter Dimov 15 Dec '04

15 Dec '04

Sean Parent wrote: > On Dec 6, 2004, at 12:10 PM, Peter Dimov wrote: >> >> This is not a bug. Bind was deliberately changed to return by value >> because of a bug report similar to the following: >> >> pair_t make_pair( int, int ); >> >> bind( &pair_t::first, bind( make_pair, 10, 20 ) )(); >> >> The inner bind returns by value (because make_pair returns a value) >> and the outer bind returns a reference to a temporary. >> >> A similar, but rare, situation can arise when bind is invoked on an >> rvalue: >> >> pair_t const make_pair(); >> >> bind( &pair_t::first, _1 )( make_pair() ); >> >> I'm more interested in the actual code that was broken by this >> change, because the assert() above was never required to pass. >> By-value or by-reference was (and probably still is) an open >> question. Of course I should have gotten it right in the first place. > > The documentation explicitly states that it will return a const > reference: > ----- >> bind(&X::f, args) >> >> is equivalent to >> >> bind<R>(mem_fn(&X::f), args) >> >> where R is the return type of X::f (for member functions) or a const >> reference to the type of the member (for data members.) > ----- Yes, you are right. I missed that. > The actual failure was in conjunction with boost::function() where it > fails silently because of a cast to result type inside boost function. > Here is a snippet that was my first attempt at isolating the problem: > > ---- > #include <boost/bind.hpp> > #include <boost/function.hpp> > #include <utility> > #include <cassert> > > int main() > { > typedef std::pair<int, int> pair_t; > > pair_t pair(10, 20); > > boost::function<const int&(const pair_t&)> > function(boost::bind(&pair_t::first, _1)); > > const int& x = function(pair); > > assert(&pair.first == &x); > > return 0; > } I get warning C4172 from VC++ 7.1, "returning address of local variable or temporary", on this example (in function_template.hpp:111). The example can be further simplified to: #include <boost/function.hpp> int f() { return 5; } int main() { boost::function<int const & ()> g( f ); int const & r = g(); } which produces the same warning. A static_assert in boost::function would probably help on compilers that don't emit a warning. [...] >> The explicit version: >> >> const int& x = boost::bind<int&>(&pair_t::first, _1)(pair); >> >> should work on conforming compilers. > > Good to know - I will review my code and try to be explicit where > possible - however, I use bind() a lot within templates and rely on it > not making an additional (often expensive) copy of my members. I don't > think there there is a correct answer for the default behavior > (between returning a const& and a value) but the docs need to be > consistent - and a change of this nature needs to be called out in > the release notes. Yes, you are right. I underestimated the impact of this change; the new behavior was supposed to eliminate this sort of bug, not introduce it. Breaking existing code is never pleasant. The change has been in the CVS for some time, but unfortunately most real-world testing occurs on the actual releases.

4 4

Cross Builder and pkg-config discussions
by David Abrahams 15 Dec '04

15 Dec '04

These discussions should probably move to the Boost.Build mailing list now. They've drifted a little far from library development issues. http://www.boost.org/more/mailing_lists.htm#jamboost -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[PATCH]Enhancing any_cast
by Mikhail Glushenkov 15 Dec '04

15 Dec '04

This is an enhanced version of Unai Uribarri's patch (see http://lists.boost.org/MailArchives/boost/msg42284.php ). Adds support for the following syntax: boost::any a = 7; int& i = any_cast<int&>(a); Current syntax for reference extraction is int& i = *any_cast<int>(&a); Old syntax is preserved. On compilers without support for partial template specialization users are required to provide explicit specializations of boost::remove_reference for their classes (usually via BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION) if they want to use the new syntax. Patch was tested on msvc 6 and 7.1, intel 8.1 and gcc 3.3.1. If this patch will be accepted, I'll write tests/update documentation. --- any.hpp Thu Sep 16 11:23:30 2004 +++ new_any.hpp Fri Dec 10 19:47:45 2004 @@ -15,6 +15,12 @@ #include "boost/config.hpp" #include <boost/throw_exception.hpp> +#include <boost/type_traits/remove_reference.hpp> + +#ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION +#include <boost/type_traits/is_reference.hpp> +#include <boost/static_assert.hpp> +#endif namespace boost { @@ -168,12 +174,39 @@ } template<typename ValueType> - ValueType any_cast(const any & operand) + const ValueType any_cast(const any & operand) { - const ValueType * result = any_cast<ValueType>(&operand); + #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Please use BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro + // to generate specialization of remove_reference for your class + // See type traits library documentation for details + BOOST_STATIC_ASSERT(!::boost::is_reference< + boost::remove_reference<ValueType>::type >::value); + + #endif //BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + + typedef typename boost::remove_reference<ValueType>::type Type; + const Type * result = any_cast<Type>(&operand); if(!result) boost::throw_exception(bad_any_cast()); return *result; + } + + template<typename ValueType> + ValueType any_cast(any & operand) + { + #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Please use BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro + // to generate specialization of remove_reference for your class + // See type traits library documentation for details + BOOST_STATIC_ASSERT(!::boost::is_reference< + boost::remove_reference<ValueType>::type >::value); + + #endif //BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + + typedef typename boost::remove_reference<ValueType>::type Type; + Type * result = any_cast<Type>(&operand); + if(!result) + boost::throw_exception(bad_any_cast()); + return *result; } }

2 3

RE: [boost] Re: Re: feature wish for boost 1.32.1 or 1.33.0: pkg- config support
by Stefan Seefeld 15 Dec '04

15 Dec '04

> From: Neal D. Becker [mailto:ndbecker2@verizon.net] > So, do you mean you want to use pkg-config to record the > settings that were > used to build boost? If so, I misunderstood. This might be useful. Indeed, that's how pkg-config is used. However, as a full-blown boost build process will result in quite a number of different configurations, the pkg-config approach would need to reflect that. For example, boost would need to generate one pkg-config script for each configuration that has been built. Regards, Stefan

2 1

Web typography
by David Abrahams 15 Dec '04

15 Dec '04

While Rene was wrangling fonts I forgot that I went through this whole process with Bill Venners of Artima. We ended up with a very different answer, because Bill abhors the idea of specifying a font size; he wants to respect peoples' preferences. I would appreciate it if everybody would check out: http://www.artima.com/cppsource/metafunctions.html and see how it compares with Rene's page at http://redshift-software.com/~grafik/boost/index.htm on your sundry browsers. I don't have an idea of which one is better, but we should at least get the benefit of that research. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 8

RE: [boost] Re: Cross Builder, v1.0
by Ferdinand Prantl 15 Dec '04

15 Dec '04

Hi Hajo, > From: Hajo Kirchhoff > > I am trying to decide on a build tool for the Lit Window > Library and am considering bjam, cmake, bakefile and would > just like to get an opinion about your tool before delving > deeper into it. BTW, I need linux support as well as VC6++ > and .NET project creation, meaning the tool should create > .NET project/solution files rather than acting as a build tool. I wanted the same - just generate makefiles/projects. I use tmake (1.11 with some tweaks of me) from Trolltech (predecessor of qmake written in Perl). It generates makefiles/projects from templates and creates them for a platform from a couple of lines in a file.pro. You must run the build afterwards manually. Doxygen uses tmake, for example and Qt uses qmake, which has the same principle and configuration. The discussion gets a little off-topic... ;-) Ferda

1 0

Front page, one last time.
by Rene Rivera 15 Dec '04

15 Dec '04

Boosters, OK, I haven't heard anything in the way of further comment on the new front page design. I've put in a version of the current logo while we work that out. And done some minor cleanup of the css and xhtml: http://redshift-software.com/~grafik/boost/index.htm Boost C++ Libraries If there aren't any serious objections, I'll go ahead and commit this to CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

16 33

RE: [boost] Re: Re: rational with finite precision
by Michiel Salters 15 Dec '04

15 Dec '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: zondag 12 december 2004 22:48 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: rational with finite precision ... > Finally, it would be nice if someone would actually submit > infinite precision number types ... Are you aware of N1692? There will probably be two follow-ups to it, one (N1718) by the same author who will be proposing a rational class as well, and one by me ( currently still in MSWord form, and I'm waiting for a number) which proposes standardese for an <integer> header/class. Regards, Michiel Salters 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

Config library public or not?
by Ulrich Eckhardt 15 Dec '04

15 Dec '04

Hi! The documentation says the lib is not intended for users of boost, but only to aid implementing boost itself. I asked the question some time ago (long before 1.32) and the consensus was that it was in fact public and the documentation was wrong/outdated, but even with this release it didn't change. What's the deal? Did I miss anything? Uli

4 4

[Boost-bugs] [ boost-Support Requests-1085691 ] Boost-1.30.2 and gcc-3.4.2
by SourceForge.net 15 Dec '04

15 Dec '04

Support Requests item #1085691, was opened at 2004-12-15 02:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1085691&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost-1.30.2 and gcc-3.4.2 Initial Comment: I cannot build the boost-1.30.2 with the new compiler gcc-3.4.2 on RH and EM64T machine. Does this version support the new compiler? The last boost version - 1.32 passed compilation with gcc-3.4.2 without problems. Thanks, Genia ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1085691&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Language Binding API
by Brian Braatz 14 Dec '04

14 Dec '04

A few months ago I recall David Abrahams sent a quick mail that referenced a Language Binding API for hooking in dynamic languages into C++. It looked like something he was brewing on. I was just curious if anything became of that. (or is it like those 1,000 things I have on my plate and have not been able to finish :) ) Dave?

3 2

is_abstract update
by John Maddock 14 Dec '04

14 Dec '04

Following on from the recent discussion, we now have: BOOST_NO_IS_ABSTRACT added to the config system, this is likely to cause some new failures with config_test.cpp until we get the macro added to those compiler config files that need it (although Gcc, Visual C++, Borland C++ are already taken care of). is_abstract no longer uses SFINAE when BOOST_NO_IS_ABSTRACT is defined, instead it defaults to the same value as is_polymorphic: the rationale is that "true" is the safe default (if there is one), but since non-polymorphic types obviously can't be abstract, we can safely evaluate to false for those. Users wanting some other behaviour should check for BOOST_NO_IS_ABSTRACT. Robert, is this enough for you to fix the ODR problem in the serialisation lib for is_abstract? John.

4 5

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? Good catch! I can confirm that it is indeed a problem. Should have a fix in a day or two. The last error code is set to ERROR_FILE_NOT_FOUND in the particular case you are talking about, and something else otherwise, so it is possible to distinguish it from other conditions. --Beman

1 0

patch: Boost.Jam: PATH_MAX not defined in SCO 5.0.5
by Davlet Panech 13 Dec '04

13 Dec '04

Added default for PATH_MAX as it isn't defined on my system (sco3.2v5.0.5/gcc2.95.2) --- tools/build/jam_src/pwd.c.orig 2004-12-13 14:58:32.362510600 -0500 +++ tools/build/jam_src/pwd.c 2004-12-12 17:32:07.000000000 -0500 @@ -21,7 +21,9 @@ #endif #endif - +#ifndef PATH_MAX +# define PATH_MAX 4096 +#endif LIST* pwd(void)

1 0

Re: [boost] Some Boost.Filesystem problems
by Beman Dawes 13 Dec '04

13 Dec '04

At 04:42 PM 12/12/2004, Ben Hutchings wrote: >I noticed that Boost.Filesystem doesn't use readdir_r to iterate over >directories, even if it is available, making that non-thread-safe. >There is a comment to this effect in operations_posix_windows.cpp. > >I've attached a patch that I believe will allow it to detect whether >readdir_r is available and to use it iff it is. I have only tested this >on Linux with g++ 3.3, but I tried deliberately breaking the declaration >of readdir_r and verified that the code continues to work without it. Interesting approach! I guess the alternative is hand configuration, and that isn't very attractive. So let me take a look at your patch in detail and get back to you. >On a visual inspection some time back I also noted that there's no >special handling for empty root directories on Windows. The problem >with these is that while even an empty directory normally has entries >for "." and "..", so that FindFirstFile can return something, root >directories on FAT volumes (and I think NTFS as well) do not have these >and Windows doesn't fake them, so FindFirstFile on an empty root returns >INVALID_HANDLE_VALUE. Note that this only applies to real root >directories, not to the roots of drives that are mapped to >sub-directories using subst or file sharing. I never got round to >checking whether the Boost code actually handles this or not, as I only >use Windows at work and we don't use Boost.Filesystem there. Perhaps >someone could check that out? I've got some code that should serve to check that out. I'll let you know. > Unfortunately it's impractical to test >automatically, as empty volumes are hard to generate on demand! That's one of the difficulties of the library; there are quite a few test cases which are difficult and/or expensive to create on demand for testing. Thanks for you help, --Beman

1 0