C/C++」タグアーカイブ

UNIX fork

何を今頃になって子プロセスについて詳しく調べる。
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 がドンダケ簡単なのかを思い知っただけだった。
てかやはり非同期はメインループをぐるぐる回すのが一番解りやすいや。

GTask

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

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

no_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 の破棄はコレでいいのかよくワカンネェ(ぅぉい!

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

murti_core

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

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

Gedit gcc

Gedit の外部ツールは便利だが自分で設定したショートカットキーを忘れる。
簡単なキーに割付けたくてもできないことも多いし。
特に C ビルドで GLib や Nemiver の利用を振り分けしたい場合とか。

Nemiver | PaePoi

本格的に作るものなら当然 Makefile を用意するので問題ない。
けれどチビッと試したいコードのためにそんな面倒したくないですよ。
プログラミング関連は全部 F5 キーだけでまかなえないものか。

そうだ、’GLib.h’ という文字列が含まれているかどうかで振り分けできないか?
ものは試しだ、こんなツールを作ってみた。

#!/bin/sh
PYTHON="text/x-python"
GJS="application/javascript"
HTML="text/html"
BASH="application/x-shellscript"
VALA="text/x-vala"
CSRC="text/x-csrc"
echo @MIMEtype $GEDIT_CURRENT_DOCUMENT_TYPE
if [ $GEDIT_CURRENT_DOCUMENT_TYPE = $PYTHON ]; then
    python3 $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $GJS ]; then
    gjs $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $HTML ]; then
    google-chrome $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $BASH ]; then
    sh $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $VALA ]; then
    vala $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $CSRC ]; then
    src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
    case $src in
        *gtk.h*)
            echo "Gtk Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0` ;;
        *glib.h*)
            echo "GLib Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0` ;;
        *)
            echo "Gcc Build"
            gcc $GEDIT_CURRENT_DOCUMENT_PATH ;;
    esac
else
    echo Non Support File
fi

全部読み込んで case 文にしたのは inclide が一行目とは限らないので。
ぶっちゃけ効率ガン無視だがチョコッとビルド用途なのでいいよね。

ついでに Nemiver 用も

#!/bin/sh

src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
case $src in
    *gtk.h*)
        echo "Gtk Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0`
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
    *glib.h*)
        echo "GLib Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0`
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
    *)
        echo "Gcc Build"
        gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH
        if test $? -eq 0; then
            nemiver debug
        fi
        ;;
esac

gedit_tool

これで F5 を押すだけで筆者が使う言語は全部まかなえるぜ。
あと PHP があるけどこれは Apache 経由でしか使わないので。

いや、本当はモードごとに書いたほうがいいのだろうけどね。
ツールが一つで自力振り分けのほうが筆者はメンテが楽なだけ。

Mac x86_64

さて、筆者もついに Mac を手に入れた。
これで Mac 向けアプリの開発、をするかどうか今は解らない。

ところで Mac 向けアプリの C コンパイラは UNIX 系なので gcc である。
困ったことに Xcode 付属品らしい、つまり Xcode を入れる必要がある。

App Store から落とす、って Xcode って 2.57GB もあるんかい!
単なるアプリケーションなのに Fedora iso の二倍って何だよ。
Linux アプリはデカくてもキロバイト単位なので本当にウンザリする。

インストールが終わって即使おうと思ったが gcc が見つからない。
C言語入門 – MacでC言語 – コンパイラ(gcc)のインストール – Xcode – Command Line Tools – Webkaru
こんなページを見つけたけど Yosemite では一度起動すれば自動で入った。

gcc で C/C++ – L’Isola di Niente
OS X はたしか 64bit だったはず。
コンパイラが gcc だから Linux x86_64 と同じ結果になると思う。
上記ページの x86_64 サイズ確認コードを動かしてみる。

以前は sizeof の値を %d にしていたのだが %lu にしろと Warning が出た。
Mac の gcc は Linux より警告レベルを高く設定しているようだ。
ということで %lu 指定に書き換えて普通にビルド、そして実行。

x86_64

やはり Linux x86_64 とまったく同じだね。
日本語を扱う場合は UCS-4 だということに注意しよう。
てか UTF-16 なのは Windows だけなんだが。

しかし /usr/include ディレクトリが存在しないぞ。
スタジオエッチはドコにあるのだ?

stdioh

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
にあった、なるほど Xcode 必須なわけだ。

まあ Xcode のエディタは思っていたよりシンプルで使えそう。
エディタを探そうと思ったけどコレを使いこなしたほうがよさげ。
というか、なるべくアプリは少なくしたい、デカいのはもう嫌。
私的に必須な逆インデントのショートカットキーもあるので問題ない。

no_modeline

さすがに modeline は使えなかった、惜しい。
ちなみに Gedit は Yosemite では起動すらできなかった。

GtkBuilder

GtkBuilder を入れてみた。
見た目は凄い多機能に見える、どんな感じなんだろう。
ちなみに、コレも dnf コマンドからでないと入らない。

gnome_builder_install

あれ、clang 必須なのかな?
というかこの名前なのに Gtk+ ヘッダは依存関係にはないのかよ。
後で判るけど gcc でよかった、その他必要そうなものも導入しておこう。

早速新規プロジェクトを作ってみよう。
起動すると HDD 内の GPL プロジェクトを自動検索していた。
便利なんだか余計なお世話なのか、大半が参考用なのに。

あらかじめ作業用ディレクトリを作っておいく。
起動したら左上の [New] ボタン、フォルダアイコンのほうをクリック。
先程作ったディレクトリを指定し [Continue] する。

new_proj

configure.ac をプロジェクトファイルとして扱うようだ。
つまり autotools も必須ということみたい。
適当にコードを書いてプロジェクトを保存…

できなかった。

色々試したが autogen.sh 必須。
autotools にて自力で configure.ac を作った後に使うもののようだ。

というか、コイツのビルド機能は autogen.sh を実行するだけ。
そりゃコンパイラはどっちでもいいわ。

一応、autogen.sh は autotools のコマンドをまとめておくスクリプト。
最小限のサンプルを置いておくよ、README のとおりにやってね。
honda-0.0.1.tar.gz

そうそう、Build といっても configure スクリプトを作るまでです。
make 以降は自力。

小物を作って遊ぶには無駄すぎる。
デバッガもない、コレを IDE と言ってもいいのだろうか?
単なるテキストエディタだ。

コード補完や閉括弧自動挿入と初心者大喜びなエディタなのに。
私的に期待外れというかショボすぎて唖然とした。

うーん、今後に期待しとく。