Dnia 30-07-2010 o 22:15:50 Tomek Sowiński <just@ask.me> napisał(a):

> writeln('-'.repeat.take(5));

Oh, and if repeat had slicing (as it should)...  '-'.repeat[0..5]
Still, it's far cry from Python's  '-' * 5

Tomek

On Friday, July 30, 2010 13:10:46 Steven Schveighoffer wrote:
> On Fri, 30 Jul 2010 15:56:36 -0400, Jonathan M Davis
> 
> <jmdavisprog@gmail.com> wrote:
> > On Friday, July 30, 2010 10:14:45 Steven Schveighoffer wrote:
> >> I think a function to do it is fine, like makeArray('-', 5);
> > 
> > Well, creating a function for producing an array literal and returning
> > it using
> > templates and string mixins wouldn't be all that hard, but if you want
> > to create
> > a dynamic array of arbitrary size at runtime, that's not going to work,
> > and a
> > makeArray() function would have exactly the same tools that you have to
> > create
> > an array of all the same value.
> 
> The function would call gc_malloc directly, which does not initialize the requested memory.  Actually, it would call a new run time function that I will write, which would initialize the array length also.

Well, if there's a function other than new to allocate GC memory, then makeArray() is quite doable. I've never dealt with anything but new. As far as I've been aware, you either use new for GC memory or malloc for non-GC memory. If there's a gc_malloc, then that would solve the problem and it would make good sense to do that with makeArray().

> 
> > So, it's not going to be any more efficient that
> > what you can do.
> > 
> > int[] a = new int[](x);
> > a[] = val;
> > 
> > _should_ be fairly easily optimized by the compiler and thus really
> > should be
> > optimized down to an initialization rather than an initialization and an
> > assignment.
> 
> It's not.  The only runtime functions available to the compiler look like this:
> 
> _d_newarrayT(TypeInfo ti, size_t length);

I guess that's one thing that comes of not really implementing it as a primitive. If there are enough such functions that would be properly optimizable had they actually been implemented as primitives, I would think that there would be some merit in finding a way to get the compiler to understand that it can do such optimizations. But I really don't know how all that works in dmd, so I have no idea how feasible that is.

- Jonathan M Davis

On Fri, 30 Jul 2010 16:31:49 -0400, Jonathan M Davis <jmdavisprog@gmail.com> wrote:

> On Friday, July 30, 2010 13:10:46 Steven Schveighoffer wrote:
>
>> It's not.  The only runtime functions available to the compiler look like
>> this:
>>
>> _d_newarrayT(TypeInfo ti, size_t length);
>
> I guess that's one thing that comes of not really implementing it as a
> primitive. If there are enough such functions that would be properly optimizable
> had they actually been implemented as primitives, I would think that there would
> be some merit in finding a way to get the compiler to understand that it can do
> such optimizations. But I really don't know how all that works in dmd, so I have
> no idea how feasible that is.

To be clear, the compiler could do the optimization if it had another runtime function to call.  But since there is *no* runtime function that allocates a new array and initializes it with a custom initial element, how do you make a primitive?

So if the function exists, the compiler can be fixed to make the sequence of "create then assign" a primitive, but I think just a runtime function is good enough, and will work without compiler changes.

-Steve

== Quote from Jonathan M Davis (jmdavisprog@gmail.com)'s article
> A makeArray() function wouldn't hurt any, but I don't think that it would really
> buy us much. Of course, truth be told, I've always thought that the ability to
> construct a string or vector in C++ all of a single value was pretty useless.
> Obviously, some people find it useful at least once in a while, but I've never
> had much use for it. A makeArray() function would probably still be a good thing
> to have, but what we really need here is either a syntactic way to do it or for
> the compiler to optimize out the useless initialization (as well as inline
> makeArray()) so that you don't have to deal with the extra cost of setting
> everything twice.
> - Jonathan M Davis

If I'm writing a program that pretty prints tree data, or output of sql, like Oracle's sqlplus, or postgres equivalent, I find having such a utility function/constructor a pretty handy feature.

I don't know where such a tool should finally be placed in D, but I having it available as a library or as part of the language would be great.  It seems like a lot of other languages have it like python, perl, C++, and Java.  So it can't be that useless.

>
>
> I don't know where such a tool should finally be placed in D, but I having
> it
> available as a library or as part of the language would be great.  It seems
> like a
> lot of other languages have it like python, perl, C++, and Java.  So it
> can't be
> that useless.
>


There is fill() in std.algorithm, but it needs an already present range...

auto s = new int[5];
fill(s, 10);

s is now [10,10,10,10,10]

On Friday, July 30, 2010 14:13:15 dcoder wrote:
> If I'm writing a program that pretty prints tree data, or output of sql, like Oracle's sqlplus, or postgres equivalent, I find having such a utility function/constructor a pretty handy feature.
> 
> I don't know where such a tool should finally be placed in D, but I having it available as a library or as part of the language would be great.  It seems like a lot of other languages have it like python, perl, C++, and Java.  So it can't be that useless.

Well, I certainly have no problem with a function like makeArray() existing. It's just that it's one of those functions that I've never found useful, and I don't think that I've ever seen anyone use it in code.

Now, for strings, I find such a function to be a bit dangerous since it's ignoring the fact that char is a UTF-8 code unit rather than an ASCII value, but for other types of arrays, that wouldn't be a problem. And for strings, you could either use dstrings or just be certain that all of your characters are actually a single code unit. But I certainly wouldn't want the equivalent of having a string constructor that takes a char and a count like C++'s string does. It would be fine in many cases, but string functions that take chars are generally asking for trouble due to unicode issues. But since, string in D is an array rather than a class, that's not really a problem in the same way. makeArray() being for arrays in general rather than specifically strings would not promote bad string code in the same way that C++'s string constructor does.

- Jonathan M Davis

On Fri, 30 Jul 2010 16:30:17 -0700, Jonathan M Davis <jmdavisprog@gmail.com> wrote:
> On Friday, July 30, 2010 14:13:15 dcoder wrote:
> > If I'm writing a program that pretty prints tree data, or output of sql, like Oracle's sqlplus, or postgres equivalent, I find having such a utility function/constructor a pretty handy feature.
> > 
> > I don't know where such a tool should finally be placed in D, but I having it available as a library or as part of the language would be great.  It seems like a lot of other languages have it like python, perl, C++, and Java.  So it can't be that useless.
> 
> Well, I certainly have no problem with a function like makeArray() existing. It's just that it's one of those functions that I've never found useful, and I don't think that I've ever seen anyone use it in code.

I agree with this sentiment. I think the feature is pretty niche to begin with, and the compiler should be able to optimize out the initialization in the sample I gave previously. D is indeed a systems language, but I (and I'm sure others) would like to use it in a high- level way, where I can write natural, straightforward code and expect the compiler to do the Right Thing.

Besides, performance is not an applicable argument for this use case. Even if the array initialization is compiled into the binary, the amount of time it would take is infinitesimal. If someone's trying to initialize a 100,000 element array to some specific value, they're likely going to write their own makeArray() anyways.

== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> I was wrong, I looked through the runtime and did not find such a
function.

std.string has a repeat() function.  Try:

import std.string;

void main()
{
   string divider = repeat("-", 5);
   writeln(divider);
}

Jason

On Sat, 31 Jul 2010 05:37:41 -0400, Jason Spencer <spencer8@sbcglobal.net> wrote:

> == Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
>> I was wrong, I looked through the runtime and did not find such a
> function.
>
> std.string has a repeat() function.  Try:
>
> import std.string;
>
> void main()
> {
>    string divider = repeat("-", 5);
>    writeln(divider);
> }

It doesn't do the right thing.  It allocates, then initializes, resulting in a double-initialization.

-Steve

On Fri, 30 Jul 2010 19:41:03 -0400, Justin Spahr-Summers <Justin.SpahrSummers@gmail.com> wrote:

> On Fri, 30 Jul 2010 16:30:17 -0700, Jonathan M Davis
> <jmdavisprog@gmail.com> wrote:
>> On Friday, July 30, 2010 14:13:15 dcoder wrote:
>> > If I'm writing a program that pretty prints tree data, or output of  
>> sql,
>> > like Oracle's sqlplus, or postgres equivalent, I find having such a
>> > utility function/constructor a pretty handy feature.
>> >
>> > I don't know where such a tool should finally be placed in D, but I  
>> having
>> > it available as a library or as part of the language would be great.   
>> It
>> > seems like a lot of other languages have it like python, perl, C++,  
>> and
>> > Java.  So it can't be that useless.
>>
>> Well, I certainly have no problem with a function like makeArray() existing.
>> It's just that it's one of those functions that I've never found useful, and I
>> don't think that I've ever seen anyone use it in code.

That's because it's not a trivial function to write :)  One has to have intimate knowledge of the runtime and understand how to properly allocate a block for this purpose.

Basically, there have been code instances of the form:

T[] x = new T[n];
x[] = initval;

Because that's the only way to do it.  Offer a function like makeArray, and why *wouldn't* you change to it?  I prefer a single line/initialization anyways.

> I agree with this sentiment. I think the feature is pretty niche to
> begin with, and the compiler should be able to optimize out the
> initialization in the sample I gave previously. D is indeed a systems
> language, but I (and I'm sure others) would like to use it in a high-
> level way, where I can write natural, straightforward code and expect
> the compiler to do the Right Thing.

I just find the syntax awkward:

char[] divider = new char[5]; // hey, compiler I'm initializing divider
divider[] = '-'; // OOHHH got you there, I wasn't done yet :)

It just seems natural that I should be able to do this in one line.  Having the compiler optimize isn't a bad thing, but relying on the optimization because "we can't find a better way" seems crappy to me.

> Besides, performance is not an applicable argument for this use case.
> Even if the array initialization is compiled into the binary, the amount
> of time it would take is infinitesimal. If someone's trying to
> initialize a 100,000 element array to some specific value, they're
> likely going to write their own makeArray() anyways.

The performance improvement is certainly a smaller argument compared to the syntax.  But it is a nice bonus.  There are more significant performance bugs in initialization of static arrays using array literals.

-Steve