Re: [boost] minor nitpick: why signal.hpp instead of signals.hpp?(notext)

2003-07-11 Thread Douglas Gregor
Subject: [boost] minor nitpick: why signal.hpp instead of signals.hpp? (notext) Probably a mistake. signal.hpp made sense when the library was not in the namespace boost::signals, but signals.hpp makes more sense now. This should probably change. Doug

[boost] Re: Re: mpl::if_ and ICE triggered on GNU g++-cvs-today

2003-07-11 Thread Markus Werle
Martin Wille wrote: That is the output for gcc-3.4 from today? I've run the configure script with gcc version 3.4 20030710 (ie. from today) and got these results: [..] I should have mentioned the platform: A PA-RISC with hpux-11.11 Things are hard to set up on that machine :-( Markus

[boost] Boost.Threads bug?

2003-07-11 Thread Alexander Nasonov
There is a less comparison in several places of time-related stuff. I believe that less-or-equal is better. Take a look for example at if statement here: inline void to_timespec(const boost::xtime xt, timespec ts) { ts.tv_sec = static_castint(xt.sec); ts.tv_nsec =

Re: [boost] Re: smart_assert and range_ template

2003-07-11 Thread John Torjo
Hi Danny, http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/) Here's an excerpt of some code: I have some problems to see the connection between smart_assert and your errounous code below. Can you explain? The code shown below is from the smart_assert

[boost] New iterator adaptors and bjam builds

2003-07-11 Thread Jens Maurer
The new iterator adaptors appear to have been checked in to the main boost CVS. The boost build setup appears not to take header-file dependencies between libraries into account. Therefore, in order to produce a valid test run for publication, you should completely remove all binaries etc.

[boost] Recursive_mutex bug?

2003-07-11 Thread Lev Assinovsky
Hi All! I caught a memory leak (24 bytes) when using recursive_mutex class in Solaris 8. This class initializes a pthread_mutexattr attribute but never destroys it thus leaving the leak. We use tons of the recursive mutexes in our huge app and that leak leads to significant memory loss. Regards,

[boost] Re: functors for taking apart std::pair?

2003-07-11 Thread Edward Diener
Andy Sawyer wrote: From: Andy Sawyer [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Subject: [boost] Re: functors for taking apart std::pair? Date: Thu, 10 Jul 2003 22:10:42 +0100 ED == Edward Diener [EMAIL PROTECTED] writes: Marshall Clow wrote: I recently had a need for a

Re: [boost] Recursive_mutex bug?

2003-07-11 Thread John Maddock
I caught a memory leak (24 bytes) when using recursive_mutex class in Solaris 8. This class initializes a pthread_mutexattr attribute but never destroys it thus leaving the leak. We use tons of the recursive mutexes in our huge app and that leak leads to significant memory loss. That does

[boost] computional geometry visualization

2003-07-11 Thread Vygis D.
Hello, My work on geometrical lib is evolving and finally I found out that programming is so much fun chuckle. Credits to Jaap Suter, he has done a wonderful work on geometrical algebra library although I don't know whether it's keep going. Would be nice to hear something from him. About two

[boost] mpl/loki

2003-07-11 Thread Drazen DOTLIC
Hello, I've recently discovered that mpl provides all the functionality I was previously using from loki, so I decided to switch. There is one small thing driving me crazy, and I was wondering if I missed something... I was using loki's TypeAtNonStrict algorithm to give me type from type list

[boost] intrusive_ptr does not compile under MSVC 6 + STLPort

2003-07-11 Thread Stefan Slapeta
... and the reason is that this Boost workaround # if BOOST_WORKAROUND(BOOST_MSVC, = 1200 __SGI_STL_PORT) does never apply as config.hpp is not included and therefore BOOST_MSVC IS NOT SET!!! You have to manually include config.hpp before intrusive_ptr to make it run :-( S.

[boost] Re: mpl/loki

2003-07-11 Thread David Abrahams
Drazen DOTLIC [EMAIL PROTECTED] writes: Hello, I've recently discovered that mpl provides all the functionality I was previously using from loki, so I decided to switch. Just a note: Loki (generic programming applied to design patterns) and MPL (C++ template metaprogramming) preally have a

Re: [boost] Re: Interest in multiindex_set?(again)

2003-07-11 Thread Joaquín Mª López Muñoz
Jeremy Maitin-Shepard ha escrito: [...] find(key) and related search memfuns are already supported in the way you suggest! Look for special lookup operations in the documentation. Matter of fact, the operations provided are even more powerful in that they allow for alternative

[boost] Bug in Boost.Threads condition_impl::notify_all

2003-07-11 Thread Michael Glassford
A while back there was a thread about a bug in notify_all that causes it not to release the mutex and semaphore under some circumstances. For what it's worth, I just noticed that, although this has been fixed in the main branch of CVS, it still exists in the thread_dev branch. Mike

RE: [boost] Re: mpl/loki

2003-07-11 Thread Drazen DOTLIC
Just a note: Loki (generic programming applied to design patterns) and MPL (C++ template metaprogramming) preally have a different focus; you may yet find some Loki components that are useful to you. That's possible, but hasn't happened up to now. Actually, I had to replace loki with several

Re: [boost] mpl/loki

2003-07-11 Thread Aleksey Gurtovoy
Drazen DOTLIC wrote: Hello, Hi Drazen, I've recently discovered that mpl provides all the functionality I was previously using from loki, so I decided to switch. There is one small thing driving me crazy, and I was wondering if I missed something... I was using loki's TypeAtNonStrict

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
Jens Maurer [EMAIL PROTECTED] writes: The new iterator adaptors appear to have been checked in to the main boost CVS. The boost build setup appears not to take header-file dependencies between libraries into account. In what sense? If a C++ source file includes a header (even indirectly)

[boost] Re: intrusive_ptr does not compile under MSVC 6 + STLPort

2003-07-11 Thread David Abrahams
Stefan Slapeta [EMAIL PROTECTED] writes: ... and the reason is that this Boost workaround # if BOOST_WORKAROUND(BOOST_MSVC, = 1200 __SGI_STL_PORT) does never apply as config.hpp is not included and therefore BOOST_MSVC IS NOT SET!!! You have to manually include config.hpp before

[boost] Re: mpl/loki

2003-07-11 Thread David Abrahams
Drazen DOTLIC [EMAIL PROTECTED] writes: Might I suggest you get ahold of Leor Zolman's latest STLFilt package (www.bdsoft.com)? It contains some great features for formatting nested templates so that they are readable. Thanks, I knew about Leor's package and used it in the old days (VC6),

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
Jens Maurer [EMAIL PROTECTED] writes: The following libraries are now broken and should be fixed: - filesystem - graph - multi_array - random_demo - signals - tokenizer - utility What problems are you having with the utility lib? I don't see any. -- Dave Abrahams Boost

[boost] Re: mpl/loki

2003-07-11 Thread David Abrahams
Drazen DOTLIC [EMAIL PROTECTED] writes: Btw, VC7.1 does not seem to like identity in this (and David's) scenario - it complains that it does not have inner typedef to type, even though it does. Can you please post a small example which fails? Thanks, Dave -- Dave Abrahams Boost

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
David Abrahams [EMAIL PROTECTED] writes: Jens Maurer [EMAIL PROTECTED] writes: The following libraries are now broken and should be fixed: - filesystem - graph I'm doing the fixes to the graph library. BTW, CWPro8 picks up *reams* of bugs in this library which have nothing to do with

[boost] Re: mpl/loki

2003-07-11 Thread David Abrahams
Drazen DOTLIC [EMAIL PROTECTED] writes: Yes, but leor's package has been much improved and provides things VC7.1 does not. See http://www.bdsoft.com/dist/gccmeta-demo.txt I don't know if you've seen VC7.1 error reports Of course I have. I wouldn't say that STLFilt improves on it if I

RE: [boost] Re: Re: test_fp_comparisons and rounding errors

2003-07-11 Thread Rozental, Gennadiy
This is what BOOST_CHECK_CLOSE is doing basically. Yes, that's the point. What I proposed is that the user can combine the macro with the comparator (I changed the macro name), because the comparison method is often application specific. I suggested to have an absolute error comparator

RE: [boost] Re: Re: test_fp_comparisons and rounding errors

2003-07-11 Thread Rozental, Gennadiy
Do I understand correctly that BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); would check that the absolute difference between v1 and v2 is not more than two eps? Paul No. BOOST_CHECK_CLOSE performs relative errors comparison. See

RE: [boost] Re: mpl/loki

2003-07-11 Thread Drazen DOTLIC
Btw, VC7.1 does not seem to like identity in this (and David's) scenario - it complains that it does not have inner typedef to type, even though it does. Can you please post a small example which fails? Well, your own :) from few hours ago, used something like this (btw, I am using

[boost] Proposed smart_handle library

2003-07-11 Thread John Madsen
Starting from the smart_ptr headers (shared, scoped, and weak), I've created corresponding handle classes. The motivation is to provide RAII semantics for handle based resources. Windows' HANDLEs, FILE*s, and file descriptors are the most obvious examples. There are two main differences

Re: [boost] New iterator adaptors and bjam builds

2003-07-11 Thread Jens Maurer
David Abrahams wrote: What problems are you having with the utility lib? I don't see any. Looking at my Linux regression test results, there's plenty of lines with utility in the first column and *_iterator_example in the second, which says Fail for all the compilers. Those are probably

Re: [boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread Jens Maurer
David Abrahams wrote: In what sense? If a C++ source file includes a header (even indirectly) and the header changes, the source file should be recompiled. No recompilation is neccessary just because an application links to a built library whose sources include a header file that changed.

[boost] Boost.Graph bugs

2003-07-11 Thread David Abrahams
I have updated Boost.Graph to use the new iterator adaptors, except for the LEDA and standford graph support stuff: I lack the neccessary headers to test it. Some of the bugs uncovered by CWPro8 are serious, and some don't even have a resolution that I can see. For example: *

[boost] Re: mpl/loki

2003-07-11 Thread David Abrahams
Drazen DOTLIC [EMAIL PROTECTED] writes: Blatant copy from your mail plus small typo (size_t_c to size_t only) corrected: template class S, class N struct type_at_non_strict : mpl::apply_if mpl::greatermpl::sizeS,N , mpl::atS,N ,

Re: [boost] Proposed smart_handle library

2003-07-11 Thread Larry Evans
John Madsen wrote: Starting from the smart_ptr headers (shared, scoped, and weak), I've created corresponding handle classes. The motivation is to provide RAII semantics for handle based resources. Windows' HANDLEs, FILE*s, and file descriptors are the most obvious examples. [snip] I'd

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
Jens Maurer [EMAIL PROTECTED] writes: David Abrahams wrote: What problems are you having with the utility lib? I don't see any. Looking at my Linux regression test results, there's plenty of lines with utility in the first column and *_iterator_example in the second, which says Fail for

Re: [boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread Jens Maurer
David Abrahams wrote: That's really odd. Everything works perfectly on my machine with gcc-3.2 and CWPro8.3 except for a numeric_traits_test failure with gcc-3.2 and that has no relation to iterator_adaptors. I can't believe it. Very strange. I've just removed libs/utility and re-cvs

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
Jens Maurer [EMAIL PROTECTED] writes: David Abrahams wrote: That's really odd. Everything works perfectly on my machine with gcc-3.2 and CWPro8.3 except for a numeric_traits_test failure with gcc-3.2 and that has no relation to iterator_adaptors. I can't believe it. Very strange. I've

Re: [boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread Joel de Guzman
David Abrahams [EMAIL PROTECTED] wrote: Jens Maurer [EMAIL PROTECTED] writes: May I suggest that you remove (for example) (ALL_LOCATE_TARGET)/status/bin/transform_iterator_example.test No wonder! That's not the utility suite; that's the iterator_adaptors suite. Mostly an easy fix.

Re: [boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread Beman Dawes
At 01:27 PM 7/11/2003, David Abrahams wrote: Jens Maurer [EMAIL PROTECTED] writes: The following libraries are now broken and should be fixed: - filesystem - graph - multi_array - random_demo - signals - tokenizer - utility What problems are you having with the utility lib? I

Re: [boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread Joel de Guzman
Beman Dawes [EMAIL PROTECTED] wrote: At 01:27 PM 7/11/2003, David Abrahams wrote: Jens Maurer [EMAIL PROTECTED] writes: There seem to be a number of files in boost-root/libs/utility that are holdovers from the prior version of iterator adaptors. I'll fix this situation. Is the plan to

[boost] Re: New iterator adaptors and bjam builds

2003-07-11 Thread David Abrahams
Beman Dawes [EMAIL PROTECTED] writes: At 01:27 PM 7/11/2003, David Abrahams wrote: Jens Maurer [EMAIL PROTECTED] writes: The following libraries are now broken and should be fixed: - filesystem - graph - multi_array - random_demo - signals - tokenizer -