Can't see anything to tell me this.
If I defined and array of 5000 items, and I want to iterate through them, I don't want to check 5000 when only the first 200 are populated...


At the moment, I have to keep track of how many items I fill the array with.

There is nothing in any computer language I know that will tell you this. If you're using your own Type for the array, add a sentinal like Active. When you add data into the array set Active to True. You can then step through the array until active[x] is false.

On the whole, keeping count is more elegant and perfectly normal, and consumes less memory. I do this all the time for buffer management and stacks.

Or go thru a for i loop and check wich arrays dosn't equal 0

Sorry tired and gave an wrong answer

Sorry: I also had my OO head on. Delphi has a list.count type property, but I'm fine with keeping a counter for the amount of contents.

I use Delphi every day. Same thing - an array is NOT a list in Delphi either!

Checking 5000, or checking 200, should not take more then a millisecond in logic time? what's the problem?

It's ok. I was just wanting to be as efficient as possible.

(and yes, you can get an array count in delphi and freebasic to name 2 languages I have used this in)

This sort of thing would be nice in arrays within AGK; there are many languages that automatically maintain a number of "attributes" about an array (or collection) to make things like this easy and efficient.

I'd like to see things like the following in AGK...

array.COUNT - Return number of populated elements
array.FIRST - Pointer to first element
array.NEXT(x) - Pointer to next element
array.DELETE[(x,y)] - Remove all elements or remove a specific element or remove element X through Y

Perhaps the biggest improvement to arrays would be to allow associative arrays to be used, i.e. indexed by a string rather than an integer.

If you keep the array sorted so that the "200" items are at the start of the array you can just check for an empty slot and then exit the loop when you find one IE:

@nz0 "(and yes, you can get an array count in delphi and freebasic to name 2 languages I have used this in)"

Like to see a Delphi example of this with a static array!

@jim: here you go

@nz0: Sorry, mate. That merely tells you the range of the array. It does NOT tell you whether it is populated or not. It's there because in Pascal you can declare VAR A: array [-23,48] of something. An array has no intelligence and does not know or care what you shove into it.

red5 is also confusing list operations with arrays, which do not have operators or methods. An array is a dumb chunk of memory. It is not object orientated. AppGameKit is not OOP. To make it so would, of course, be nice, but would mean a complete redefinition of the language and compiler.

Jim - I'm not confused about anything, I'm merely saying what I would like to see supported in AGK; what I suggested would not mean a complete redefinition of the language or compiler at all since I'm not suggesting the language be changed from procedural to OO.

Of course an array is nothing more than a block of memory but that does not mean the language can't include methods (functions or procedures or whatever you want to call them) that act upon the array.

Sorry Red5 - I didn't mean to seem rude!

I'm not sure that the keyword ARRAY is appropriate for this. There's been discussion elsewhere about having a list type and methods for it, but ultimately it comes down to dynamic memory allocation and at least a reference pointer exposed. And obviously inheritance would be elegant, and then we're back to OOP.

We could (will?) debate this for years, but my view is that tier 1 should remain a simple language for simple games. That's not to say that we couldn't write some wrappers to provide list functionality across an array, but it's still going to need user modification for most array types, isn't it?

Jim - no problem

I think you are correct, it is the word "array" that can cause confusion; in it's purest form an array is as you say, merely a block of memory whereas what we are all really wanting is a simple implementation of a "collection" or "list" which internally is an array with built-in intelligence for want of a better term. In my original post I actually used the word "collection" in brackets to suggest this was what I meant.

In my opinion, AppGameKit should remain primarily procedural with perhaps "object capabilities" in the future, a bit like PHP is now; i.e. you can develop using procedural code but you can build and think using objects if you want/need to.

Wrappers in some cases are good but as I'm sure you'll know, there are many issues with wrappers such as multiple/changing implementations, standards (or lack thereof), the compiler can't easily optimise them (if at all), general performance...etc.

For simple things like what we are discussing here, it would be nice if they were part of the core language.

Red5 - I agree with you in many ways, but I can see a lot of implementation headaches in the compiler and runtime system which I doubt Paul or Lee would want to look at with more pressing issues at hand. The runtime system has to run in a sandbox using a byte-code interpreter. Adding dynamic types to this is actually rather nasty! I don't know the internals, but suspect that AppGameKit is having to manage its own heap and stack to a large extent.

Almost all list and collection implementations are effectively dynamic arrays of pointers which can then be typecast implicitly or explicitly to some meaningful structure which may not be contiguous in memory. This gets a bit hairy in the sandbox for arbitrary types, I think!

Delphi's base TList allocates 16 pointers in an array, and then adds another 16 if the function TList.add(something) runs out of space. However, you can define a primary allocation, which is faster because otherwise memory copying happens.

Can you think of a bit of simple example code that does not require pointer referencing and allows for a list to grow or shrink?

Sure, I agree completely, there are certainly more pressing issues/bugs/omissions in AppGameKit than this particular topic but as a possible future enhancement it would be useful to enhance arrays a little so that they behave a little more like a collection.

I'm not that familiar with Delphi (other than a brief eval I did of Turbo Pascal I worked on about 20 years ago which then morphed into Delphi a few years later I think) so I can't comment on that as such but for me I would be happy to stick with static (pre-allocated) arrays for now, not being dynamic is not so much of a problem, the biggest thing lacking in arrays (IMO) in AppGameKit is the fact that you can only use positional based arrays (i.e. indexed by an integer), they would be vastly improved if they supported associative arrays and since associative array are tricky to iterate without pointer referencing then a FIRST and NEXT method/func/proc (or similar) would be useful too.

I think you are probably right, given that AppGameKit is platform independent then it will probably be managing its own heap and stack completely since it won't be able to rely on the underlying implementation given that each platform may do things differently.

In any case, it's an interesting conversation and we're on the same'ish page I think.

Delphi has come rather a long way since Turbo Pascal -)

The latest version Delphi XE2 is cross-platform and extremely powerful:
http://edn.embarcadero.com/article/41593

I would love to be able to combine the power of Delphi with the power of AGK's sprite engine, and have posted a request for a set of Delphi compatible libraries.

Lists are VERY easy in Delphi, with automatic sorting, loading from files, saving to files etc. Great stuff.

Why not create an iterator that you add or subtract from and then use that as your count for going through the array?
I think Lee may be planning on adding some of these features to AppGameKit Tier 1. Might have to go to the bug board and put it in as a request.