- Boost - lists.boost.org

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

05 Jun '05

> >> > >>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 > >>{ > >>}; > > This code has a problem when type_t is not in sequence_t: the > past-the-end iterator gets dereferenced. I wrote a short program to do > what you want (it's more explicit, it uses mpl::contains<>): > > #include <boost/mpl/vector.hpp> > #include <boost/mpl/if.hpp> > #include <boost/mpl/contains.hpp> > > namespace mpl = boost::mpl; > > struct do_copy_col {}; > struct dont_copy_col {}; > > template<typename T, typename Seq> > struct copy_col_if_in_dest > : mpl::if_< > mpl::contains<Seq, T>, > do_copy_col, > dont_copy_col > >::type > { > }; > > int main() > { > typedef mpl::vector<char, short, int, long> v; > do_copy_col do_copy = copy_col_if_in_dest<int, v>(); > dont_copy_col dont_copy = copy_col_if_in_dest<bool, v>(); > return 0; > } > [Brian Braatz Writes:] Wow. Many THANKS- the mpl::contains<> is REALLY what I was looking for. (Though the exercise of doing it with if_<> was a useful experience) THANK YOU ( I have been burning the morning and afternoon oil here the last few weeks trying to get a lib I am proposing ready for boost people to look at) -I am going to replace the code I had with the code you presented, and make a note of your contribution. THANKS AGAIN! Brian

1 0

problems buidling latest cvs version
by Christopher Lux 05 Jun '05

05 Jun '05

hi, bjam cancels buidling in v1 and v2 mode on the latest cvs checkout. i used bjam built from the source from the checkout. error message said: Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). C:\_development\boost_cvs\tools/build/v1\boost-base.jam:1966: in subvariant-target *** argument error * rule library-file ( target : sources + ) * called with: ( <@boost!libs!iostreams!build\libboost_iostreams.lib\vc-7_1\debug\runtime-link-static>libboost_iostreams-vc71-sgd-1_33.lib : ) * missing argument sources C:\_development\boost_cvs\tools/build/v1\boost-base.jam:119:see definition of rule 'library-file' being called C:\_development\boost_cvs\tools/build/v1\boost-base.jam:2403: in stage Jamfile:195: in load-jamfiles C:\_development\boost_cvs\tools\build\v1\bootstrap.jam:21: in boost-build C:\_development\boost_cvs\boost-build.jam:16: in module scope

1 0

[typeof] Small feature request
by Pavel Chikulaev 05 Jun '05

05 Jun '05

Hi all, I've got a small feature request to type_of library: 1) BOOST_TYPEOF_CONSTANT_COMPLEXITY Macro is defined if typeof can't evaluated with constant complexity 2) BOOST_TYPEOF_LINEAR_COMPLEXITY Macro is defined if typeof can't evaluated with linear complexity -- Pavel Chikulaev

2 2

[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 04 Jun '05

04 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