Here's a heads-up that I am changing the format of those native methods
which are being upgraded to support strings properly. The code
generator initializes a stack variable for each type conversion; my own
experience is that this makes the code more verbose and harder to read.
Then there's the question as to whether you can trust the compiler to
optimize all of this extra stuff away (I never learned to trust C
compilers' optimizers).
As a result, you'll see code like this:
JNIEXPORT jboolean JNICALL
Java_org_gnu_gtk_TextIter_gtk_1text_1iter_1backward_1search (JNIEnv
*env, jclass cls, jint iter, jbyteArray str, jint flags,
jint matchStart, jint matchEnd, jint limit)
{
GtkTextIter *iter_g = (GtkTextIter *)iter;
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
GtkTextSearchFlags flags_g = (GtkTextSearchFlags) flags;
GtkTextIter *matchStart_g = (GtkTextIter *)matchStart;
GtkTextIter *matchEnd_g = (GtkTextIter *)matchEnd;
GtkTextIter *limit_g = (GtkTextIter *)limit;
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
{
jboolean result_j = (jboolean) (gtk_text_iter_backward_search
(iter_g, str_g, flags_g,
matchStart_g, matchEnd_g, limit_g));
return result_j;
}
}
be putback as this:
JNIEXPORT jboolean JNICALL
Java_org_gnu_gtk_TextIter_gtk_1text_1iter_1backward_1search (JNIEnv
*env, jclass cls, jint iter, jstring str, jint flags,
jint matchStart, jint matchEnd, jint limit)
{
const char *str_utf = (*env)->GetStringUTFChars(env, str, NULL);
jboolean result_j = (jboolean) gtk_text_iter_backward_search (
(GtkTextIter*)iter,
(gchar*)str_utf,
(GtkTextSearchFlags)flags,
(GtkTextIter*)matchStart,
(GtkTextIter*)matchEnd,
(GtkTextIter*)limit);
(*env)->ReleaseStringUTFChars(env, str, str_utf);
return result_j;
}
If a parameter is cast the same way twice I keep the temporary variable,
again to make things as legible as possible.
Any objections?
Tom
|