www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.array suggestion (version 3)

reply 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
Apr 07 2006
parent reply 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:

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.
Sep 04 2006
parent reply 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:

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
Sep 04 2006
parent 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:

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.
Sep 04 2006