Re: [boost] Interest for a perl6-like-junctions-class?

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.

http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&filename=multivalues.zip&directory=rob_stewart&

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
maximum.

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
better?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;