Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-07 14:22:21

From: FlSt_at_[hidden]
> Rob Stewart wrote:
> >From: FlSt_at_[hidden]
> >>Rob Stewart wrote:
> >>>From: FlSt_at_[hidden]
> >>>
> g++ 4.0.1 is a lot faster, but needs more RAM (as I saw with top).
> Compilation times of my test program with the new version:
> g++4.0.1 1,5 minutes
> g++3.3.6 7,5 minutes
> g++2.95 3,75 minutes

Progress is good.

> I'm using Linux and tested the compilers with -O0 -g -Wall -W options
> (no optimizing and debug infos) and the "time" command for the
> compilation time measurement. I think comparisons with optimizing
> activated makes no sense, because the compiler version are to different.

When comparing you library and mine, you can compare with
optimized builds. Normally, I find optimized builds to compile
and link faster, with GCC 3.2 at least, than debug builds, so
that's what I make by default.

> >>test program. I removed the xxx_of functions for STL-Iterators, because
> >>Ranges of STL-Iterators can be generated with make_iterator_range(
> >>begin, end )
> >
> >I haven't looked at supporting pairs of iterators yet. You're
> >right that one can use make_iterator_range, but if we can use a
> >pair right out of the box, all the better
> >
> see below. There is another reason why I removed them.

I have support for them now. My approach requires storing
iterator_ranges, but not other ranges, through PTS.

> >I switched back to your test program and it again took a very
> >long time to compile. When I ran it, it dumped core due to what
> >looks like infinite recursion (SIGSEGV).
> >
> No, the problem is that you removed the storage of the Range. When you
> create a instance of a junction with the STL-iterator-range with
> boost::range::make_iterator_range() it creates a temporary object which
> is lost after creating the junction creation. That was the secons reason

I was just saying what I though the call stack was indicating. I
figured the problem had to do with the references, but I hadn't
dug into it.

I was also pointing out that using references didn't impact the
compilation time noticeably.

> I removed the STL Ranges support. ;-) In my new version (v9) I use
> references to the range. ( But I think the cost of holding a range would
> be minimal. )

If the range is a large std::map of some large data type, the
cost would not be minimal.

Have you looked at my implementation? What do you think of my
approach? I plan to examine your latest version and will report
my findings soon.

I have support for not_all_of and n_m_of now, though I need to
write tests for them.

Would "some_of" be a better name than "n_m_of?" The latter isn't
the most inventive name and I was hoping to find something better
(if there is anything). Both would be parameterized with two
values (min and max). I know "some" is quite vague, like "any,"
but the required parameters would force supplying the minimum and

We could also try "min_max_of," but that suggests a function that
returns a pair of values.

"n_m_of" uses anti-alphabetical ordering of the letters. That
rather suggests the template argument order of maximum then
minimum. Perhaps changing to "x_y_of" or "a_z_of" would be

Rob Stewart                           stewart_at_[hidden]
Software Engineer           
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at, gregod at, cpdaniel at, john at