Re : Sorting list problems in 2013

[just4u78]

I'm programming by CVI.

However, I encounter a critical problem - the list sort built-in library does not work.

In both of console and real-time application, the sort result is wrong.

How can I solve this problem.

=================================================================

int main (int argc, char *argv[])
{
 double value1 = 3.0;
 double value2 = 4.0;
 double value3 = 1.0;
 double value4 = 2.0;
 
 double test;
 
 int i;

 ListType newList;

// if (argc < 2 || argc > 3)
//  usage (argv[0]);

 printf("This is built-in List type test program!\n");
 
 newList = ListCreate(sizeof(double));
 
 if (newList == VI_NULL)
 {
  return -1;
 }

 ListInsertItem(newList, &value1, END_OF_LIST);
 ListInsertItem(newList, &value2, END_OF_LIST);
 ListInsertItem(newList, &value3, END_OF_LIST);
 ListInsertItem(newList, &value4, END_OF_LIST);

 printf(">>>>> The original list\n");
 for (i=0; i<ListNumItems(newList); i++)
 {
  ListGetItem(newList, &test, i);
  printf("[%d] %f\n", i, test);
 }

 ListInsertionSort(newList, DoubleCompare);
 
 printf(">>>>> The sorted list\n");
 for (i=0; i<ListNumItems(newList); i++)
 {
  ListGetItem(newList, &test, i);
  printf("[%d] %f\n", i, test);
 } 

 
 if (newList)
 {
  ListDispose(newList);
 }

 return 0;
}

=================================================================

This is built-in List type test program!
>>>>> The original list
[0] 2.000000
[1] 3.000000
[2] 4.000000
[3] 1.000000
>>>>> The sorted list
[0] 4.000000
[1] 1.000000
[2] 2.000000
[3] 3.000000

[just4u78]

ListInsertItem function is not correctly working, too.

Who's duty about modification of this wrong library?

[RobertoBozzolo]

There is nothing wrong in those function, it's really that you haven't read the help for ListGetItem, which clearly states that positionOfItemToGet parameter must vary from 1 to the number of items in the list. With your for loops starting at 0, you are really reading the last element in the list first (END_OF_LIST has the value of 0), next all other elements except the last one.

[just4u78]

Thanks for your attention.

I just know about the index.

[jm73]

Hello,

I met the same problem with ListFindItem:

ListFindIt​em with StartingPo​sition out of range

You are not alone

Most CVI functions returned error codes except the List functions, most CVI functions are 0 based except the List functions. The List functions don't respect the CVI "rules", unfortunatly for us !

Best regards.

[RobertoBozzolo]

Well, as Daniel and Luis explained in the thread you linked, this is not actually a bug, even though I agree that it's not obvious.

Neither it's true that list functions are the only 1-based ones: just as an example, when you work with tables, row and column indexes are 1-based, working with a database the first record is 1 and there may be other cases.

The true fact is that when you use a function that requires an index you must double-check whether it is 1-based or 0-based.

[jm73]

Hello Roberto,

I agree with you, it's not a bug and we must be careful when using index.

1°) I think the documentation is "ambiguous". The parameter startingPosition for ListFindItem function is defined like this:

The position of the item in the list to start the search from. The position may be a number from 1 to the number of items in the list.
To start searching from the first item in a list, the constant FRONT_OF_LIST may be passed.

When you read " The position may be a number from 1 to the number of items in the list"  you mind automatically eliminates values <1 (you never remember that FRONT_OF_LIST = -1 ! ) and END_OF_LIST is not mentionned.

If you write the help like below with the possible values, perhaps there will be less confusion:

The position of the item in the list to start the search from. The possible values are:

• -1 (FRONT_OF_LIST) to start searching from the first item in a list.
• 0 (END_OF_LIST) to start searching from the last item in a list.
• a number between 1 and the number of items in the list.

2°) I think it's was a bad idea to define END_OF_LIST = 0 because 0 is a "special" value.

END_OF_LIST = -2 would have been a better choice. So ListGetXXX would return NULL with an index = 0 and the index mistake would  be easier to detect .

Bye.

[RobertoBozzolo]

Yes, you're right, that choice of constant value is odd and may lead to confusion, even more if you consider for example that VAL_TO_EDGE (the constant used to set Rect structures up to the end of valid range in tables) is defined as -1!

That note of passing FRONT_OF_LIST to start searching from the beginning is too weak compared to END_OF_LIST being set as 0, so I agree that an improvement in the function help may be needed.

I have as a golden rule to carefully read the help and use system-defined constant whenever possible: this example encourages me to continue this way!