Hello D World!

I've been looking over the specs for D.  I really like the way it's evolving.  As always, I have some ideas.

My first suggestion is to use the std::vector resizing algorithm for array resizing.  This way, you can add elements to an array without having to worry about inefficiency.

Another suggestion is to include set syntax.  I think Delphi has sets if I'm not mistaken.  Sets simplify syntax and save lots of typing.  There are two ways to use sets.  The first is with the "in" keyword, or "is an element of", which would work like this:

int a;
...
if(a in {1 .. 3, 6, 9}) { ... }

Note the {1 .. 3, 6, 9} following the "in" keyword is a set.  The compiler would translate the above expression into:

if (a >=1 && a <=3 || a ==6 || a==9) { ... }

Sets could also be used to perform iterations.  Perhaps something like:

for(int a = {1 .. 3, 6, 9}) { ... }

And the for loop would work as you would expect.  The expression could be expanded by defining the "..." to be a function.  Then the expression would expand to:

void func(int a) { ... }
for(int a = 1; a <=3; a++)func(a);
func(6);
func(9);

-Craig

On Sat, 24 Aug 2002 14:56:10 -0400 "cblack01" <cblack01@cox.net> wrote:

> My first suggestion is to use the std::vector resizing algorithm for array resizing.  This way, you can add elements to an array without having to worry about inefficiency.

It was discussed not long ago. Walter says it cannot be done, even though I
don't really
understand reasons - but as soon as templates get implemented, we could write
our own vector.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374931050334954@news.digitalmars.com...
> On Sat, 24 Aug 2002 14:56:10 -0400 "cblack01" <cblack01@cox.net> wrote:
>
> > My first suggestion is to use the std::vector resizing algorithm for
array
> > resizing.  This way, you can add elements to an array without having to worry about inefficiency.
>
> It was discussed not long ago. Walter says it cannot be done, even though
I
> don't really
> understand reasons - but as soon as templates get implemented, we could
write
> our own vector.

The reason is the resizer doesn't know if some array slice is using the memory just above it. For example, allocate an array of 100. Take a slice from 0..50. Now take the slice, and resize it up to 80. It will step all over the original array. For example:

    char a[] = new char[100];
    char b[] = a[0..50];
    b.length = b.length + 30;

On Sat, 24 Aug 2002 20:29:23 -0700 "Walter" <walter@digitalmars.com> wrote:

> The reason is the resizer doesn't know if some array slice is using the memory just above it. For example, allocate an array of 100. Take a slice from 0..50. Now take the slice, and resize it up to 80. It will step all over the original array. For example:
> 
>     char a[] = new char[100];
>     char b[] = a[0..50];
>     b.length = b.length + 30;

The answer is simple: slices should not be resized (and the compiler must be
able to catch it). This probably needs some kind of flag, for example the most
significant bit of length could serve as an indicator. Resizing slices is a
weird
idea anyhow... Of course ~= should also be forbidden, as well as any other
operations that change length. Once slice is taken, it cannot be changed - only
data within it can.

"Walter" <walter@digitalmars.com> wrote in news:ak9ime$bdv$2@digitaldaemon.com:

>     char a[] = new char[100];
>     char b[] = a[0..50];
>     b.length = b.length + 30;

I have another question along these lines.

char[] a;
a.length = 1000000;

char[] b;
b = a[9000..9010];

char[] c;
a = c;

Now except for 9000..9010 the rest of the
1000000 byte array is unreferenced.  Does
b hold the entire original memory block from
being collected or is there some gc magic
that will reclaim the unreferenced parts?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374934732140394@news.digitalmars.com...
> On Sat, 24 Aug 2002 20:29:23 -0700 "Walter" <walter@digitalmars.com>
wrote:
>
> > The reason is the resizer doesn't know if some array slice is using the memory just above it. For example, allocate an array of 100. Take a
slice
> > from 0..50. Now take the slice, and resize it up to 80. It will step all over the original array. For example:
> >
> >     char a[] = new char[100];
> >     char b[] = a[0..50];
> >     b.length = b.length + 30;
>
> The answer is simple: slices should not be resized (and the compiler must
be
> able to catch it). This probably needs some kind of flag, for example the
most
> significant bit of length could serve as an indicator. Resizing slices is
a
> weird
> idea anyhow... Of course ~= should also be forbidden, as well as any other
> operations that change length. Once slice is taken, it cannot be changed -
only
> data within it can.

The problem is distinguishing a slice from the original allocation. Having an extra bit I suspect will kill off any performance gains that you'd get from resizing in place.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns927562C96AF5Dpatcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ak9ime$bdv$2@digitaldaemon.com:
>
> >     char a[] = new char[100];
> >     char b[] = a[0..50];
> >     b.length = b.length + 30;
>
> I have another question along these lines.
>
> char[] a;
> a.length = 1000000;
>
> char[] b;
> b = a[9000..9010];
>
> char[] c;
> a = c;
>
> Now except for 9000..9010 the rest of the
> 1000000 byte array is unreferenced.  Does
> b hold the entire original memory block from
> being collected or is there some gc magic
> that will reclaim the unreferenced parts?

The entire block will be held.

On Sun, 25 Aug 2002 09:25:23 -0700 "Walter" <walter@digitalmars.com> wrote:

> The problem is distinguishing a slice from the original allocation. Having an extra bit I suspect will kill off any performance gains that you'd get from resizing in place.

Why? It would be just a single bitwise AND to check the bit, and, if it is a
slice, another one to
reset it. On the other hand, adding elements to end of list would be _hundred_
times faster
on large lists.

"Walter" <walter@digitalmars.com> wrote in news:akb9vs$28kh$2 @digitaldaemon.com:

> The entire block will be held.

That's what I thought.  This should probably be
in the "Things to be careful about" section of
"Tips and Tricks of the D programming gurus".

Pavel Minayev wrote:

> On Sun, 25 Aug 2002 09:25:23 -0700 "Walter" <walter@digitalmars.com> wrote:
> 
>>The problem is distinguishing a slice from the original allocation. Having
>>an extra bit I suspect will kill off any performance gains that you'd get
>>from resizing in place.
>  Why? It would be just a single bitwise AND to check the bit, and, if it is a slice, another one to
> reset it. On the other hand, adding elements to end of list would be _hundred_ times faster
> on large lists. 

I've done this for my port.  Works nice.  Assignment, returning, and passing as an in argument also clear the bit, although that doesn't have to be done if the previous owner doesn't take advantage of it or is going out of scope.  The only costly operation is in finding out how much more space a list has in it, but this is nothing compared to doing allocation too much.