• Oskar Linde (46/46) Apr 07 2006 Hi,
• Ivan Senji (7/10) Sep 04 2006
• Oskar Linde (9/21) Sep 04 2006 Sorry for this short reply. I am a little short on time. But you have a
• Ivan Senji (5/26) Sep 04 2006 That sounds great. A more generic version of those functions would be

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

Hi,

It's time for version 3 of my std.array suggestion. Some changes:

* rfind() is implemented and works similar to find()

* find() is extended to support searching of for dchars in char[] arrays 
, sub-array searches and similar. rfind() also supports searching for 
dchars in chars[] and similar by transforming the search into a 
substring search. The limitation is that currently rfind() does not 
support something like:

rfind(char[] arr, bool delegate(dchar c) pred)

Which would need something like:

reverse_foreach(size_t ix, dchar c; arr) { if (pred(c)) return ix; }

which in turn would require either a reimplementation of everything in 
src/phobos/internal/aApply.d but for reverse iteration or make rfind 
work on a duplicated reversed array.

* .findMax(), .findMin(). Similar to .max() and .min(), but returns the 
index rather than the element. (Returns size_t.max (-1) on empty arrays)

* repeat() is implemented with the same functionality as std.string.repeat:
assert("-=".repeat(10) == "-=-=-=-=-=-=-=-=-=-=");

All functions work well with the current IFTI support. As it stands now, 
there are template functions that replace the following functions from 
std.string:

find
rfind
repeat
split (except the no argument default behavior to split on whitespace)
join
count

Contrarily to std.string, for which the above functions only supports 
char[] arrays, the template functions work equally well on wchar[], 
dchar[] and char[], as well as ubyte[] and similar. (Not to mention 
double[], MyType[], etc...)

The template versions are also in many cases more flexible than the 
std.string ones. All functions, where it makes sense, supports working 
on single elements, sub-arrays and via delegates/functions:

assert(" asdf   123 asd ".count(&isalnum) == 10);

const double[] nums = [12.3,-4,2,0];
assert(nums.count(delegate bool(double x) { return x > 0; }) == 2);

assert("aaaaa".count("aa") == 2);
assert(/*(char[])*/"åäöåäö".count(/*(wchar)*/'å') == 2);

By being templated, the .doSort() implementation is also faster than the 
built in .sort and is easily replaceable by whatever sorting algorithm 
would suit the data best.

The ugly documentation and implementation:
http://www.csc.kth.se/~ol/array.html
http://www.csc.kth.se/~ol/array.d

/Oskar

Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:

Oskar Linde wrote:
 Hi,
 
 It's time for version 3 of my std.array suggestion. Some changes:

<snip>

Sorry for a little late reply but I have been thinking about your 
std.array a little and was wondering why restrict ourselves to arrays,
wouldn't it be better to have std.algorithm that would work on both 
arrays and user defined types that have opApply or have opIndex and 
length. It is possible to check those things at compile time.

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

Ivan Senji wrote:
 Oskar Linde wrote:
 Hi,

 It's time for version 3 of my std.array suggestion. Some changes:

 <snip>
 
 Sorry for a little late reply but I have been thinking about your 
 std.array a little and was wondering why restrict ourselves to arrays,
 wouldn't it be better to have std.algorithm that would work on both 
 arrays and user defined types that have opApply or have opIndex and 
 length. It is possible to check those things at compile time.

Sorry for this short reply. I am a little short on time. But you have a 
good point that I have been pursuing lately. It is very possible to make 
the algorithms more generic. In fact, many algorithms should already 
work on any type supplying a length, an opIndex and an opApply. I would 
like to go further by identifying and minimizing the requirements each 
algorithm places on its argument types. Such requirements should then be 
classified into concepts and documented.

/Oskar

Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:

Oskar Linde wrote:
 Ivan Senji wrote:
 Oskar Linde wrote:
 Hi,

 It's time for version 3 of my std.array suggestion. Some changes:

 <snip>

 Sorry for a little late reply but I have been thinking about your 
 std.array a little and was wondering why restrict ourselves to arrays,
 wouldn't it be better to have std.algorithm that would work on both 
 arrays and user defined types that have opApply or have opIndex and 
 length. It is possible to check those things at compile time.

 
 Sorry for this short reply. I am a little short on time. But you have a 
 good point that I have been pursuing lately. It is very possible to make 
 the algorithms more generic. In fact, many algorithms should already 
 work on any type supplying a length, an opIndex and an opApply. I would 
 like to go further by identifying and minimizing the requirements each 
 algorithm places on its argument types. Such requirements should then be 
 classified into concepts and documented.

That sounds great. A more generic version of those functions would be 
something extremely useful. I have been experimenting with that idea 
myself, and the biggest problem might be identifying what those minimal 
requirements should be.