- Boost - lists.boost.org

RE: [boost] Re: [function types] Formal Review begins today.
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 David Abrahams > > > > "Brilliance is a mastery of the obvious" <*>>> and documentation should > > seek to brilliantly expose the obvious over complicated subjects. > [David Abrahams Writes:] > Another thing: the author of documentation should (usually) disqualify > him- or herself from making judgements about understandability and > especially approachability. The problem is that once you understand > it, it's very hard to see the places where it fails to communicate to > someone who doesn't. [Brian Braatz Writes:] :) " The problem is that once you understand > it, it's very hard to see the places where it fails to communicate to > someone who doesn't." A RESOUNDING YES!!!!!!- And thank you David. This sentence is worthy of printing out and hanging on my wall. Or maybe I should make tee-shirts and hand them out at conferences. Or better yet, I could have stickers made and hand those out. Then anytime someone sees some documentation that fails to make sense to normal humans, they can slap the sticker on it and hand it back to the author.

1 0

boost cvs build failure: Unknown suffix
by Neal Becker 07 Jun '05

07 Jun '05

PYTHON_ROOT=/usr PYTHON_VERSION=2.4 bjam -sTOOLS=gcc stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). Unknown suffix on <@boost!libs!iostreams!build><<<<<<< - see UserObject rule in Jamfile(5).

1 1

[cvs] waiting for lock
by Pedro Lamarão 07 Jun '05

07 Jun '05

TortoiseCVS, while trying to update a working copy, has been telling me for more than an hour that it's "waiting for david_abrahams's lock in /cvsroot/boost/boost/libs/preprocessor/doc/headers/control". I'm not sure what that means besides me being currently incapable of cvs update. I'll keep trying for a while. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business

2 2

Liquidnet is using boost
by Max Khesin 07 Jun '05

07 Jun '05

Ok, I've been waiting to say this :-), thanks for putting this page together John! Liquidnet, a financial startup and last 5th fastest growing company according to Inc is using Boost. Libraries most used, in order of importance (as if I can really measure that): shared_ptr bind boost.python lexical_cast optional any tuple regards and keep up the great work, max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

[Iostreams] Fails to build on Windows
by Keith MacDonald 07 Jun '05

07 Jun '05

At the time of writing, Iostreams from CVS head still does not build on Windows XP, due to missing header files. The build starts with these comments: ****************************************************** Building Boost.Iostreams with bzip2 support disabled. HINT: define the environment variable BZIP2_SOURCE to point to the root directy of your bzip2 installation if you have one. For more options, consult the Boost.Iostreams documentation ****************************************************** ****************************************************** Building Boost.Iostreams with zlib and gzip support disabled. HINT: define the environment variable BZIP2_SOURCE to point to the root directy of your zlib installation if you have one. For more options, consult the Boost.Iostreams documentation ****************************************************** Presumably "BZIP2_SOURCE" should not effect both types of compression, and "directy" is a typo. Anyway, the following errors are then reported 8 times each: bzip2.cpp(14) : fatal error C1083: Cannot open include file: 'bzlib.h': No such file or directory zlib.cpp(14) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory The command line I used for the build was: bjam -sTOOLS=vc-8_0 -sICU_PATH=F:\Dev\icu-3.2 -sPYTHON_ROOT=C:\Apps\Python24 -sPYTHON_VERSION=2.4

3 8

RE: [boost] Re: [function types] Formal Review begins today.
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 Jody Hagins > > Well, in case you don't know MPL (although the primary audience most > > likely will) you can still have a look at the synopsis and look for > > the version with non-type template parameter... > > I would disagree with you here. Many boost users do not know MPL. Many > more probably have a cursory knowledge of MPL, but still need > documentation handy to make use of it. > > > > How do functors fit in here? If a class overloads operator(), is it > > > considered a function type? > > > > > > No. Is the definition really that unclear ? > > > > How could this probably work if operator() is a function template ? > > > > You can decompose a member function pointer to a parentheses operator > > (which implies it's already instantiated if it's a template > > function), though (after deduction or using some kind of typeof > > operator). > > No, it is clear, but I would think that some notes about operator(), > boost::function, and boost::lambda would be appropriate, since some > folks may want to use them in some ways related to function_types. > > > > > knowledge of the MPL. However, the docs seem to take too much for > > > granted, and make too many assumptions. I'd like to see more > > > detail, especially in the descriptions. > > > > What do you mean with "assumption" ? Preconditions on template > > arguments ? > > I think interface documentation should make the lowest common > assumptions. Not everyone is familiar with the types of problems this > library is trying to solve. I am sure you are not merely targeting an > audience of people who could implement this library themselves, but > those who would like this functionality without implementing the > details. > > FWIW, most boost libraries fail in this regard, in my opinion. Library > documentation should make as few assumptions about the knowledge and > experience of the user as possible. > [Brian Braatz Writes:] THANK YOU JODY- I was going to say that (grin). Allow me to add a suggestion. PICK YOUR TARGET person's skills. And then write your docs to that person. I would advocate - if you can pull it off- think about someone you know who has 2-3 years CPP experience. Think about how you would communicate your library to that person. Walk them through using the library and solving problems with the library. Assume the user knows VERY LITTLE about metaprogramming etc. Hope that helps, and thank you Jody for spending the time to write up your feedback :)

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 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