From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-07 14:22:21
> 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 http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk