- Boost - lists.boost.org

RE: [boost] Re: Re: Typeof: Review result
by Brian Braatz 07 Jun '05

07 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Paul A Bristow > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | Subject: RE: [boost] Re: Re: Typeof: Review result > | > | It is not something one slaps together just to get their > | name in lights (to me at least). A boost library makes you go > | "Wow". if it doesn't make you go "Wow" it doesn't belong in boost. > [Paul A Bristow Writes:] > WOW! - What a elistist view! > > Nothing WOW about STATIC_ASSERT (for example) - but not just useful but > invaluable. > [Brian Braatz Writes:] 1- I was stating how I PERSONALLY felt about the issue. 2- The problem with thinking in the "wow" paradigm, is that is relative. STATIC_ASSERT has a wow factor to it for many. For some it does not. > IMO Boost library is about USEFULNESS and QUALITY. > [Brian Braatz Writes:] Add "efficiency" and you just described where the "wow" comes from :) > Quality code that starts by peer review AND because it is well exercised > by > lots of users on lots of different environments, and is amended often, > so is likely to be as correct as can be and as portable as practical. > [Brian Braatz Writes:] Yes > And nobody gets their names in lights - just a bucket load of hassle > manipulating their code for all the non-compliant compilers. > > Paul [Brian Braatz Writes:] HAHAHAH The underlying truth shows itself :).

1 0

[shared_ptr] dealing with shared_ptr and cycles
by Lorenzo Bettini 07 Jun '05

07 Jun '05

Hi I have this simple program, that has a class with a shared pointer to another object of the same type: #include <boost/shared_ptr.hpp> #include <string> #include <iostream> using namespace std; class C; typedef boost::shared_ptr<C> CP; class C { private: string s; CP cp; public: C(const string &ss, CP c = CP()) : s(ss), cp(c) {} void set(CP c) { cp = c; } ~C() { cout << "deleting C" << endl; } }; int main() { CP cp = CP(new C("C")); CP cp2 = CP(new C("C2")); cp->set(cp2); //cp->set(cp); cout << "use_count: " << cp.use_count() << endl;; return 0; } if I remove the comment for cp->set(cp), i.e., I set the shared_pointer to itself, there's a cycle, and thus use_count returns 2, and the object cp is never deleted (shown also by using valgrind). This is a simple program just to reproduce a much more complex situation with a data structure that deals with mutual recursive references. I do not know in advance whether the shared pointer refers to the same object or to another different object (for instance I perform also cp->set(cp2)). Now, the documentation (http://www.boost.org/libs/smart_ptr/shared_ptr.htm) says that "Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed. For example, if main() holds a shared_ptr to A, which directly or indirectly holds a shared_ptr back to A, A's use count will be 2. Destruction of the original shared_ptr will leave A dangling with a use count of 1. Use weak_ptr to "break cycles."" However, it is not clear to me how to use weak_ptr in this context... can some one provide some clue, please? many thanks in advance Lorenzo

6 13

RE: [boost] Re: serialization of objects with overloaded new/delete
by Andreas Brinck 07 Jun '05

07 Jun '05

Hi, > For this to work, one needs a SFINAE compiler, right? yes, perhaps the code could be modified to use the boost::enable_if utility to make it a bit clearer what's going on. > I faintly remember that early versions of the documentation (during > review) described a completely different type of support for classes > with operator new. I don't recall the details but I believe > that one was > able to specialize a template for types with operator new. > While being > slightly more cumbersome, this sort of support would work > with virtually > any compiler, not just the ones that support SFINAE. It would be > interesting to hear why this kind of operator new support was > discontinued later. I think you answered your own question. Judging from the lack of responses to my post, serializing objects with overloaded new doesn't seem to be important to most people. I guess the maintainers of the library didn't want to complicate the interface to accomodate a small minority of users. The SFINAE principle is probably the best way to handle it right now. Regards /Andreas Brinck ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.f-secure.com/

2 1

[call traits] patch for Borland BCB6
by AlisdairM 07 Jun '05

07 Jun '05

The version check in the existing Borland workaround has not been kept up to date - see patch below: cvs diff -w boost\detail\call_traits.hpp (in directory D:\Projects\boost) Index: boost/detail/call_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/call_traits.hpp,v retrieving revision 1.13 diff -w -r1.13 call_traits.hpp 94c94 < #if defined(__BORLANDC__) && (__BORLANDC__ <= 0x560) --- > #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564 ) ) -- AlisdairM

2 1

Re: [boost] Re: Boost Array Initialization Technique
by brangdon＠cix.compulink.co.uk 07 Jun '05

07 Jun '05

In-Reply-To: <d80vqg$i5u$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > Dave's email program has broken the threading Has it? In my browser my comments are posted to the intended part of the thread. Some of the replies have gone amiss, and some haven't. Specifically Jonathan Turkanis's replies to me have been misthreaded, but his replies to other people have too. I figured that was his email program, not mine. Are you seeing something different? My apologies to the list if so. If there is a diagnosable problem with my software I can contact the author. Feel free to reply directly if this is off-topic. -- Dave Harris, Nottingham, UK.

3 2

Borland patch for Boost Test
by AlisdairM 07 Jun '05

07 Jun '05

THe following patch should allow Borland BCB6 to pass the boost_check_equal_str test case. The problem appears to be pointer-decay of arrays. cvs diff -w boost\test\test_tools.hpp (in directory D:\Projects\boost) Index: boost/test/test_tools.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/test_tools.hpp,v retrieving revision 1.53 diff -w -r1.53 test_tools.hpp 285a286,296 > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > template<typename T, std::size_t N > > struct print_log_value< T[N] > { > void operator()( std::ostream& ostr, T const* t ) > { > ostr << t; // by default print the value > } > }; > > #endif > 333a345,354 > #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) > // Borland suffers premature pointer decay passing arrays by reference > template<typename T, std::size_t N > > struct print_helper_t< T[ N ] > { > explicit print_helper_t( T const * t ) : m_t( t ) {} > > T const * m_t; > }; > > #endif -- AlisdairM

2 1

boost book error
by Dirk Griffioen 07 Jun '05

07 Jun '05

Hi, At the moment I get the following error when I try to run my boostbook setup: xslt-xsltproc bin\msvc\debug\threading-multi\moip.doxygen.docbook xslt-xsltproc-dir html\HTML.manifest warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl" compilation error: file file:///G%3A/dev_/stl/boost_1_32_0/tools/boostbook/xsl/html.xsl line 8 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk-common.xs Last saturday everything was fine. There's no firewall etc between me and http:// Has anything canged? Should I update to a newer version? Hope anyone can help, Dirk Griffioen

1 0

RE: [boost] Re: Re: Typeof: Review result
by Brian Braatz 07 Jun '05

07 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > Sent: Monday, June 06, 2005 4:53 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Typeof: Review result > > Brian Braatz wrote: > > > Here is an idea: what-cha think- We should add a "Wow" factor to the > > lib review template. > > > > I dunno, maybe something like > > > > "Rate the WOW factor of this library:(1-5)" > > > > (now that I have made the suggestion, here comes the controversy > > (grin)) > > > > the question then becomes what if a library, gets all 1's. Does it > > still get accepted? I say no, there are plenty of "YET-ANOTHER-X" > libraries > > out there already. > > > > I say, (more controversy) that something can have a semi-boring > > functional use, but it's implementation, at the very least should have > > some "Wow" in it. > > Most people seems to agree we need a bigint library. Somehow I'm skeptical > we > can find one with a WOW factor above 2. ;-) > > Jonathan > [Brian Braatz Writes:] Hmm.. ON a serious note. It might be worth just "Capturing" the WOW factor, and using that as one piece of the "do we accept" or not puzzle.

1 0

RE: [boost] Re: Re: Typeof: Review result
by Brian Braatz 07 Jun '05

07 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > > Brian Braatz wrote: > > > Here is an idea: what-cha think- We should add a "Wow" factor to the > > lib review template. > > > > I dunno, maybe something like > > > > "Rate the WOW factor of this library:(1-5)" > > > > (now that I have made the suggestion, here comes the controversy > > (grin)) > > > > the question then becomes what if a library, gets all 1's. Does it > > still get accepted? I say no, there are plenty of "YET-ANOTHER-X" > libraries > > out there already. > > > > I say, (more controversy) that something can have a semi-boring > > functional use, but it's implementation, at the very least should have > > some "Wow" in it. > > Most people seems to agree we need a bigint library. Somehow I'm skeptical > we > can find one with a WOW factor above 2. ;-) > > Jonathan > [Brian Braatz Writes:] Oh I dunno, to me a big int is EXCITING (grin). :) (yes your point is in alignment with the second point I made against my own suggestion)

1 0

Re: [boost] Re: Re: Boost Array Initialization Technique
by brangdon＠cix.compulink.co.uk 07 Jun '05

07 Jun '05

In-Reply-To: <d80h47$irf$1(a)sea.gmane.org> technews(a)kangaroologic.com (Jonathan Turkanis) wrote (abridged): > array can't be given constructors without sacrificing the aggregate > initialization syntax. OK... although I'd rather have constructors than aggregate initialisation syntax. If the problem is performance, surely the compiler can optimise away the difference (given that it's a standard library component with known semantics)? Anyway, it sounds like this battle is already lost. Is there a rational for not allowing zero-sized arrays? What is the intended semantics of: array<int> a; // Or array<int,0>. assert( a.empty() ); ? Isn't this kind of thing likely to occur in generic template code? -- Dave Harris, Nottingham, UK.

4 4