June 2005 - Boost - lists.boost.org

[1.33] recent check-ins break date-time serialization tests
by Jeff Garland 05 Jun '05

05 Jun '05

I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere... summary: http://tinyurl.com/ayl5j detailed example: http://tinyurl.com/e2pa5 Jeff

4 4

boost::lock_error - documentation bug
by Paul Groke 05 Jun '05

05 Jun '05

Hi everybody, there seems to be a bug in the documentation (or implementation?) of boost::lock_error. The documentation (http://www.boost.org/doc/html/lock_error.html) describes lock_error as: Synopsis: class lock_error : public std::logical_error { ... Whereas them implementation (1.32.0, thread/exceptions.hpp) declares boost::lock_error as derived from boost::thread_exception which is derived from std::exception and nothing more. Even assuming std::logic_error was ment (there is no class std::logical_error ) I'd say that's a documentation bug. I haven't looked through all the other exception classes defined by boost::thread ... maybe someone should :-) bye, Paul

1 0

RE: ICE ICE BABY! (my MPL code is ICEing)
by Brian Braatz 05 Jun '05

05 Jun '05

HAHAHAHA Nevermind. copy_col_if_in_dest<boost::mpl::at<src::typelist, boost::mpl::int_<0> >::type,src::typelist>(); instead of being src::typelist (which is a ref to the param of type src_t) it needs to be src_t::typelist. it was indeed something stupid- I am undecided as to which is more stupid. The fact that I didn't catch that or the fact that MSVC ICE'd on it...... sorry for bugging you guys > -----Original Message----- > From: Brian Braatz > Sent: Saturday, June 04, 2005 2:38 PM > To: 'boost(a)lists.boost.org' > Subject: ICE ICE BABY! (my MPL code is ICEing) > > Sitting in the backyard. > > Beautiful day, got up at 3am to get something figured out (for proposed > boost profiler \ introspection library). > > Good news is I figured out the MPL code needed to accomplish my goal. > After typing in an incremental version of the code, I got the dreaded > internal compiler error (ICE). > > I am chewing on this- and thought I would post it so to provide an > opportunity for someone to show how incredibly stupid I am because I did > something that was obviously wrong. (you can even rub my nose in it if you > like :) ) > > here is the code: > > I am tearing it apart\deconstructing to try to figure out what is kicking > in the ICE. (I am also going to try it with an eval_if (which I should be > using anyway) just to see what happens) > > I am using boost 1.32 and vc7.1 > > struct do_copy_col > { > typedef do_copy_col type; > do_copy_col() > { > std::cout << "do_copy_col" << std::endl; > } > // todo- implement operator()(dest,src) > }; > struct do_not_copy_col > { > typedef do_not_copy_col type; > do_not_copy_col() > { > std::cout << "do_not_copy_col" << std::endl; > } > > // todo- implement operator()(dest,src) > }; > > template <class type_t, class sequence_t> > struct copy_col_if_in_dest > : public if_< typename is_same< typename deref<typename > boost::mpl::find<sequence_t, type_t>::type >::type, type_t>, do_copy_col, > do_not_copy_col>::type > { > }; > > template <class src_t, class dest_t> > void copy_union(src_t & src, dest_t & dest) > { > copy_col_if_in_dest<boost::mpl::at<src::typelist, boost::mpl::int_<0> > >::type,src::typelist>(); > }

2 1

ICE ICE BABY! (my MPL code is ICEing)
by Brian Braatz 04 Jun '05

04 Jun '05

Sitting in the backyard. Beautiful day, got up at 3am to get something figured out (for proposed boost profiler \ introspection library). Good news is I figured out the MPL code needed to accomplish my goal. After typing in an incremental version of the code, I got the dreaded internal compiler error (ICE). I am chewing on this- and thought I would post it so to provide an opportunity for someone to show how incredibly stupid I am because I did something that was obviously wrong. (you can even rub my nose in it if you like :) ) here is the code: I am tearing it apart\deconstructing to try to figure out what is kicking in the ICE. (I am also going to try it with an eval_if (which I should be using anyway) just to see what happens) I am using boost 1.32 and vc7.1 struct do_copy_col { typedef do_copy_col type; do_copy_col() { std::cout << "do_copy_col" << std::endl; } // todo- implement operator()(dest,src) }; struct do_not_copy_col { typedef do_not_copy_col type; do_not_copy_col() { std::cout << "do_not_copy_col" << std::endl; } // todo- implement operator()(dest,src) }; template <class type_t, class sequence_t> struct copy_col_if_in_dest : public if_< typename is_same< typename deref<typename boost::mpl::find<sequence_t, type_t>::type >::type, type_t>, do_copy_col, do_not_copy_col>::type { }; template <class src_t, class dest_t> void copy_union(src_t & src, dest_t & dest) { copy_col_if_in_dest<boost::mpl::at<src::typelist, boost::mpl::int_<0> >::type,src::typelist>(); }

1 0

Function type to function call, how to?
by Arkadiy Vertleyb 04 Jun '05

04 Jun '05

Hi all, I was trying to come up with a useful example of LVALUE_TYPEOF, so I decided to implement the "trace" function from the motivation section of decltype/auto proposal. However I ran into unexpected problem: Given a function type F, and parameter type T, how to create an expression for typeof to use in the return type? I use VC71, and the only thing that seems to work (but with a warning) is: F()(T()) The warning is something about using a null pointer to call a function... *(F*)0 doesn't work, and something like make<F>() doesn't work either -- 'expression can't be evaluated to a function call with one parameter', or something like this. What would be the correct way of doing this, and is there one? Thanks in advance. Regards, Arkadiy

3 5

Re: Typeof: Review result
by Tom Brinkman 04 Jun '05

04 Jun '05

Jonathan Turkanis wrote: > Another easy improvement would be to add accepted libraries under a > probation or beta period of say six months. The library would remain > beta until its stable enough and has additional time for more user > scrutiny. A prominent boost member would make the judgement about > when to remove the library from its beta period. During the beta > period, the library author would be asked to complete the libraries > documentation, examples and requested changes from the additional user > scrutiny. >> Why make a library which has been in development for a long time and has >> received intense scrutiny undergo a probationary period? When a library is in the beta period, the author could change the public interfaces based upon the usablity concerns of its users. In some cases, as most library's take many-many months to fully appreciate and learn, this could be a benefit. I see that the term "beta" is ubiquitious and basically means that the "technology" is in active development and may change before its final release. Labeling newly accepted libraries as "beta" for a time would give the libfrary author more time to refine the submission. > If there are no objections, I will start requesting that libraries > under review be sponsered by at least prominent boost member. This > would ensure that accepted libraries meet the approval of a least one > prominent boost member. >> This sounds similar to the mentoring idea that was proposed after the >> >> OOPSLA meeting. I think it's a good idea, as long as you expand the list of >> "prominents" to include all active library authors and maintainers. Agreed. Review Wizard, Tom Brinkiman Jonathan

3 2

Re: stride iterators and matricies
by Sam Saariste 04 Jun '05

04 Jun '05

"Peter Dimov" <pdimov(a)mmltd.net> wrote in message news:<001001c5686f$8c19d950$6501a8c0@pdimov>... > Neal Becker wrote: > > > Here's my version: > > [...] > > One interesting problem with strided iterators is coming up with end values. > Suppose you have > > int x[ 4 ]; > > and you want to iterate over x[1] and x[3] with stride 2. Your begin > iterator will be x+1, and your end iterator will be x+5 - an invalid > address. > I don't think end values are a difficult problem as long as the size of the range is guaranteed to be a multiple of the stride and I have always found this to be a reasonable restriction. In addition to the stride, the iterator interface does need an offset parameter. In your example the size of the range is indeed a muliple of the stride, so there is a simple solution: store the underlying iterator without offset and add the offset when dereferencing the iterator. In that case your underlying iterator would take the values, &x[0], &x[2], and &x[4] - a valid one-passed-the-end iterator that can be compared to the end slice iterator. So relating to your example I would write something like: std::for_each( slice_iterator<int*,2,1>(boost::begin(x)), slice_iterator<int*,2,1>(boost::end(x)), do_stuff); and that works fine (as long as size of x is a multiple of the stride. An interesting consequence of this approach is that for a slice iterator with a run-time specified stride and offset, the end slice iterator does _not_ depend on its stride or offset. I have made this an explicit feature of a slice iterator I once wrote and found this to be very convenient as I always ended up iterating n times over a range for a stride of n (each time with a different offset). Sam Saariste

1 0

Serialization errors galore
by Victor A. Wagner Jr. 04 Jun '05

04 Jun '05

C:\Projects\boost\boost/archive/basic_archive.hpp(21) : fatal error C1189: #error : "no serialization headers my precede any archive headers" Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 2

serialization of objects with overloaded new/delete
by Andreas Brinck 04 Jun '05

04 Jun '05

Hi, I'm working on an application where we wan't to serialize objects with overloaded operator new/delete. After reading at the library homepage that it isn't possible I decided to take a look at the library code and found the following code snippet in iserializer.hpp: template<class T> struct heap_allocator { #if 0 // note: this fails on msvc 7.0 and gcc 3.2 <snip> static T * invoke(){ return new_operator(has_op_new(static_cast<T *>(NULL))); } #else // while this doesn't handle operator new overload for class T static T * invoke(){ return static_cast<T *>(operator new(sizeof(T))); } #endif }; Since we're using msvc 7.1 i decided to enable the disabled code and see what happened. The code didn't compile but after fixing some trivial compile errors I ended up with the following version: template<class T> struct heap_allocator { #if defined(_MSC_VER) && (_MSC_VER >= 1310) // note: this fails on msvc 7.0 and gcc 3.2 template <class U, U x> struct test; typedef char* yes; typedef int* no; template <class U> static yes has_op_new(U*, test<void* (*)(std::size_t), &U::operator new>* = 0) {return 0;} static no has_op_new(...) {return 0;} template<class U> static void * new_operator(U); static void * new_operator(yes){ return (T::operator new)(sizeof(T)); } static void * new_operator(no){ return (operator new(sizeof(T))); } static T * invoke(){ return static_cast<T *>(new_operator(has_op_new(static_cast<T *>(NULL)))); } #else // while this doesn't handle operator new overload for class T static T * invoke(){ return static_cast<T *>(operator new(sizeof(T))); } #endif }; which at least in our project compiles, links and works just fine. I sent the change to Robert Ramey and he said he would examine it but I thought I would consult the members of this list as well. Does this work as expected or are there any hidden gotchas? 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

Re: [Boost-testing] [Type Traits] AIX 5.1/vacpp6: is_enum fails to compile (Was: documentation on performing regression tests ?)
by Toon Knapen 04 Jun '05

04 Jun '05

John Maddock <john(a)johnmaddock.co.uk> wrote: >> John, do you have any ideas what's up here? > >Not really. However there was one change to is_enum since the last >release > (http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/type_traits/is_enum .hpp?r1=1.12&r2=1.13) >and does affect the code that produces the error. So you could try >reverting the code and see if that fixes things for vacpp. OK, thanks I will try that. So if I understand correctly, the process_jam_log program does not compile as it should because it uses the type_traits? >Failing that, >the standard advice is to build the regression test helper programs with >gcc, irrespective of what compiler you're going to test on the actual test >run. Well getting gcc to run correctly on aix is probably even more difficult;-(

1 0