あれ？

Fedora 33 の gcc で C99 ってオプション無しで対応しているんだね。
知らない人多いかもだけど C99 以前は先に変数宣言が必須だったのよ。
ちなみに GNOME アプリのソースは今でも全部そうなっている。

C++11 範囲ベース for ループ 入門

C++ 11 もそのまんまビルドできるじゃん。
いや筆者って C++ は面倒臭いのでほとんど使わないんだけど。

C++14 – Wikipedia

検索したら C++14 も既に、Clang も当然のように。
なんてこった。。。。。

gcc で C/C++ – Paepoi

筆者の作った上記ページがまさか過去の遺物になっていたとは。
M1 Mac で Clang なんてページを追加しようと思ったらこんなことに。
書き換えするか、忙しいのでのんびり待ってね。

前回 jxa で readline を使ったけどさ。
やっぱり C でも使いたいヤン。

GNU readline | Apribase

タブキー保管ができたり上矢印キーで履歴が辿れたり、まさに端末って感じ。
gets や scanf は非推奨なんだし、端末入力はコレに統一でいいじゃん。

Fedora では libreadline.so は最初から入っている。
でも C のヘッダは無いので以下のコマンドでヘッダを追加する必要がある。

# ncurses ヘッダも依存関係で入るけど気にしない。
sudo dnf install readline-devel

macOS では Command Line Tools の導入で readline.h も入ってくる。
GNU のものではなく互換品だったりするけど。
なので検索すると editline/readline.h と指定、なんて出てくると思う。
現在は以下にシンボリックリンクがあるので readline/readline.h のままでいい。

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/readline.h

ビルドするにはどちらも -l リンカオプションは必要。

#include <stdio.h>
#include <stdlib.h> /* free() */
#include <string.h> /* strcmp() */
#include <readline/readline.h>
#include <readline/history.h>

/*
    Fedora: gcc -lreadline src.c
    macOS:  clang -lreadline src.c
*/

int main(void) {
    char *s;
    printf("usage: exit 又は Ctrl+D で終了\n");
    while (1) {
        s = readline(">> ");
        if (s == NULL) { /* Ctrl+D */
            printf("\n");
            break;
        } else if (strcmp(s, "exit") == 0) {
            free(s);
            break;
        } else if (*s == '\0')
            printf("なんか打ち込めよ！\n");
        else
            printf("%s はカッコイイ！！！\n", s);
        add_history(s);
        free(s);
    }
    return 0;
}

で。

Fedora, macOS 共に上矢印キーで履歴が辿れるし control+D も使える。
macOS の history.h って実は readline.h へのリンクなので不要だけど互換のために。
string.h 等の指定も省略可能だけど警告がウザいので入れたほうがいい。

何を今頃になって子プロセスについて詳しく調べる。
UNIX 系なら fork という C 言語の関数で使えますね。

[unix fork] というワードで検索すれば山程サンプルコードが見つかる。
みんな waitpid という関数を呼んでいます。

技術的雑談-プロセスの生成と後始末(Linux C++編) – Tsubasa’s HomePage

上記が綺麗にまとめてくれている、筆者の勝手な感想だけど。
つまり子プロセスは必ずゾンビプロセスになるので回収しなきゃいけないのねん。

あれ、Gio.Subprocess も g_subprocess_wait 呼出しが必要だったりする？
devhelp をよく見ると

GSubprocess will quickly reap all child processes as they exit, avoiding “zombie processes” remaining around for long periods of time.
g_subprocess_wait() can be used to wait for this to happen, but it will happen even without the call being explicitly made.

と書いているので必須ではないみたい。
待つ必要がある時だけ呼び出せばいいのね。

とにかく Node.js の
require(‘child_process’).exec;
と同等に動くサンプルソースを書いてみる、関数ポインタを使えばいいかな。
今回も動作が解りやすいように GUI アプリを立ち上げてみる。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

void child_process_cb(char* command) {
    execl(command, NULL);
    printf("This string is not displayed\n");
}

void nodejs_exec(char *command, void (*callback)(char*)){

    pid_t pid;
    int status;

    pid = fork();
    if (pid == 0) {
        printf("__child__\n");
        callback(command);
        exit(-1);
    }

    printf("__start__\n");

    waitpid(pid, &status, 0);
    /* printf ("PID: %d status: %d\n", pid, status); */
}

int main(){
    nodejs_exec("/usr/bin/eog", &child_process_cb);
    return 0;
}

で

と eog を終了するまで待機するのが解ります。
子プロセスの stdout を得たい場合は下記のようにすればいい。
面倒臭い！

printf – execvp fork : wait for stdout – Stack Overflow

GSubprocess がドンダケ簡単なのかを思い知っただけだった。
てかやはり非同期はメインループをぐるぐる回すのが一番解りやすいや。

Python の threading はあまり意味が無いので有名。
じゃあマルチスレッドは GLib でやればいいんでないの？
GLib (Gio) でのマルチスレッドは GTask で簡単にできるらしい。

早速 PyGObject で…
g_task_run_in_thread 関数がバインドされていないヤン！

Gjs からも当然使えないってことだよね。
ならば Vala で、って valadoc のどこにも書いていない…

しかたがない、久々に C 言語でやってみるか。
画像が沢山あるディレクトリから GdkPixbuf をリサイズして取り込む例。
マルチスレッドで取り込み次第順次表示していく感じで。

GF_PATH 定数は自前で画像の多いディレクトリに書き換えてね。

#include <gtk/gtk.h>
#include <gdk-pixbuf/gdk-pixbuf.h>

/*
gcc tasktest.c `pkg-config --cflags --libs gtk+-3.0`
*/

#define GF_PATH "/home/sasakima-nao/pic/test"

GtkWidget *flowbox;

void
task_cb (GTask *task, gpointer source_object, gpointer task_data, GCancellable *cancellable) {

    GdkPixbuf *pixbuf;
    GtkWidget *image;

    pixbuf = gdk_pixbuf_new_from_file_at_size (task_data, 80, 100, NULL);
    image = gtk_image_new_from_pixbuf (pixbuf);
    gtk_widget_show (image);
    gtk_container_add (GTK_CONTAINER (flowbox), image);
    g_free (task_data);
    g_object_unref (task);
}

void
button_click_cb () {

    GFile *file;
    GFileEnumerator *dirlist;
    gssize result;

    file = g_file_new_for_path (GF_PATH);
    dirlist = g_file_enumerate_children(file, G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME, G_FILE_QUERY_INFO_NONE, NULL, NULL);
    while (TRUE) {
        GFileInfo *info;
        if (!g_file_enumerator_iterate (dirlist, &info, NULL, NULL, NULL))
            break;
        if (!info)
            break;
        GTask *task;
        gchar *fullpath;
        fullpath = g_strdup_printf ("%s/%s", GF_PATH, g_file_info_get_display_name (info));
        task = g_task_new (NULL, NULL, NULL, NULL);
        g_task_set_task_data (task, fullpath, NULL);
        g_task_run_in_thread (task, task_cb);
    }
    g_object_unref (dirlist);
}

int
main (int argc, char *argv[]) {

    GtkWidget *window;
    GtkWidget *button;
    GtkWidget *vbox;
    GtkWidget *scrolled;

    gtk_init (&argc, &argv);
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    button = gtk_button_new_with_label ("clicke!");
    g_signal_connect (G_OBJECT (button), "clicked", button_click_cb, NULL);
    flowbox = gtk_flow_box_new ();
    gtk_widget_set_valign (GTK_WIDGET (flowbox), GTK_ALIGN_START);
    vbox = gtk_box_new (GTK_ORIENTATION_VERTICAL, 0);
    gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, FALSE, 0);
    gtk_box_pack_start (GTK_BOX (vbox), flowbox, TRUE, TRUE, 0);
    scrolled = gtk_scrolled_window_new (NULL, NULL);
    gtk_container_add (GTK_CONTAINER (scrolled), vbox);
    gtk_container_add (GTK_CONTAINER (window), scrolled);
    g_signal_connect (G_OBJECT (window), "delete_event", gtk_main_quit, NULL);
    gtk_window_resize (GTK_WINDOW (window), 600, 400);
    gtk_widget_show_all (window);
    gtk_main ();

    return 0;
}

面倒臭え！
何故 C で作りたい初心者が多いのか理解できネェ！！
GTask の破棄はコレでいいのかよくワカンネェ（ぅぉい！

とにかく起動してボタンを押してみる。

うん、これだけで見事に CPU コアをフルに使って動いている。
画像も一枚ずつ順次表示される、なるほど。

これで本格的マルチスレッドもバッチリ。
って、Comipoli で使いたいんで Python でないと困るんだけーが。