View mode: basic / threaded / horizontal-split · Log in · Help
June 29, 2012
Range to array
It is terrible to use a function of std.range if you are not 
using "auto" as type all the time.
Why isn't there a convert function for the original type?
I know "array(Range)" of std.array is what i want, but why do i 
have to import two  modules to use one?
Wouldn't it be better if std.range imports std.array implicit?
Otherwise (IMO) std.range needs some convert functions like

[code]
T[] Range(alias func, T)(T[] array) {
	return func(array).array();
}

T[] Range(alias func, T, U)(T[] array, U a) {
	return func(array, a).array();
}

T[] Range(alias func, T, U)(T a, U b) if (!isArray!(T)) {
	return func(a, b).array();
}
[/code]

or, if you prefer, in compressed (but without the type safety):
[code]
auto Range(alias func, Args...)(Args args) {
	return func(args).array();
}
[/code]

I think something like that is missing in std.range.
June 30, 2012
Re: Range to array
On Saturday, June 30, 2012 01:43:44 Namespace wrote:
> It is terrible to use a function of std.range if you are not
> using "auto" as type all the time.
> Why isn't there a convert function for the original type?
> I know "array(Range)" of std.array is what i want, but why do i
> have to import two  modules to use one?
> Wouldn't it be better if std.range imports std.array implicit?
> Otherwise (IMO) std.range needs some convert functions like

std.range already publicly import std.array.

Not to mention, if you're using ranges heavily, it's not all that uncommon to 
not actually need std.array.array very often. In general, if you're constantly 
converting ranges to arrays, then I'd argue that you're doing something wrong. 
There are definitely times when you need to convert a range to an array, but in 
general, you can just pass the result of one range-based function to another 
and operate on the data just fine without needing to convert to arrays at all. 
Worst case, you convert once you're done with all of various operations that 
you need to do on the data. But if you're passing arrays around rather than 
ranges, unless you actually need arrays for some reason, you should really 
consider passing ranges around like Phobos does. You're code's not going to be 
terribly efficient if you're constantly converting the results of range-based 
functions into arrays, since that means allocating more memory for the same 
data every time that you do that.

- Jonathan M Davis
June 30, 2012
Re: Range to array
> std.range already publicly import std.array.

Oh, good to known.

>
> Not to mention, if you're using ranges heavily, it's not all 
> that uncommon to
> not actually need std.array.array very often. In general, if 
> you're constantly
> converting ranges to arrays, then I'd argue that you're doing 
> something wrong.
> There are definitely times when you need to convert a range to 
> an array, but in
> general, you can just pass the result of one range-based 
> function to another
> and operate on the data just fine without needing to convert to 
> arrays at all.
> Worst case, you convert once you're done with all of various 
> operations that
> you need to do on the data. But if you're passing arrays around 
> rather than
> ranges, unless you actually need arrays for some reason, you 
> should really
> consider passing ranges around like Phobos does. You're code's 
> not going to be
> terribly efficient if you're constantly converting the results 
> of range-based
> functions into arrays, since that means allocating more memory 
> for the same
> data every time that you do that.
>
> - Jonathan M Davis

But a Range don't match any function that accept arrays. Or 
should i prefer to use Ranges instead of arrays?
June 30, 2012
Re: Range to array
On Saturday, June 30, 2012 11:06:06 Namespace wrote:
> But a Range don't match any function that accept arrays. Or
> should i prefer to use Ranges instead of arrays?

In general, functions should take ranges, not arrays. They're far more flexible 
that way. Requiring an array is generally overly restrictive. There are, of 
course, cases where you really do need to operate on an array or string, or 
where it's pointless to take anything else (e.g. if you're going to pass a 
zero-terminated string to a C function, then there's no point in taking a 
range of dchar instead of a string), but in general, functions should operate 
on ranges, not arrays. Just look at Phobos. For the most part, it operates on 
ranges, not arrays.

The only real exception in general is that if a function needs to operate on 
characters (rather than being generic with its type), then it's likely to be 
templatized on string type rather than on range type, but due to the fact that 
strings are variably length encoded, operating on them as ranges tends to be 
inefficent (which is why range-based functions frequently have overloads 
specifically for strings). So, ranges which wrap strings tend to be converted 
to strings far more often than other arrays do. But it's arguably the case 
that more of Phobos' functions which operate on strings should take ranges of 
dchar instead.

- Jonathan M Davis
June 30, 2012
Re: Range to array
Namespace:

> Or should i prefer to use Ranges instead of arrays?

There is no short answer to this question. Arrays and lazy ranges 
have different qualities, so they are better for different 
situations. Arrays use more memory, but in some situations they 
are faster. Lazy ranges can be a little more complex to use. 
Often I use ranges where I can, and arrays in the other cases, or 
where I have to modify the array items many times.

Bye,
bearophile
Top | Discussion index | About this forum | D home