Nemiver

gcc で C/C++ プログラミングをする際のデバッガに gdb がある。
コマンドラインツールなので vi, emacs 愛用者は普通に使えると思う。
しかし筆者のような Gedit 愛用者には少々使い辛い。

何かないかと探すと Nemiver という GUI アプリケーションがあった。
ようするに gdb のフロントエンド。
GNOME Wiki! に登録されているし突然亡くなる心配はなさそう。

Apps/Nemiver – GNOME Wiki!

書くまでもなく日本語情報は無かった。
ということで自分で使ってみる。

sudo dnf install nemiber

で Fedora は導入できる、ubuntu は apt-get でいいはず。

設定の[デバッガ]タブにて gdb の位置を指定。
/usr/bin/gdb でいいはず、この設定は必要あるのかな?
レイアウト等はお好みで。

このアプリは起動時の引数に実行ファイルを渡すので終了させる。
ビルド時に gcc への引数 -g (デバッグ情報を含める)を追加。

gcc -g hoge.c
nemiver a.out

nemiver01

使い方は Visual Studio とだいたい同じですね。
F6 キーで次行へ進む、F7 キーで関数の内部へ入る。
F11 キーでカーソル行まで一気に進む、等々。

ブレークポイントは行番号横をクリック。
F5 を押していくと指定した位置で止まるのでその時の変数値なんかを。
下ペインのブレークポイントタブで通過数を確認等もできる。

下ペインのコンテキストタブで変数の現在値を確認できる。
日本語の文字列変数もそのまま確認できるけど静的配列だとダメです。

pchar

これ以外は各自で目的が違うと思うので勝手に調べてね。
Visual Studio を使っていた人ならなんとなく解ると思う。

っっって、つまり結局は毎回コマンドを打たなければいけないのか。
では意味がないので Gedit の外部ツールに登録してしまおう。

#!/bin/sh
gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0`
if test $? -eq 0; then
    nemiver debug
fi

external_tools

筆者は GLib を使うのでこんな感じにしてみました。
デバッグの為だけに糞重い開発環境を使う必要はないです。

しかし Gedit は便利だ、コマンドが充実した Linux が便利なだけですが。
問題は外部ツールが増えすぎると指定したキーを忘れてしまうことだ。

我家公主最可愛

台湾版ウチ姫にはオリキャラがいるみたい、名前を見れば納得。
《我家公主最可愛》 台灣官方網站

というか他の姫様達って初期のまだ良かった頃のまんまや。
攻撃力二倍姫もいないしアビリティは固定、ボイスも無い?

この頃程度に戻してほしいな、今のウチ姫は面白くない。
かといって他のゲームはもっとツマランので乗り換えできねー。

uchihime

実は今迄に五千円しか課金していない。
アメーバコインが使えた頃に Android で買ったので星屑はゼロのままw
台湾の皆様、そんなほぼ無課金でも結構 SR は集まりますよ。
めぼしいのは数人しかいませんけど組み合わせを考えるのもまた一興。

いや遊ばせてもらっているのだしあと数万なら払ってもいいのですが…
最近のガチャにン万円使って当たり姫を引かないと参加しても無駄骨が確定なランキングクエスト連発で流石にその気が失せた。
ギルドとか競い合いの要素が無かったから気に入ったのに。
ピンボールは面白いんだよ、無益な競い合いに金なんて払いたくないの。

でもランキング上位陣を見ると当たり姫がワンサカ。
こういうイベントばかりになったのはコリャ当然だなと。

嘆いたり馬鹿にしたりしている人、そうじゃなくてプログラミングを始めよう。
こういう人達がジャブジャブ課金したくなる楽しいゲームを皆も作っていこう。
以上プログラミングの勧めでした。

どうでもいいけど、Fedora 21 の iPhone コネクトアイコン。

iphone

どうみても昔ながらのケータイです。
Fedora 20 は普通に iPhone と同じ見た目だったのに何故変えた?
iPhone mount in GNOME | PaePoi

Stack area

最近スタック領域とかエラそうなことを書いているけど。
よく考えたら実は何故スタック領域という名前なのかを知らない。
スタックってデータを後入れ先出しすることだよね。

#include <stdio.h>
#include <stdlib.h>

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

    /* 自動変数はスタック領域 */
    int   i;        /* 4 byte 確保 */
    char  str1[6];  /* 6 byte 確保 */
    char* str2;     /* 8 byte (64bit の場合)確保 */

    /* NULL文字'\0'が入るので 5 byte 以下 */
    sprintf(str1, "%s", "Ninja");

    /* 256 byte をヒープ領域に確保 */
    str2 = malloc(256);
    sprintf(str2, "%s", "Kawasaki");

    for (i=0; i<2; i++)
        printf("%s %s\n", str2, str1);

    /* ヒープ領域確保分は解放する(確保を手放す)必要あり */
    free(str2);

    /* 解放されても別スレッドに上書きされるまでは残っている */
    printf("%s\n", str2);

    return 0;
}

ということさえ解っていれば別に意味は知らずとも…
ではイカンよな、もう少し理解しなきゃ。

学校では教えてくれないこと | 技術コラム集(組込みの門) | ユークエスト

そういう意味だったのか、宣言順に積み上がっていくのね。
ただ x86_64 だと 8 バイトでは上手くいかなかったので 16 に。

#include <stdio.h>
#include <string.h>

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

    char a[16] = "元の文字列", b[16];

    printf("before a[]=<%s>\n", a);
    strcpy(b, "0123456789abcdef破壊");
    /*
     * ちなみにコチラだと Segmentation fault
     * sprintf("%s\n", b, "0123456789abcdef破壊");
    **/
    printf("after  a[]=<%s>\n", a);

    return 0;
}

buffer_over_run

なるほど、これは完全に後入れ先出しだ。

関数内の自動変数もスタックに入るから確かにコレが一番効率いいな。
スタックってそういう処理がしたい場合に利用するのか、うんうん。
それも解って得した気分。

しかしこういう gcc で解説してくれるサイトなんですが。
皆 stdio.h だけインクルードしているけど、筆者の環境では

strcpy を使う時は string.h
malloc を使う時には stdlib.h

と関数宣言されているヘッダを直インクルードしないと警告になる。
ビルドはできるけどね、警告が出るのって嫌じゃないですか。

GIOChannel

glib での読み書きは g_open ではなく GIOChannel で行うらしい。
もう情報が山ほどありすぎてワケワカだよ、独学の限界を感じる。
まだよく解っていないけどとりあえずテキストで試してみた。

#include <glib.h>

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

    GIOChannel* channel;
    GError*     error = NULL;
    gchar*      str;
    gsize       length;
#if !GLIB_CHECK_VERSION (2,35,0)
    g_type_init ();
#endif
    channel = g_io_channel_new_file("watch.txt", "r", &error);
    if (error)
    {
        g_warning (error->message);
        g_error_free (error);
        return 1;
    }
    g_io_channel_read_to_end(channel, &str, &length, &error);
    if (error)
    {
        g_warning (error->message);
        g_error_free (error);
        g_io_channel_unref(channel);
        return 1;
    }
    g_printf(str);

    g_free(str);
    g_io_channel_unref(channel);
    return 0;
}

iochannel

こういうことでいいのかな?
char 配列ならバイト単位だからバイナリにも応用できるな。

んで、いつものように vala のサンプルコードを見てみる。
GLib.IOChannel ? glib-2.0
g_io_add_watch でハンドラを用意してメインループを回している。
このコードだとこうするメリットが特に見当たらないんですけど。

GMainLoop, GMainContext和GSource学?笔? – ?匠Smith先生的?? – 博客?道 – CSDN.NET

こんなこともできるのか、端末からの読み書きに GMainLoop とは。
つまりメインループを回すことに意義があるってことかな。

ただバックスラッシュ(\)がスラッシュ{/}になっているのは何故?
そこを書き換えて g_type_init を消せば普通にビルドできます。
このコードを参考に色々弄ってみると面白いかも。

中国にも glib を使っている人がいるんだな、つか日本人は…

g_fopen = int

#include <stdio.h>
#include <glib.h>
 
int
main (int argc, char *argv[]) {

    FILE*  f;

    /* OK */
    f = fopen("suzuki.txt", "w"); //return pointer
    fprintf(f, "SUZUKI %s", "Hayabusa");
    fclose(f);

    /* Error (x86_64) */
    f = g_fopen("kawasaki.txt", "w"); // return int
    g_fprintf(f, "KAWASAKI %s", "Ninja");
    g_close(f, NULL);

    /* No Error (x86_64)
    gint n = g_fopen("kawasaki.txt", "w"); // return int
    g_close(n, NULL); */

    return 0;
}

g_fopen

おいおい、どういうことだよ。
devhelp をよく見ると「コレは Windows の表記だ」とあるが。
fopen にマッピングではなく stat に合わせているのか?

glibc は glib のサブセットだと思いこんでいたけど違うんだな。
つまり Linux では FILE* は使わないほうがいいということみたい。
x86(32bit) だと気が付かないで混乱するかも。

glib – C言語で、UTF-8 の文字列から Unicode のコードポイントを取得するやりかた – Qiita

g_utf8_to_ucs4_fast って fast だから速いのかな?
GLib ってまだまだ知らないことが沢山あるな。

ただコードポイントを取得なら Python3 のほうが簡単そう。
単文字を ord() すれば UCS-4 のまま値が取れそうだけど、試すか。

文字コード考え方から理解するUnicodeとUTF-8の違い | ギークを目指して
「ほげふが」が [U+307B] [U+3052] [U+3075] [U+304C]
になれば OK ということね。

#!/usr/bin/env python3

s = "ほげふが"
for a in s:
    print("[U+{0:04X}] ".format(ord(a)), end=" ")

python_ord

思ったとおり。
ワイド文字が UTF-16 になる Windows 版じゃ変換が必要だけど。
ごめん Windows Python3 でも IronPython でもできるわ

win_code_point

ipy_code_point

Linux は GLib が簡単に使えて Python も実用的。
やはりプログラミングするなら Linux ですよ。