www.digitalmars.com         C & C++   DMDScript  

D - Arrays, insert, delete, move?

reply Patrick Down <pat codemoon.com> writes:
Since overlapped copying of arrays is disallowed it
might be nice if arrays had built in element insert
and delete or maybe just a move?

int[10] a;

// Move all the elements of a down over writeing a[0]
a.move(1,0,a.lenght-1);

a.delete(0,1);
// Same effect

Maybe an addtional flag to indicate what to do with
the uncovered elements.

a.delete(0,1,true);
// Same effect but a[9] = 0 too

a.delete(0,1,false);
// Same effect but a[8] == a[9]
May 05 2002
next sibling parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
I like the idea of an insert method that would expand the array, shift
everything over, and then put the new element in its place.

int[10] foo;
foo.insert(index,element);

Same with
delete. It would make sorted arrays very easy to implement. If you
wanted to go overboard, you could even have a insertinorder method
that would insert a new element into its rightful spot. I suppose
that would be better handled by a special SortedArray class though.

Or, perhaps if you left off the index argument, the method would
automatically find where in the array to insert the element? I am
not sure if this would involve calling some compareTo argument like
java does, or how D would accomplish this.

Patrick Down wrote:


 Since overlapped copying of arrays is disallowed it
 might be nice if arrays had built in element insert
 and delete or maybe just a move?
 
 int[10] a;
 
 // Move all the elements of a down over writeing a[0]
 a.move(1,0,a.lenght-1);
 
 a.delete(0,1);
 // Same effect



I'm not completely sure what the second argument is for. Couldn't you
just have one argument saying which element you want to delete?
i.e

a.delete(4);
// now a[4] == a[5] if it shifts the remaining elements automatically?


 
 Maybe an addtional flag to indicate what to do with
 the uncovered elements.
 
 a.delete(0,1,true);
 // Same effect but a[9] = 0 too
 
 a.delete(0,1,false);
 // Same effect but a[8] == a[9]
May 05 2002
parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
 I'm not completely sure what the second argument is for. Couldn't you
 just have one argument saying which element you want to delete?
 i.e


My guess is that it is the number of elements to delete
        <object>.delete( <array.offset>, <elements.to.delete> )
        <object>.insert( <array.offset>, <object.to.insert> )
Is this correct;  if so it eems a good idea for the standard library 
(methods added to the base object class).

I suggest delete shortens the array by 1 item always, or sets the remaining 
items to NULL,  it would be simple for the user to do other functions such 
as setting object[8] == object[9],  therefore adding flags to alter its 
function seems at best inelegant.

C 2002/5/5
May 05 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92059CFA5F567patcodemooncom 63.105.9.61...

 Since overlapped copying of arrays is disallowed it
 might be nice if arrays had built in element insert
 and delete or maybe just a move?

 int[10] a;

 // Move all the elements of a down over writeing a[0]
 a.move(1,0,a.lenght-1);

 a.delete(0,1);
 // Same effect

 Maybe an addtional flag to indicate what to do with
 the uncovered elements.

 a.delete(0,1,true);
 // Same effect but a[9] = 0 too

 a.delete(0,1,false);
 // Same effect but a[8] == a[9]



This is what you get when you start adding some
really usefull features to a language...
People just keep coming back for more! :)

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 05 2002
parent "Robert W. Cunningham" <rcunning acm.org> writes:
OddesE wrote:


 ...
 This is what you get when you start adding some
 really usefull features to a language...
 People just keep coming back for more! :)


Most of the requests seem to be centering on the issue of making it
EXPLICIT what the programmer wants the compiler (and the compiled
program) to do.  While many requests are to make complex things simpler,
most requests seem to try to keep logically simple things simple (clear,
obvious, not necessarily easy) in the language, in its implementation,
and in its use.

While it may seem like feature-itis, I believe this trend is a Good
Thing.  While Wirth tried to do similar things from a minimalist
academic top-down perspective (Pascal, Modula, Oberon, etc.), the "D
Way" is more bottom-up and inclusive: To take C, dump it's worst sins
(but keeping printf() for nostalgic reasons), and adding "C++-like"
features without incurring needless complexity in either the language
design, its implementation, or its use.

From this perspective, many of the requested D features seem more like
"mini patterns" than new or novel language features.  They reflect how
real programmers use languages, and the solutions to common situations
and problems they keep encountering.

Is it time to look at requested D features within a broader scope?  Some
clearly affect the language at its core, while others are "syntactic
sugar" for "mini-patterns".  Would it be possible (or desirable) to add
a "sugar" layer to D so that "mini-patterns" (or other style rules)
could be implemented as compiler plugins (or other meta-layer device)?

I can see many uses for such features, especially if the "plugin"
mechanism used content that was in text form, and would need to be part
of the general code base (like an include file or a library).  Yes, such
plugins would probably look very much like rewrite rules.  But they
would NOT be a pre-processor as such, since they would truly represent
language extensions, and not mere textual trickery.

I'm no compiler or language designer, but I would love to be able to
customize the "higher" features of a language on a per-project basis,
and still remain true to the "essence" of the underlying language.  We
presently are forced to obtain such features either via administrative
means (rules and conventions for people to follow, not compilers), or
the use of cumbersome libraries and object hierarchies, or via external
custom languages (M4 processors that support a modified C, for example).

So, though the fundamental D language may not support the declaration of
infix functions or the overloading of operators, it may be possible to
obtain such functionality through the use of compiler plugins ("sugar
pills").  Think of such "plugins" as syntactic (or semantic?)
libraries.  Or as a way to keep the those needing such features within
the D world, and not forcing them to fall back to the "bad old days" of
preprocessing.

Or would this turn D into its own YACC?  Or into a "meta-language"?

Just a Sunday evening thought...


-BobC
May 05 2002
prev sibling parent reply Patrick Down <pat codemoon.com> writes:
Hmmm...

s[0..2] = s[1..3];	error, overlapping copy

Is this a compiler error or a runtime problem?

What if I do this...

b = a[1..10];
a[] = b[];
May 05 2002
parent Patrick Down <pat codemoon.com> writes:
Patrick Down <pat codemoon.com> wrote in 
news:Xns9205EEE9EA455patcodemooncom 63.105.9.61:


 
 Hmmm...
 
 s[0..2] = s[1..3];     error, overlapping copy
 
 Is this a compiler error or a runtime problem?
 
 What if I do this...
 
 b = a[1..10];
 a[] = b[];
 


Ok I answered my own question.

void FillArray(inout int[] a)
{
  a.length = 10;
  for(int i=0; i < 10; ++i)
    a[i] = i;
}

int main(char[][] args)
{
  int[] s;
  int[] t;

  printf("Start\n");

  FillArray(s);

  t=s[1..10];
  s[0..9]=t[0..9];
  
  return 0;
}

Generates:
Start
Error: overlapping array copy
May 05 2002