January 2005 - Boost - lists.preview.boost.org

Release 1.33
by Robert Ramey 10 Feb '05

10 Feb '05

I would hope that soon we might think of releasing an updated version of boost - 1.33 As far as I know this might include a)bug fixes for herefore untested combinations of compilers, varients, etc b)Jonathon Turkanis stream bufffer library c)Other libraries (Ranges?) d)Serialization library - bugfixes and DLL version Robert Ramey

6 15

Checking out latest Boost lock problem
by Edward Diener 09 Feb '05

09 Feb '05

Attempting to check out the latest Boost I am being stopped by: cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc

22 57

io state and multi-restore
by Gennadiy Rozental 08 Feb '05

08 Feb '05

Is there a way to use io state savers in single save/multiple restore mode? Gennadiy

3 9

Boost 1.32 patches for IBM z/Series S390 Linux
by Jonathan Biggar 08 Feb '05

08 Feb '05

Attached are a couple of patches needed to compile boost 1.32 on S390 running Linux. Can someone apply these to the boost source? -- Jon Biggar Levanta jon(a)levanta.com --- boost/detail/limits.hpp Thu Feb 26 10:26:47 2004 +++ boost/detail/limits.hpp.new Sat Jan 29 13:56:49 2005 @@ -49,7 +49,7 @@ // The macros are not named appropriately. We don't care about integer // bit layout, but about floating-point NaN (etc.) bit patterns. -#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) +#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__s390__) #define BOOST_BIG_ENDIAN #elif defined(__i386__) || defined(__alpha__) || defined(__ia64) || defined(__ia64__) #define BOOST_LITTLE_ENDIAN --- tools/build/v1/gcc-tools.jam Fri Jan 28 21:00:04 2005 +++ tools/build/v1/gcc-tools.jam.new Fri Jan 28 20:55:18 2005 @@ -297,6 +297,11 @@ flags gcc CFLAGS <address-model>32 : -mgp32 ; flags gcc CFLAGS <address-model>64 : -mgp64 -mlong64 ; } +#S390 +if $(OSPLAT) = 390 +{ + flags gcc CFLAGS <threading>multi : -D_REENTRANT ; +} # # define compiler names if not set:

6 15

boost::program_options extensions
by Preston A. Elder 08 Feb '05

08 Feb '05

I've been working with boost::options, and these is one gaping hole in it, that I have noticed. There is no way to use a custom converter in the default po::typed_value class. This is such a flaw, I've actually copied typed_value, and created one that accepts a function of parser(), which you would supply a boost::function2<void, boost::any &, const std::vector<std::basic_string<charT> > & Why would I want to do this? I have created a bunch of generic converters that can be used for a number of things, from validation to translation. The ones I have so far are: validate_oneof - used as: value<T>()->parser(validate_oneof<T>(first_val) + second_val + third_val + fourth_val)) This will then ensure that the value supplied is one of these values (obviously validate_oneof is a class with an overridden operator+ and an operator() for calling). validate_range - used as: value<T>()->parser(validate_range<T>(first, last)) This will ensure that the value lies between these values. You might be able to achieve the same with notifiers, I don't know, but from here, it gets more interesting. validate_mapped - used as: value<T>()->parser(validate_mapped<K,T>(first_key, first_val) + std::make_pair(second_key, second_val) + std::make_pair(third_key, third_val)) This will then allow you to specify a value of one type, but have a different type stored. This is particularly useful to allow, say: LogLevel = info and then have that actually stored as an in (say, 5) in the values. I have others to do syntax validation too, so say validate_ipaddr which will ensure that it is a valid IP address before storing it, and so on. Again, I'm not sure how much notifiers would do this too. But also consider the following. A 'validator' that allows you to take an IP address as text, verify it is a valid IP address (hell, if someone wanted to add logic, verify it is within a certain range if they wanted to), and then store it as an in_addr_t. Or even better, a 'validator' that checks to see if 'http://' is prefixed to a web address, and either removes it or adds it, depending on what you need. A notifier might be able to catch bad values, but not change types or correct the data. And all in all, the change to do this was minimal, apart from adding the 'parser' function, my xparse function is simply: if (m_parser) m_parser(value_store, new_tokens) else validate(value_store, new_tokens, (T*) 0, 0); Feel free to e-mail me if you want my code, or want me to post it. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

2 8

Re: Problem with code in common_factor_ct.hpp
by David Abrahams 07 Feb '05

07 Feb '05

"John H. Spicer" <jhs(a)edg.com> writes: > This file includes the code below in an #else for > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. We give an error on that code because > of a missing "template" keyword (between :: and helper). > > What is the proper channel for reporting things like this? http://www.boost.org/more/bugs.htm shows several alternatives. > template < unsigned long Value2 > > struct helper > { > BOOST_STATIC_CONSTANT( unsigned long, value > = static_gcd_helper2_t<Value2>::helper<Value1 % Value2>::value ); > }; > -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Complex type failure with boost::lexical_cast
by Preston A. Elder 04 Feb '05

04 Feb '05

Hi, check out this code: #include <boost/lexical_cast.hpp> #include <iostream> struct my_type { int a; int b; }; template<typename C, typename T> std::basic_istream<C,T> &operator>>(std::basic_istream<C,T> &is, my_type &mt) { is >> mt.a >> mt.b; return is; } int main() { std::string input = "1 2"; my_type mt; try { mt = boost::lexical_cast<my_type>(s); std::cout << "TEST 1: " << mt.a << " " << mt.b << std::endl; } catch (boost::bad_lexical_cast &) { std::cout << "TEST 1 FAILED" << std::endl; } input = "3 4"; std::stringstream ss; ss << s; ss >> mt >> std::ws; if (ss.eof()) std::cout << "TEST 2: " << mt.a << " " << mt.b << std::endl; else std::cout << "TEST 1 FAILED" << std::endl; return 0; } The output I get is: TEST 1 FAILED TEST 2: 3 4 My investigation has shown that this occurs because boost::lexical_cast calls stream.unsetf(std::ios::skipws); My question is, why does it do this - as this specifically stops lexical_cast from working with complex types. So could this be an option, or completely disabled, or made an option (somehow) to lexical_cast? I understand some logic to not skipping whitespace, however I believe its use is limited - especially since there is a specialization for std::string and std::wstring already which does not even use operator>>. As a side note, yes, I could change my operator>>, however the sample operator>> above is typical for an operator>> for a complex class, almost always they assume that skipws is turned on, and don't bother checking. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

5 11

atomic_count on MSVC/Win32, Tim Fenders optimization
by Hauptmann Peter 04 Feb '05

04 Feb '05

Hi, I noticed that boost/detail/atomic_count.hpp uses the intrinsic verisons of _InterlockedIncrement, _InterlockedDecrement only for Win64 builds. is there a reason? it is documented for VC 2003 without target platform restrictions (and it's "known to work" on VC6, too). thanks peter __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

2 1

A swapping implementation of the C++ library
by Chris Jefferson 04 Feb '05

04 Feb '05

While this isn't strictly related to the development of boost, I believe it may be interesting to developers of boost, and I would also be very interested in hearing any opinions (good and bad) from users and developers of boost. I am currently in the process of implementing all applicable (sort, rotate, partition, etc..) functions in the C++ standard library using only calls to iter_swap. Obviously for those classes with expensive copies and cheap swaps (list, vector, map, set, etc) this is a big win, however it unfortunatly can be slightly slower for classes and types which fall on the basic definition of swap. Therefore there will be an implementation-specific type trait defined (name to be decided) which can be defined to enable the swapping versions of functions. I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library). While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements. I would be interested in knowing if anyone has any comments, and also should such code be implemented in g++ if boost would be willing to add the compiler-specific extra information to mark any classes with efficent swap as such. Note: I am aware there are various ways of trying to approximate if someone has specialised swap, such as checking for a swap member function. However at least at first, it is my belief such a library should probably be strictly op-in. Thank you, Chris

2 2

boost v 1.33 ?
by Robert Ramey 04 Feb '05

04 Feb '05

Could we consider fixing a date for boost 1.33. I would like to agree to just concentrate on fixes, tests and resolving pending issues regarding code currently checked into cvs.. I think this would be relatively painless - at least compared to the last time. Robert Ramey

8 19