[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using collections
From: |
Ken Cline |
Subject: |
Re: Using collections |
Date: |
Wed, 22 Jan 1997 21:20:15 -0500 (EST) |
Glen,
(I meant to respond sooner, but was side-tracked for a few
days... I'm sending this mainly just to clear up my
earlier question...)
Ah yes, I should have sent some code. Sorry.
On each cycle of the simulation each agent performs its
"step" function (a la Heatbugs) within which it makes the
following method call:
[self getNextGoal];
Then in the "getNextGoal" method we have:
-getNextGoal {
id next_goal;
if ( [goalIndex getLoc] != End &&
(next_goal = [goalIndex next]) != NULL )
[self setGoal: next_goal];
else
[self setGoal: current_pos];
}
(Note: this doesn't depend on the fact the Objective-C
supports short-circuiting =:-)
I started with just:
if ( (next_goal = [goalIndex next]) != NULL )
[self setGoal: next_goal];
but this will move the index past the end of the list and
cause a core dump if the agent continues to call the
"getNextGoal" function.
Another possiblity would be:
if ( [goalIndex getLoc] != End )
[self setGoal: [goalIndex next]];
but this will send a nil value to the "setGoal" function
when the end of the list is reached.
Actually, it just occurred to me that I do trap that error
in the "setGoal" function... hmm, should have thought of
that before I wasted your time...
Like I indicated, I sent this to clear up what I was asking;
your answers were very helpful and I've got something that
works.
Thanks!
Ken.
--------------------------------------
On Thu, 16 Jan 1997, glen e. p. ropella wrote:
>
> [sorry about that... to finish...]
>
> > 2. I've discovered that a list index doesn't perform any
> > bounds checking in the "next" method. That is, if you call
> > [index next] when you are at the "End" of the list, then you
> > get a core dump.
> >
> > However, [index getLoc] doesn't return "End" until after
> > you moved past the last list element. Therefore, when I'm
> > traversing the list, I test two conditionals:
> > ([index getLoc] != End) and ([index next] != nil).
> >
> > Have I overlooked an more direct way of stopping at the
> > end of a list? Is there a method to "peek" ahead without
> > moving the index? Perhaps the "getOffset" method can be
> > used to accomplish this?
>
> I'm not sure what the problem is, here. The first statement I understand.
> If one has a list:
>
> 1 next 2 next 3 next 4
> -- -- -- --
> |i | |i | |i | |i |
> |--| |--| |--| |--|
> Index => |j | |j | |j | |j |
> |--| |--| |--| |--|
> |k | Index => |k | |k | |k |
> -- -- -- --
> End End Index => End End
> Index =>
>
> ==> k ==> End ==> Core Dump
>
>
> But, the test for having already retrieved the last member of the
> list can be done around the call to "next." For example, from
> the docs, a usual use of the "next" message might be:
>
> index = [aCollection begin: aZone];
> while ( (member = [index next]) ) {
> // do something with member ...
> }
>
> In other words, the "next" transfer from state (2) to state (3)
> above should return 0 or NULL, which would break out of the
> while loop in the code example.
>
> But, more directly, you should be able to use:
>
> if ([list atOffset: [index getOffset] + 1]]) {
> [ ... do whatever ...]
> }
>
> However, I would avoid doing anything like this because
> it relies on the constancy of the list (i.e. it hasn't
> been changed) and that the index hasn't been manually moved
> around.
>
> Let me know if you've done all this and you're still getting
> that behavior! And code would help, also.
>
> glen
>
>
_________________________________________________________
Ken Cline address@hidden
SAIC VOICE (410) 571-0413
Annapolis, MD FAX (301) 261-8427
- Using collections, Ken Cline, 1997/01/15
- Re: Using collections, glen e. p. ropella, 1997/01/17
- Re: Using collections, glen e. p. ropella, 1997/01/17
- Re: Using collections,
Ken Cline <=
- Re: Using collections, glen e. p. ropella, 1997/01/23
- Re: Using collections, Roger M. Burkhart, 1997/01/23
- Re: Using collections, Roger M. Burkhart, 1997/01/27
- Re: Using collections, Kevin Crowston, 1997/01/27
- Re: Using collections, Roger M. Burkhart, 1997/01/28