Home› AMX User Forum› NetLinx Studio

Things that make me go "HMMMM!" :)

Spire_JeffSpire_Jeff Posts: 1,917
in NetLinx Studio
Ok, using this function:
DEFINE_FUNCTION integer[MAX_NUM_DEVS] filterArray(integer type){
	stack_var integer arrayX[MAX_NUM_DEVS];
	stack_var integer x;
	switch (type){
		case 1:{ // nUSER_BTN_TEST3
			for(x=1;x<=LENGTH_ARRAY(nUSER_BTN_TEST3);x++)
				arrayX[x] = nUSER_BTN_TEST3[x];
			return arrayX;
		
		}
	}
}
Does the stack_var that I am returning continue to exist after the function exits? If so, when does it finally clear itself from memory? Am I opening a path to memory leaks by doing this? This function is intended to be used to supply information to another function, so there are pointers flying all over the place... does NetLinx have an ATC (Air Traffic Controller) to deal with all of this elegantly?

Just a question I have, but I don't have time to play with it right now, so I decided to throw it out there for the masses to play with :)

Jeff

Comments

  • viningvining Posts: 4,368
    I think it's like a relay race where you're just passing the baton and it only exists in the hand of the current holder.
  • jjamesjjames Posts: 2,908
    At first glance at the topic name, I was scared to look. :D

    I agree with Vining here, BTW.
  • jason_the_adamsjason_the_adams Posts: 108
    I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.

    Like I said, I think it's more like Smear the Queer.
  • mpullinmpullin Posts: 949
    jason_the_adams wrote: »
    I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.

    Like I said, I think it's more like Smear the Queer.
    Hmmmmm....
  • Spire_JeffSpire_Jeff Posts: 1,917
    Well, that is the way I thought it happened, but I was having an odd problem with this and changing from stack_var to local_var seems to have cleared up the issue.... When I have some more time, I will try to narrow down the cause of the problem.

    Jeff

    P.S.
    In case anyone is wondering about the situation, I have a function being called that creates a stack_var of type integer[]. There is a switch case that calls another function using the integer[] with different options based on the case. (a couple other things happen inside the case as well, but nothing tied to the integer[].) When the first case is used, the array passed is correct. When the second case is used, the array that was getting passed was not initialized. Right now there are only 2 different cases.
  • Dan ColegroveDan Colegrove Posts: 39
    SET_LENGHT_ARRAY

    When ever I make an assignment like:

    nSomeArray[x] = x

    or

    nSomeArray[x] = nSomeOtherArray[x]

    I always call the function SET_LENGTH_ARRAY()

    In your for loop try adding

    for(x=1;x<=LENGTH_ARRAY(nUSER_BTN_TEST3);x++)
    {
    arrayX[x] = nUSER_BTN_TEST3[x];
    SET_LENGTH_ARRAY(arrayX,x);
    }


    Dan
  • Spire_JeffSpire_Jeff Posts: 1,917
    I don't think the length is the problem. As I recall, the array was being set correctly, then when it was passed from the second case, the values all changed to random numbers (basically it created a new instance of the stack_var). Eventually, I will try to get the code stripped down to only the two functions and necessary code to test it out. I will try to post the results here.

    Jeff
  • DHawthorneDHawthorne Posts: 4,584
    Any properly executed function handler should allocate memory for its return value independent of any stack variable within the module that might be assigned to it. Once you execute the RETURN statement, that stack variable referenced by all rights should get assigned to the memory allocated to the return value. I would be very surprised if this were not the case in NetLinx. So, in other words, your return value should still be intact until next time you call the function.
  • viningvining Posts: 4,368
    I've been working on a recursive funtcion that has uses a wait before it calls itself and I was passing it a constant value and then out of curiosity I decided to see what would happen if I passed it a var value that was declared as a STACK in the code that initially calls this function.

    I thought it would still work but I'm never quite sure of any thing lately. Sure enough the function holds and retains the value and changes to the initial value through out all the waits.
    The code:
DEFINE_FUNCTION fnDoRadarUpdate(INTEGER iRadarIndx)

     {
     SEND_COMMAND dvActiveTP,"'^RMF-Ani_Rad_',itoa(iRadarIndx -1),',&#37;Aridge/lite/',
			      Rad_Image_Type[nGetRadImageIndx],'%F',cGetRadRegion,'_',itoa(iRadarIndx - 1),'.png'" ; 
     SEND_COMMAND dvActiveTP,"'^RFRP-Ani_Rad_',itoa(iRadarIndx - 1 )" ;
     SEND_LEVEL   dvActiveTP, 1, iRadarIndx ;
     SEND_COMMAND dvActiveTP,"'^BMP-1,',itoa(iRadarIndx),',Ani_Rad_',itoa(iRadarIndx - 1)" ;
     SEND_COMMAND dvActiveTP,"'^RFR-Ani_Rad_',itoa(iRadarIndx - 1)" ;
     
     if(iRadarIndx > 1)
	  {
	  WAIT 5
	       {
	       fnDoRadarUpdate(iRadarIndx - 1)
	       }
	  }
     else
	  {
	  RETURN ;
	  }
     }
     
DEFINE_FUNCTION fnChangeRadImageType()

     {
     STACK_VAR INTEGER nRadarIndx ;
     
     nRadarIndx = NUM_ANI_RAD_PICS ; //NUM_ANI_RAD_PICS = 8
     fnDoRadarUpdate(nRadarIndx) ;
     }




    Notifications:
Line     12 :: Command To [10001:28:1]-[^RMF-Ani_Rad_7,%Aridge/lite/N1P%FOKX_7.png] - 11:37:34
Line     13 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_7] - 11:37:34
Line     14 :: Level Value To [10001:28:1] - Level 1  Value= 8 - 11:37:34
Line     15 :: Command To [10001:28:1]-[^BMP-1,8,Ani_Rad_7] - 11:37:34
Line     16 :: Command To [10001:28:1]-[^RFR-Ani_Rad_7] - 11:37:34
Line     17 :: Feedback:On [10001:28:1] - Channel 64  - 11:37:34
Line     18 :: Output Channel:On - From [10001:28:1] - Channel 64  - 11:37:34
Line     19 :: Feedback:Off [10001:28:1] - Channel 67  - 11:37:34
Line     20 :: Output Channel:Off - From [10001:28:1] - Channel 67  - 11:37:34
Line     21 :: Command To [10001:28:1]-[^RMF-Ani_Rad_6,%Aridge/lite/N1P%FOKX_6.png] - 11:37:34
Line     22 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_6] - 11:37:34
Line     23 :: Level Value To [10001:28:1] - Level 1  Value= 7 - 11:37:34
Line     24 :: Command To [10001:28:1]-[^BMP-1,7,Ani_Rad_6] - 11:37:34
Line     25 :: Command To [10001:28:1]-[^RFR-Ani_Rad_6] - 11:37:34
Line     26 :: Command To [10001:28:1]-[^RMF-Ani_Rad_5,%Aridge/lite/N1P%FOKX_5.png] - 11:37:35
Line     27 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_5] - 11:37:35
Line     28 :: Level Value To [10001:28:1] - Level 1  Value= 6 - 11:37:35
Line     29 :: Command To [10001:28:1]-[^BMP-1,6,Ani_Rad_5] - 11:37:35
Line     30 :: Command To [10001:28:1]-[^RFR-Ani_Rad_5] - 11:37:35
Line     31 :: Command To [10001:28:1]-[^RMF-Ani_Rad_4,%Aridge/lite/N1P%FOKX_4.png] - 11:37:35
Line     32 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_4] - 11:37:35
Line     33 :: Level Value To [10001:28:1] - Level 1  Value= 5 - 11:37:35
Line     34 :: Command To [10001:28:1]-[^BMP-1,5,Ani_Rad_4] - 11:37:35
Line     35 :: Command To [10001:28:1]-[^RFR-Ani_Rad_4] - 11:37:35
Line     36 :: Command To [10001:28:1]-[^RMF-Ani_Rad_3,%Aridge/lite/N1P%FOKX_3.png] - 11:37:36
Line     37 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_3] - 11:37:36
Line     38 :: Level Value To [10001:28:1] - Level 1  Value= 4 - 11:37:36
Line     39 :: Command To [10001:28:1]-[^BMP-1,4,Ani_Rad_3] - 11:37:36
Line     40 :: Command To [10001:28:1]-[^RFR-Ani_Rad_3] - 11:37:36
Line     41 :: Command To [10001:28:1]-[^RMF-Ani_Rad_2,%Aridge/lite/N1P%FOKX_2.png] - 11:37:36
Line     42 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_2] - 11:37:36
Line     43 :: Level Value To [10001:28:1] - Level 1  Value= 3 - 11:37:36
Line     44 :: Command To [10001:28:1]-[^BMP-1,3,Ani_Rad_2] - 11:37:36
Line     45 :: Command To [10001:28:1]-[^RFR-Ani_Rad_2] - 11:37:36
Line     46 :: Command To [10001:28:1]-[^RMF-Ani_Rad_1,%Aridge/lite/N1P%FOKX_1.png] - 11:37:37
Line     47 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_1] - 11:37:37
Line     48 :: Level Value To [10001:28:1] - Level 1  Value= 2 - 11:37:37
Line     49 :: Command To [10001:28:1]-[^BMP-1,2,Ani_Rad_1] - 11:37:37
Line     50 :: Command To [10001:28:1]-[^RFR-Ani_Rad_1] - 11:37:37
Line     51 :: Command To [10001:28:1]-[^RMF-Ani_Rad_0,%Aridge/lite/N1P%FOKX_0.png] - 11:37:37
Line     52 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_0] - 11:37:37
Line     53 :: Level Value To [10001:28:1] - Level 1  Value= 1 - 11:37:37
Line     54 :: Command To [10001:28:1]-[^BMP-1,1,Ani_Rad_0] - 11:37:37
Line     55 :: Command To [10001:28:1]-[^RFR-Ani_Rad_0] - 11:37:37
  • Rod NRod N Posts: 28
    this is strangely familiar...
    jason_the_adams wrote: »
    I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.

    Jason... what you've described is called AFL....
  • travtrav Posts: 188
    AFL

    GAHAHAHAHAHAHAHahahahhaa *cough* hah!
Sign In or Register to comment.