Returning and Using Strings

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Since all extensions will have to be recompiled anyway, I was wondering if any had given any thought to conventions regarding strings. Here are a few questions I'd like to have answered:

    -Is null an acceptable return value? Will an extension ever be passed null? (I'm guessing the answer to the first question will answer the second.)
    -If a string is passed to a function, can that function modify it? I would imagine that this would be a bad thing to do but that really depends on the answer to my next question.
    -If a function is returning a string, should it ever return a pointer to one of its internal strings? SHould it always return a copy?


    These are a few things that bothered me in previous extensions. I know that MMF never used null strings, but I know that a few 3EE extensions did return them, which could cause other extensions (that were not expecting nulls) to crash.

    I also saw another scenario where the Associative Array object would return a pointer to one of its interanl strings and then a function in another object (String Manipulator maybe) would modify that string directly, causing AssArray to exhibit odd behavior.

    I would just like to avoid these scenarios in MMF2 if at all possible. Conventions on these sorts of things would be nice.

    Since all extensions will have to be recompiled anyway, I was wondering if any had given any thought to conventions regarding strings. Here are a few questions I'd like to have answered:

    -Is null an acceptable return value? Will an extension ever be passed null? (I'm guessing the answer to the first question will answer the second.)
    -If a string is passed to a function, can that function modify it? I would imagine that this would be a bad thing to do but that really depends on the answer to my next question.
    -If a function is returning a string, should it ever return a pointer to one of its internal strings? SHould it always return a copy?


    These are a few things that bothered me in previous extensions. I know that MMF never used null strings, but I know that a few 3EE extensions did return them, which could cause other extensions (that were not expecting nulls) to crash.

    I also saw another scenario where the Associative Array object would return a pointer to one of its interanl strings and then a function in another object (String Manipulator maybe) would modify that string directly, causing AssArray to exhibit odd behavior.

    I would just like to avoid these scenarios in MMF2 if at all possible. Conventions on these sorts of things would be nice.

    >> -Is null an acceptable return value?

    No, you must not return NULL. Return an empty string if necessary.

    >> Will an extension ever be passed null?

    Theoretically no, but practically yes : there might be bugs or another extension could return NULL and MMF2 could pass it to your function directly without processing it

    => you should always test if a string parameter is NULL.

    >> If a string is passed to a function, can that function modify it?

    No, you must not modify it.

    >> If a function is returning a string, should it ever return a pointer to one of its internal strings?

    It can return a pointer to an internal string. MMF2 will make a copy if necessary.

    >> Should it always return a copy?

    No.

    Note: if you want to allocate memory for returning a string, use a callRuntimeFunction ( ... RFUNCTION_GETSTRINGSPACE_EX ... ). MMF2 frees strings allocated with this function when it no longer needs them.

    >> I know that a few 3EE extensions did return them, which could cause other extensions (that were not expecting nulls) to crash.

    Yes, that's what I said above.

    >> the Associative Array object would return a pointer to one of its interanl strings
    >> and then a function in another object (String Manipulator maybe) would modify that string directly

    Bad practice, you must not modify strings passed as parameters.

    Yves.

    >> -Is null an acceptable return value?

    No, you must not return NULL. Return an empty string if necessary.

    >> Will an extension ever be passed null?

    Theoretically no, but practically yes : there might be bugs or another extension could return NULL and MMF2 could pass it to your function directly without processing it

    => you should always test if a string parameter is NULL.

    >> If a string is passed to a function, can that function modify it?

    No, you must not modify it.

    >> If a function is returning a string, should it ever return a pointer to one of its internal strings?

    It can return a pointer to an internal string. MMF2 will make a copy if necessary.

    >> Should it always return a copy?

    No.

    Note: if you want to allocate memory for returning a string, use a callRuntimeFunction ( ... RFUNCTION_GETSTRINGSPACE_EX ... ). MMF2 frees strings allocated with this function when it no longer needs them.

    >> I know that a few 3EE extensions did return them, which could cause other extensions (that were not expecting nulls) to crash.

    Yes, that's what I said above.

    >> the Associative Array object would return a pointer to one of its interanl strings
    >> and then a function in another object (String Manipulator maybe) would modify that string directly

    Bad practice, you must not modify strings passed as parameters.

    Yves.

    Thanks, Yves.

    These were the answers I was hpoing for. It might be worth noting the caveat about not modifying passed strings in the EXPPARAM_STRING and PARAM_EXPSTRING sections of the SDK help and noting the warning not to return NULL in the EXPFLAG_STRING section.

    Thanks,
    -Matt

    Thanks, Yves.

    These were the answers I was hpoing for. It might be worth noting the caveat about not modifying passed strings in the EXPPARAM_STRING and PARAM_EXPSTRING sections of the SDK help and noting the warning not to return NULL in the EXPFLAG_STRING section.

    Thanks,
    -Matt

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login