April 2005 - Boost - lists.boost.org

lexical_cast with default value
by Dave Dribin 29 May '05

29 May '05

Hi all, I recently discovered lexical_cast, and it's very nice and elegant. I'd like to put in a feature request, though: the ability to use a default value rather than throwing an exception on conversion failure. Basically, it would take a second argument that would be the value returned if the conversion fails. This could be used directly in the example, like: std::vector<short> args; while(*++argv) { args.push_back(lexical_cast<short>(*argv, 0)); } This eliminates the throwing and catching of an exception for cases where conversion failure is not an exceptional. I've attached a patch to lexical_cast.hpp found in Boost 1.32.0 -Dave

6 18

Logging Library -- Formal Review Request
by John Torjo 22 May '05

22 May '05

Hi all, I've just updated the Boost Log Library: http://torjo.com/code/logging-v132.zip I would also like to ask for a _Formal Review_. The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

13 54

Big integer library
by Marcin Kalici�ski 19 May '05

19 May '05

Tracking the disussion on n1774 'Big integer library proposal for C++0x' I see there is a lot of controversy about it, and it will probably need much tweaking before (if ever) it is accepted. Wouldn't that be a good idea to have a big integer added to boost so that we can create a 'working practice' before anything gets standarised? I have some preliminary source code, some spare time, and would volunteer to work on it if there's enough interest. cheers, M.

11 10

xpressive not in boost.1.33, but what about 1.34?
by Bronek Kozicki 19 May '05

19 May '05

I suppose xpressive has not been accepted into boost yet (or I missed library review). This would mean that we will not see it in boost 1.33. Is there any chance we would see it in boost 1.34? B. -- Bronek Kozicki brok(a)rubikon.pl http://b.kozicki.pl/

8 13

operators.hpp bugs
by Søren Lassen 17 May '05

17 May '05

I have found a couple of "undocumented features" in operators.hpp: 1) The return values from a lot of the binary operators should be declared const, so that it is not possible to assign to the temporary object that results from the operation. An example: if(!(a/b=c/d))... This statement is obviously a typo. The assignment operator= should have been a comparison operator==. With the current definition of operator/ in operators.hpp, the compiler will not recognize this as an error. Instead, the following will happen: first, the values of a/b and b/c are calculated and placed in temporary objects. Then, the result of a/b is overwritten by the result of c/d. Finally, operator! converts that to a boolean and the if statement acts on it (in other words, the statement is probably interpreted as "if(!c)..."). If, on the other hand, the return value from operator/ is declared constant, the compiler will catch the error, and probably say something like "lvalue required". Much better. 2) I think the "Named Return Value Optimization" code is a misunderstanding. The way I read the excerpts from the C++ standard quoted in the documentation (see http://www.boost.org/libs/utility/operators.htm#symmetry) is as follows: The standard places some limits on when NAMED objects may be optimized away. From this follows implicitly that UNNAMED objects may always be optimized away. Or, to quote from Scott Meyers' "More Effective C++", page 109-110: "However, the fact remains that unnamed objects have historically been easier to eliminate than named objects, so when faced with a choice between a named object and a temporary object, you may be better off using the temporary. It should never cost you more than its named collegue, and, especially with older compilers, it may cost you less". In other words: some compilers may not have Named Return Value Optimization, but most of them have (Unnamed) Return Value Optimization, which means that temporary, unnamed objects are optimized away where possible. So, I think, a better way of writing e.g. operator+ is the good old-fashioned: template <class T> inline const T operator+(const T& lhs,const T& rhs) {return T(lhs) += rhs;}; 3) When using compilers that do not support operators in namespaces (#ifdef BOOST_NO_OPERATORS_IN_NAMESPACE), the operator templates are first placed in the global namespace, and then copied to the boost namespace. The consequence of this is that it is not possible to access the templates with a "using namespace boost;" declaration - trying to do so creates an ambiguity between the stuff in boost and the stuff in the global namespace. Also, of course, the global namespace is "polluted" with quite a lot of extra names. The solution to this problem is to declare all the templates inside a "pseudo-namespace" struct in the global namespace - this also makes it easier to import the templates into boost, as even the Borland compiler now recognizes a "using" declaration. I have uploaded a new version of "operators.hpp" with fixes for above-mentioned problems to the sandbox vault. It has been tested with "rational.hpp" on the Borland 5.5 compiler and the Microsoft version 13.10.3077 compiler (the one that comes with the free Visual Toolkit 2003, and also (I think) with Visual C++ 7.1). I hope that some of you have time to test my new version with other programs and compilers. --- Søren

5 20

Re: [boost] Visual Studio 2005 Beta 2 + Multi Index
by JOAQUIN LOPEZ MU?Z 16 May '05

16 May '05

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Domingo, Abril 24, 2005 2:07 pm Asunto: Re: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > ----- Mensaje original ----- > De: Gordon Smith <schmoo2k(a)hotmail.com> > Fecha: Viernes, Abril 22, 2005 5:43 pm > Asunto: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > The following stdafx.h for a vanilla console app kills the beta > 2 > > compiler > > (I think it creates a corrupt PCH file): > > > > #pragma once > > > > #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from > > Windows > > headers > > #include <windows.h> > > #include <tchar.h> > > > > // BOOST --- > > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/multi_index/ordered_index.hpp> > > > > Hi Gordon, excuse my late answering, somehow I just didn't see > your post amidst the current flow of messages. > > Did this work for MSVC 8.0 beta 1? I'm afraid I cannot help > much here except suggest that you try to report this to > the MSVC dev team: > > http://lab.msdn.microsoft.com/productfeedback/ > > Also, please try deleting all intermediate files before > doing a fresh compile --this is sometimes helpful specially > in regard to PCHs. If you make any progress or need some > help please keep me informed. > > Also, I forgot to mention: did you play with the /Zm option? http://msdn2.microsoft.com/library/bdscwf1c(en-us,vs.80).aspx Please keep me informed. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: (Named) Parameter Library
by Cromwell Enage 15 May '05

15 May '05

BTW, the include guards in <boost/parameter/macros.hpp> are all near the end of the file. I'll presume that's not where they should be? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[ptr_container] memory usage causes problem with regression tests
by Martin Wille 12 May '05

12 May '05

Hello, for approximately a week now, I'm experiencing crashes when I run the regression tests. Victor told me he also noticed tests consuming unusual amounts of memory. I think I now found the culprit: the ptr_container test suite. This is the second time I notice the kernel run out of memory when once of the ptr_container tests is run. This is a problem for running the tests since the kernel then starts to kill processes. So this needs to get fixed ASAP. The ptr_set test output is: *** glibc detected *** free(): invalid pointer: 0x14347b4c *** Running 1 test case... unknown location(0): fatal error in "test_set": signal: SIGABRT (application abort requested) *** errors detected in test suite "Pointer Container Test Suite"; see standard output for details We need a way of portably specifying and enforcing time and memory limits for tests (it's not the first time I've been hit by tests running wild). We also need the authors of tests to make use of that feature, once we have it. I think displaying the time and memory used by a test in the regression results would be helpful (requires changes to Boost.Build, too, obviously). In this special case, it also would have been helpful if absolute times were printed in the output of Boost.Build, since all I have is the time-stamp from the error messages of the kernel but no way of correlating this time-stamp with the regression tests except for incidentally looking at the screen when the crashes happen. Regards, m

3 7

Formal Review: FOREACH macro
by Gennadiy Rozental 09 May '05

09 May '05

The formal review of Eric Nibbler's FOREACH macro starts today, April 25, and will continue until Monday, May 1st. I will be serving as review manager. BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. The library is available at: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler foreach.zip Please note that the documentation is also available separately from the sources. It also can be viewed online at: http://boost-sandbox.sourceforge.net/libs/foreach The library is known to work (with different compliance levels) at least on the following compilers: * Visual C++ 7.1 * Visual C++ Whidbey Beta * Visual C++ 7.0 * Visual C++ 6.0 * gcc 3.3.3 * Intel for Windows 8.0 * Intel for Windows 7.0 * Comeau 4.3.3 When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. Gennadiy

36 141

Re: [boost] (Named) Parameter Library
by Cromwell Enage 09 May '05

09 May '05

Daniel Wallin wrote: > Yes, that's correct. Although the code has been moved > to the Boost CVS and the namespace has been changed > to 'parameter'. Oh, that's where it is, now. Cool! A second look at the new code revealed that much of the type-extraction functionality I sought has already been implemented in <boost/parameter/aux_/arg_list.hpp>, under the nested struct 'key_value_type' (lines 71-78 and 186-196). However, this struct is defined only for older compilers. Can the definitions be moved out of the conditional macro blocks? That way, a type-extraction metafunction like the following would work: template < class ArgList, class KW, class Default > struct get_key_value_type : mpl::apply2< typename ArgList::key_value_type , KW , Default > { } > Thank you. I've merged your macro change into the > trunk, but I'm holding off the type-extraction code > until we have completed the changes we are currently > working on. No problem. Just don't take too long! My multi-state mazes project makes heavy use of this library. I'm currently working on documentation and a 2-D demo, and I hope to release it to the OS community in three or four weeks. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1