From: FlSt@gmx.de
Rob Stewart wrote:
From: FlSt@gmx.de
Rob Stewart wrote:
From: FlSt@gmx.de
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;