July 2006 - Boost - lists.preview.boost.org

Re: [boost] [system] - std::terminate() called after throw system_error
by Oliver.Kowalke＠qimonda.com 25 Jul '06

25 Jul '06

Hello, please ignore my previous post - I forgott the try-catch block (what a shame). Oliver

1 0

Re: [boost] [system] system-0.2 request for comments
by Beman Dawes 25 Jul '06

25 Jul '06

On 7/22/06, Kim Barrett <kab(a)irobot.com> wrote: > At 12:10 PM -0400 7/22/06, Beman Dawes wrote: > >* Addition of a header boost/identifier.hpp. For years I've used a > >similar class to provide the type safety and freedom from unwanted > >conversions that is missing when a simple int is used for an identifier. > >This is logically separate from the system stuff, but for convenience is > >included in the system package since error_code.hpp uses it. > > This appears to be very similar in intent to the facility provided by > boost/strong_typedef.hpp, though there are significant differences in > detail. The intents of identifier.hpp and strong_typedef differ. A strong typedef retains all operations on the underlying type in the new type. An identifier only provides a very limited set of operations on the new type. That is so an operation like multiplication of an identifier, which is almost certainly an error, is not permitted and will be detected by the complier. It wouldn't surprise me if Boost has identifier.hpp functionality somewhere, but I'm not aware of anything. --Beman

2 1

Re: [boost] [system] system-0.2 request for comments
by Oliver.Kowalke＠qimonda.com 25 Jul '06

25 Jul '06

Hi, > ~/devTools/boost_cvs/libs/system/build$ bjam ...found 225 targets... > ...updating 14 targets... > gcc-C++-action > ../../../bin/boost/libs/system/build/libboost_system.a/gcc/deb > ug/error_code.o > ../src/error_code.cpp: In function > 'std::string<unnamed>::errno_md(const > boost::system::error_code&)': > ../src/error_code.cpp:190: error: invalid conversion from > 'char*' to 'int' > ///that's the while condition here... > > char buf[64]; > char * bp = buf; > std::size_t sz = sizeof(buf); > int result; > while ( (result = strerror_r( ec.value(), bp, sz )) == ERANGE ) > { > if ( sz > sizeof(buf) ) std::free( bp ); > sz *= 2; /* Reentrant version of `strerror'. There are 2 flavors of `strerror_r', GNU which returns the string and may or may not use the supplied temporary buffer and POSIX one which fills the string into the buffer. To use the POSIX version, -D_XOPEN_SOURCE=600 or -D_POSIX_C_SOURCE=200112L without -D_GNU_SOURCE is needed, otherwise the GNU version is preferred. */ Oliver

2 1

Who wants Borland support?
by David Abrahams 25 Jul '06

25 Jul '06

In 1.33.1, Boost.Parameter supported Borland. In 1.34, we are running into compiler bugs that we don't know how to avoid. Somehow the compiler is mis-deducing the return type of operator[] on line 328 of boost/parameter/aux_/arg_list.hpp (see http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i…) If we can't find a solution to this problem very soon we'll have to mark these tests as expected failures and drop support of Borland for 1.34, and we're stumped. I'm hoping someone who cares about Borland will help us come up with an answer. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 11

Ace??? (was: ANN: POCO - C++ Portable Components)
by Sohail Somani 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of val salamakha > > Look at Chapter 5 "The ACE Service Configurator Framework" in > "C++ Network Programming" v2 of D. Schmidt . The chapter is > about the subject of your discussion and explains how it works. I have yet to understand why I need to buy a textbook to use ACE. Tthe website is not that good. Not nearly as good as boost.

3 2

Re: [boost] [mpl] Metafunction terminology - revival?
by JOAQUIN LOPEZ MU?Z 24 Jul '06

24 Jul '06

----- Mensaje original ----- De: David Bergman <David.Bergman(a)bergmangupta.com> Fecha: Lunes, Julio 24, 2006 9:11 pm Asunto: Re: [boost] [mpl] Metafunction terminology - revival? > Joaquin wrote: > > [snip] > > > I've reread the referred page, and all I can take it to > > define is: a lambda expression is a metafunction class or a > > placeholder expression. Whether this is what the authors actually > > *meant* is debatable, of course. > > What I think it literally means is that a lambda expression is > either a metafunction class or a placeholder expression, much > like a woman is either nice or mean. This does NOT imply that all > nice people are women ;-) So, I think even the literal reading of > the refered sentence(s) leaves room for non-lambda-expressive > metafunction classes... "A woman is either nice or mean" is not a definition of the term "woman", yet the referred page stands for a definition of "lambda expression", so an "if and only if" implication is assumed. OK, Abrahams and Gurtovoy's book's chapter 3 has been webpublished at artima.com and there you can read the following: ( http://www.artima.com/cppsource/metafunctions2.html ) "We'll refer to metafunction classes like add_pointer_f and placeholder expressions like boost::add_pointer<_1> as lambda expressions." (add_pointer_f is a metafunction class defined a couple of paragraphs before.) Does this convince you? Anyway, we're not discussing Aristotle or Descartes, on the contrary we enjoy the presence of MPL authors amongst us and can always ask them directly. [This does not detract from the fact that your choice of terminology is probably superior, I'm only nitpicking you for the joy of discussion. I hope you're taking it similarly :) ] > [...] > > <pedantic digression> > > Just to play devil's advocate, what gives a lambda expression > > its essence, at least in mathematical lambda calculus, is not > > the presence of place holders, but the ability to apply to > > actual arguments, > > No, that is not true, actually, since that essence of > applicability is best captured by the notion of "function." A > lambda expression is a special type of function (or, rather, > lambda expressions are isomorphic to a set of functions...) I'd say lambda calculus captures aplicability better than the cartesian definition of function as a special subset of a product set AxB, but well, it's hard to argue this objectively. [...] > /David Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components)
by Sohail Somani 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick > Sent: Monday, July 24, 2006 2:29 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components) > > > -----Original Message----- > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > > Sent: Monday, July 24, 2006 5:18 PM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable > Components) > > > > POCO's documentation is fine, sometimes a method could > > deserve more explanation but it's still fine given the fact > > most of the classes are very intuitive. > > Boost documentation is usually excellent, which is mandatory > > because some classes are not intuitive at first sight. > > ACE's website is simply unfriendly and looks careless. > > Poco's documentation is 'ok', but the fact that the comments for all > methods are *below* the method declarations is a style disaster. [snip] Boost docs > * But seriously, I think more libraries documented like boost would be great :)

1 0

Re: [boost] Boost's future, one big download?
by Sohail Somani 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Monday, July 24, 2006 2:23 PM > To: boost(a)lists.boost.org > Subject: [boost] Boost's future, one big download? > > When I read posts like "proposal: boost library for african insect > classification" (joke) and things like that, I wonder what's > going to happen > to boost in the future. > Some boost libraries are already too specific and this seems > to be on the > rise. > Is boost going to be always a single download? > Is boost's goal to become a "code wikipedia"? I don't see any harm so long as the components are appropriately independent. The toughest would be if component X stopped working in the latest release, but you need Y from the latest release as a dependency for X or something silly like that. Hopefully the OSS nature of boost would help work around that. I personally haven't had an issue like that though I use a few boost libraries here and there.

1 0

Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components)
by Bennett, Patrick 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Monday, July 24, 2006 5:18 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components) > > POCO's documentation is fine, sometimes a method could > deserve more explanation but it's still fine given the fact > most of the classes are very intuitive. > Boost documentation is usually excellent, which is mandatory > because some classes are not intuitive at first sight. > ACE's website is simply unfriendly and looks careless. Poco's documentation is 'ok', but the fact that the comments for all methods are *below* the method declarations is a style disaster. Virtually no documentation or tagging tool will work with it. Its online documentation doesn't hotlink from parameter types, doesn't graphically show the relationships, doesn't show what implements and uses each method, etc. etc. Basically, things Doxygen does - which will never work with Poco's code. :( As for ACE, I fail to see what the web site for a library has to do with the quality of library itself. By that token, I guess no one should use GCC or many of the gnu tools for that matter. It also has several books available for it. This is a good thing, not a bad thing. Doxygen documentation for it is also generated nightly and is available at http://www.dre.vanderbilt.edu/Doxygen/ So what again does this all have to do with Boost? (not that I'm helping by replying to this thread) Patrick Bennett

1 0

Should we change the reply-to setting?
by Daryle Walker 24 Jul '06

24 Jul '06

Currently, the mailing list changes all the "reply-to" headers to the list's e-mail address. This forces all replies to go to the list and loses any custom e-mail address the sender may have added. I've read "'Reply-To' Munging Considered Harmful" <http://www.unicom.com/pw/reply-to-harmful.html> and now wonder if we should change our policy. (Unfortunately for me, I think I use that field from sorting my e-mail. So the list's e-mail should still be around in posts so I can sort them.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

10 20