- Boost - lists.boost.org

[boost/limits.hpp]bug? missing CHAR_BIT
by Larry Evans 21 Aug '07

21 Aug '07

When just: #include <boost/limits.hpp> is just preprocessed, the output contains no definition of CHAR_BIT; yet, it's used (although within a #if..#endif) within limits.hpp. Limits.hpp does contain: #ifdef BOOST_NO_LIMITS # include <boost/detail/limits.hpp> #else # include <limits> #endif which makes me wonder, since CHAR_BIT is used below this code, whether the authors expected CHAR_BIT to be defined at this point? BTW, CHAR_BIT is defined in system header, limits.h. The reason it hasn't caused a problem so far was explained in another post: http://archives.free.net.ph/message/20070820.174844.ac9e6b8d.en.html

2 1

[cgi] Testing cgi
by Christian Henning 20 Aug '07

20 Aug '07

Hi there, is't it possible to create test programs, already? I just tried to include the boost/cgi.hpp and I'm getting compile errors: c:\boost-sandbox\SOC\2007\cgi\boost\cgi\basic_request.hpp(559) : error C3855: 'cgi::basic_request': template parameter 'ProtocolService' is incompatible with the declaration c:\boost-sandbox\SOC\2007\cgi\boost\cgi\basic_request.hpp(559) : error C3855: 'cgi::basic_request': template parameter 'Role' is incompatible with the declaration c:\boost-sandbox\SOC\2007\cgi\boost\cgi\request.hpp(17) : error C2955: 'cgi::basic_request' : use of class template requires template argument list c:\boost-sandbox\SOC\2007\cgi\boost\cgi\basic_request.hpp(559) : see declaration of 'cgi::basic_request' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xlocmon(231) : fatal error C1903: unable to recover from previous error(s); stopping compilation I'm using VC7.1 with the latest Service Pack. Also, I'm using current boost trunk and I've updated the CGI code an hour ago. Regards, Christian

2 1

[Ann] Variadic Templates
by Doug Gregor 20 Aug '07

20 Aug '07

Hello Fellow Boosters, I have just completed implementing support for "Variadic Templates" in GCC. Variadic templates are C++ templates that can accept any number of "extra" template arguments, just like a function that uses C-style varargs (with "...") can accept any number of extra arguments. Unlike C varags, however, variadic templates work both for class templates and function templates, and are completely type-safe. Why do variadic templates matter for Boost? For one thing, they will allow us to eliminate the use of preprocessor metaprogramming in many, many places throughout the library. This can simplify our library implementations drastically, and eliminate those annoying "caps" on the number of arguments one can use (ever tried to use bind () with 11 arguments?). Beyond that, variadic templates are just plain fun, and there are undoubtedly a great number of metaprogramming applications. Here are a few teasers to illustrate what variadic templates can do: We can implement an MPL-like type vector with one line of code: template<typename... Types> struct vector { }; The "ellipsis" means that we can pack any number of arguments into the "template parameter pack" called Types. Of course, we can do the same for MPL's vector_c: template<typename T, T... Values> struct vector_c { }; Unimpressed? Here's an implementation of tuple that accepts any number of element types: template<typename... Values> class tuple; template<> class tuple<> { }; template<typename Head, typename... Tail> class tuple<Head, Tail...> : private tuple<Tail...> { protected: Head m_head; }; We're using recursion to build up the tuple. The ellipsis operator works with partial specializations, too, packing together "extra" arguments at the end. Of course, all of this would be useless if we couldn't write some of the other tuple operations, like operator==: inline bool operator==(const tuple<>&, const tuple<>&) { return true; } template<typename T, typename... TTail, typename U, typename... UTail> bool operator==(const tuple<T, TTail...>& t, const tuple<U, UTail...>& u) { return t.head() == u.head() && t.tail() == u.tail(); } Variadic function templates can accept any number of function arguments, so we can now (finally!) implement a type-safe printf() without mangling the tried-and-true printf() syntax or restricting ourselves to POD types: void printf(const char* s) { while (*s) { if (*s == '%' && *++s != '%') throw std::runtime_error("invalid format string: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printf(const char* s, const T& value, const Args&... args) { while (*s) { if (*s == '%' && *++s != '%') { std::cout << value; return printf(++s, args...); } std::cout << *s++; throw std::runtime_error("extra arguments provided to printf"); } I've also built prototypes of of Function and Bind, among other things. The Bind example is especially interesting, and worth a read (see below) Interested? There is more information and a complete implementation in GCC available at: http://www.generic-programming.org/~dgregor/cpp/variadic- templates.html I've written two documents describing variadic templates in more detail: http://www.generic-programming.org/~dgregor/cpp/brief-intro.pdf : A brief introduction to variadic templates, that walks through the printf() implementation. http://www.generic-programming.org/~dgregor/cpp/variadic- templates.pdf : A complete proposal to introduce variadic templates into C++0x. This contains annotated versions of the tuple, function, and bind prototypes along with a detailed description of the capabilities of variadic templates. The GCC implementation is complete, supporting all of the features described in the proposal. I've used it for proof-of-concept implementations of several libraries. In the (near) future, I hope to introduce variadic templates support into the "official" GCC, but I need your help! Are variadic templates worthwhile? Will they help us build better, cleaner Boost libraries in the future? Should we bring variadic templates to the C++ committee, to enable better implementations of TR1 components and eliminate the need for much of the preprocessor metaprogramming we do today? Feedback is greatly appreciated. Cheers Doug Gregor Open Systems Lab @ Indiana University

20 39

Re: [boost] New Acknowldegement for RenderX
by Roman Kagarlitsky 20 Aug '07

20 Aug '07

> Doug Gregor <dgregor <at> osl.iu.edu> > On Aug 17, 2007, at 11:23 AM, Paul A Bristow wrote: > > Unless we had a central place where we built > Boost PDF documentation. > Ideally, we'd have an automated (nightly?) process > that built Boost documentation in PDF and HTML. > MetaComm is (was?) building the HTML; > we'd just need one license to build the PDF. > >> So on the grounds that it costs nothing to say thanks, I still feel >> it's the right thing to do. > > Makes it harder it ask for that one copy to build PDFs of Boost > documentation, if we've already given them the publicity in a public > acknowledgment. Doug, - try us. I hereby grant you permission to use XEP to format Boost project's documentation in server environment until our VP of Sales - Kevin Brown, contacts Boost and emails our formal license for such purpose. Kevin should do it either tonight or in several days (he's out of town). He will also send you a license for DevKit that includes API. I think you will find it useful. Let me know if you need anything else: Java PDF, Docbook PDF related tools: www.renderx.com/tools our new development - DiType: http://moin.renderx.com/rxwiki We always like to work with technology people who promote open standards. Roman Kagarlitsky, CEO www.renderx.com

6 12

[Probability] version 0.2.3 released
by Brook Milligan 20 Aug '07

20 Aug '07

In order to better motivate the need for the Boost Probability library, I have updated the documentation, which is accessible at http://biology.nmsu.edu/software/probability/ Although this constitutes a new release, the only difference is in documentation. As a result, the contents of v0.2.2 in the Boost Vault still reflect exactly the most recent release and I haven't uploaded a new copy. The new motivational example is taken from the problem of ascertaining the long-term trend of global climate. One database used to assess this is available from the NOAA National Climate Data Center (http://www.ncdc.noaa.gov/oa/climate/ghcn-monthly/index.php) It contains monthly data for thousands of stations worldwide, in many cases for decades. Today's version, for example, contains 590,543 records of mean temperature. A typical likelihood calculation evaluating a model of climate would involve a product of likelihoods across all of these records, almost certainly yielding a result on the order of 10^{-600,000} or less. Such numbers cannot be handled using typical floating point representations, so specialized solutions of some form are required. The natural method is to accumulate the sum of logarithms of likelihoods, rather than the product of likelihoods, across the dataset. This keeps the values within suitable bounds, but requires keeping track of the fact that different types of values (probabilities, likelihoods, and log likelihoods) are being used throughout a typical program. If these are all represented using native types, such as double, it is easy to lose track of the fact that they have different semantics. A real solution of this problem would include modules taking care of calculating the probability of each individual data record and modules taking care of accumulating that information across the records. The problem is complex enough that each of these responsibilities would realistically be divided across many units and it would not be unreasonable to expect development to be divided among many programmers. In such situations it is all too easy to lose track of what semantics apply to a specific value when the only information available in the code is the data type (e.g., double) which provides little help and some (perhaps untrustworthy) comments that may or may not be read and in any case cannot affect the compiler. Using the Probability library, one can encode the exact semantics using the type system in a way that lends itself to generic programming. The resulting clarity, safety, and maintainability is retained regardless of how large the code base becomes and how the operations are distributed across modules and/or programmers. As a result of these features, I feel that this library makes a significant contribution to solving a well-defined set of problems that occur in certain types of scientific programming and modeling. I hope you will take a serious look at its capabilities and provide me with further feedback. I am especially interested in improving the portability of the code and need testers with access to compilers other than g++. I look forward to your comments, suggestions, and general discussion. Thank you. Cheers, Brook

2 2

SVN commit emails per-project
by Vladimir Prus 20 Aug '07

20 Aug '07

Is there any way to have per-project SVN commit emails? Say, I'd like all commits in tools/jam and tools/build/v2 to go to a dedicated mailing list. We used to have boost-build(a)lists.sourceforge.net mailing list for that, but not it obviously does not work. Thanks, Volodya

3 3

[Important] Boost Subversion repository is now online
by Douglas Gregor 20 Aug '07

20 Aug '07

Hello all, The Boost Subversion repository is now back online. All of the files in CVS (including their histories) have been imported into the Subversion repository. CVS is still available for anonymous, read- only access for now, but will not be updated. The main Boost development branch is available via anonymous, read- only checkout at: http://svn.boost.org/svn/boost/trunk/ Or for developer read/write access at: https://svn.boost.org/svn/boost/trunk/ Information about accessing the Boost Subversion repository is available at: http://svn.boost.org/trac/boost/wiki/BoostSubversion Please report any problems to me to the main Boost list, and we will try to resolve them as quickly as possible. We still need help porting the regression-testing script over to use Subversion. See Trac ticket #1122: http://svn.boost.org/trac/boost/ticket/1122 Also, there is more documentation that will need to be updated within the Boost tree. - Doug Subversion tip: when you commit a change to Subversion that fixes ticket number NNN, include the text "Fixes #NNN" in your commit log. Trac will automatically close the ticket and cross-reference the commit with the ticket. See, for example, http://svn.boost.org/trac/ boost/changeset/38330

24 112

Re: [boost] ScopeExit Review Begins Today
by Küppers, Ben 20 Aug '07

20 Aug '07

Alexander, I understand your gripes about the lambda syntax, but to be perfectly frank, I have never used lambda expressions in combination with the scope guard (which is maybe why your arguments have so far been unable to convince me). My clean up actions tend to be trivial function calls or functors that don't require any lambda syntax. Moreover, I am convinced any lambda expression wouldn't get through our code inspection for exactly the reasons you bring up. However, I fear that I will face similar resistance to your syntax. It's hard to argue that a macro with (seemingly) un-typed arguments, a code block between curly braces followed by another macro, look anything like C++ (and arguing its correctness based on a future language standard probably won't do me much good either). I think the scope guard functionality is an essential tool for many programmers so its syntax needs to be accessible to the masses. A quick glimpse through some of the other reviews seems to indicate that I am not the only one with this concern. -Ben This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

Re: [boost] [GSoC][cgi] Status update.
by Peter Foley 20 Aug '07

20 Aug '07

Hi Darren, > Date: Sun, 19 Aug 2007 20:38:24 +0100 > From: "Darren Garvey" <lists.drrngrvy(a)googlemail.com> > Subject: Re: [boost] [GSoC][cgi] Status update. > To: boost(a)lists.boost.org > > > I have access to apache 1.3.*/2.* and lighttpd 1.4.*/1.5.* on windows, > cygwin and linux, but I haven't been testing on all of them yet since > there > are more fundamental things that need to be done first. :-( Thats ok. I was just curious what servers you had tested on. No need to apologise. Personally I would rather you implement the protocols then spend time testing against servers! ;) At the end of the day the end users (ie those interested in using the library) will test and provide feedback on how well it works. The main reason I was asking about support for IIS7, was it will be easier for me to test against this configuration (I am planning on setting up a virtual machine running server 2008 (I got a beta 3 disk at TechEd)). > > 2. Somewhat related to the above if the library code is > > portable will the FASTCGI support you are building in only support > pipes > > or will it also support TCP sockets? The reason I am asking is that > > IIS7 will be providing support for the FASTCGI protocol (see > > http://www.iis.net/default.aspx?tabid=1000051 for more info). > > > Currently Boost.Asio doesn't support pipes, so this library won't > either, so > it uses TCP sockets. It's undecided whether, when pipe support comes > about, > the use of the two will be a run-time or compile-time choice. Over the > summer the leaning has changed from run- to compile-time, but this is > debatable... At this point in time if I had to vote one way or another I would say I would use TCP sockets. The main reason for this would be for portability; Note: I am making the assumption that the support for pipes would be *nix only. Peter.

1 0

Re: [boost] [GSoC][cgi] Status update.
by Peter Foley 20 Aug '07

20 Aug '07

Darren, > Date: Sun, 19 Aug 2007 20:27:08 +0100 > From: "Darren Garvey" <lists.drrngrvy(a)googlemail.com> > Subject: Re: [boost] [GSoC][cgi] Status update. > To: boost(a)lists.boost.org *snip* > > The thing I've been wondering is about a single library dumping more > than > one namespace into the boost namespace, so you'd have boost::cgi, > boost::fcgi and boost::scgi. I guessed that idea would be shot down in > flames though. *snip* I am not sure what the boost policy or convention for putting stuff into the Boost namespace is but personally I think that having distinct namespaces for each type of protocol makes sense. Logically they are implementing different standards. I know there is some overlap in behaviour and use. Maybe this could be in a boost::cgi::common namespace and be pulled into each of the distinct namespaces. Peter.

1 0