- Boost - lists.boost.org

No -fcoalesce-templates with GCC 4.0 on Mac OS X Tiger
by Patrick Hartling 08 May '05

08 May '05

I haven't seen any posts about this, so please pardon me if I have missed it, but Boost does not currently build on Mac OS X Tiger with the 'darwin' toolset because the option -fcoalesce-templates has been removed from the Apple build of GCC 4.0. I have made simple modifications to my checked out copy of the latest Boost source to allow the libraries I need to build, but my changes would break the usability of Boost libraries on previous versions of OS X that need -fcoalesce-templates. I would be happy to submit a patch and run any tests if someone could suggest how I would go about modifying boost/tools/build/v1/darwin-tools.jam in a backwards compatible manner. Thanks. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/

2 3

Strange mail from this list?
by Liu Jin 08 May '05

08 May '05

Hi boosters, Recently I've got a lot of empty messages (a sample below) from the list. Is there something wrong with my mail client, or it's normal group traffic? Thanks. Jin [sample] X-From-Line: boost-bounces(a)lists.boost.org Sun May 8 00:22:21 2005 Received: from milliways.osl.iu.edu (unknown [129.79.245.239]) by 192.168.9.79 (Coremail) with SMTP id GMAWgzzrfELex+8A.1 for <cpp(a)vip.163.com>; Sun, 08 May 2005 00:22:21 +0800 (CST) X-Originating-IP: [129.79.245.239] aaazzzaaazzzaaazzzaaazzzaaazzz X-Gnus-Mail-Source: pop:cpp@pop.vip.163.com Message-Id: <427CEB3D.3B6F3C.00995> Date: Sun, 8 May 2005 00:22:21 +0800 (CST) From: boost-bounces(a)lists.boost.org X-Content-Length: 1 Lines: 2 Xref: CPP_COMPUTER mail.personal:1109

2 1

[iostreams] Compilation errors with MSVC 8
by Keith MacDonald 08 May '05

08 May '05

When building CVS Boost with MSVC 8 beta 2 (http://lab.msdn.microsoft.com/vs2005/) it generated the errors below for iostreams. operations.hpp has a mixture of line endings, and symmetric_filter_adapter_impl is missing a return type, so I guess it's telling the truth! - KM F:\CVS\boost\boost/iostreams/operations.hpp : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format F:\CVS\boost\boost/type_traits/is_abstract.hpp(81) : warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning) F:\CVS\boost\boost/type_traits/is_abstract.hpp(93) : see reference to class template instantiation 'boost::detail::is_abstract_imp2<T>' being compiled F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C2063: 'symmetric_filter_adapter_impl' : not a function F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C2888: 'symmetric_filter_adapter<SymmetricFilter,Alloc>::symmetric_filter_adapter_impl symmetric_filter_adapter_impl' : symbol cannot be defined within namespace 'iostreams' F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : fatal error C1903: unable to recover from previous error(s); stopping compilation

3 4

[range] CW on MacOSX failures...
by Rene Rivera 07 May '05

07 May '05

Could someone explain what the intent of this change is: http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/range/test/string.cp… http://tinyurl.com/8efhq Specifically the "#define _MSL_USING_NAMESPACE 1"? That is causing duplicate def errors, as this is supposed to be an internal MSL macro. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

[numeric/conversion] CW and VC8 fixes.
by Rene Rivera 07 May '05

07 May '05

All the tests for this library should now pass for all CodeWarrior versions. I also fixed two files with bad EOLs, which will likely fix the problems with VC8. Note.. if you see this kind of error on the VC8 logs: error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format It's because of EOLs problems also reported at: http://www.boost.org/regression-logs/inspection_report.html -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [boost] Re: BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 07 May '05

07 May '05

In-Reply-To: <d5d7h5$3cp$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > While this is discussible position, I did not see you prove you > point enough to reject a submission. As I said, that wasn't my reason for voting against the proposal. However, I'm content with the final result; I don't expect or want to overturn it. -- Dave Harris, Nottingham, UK.

1 0

[date_time] CodeWarrior fixes.
by Rene Rivera 07 May '05

07 May '05

I put in some fixes to clear out some of the CodeWarrior regressions. Only four types of problems still exist: 1. There are DLL tests that use std::locale, directly or indirectly I don't know, but they should be marked as expected-to-fail. 2. There are tests that fail because boost.serialization lib fails to build. I'll eventually get to checking why that doesn't build. 3. There are two tests that now compile, but fail at runtime with an access violation. From previous experience it looks like accessing a vtable method through a NULL pointer. The tests are the two *_time_input_facet. 4. There's an unexplained compiler confusion at: boost\date_time\date_parsing.hpp:262: data type is incomplete Possibly the compiler is trying to instantiate too early? Don't really know. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

[Test] Thread-safety
by Cliff Green 07 May '05

07 May '05

Silly me - I should have looked in the Boost.Test Open Issues page a couple of days ago instead of wasting my time trying to solve some multi-threading problems in my own code. So a couple of enhancement requests (for Gennadiy, or appropriate person): 1. Please state clearly in the Boost.Test documentation that it is not thread-safe. I looked all through the pages (both the current release and the 1.31 release) but the only place I find mention of thread-unsafety is in the Open Issues page. The FAQ page would also be a good place to mention Boost.Test thread-unsafety, besides the main page (and places like Usage Recommendations, Examples, Compilation, etc). 2. Please consider adding thread-safeness to the Boost.Test libraries. I know this is not a simple request, and there may be other priorities ... but many of my (and my team's) unit tests are multi-threaded, and it's a shame to not be able to use Boost.Test (or even know which, if any, parts are thread-safe). It's a nice testing framework, IMO. Note that I don't need the whole library itself to be threaded, just to be able to do things like BOOST_MESSAGE and BOOST_EQUAL within my own testing threads. (I'll offer whatever help I can provide, within the constraints of my available time.) Many thanks! Cliff

4 4

Re: [boost] BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 07 May '05

07 May '05

In-Reply-To: <989aceac050505060373e68a1(a)mail.gmail.com> caleb.epstein(a)gmail.com (Caleb Epstein) wrote (abridged): > > What about the name? Shouldn't it be "BOOST_FOR_EACH"? > > Why? Because of the distinct English words? Yes. And for consistency with other C++ macros, algorithms and keywords. I've argued at greater length in the other thread. -- Dave Harris, Nottingham, UK.

5 5

Re: [boost] Singleton Review: GCC compiler errors
by Jason Hise 06 May '05

06 May '05

Sorry about the duplicate messages, thunderbird seemed to be having a problem. Hoping it's fixed now. Jason Hise wrote: > Tom Brinkman wrote: > >> Was the "singleton" library tested on GCC. I'm getting many compiler >> errors on 3.34. > > It was a while back, but many changes have been made since then. I'll > see if I can track down a copy of gcc to try compiling with it myself. Actually, now that I'm looking into it it appears that Dev C++ uses a port of GCC by default, and I have successfully tested the latest version with Dev C++, getting no warnings or errors. What error messages are you getting? -Jason

3 2