View mode: basic / threaded / horizontal-split · Log in · Help
July 30, 2010
Re: string initialization question.
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
July 30, 2010
Re: string initialization question.
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
July 30, 2010
Re: string initialization question.
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
July 30, 2010
Re: string initialization question.
== 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.
July 30, 2010
Re: string initialization question.
>
>
> 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]
July 30, 2010
Re: string initialization question.
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
July 30, 2010
Re: string initialization question.
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.
July 31, 2010
Re: string initialization question.
== 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
August 02, 2010
Re: string initialization question.
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
August 02, 2010
Re: string initialization question.
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home