Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add StringArray_Find family of functions #36

Open
yanis-fourel opened this issue Jan 21, 2022 · 3 comments
Open

Add StringArray_Find family of functions #36

yanis-fourel opened this issue Jan 21, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@yanis-fourel
Copy link
Collaborator

Add StringArray_Find and StringArray_Find_F to be consistent with the existance of PointerArray_Find and PointerArray_Find_F.

The behavior of these StringArray functions should differ from the PointerArray ones in the usage of StringEquals for equality comparison instead of simple pointer comparison.

Another new function to search for a substring in any string of a StringArray would be nice to have as well

@yanis-fourel yanis-fourel added the enhancement New feature or request label Jan 21, 2022
@LexouDuck
Copy link
Owner

LexouDuck commented Jan 26, 2022

Partly done, via cd96b37

I have added StringArray functions which mirror the PointerArray_Find()/PointerArray_IndexOf() functions

I am leaving this issue open until we have a "Find substring anywhere inside stringarray" function implemented.

@LexouDuck
Copy link
Owner

I am thinking about how to implement this function... What prototype signature do you think that a StringArray_FindStringPart() function should have ? The big problem here is that we wish to return two values: the index/ptr within the stringarray, as well as the index/ptr of the part of the string which matched.

There are ways to work around the lack of this function, depending on the use case:

  1. if you just want the pointer of the beginning of the matching string:
char* found = StringArray_Find_F(strarr, match_func)
  1. if you just want the index of the item in the stringarray:
int found = StringArray_IndexOf_F(strarr, match_func)
  1. if you just want the pointer to the part within the string which matched:
char* found = (char*)StringArray_Reduce(strarr, match_func)
  1. if you just want the index of the matching part within the string:
int found = (int)StringArray_Reduce(strarr, match_func)
  1. if you want all of this info together from a single function call, there is currently no simple way to do this... so, my best suggestion would be to create a new struct, which we can use as a return value:
//! Stores a position inside some string within a string array.
typedef struct strarr_pos
{
    t_sint  index; //!< index of the string in the string array
    t_size  offset; //!< offset of the char within the string
}   s_strarr_pos;

s_strarr_pos StringArray_Find_Char    (t_char const* const* strarr, t_char c);
s_strarr_pos StringArray_Find_Charset (t_char const* const* strarr, t_char const* cset);
s_strarr_pos StringArray_Find_String  (t_char const* const* strarr, t_char const* str);

Tell me what you think.

@yanis-fourel
Copy link
Collaborator Author

The only way we have to find the substring is to get both the index in the array and the index in the string. So if we have both, we should probably return both and let the caller ignore whichever one he didn't care about (if any)

Returning a struct is very good for clarity. It makes what the function returns very obvious, plus it is way cleaner (shorter) on the caller's side than say, returning results via out parameters (which is the only other way to return multiple values in c, right?)

I'm all in for your prototypes defined in you 5., except maybe I'd name the fields array_index and string_index if it's clearer? But I guess it's best to keep the name consistent with whatever you've been using elsewhere in the lib

Also I see the index is a t_sint, is it because you need to return -1 if no match is found ?
We could have a field t_boolean found for this purpose, and leave both result fields to be t_size... but again we may loose any benefit from the inconsistency it would create with the rest of the lib.. your call

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants