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

utf8_collate_key

いいかげんに Y901x が落ちまくる件とソート問題を解決させねば。
なんとかさせないと追加機能もやれないよ。
落ちる件は色々試しているんだがまだ原因が解らない、困った…

ソートに関しては自力を諦め Nautilus のコードをひたすら追う。
libnautilus-private/nautilus-file.c
に compare_by_display_name というソレっぽい関数をやっと見つける。

display_name_collation_key を strcmp で比較しているだけなのか。
g_utf8_collate_key_for_filename という glib の関数で代入している。

Unicode Manipulation

あれ、もしかして数値もドットもこの関数一つで解決してまうの?

The Whole PyGTK FAQ

Python には実装されていないようで。
最近のバージョンではあるかもと dir() で探しまくるも見つからず。

とにかくこの関数でどう変換されるのか気になるので C でやってみる。
Ubuntu 10.04 デフォルトでは gcc はあるけど gtk や glib のヘッダは無い。
Glade を入れれば依存関係で Devhelp を含めまとめて入るので Glade を入れる。

/*
gcc  b.c `pkg-config --cflags --libs gtk+-2.0`
*/

#include <stdio.h>
#include <gtk/gtk.h>
#include <glib.h>

int main() {
    gchar *c;
    c = "a1.mp4";
    gchar *u;
    u = g_utf8_collate_key_for_filename (c, -1);
    printf("%s to %s\n", c, u);
    /*g_free(c); is Segmentation fault*/
    g_free(u);
    return 0;
}

久々の C なんだがこんな感じでよかったかなぁ…
strcpy で警告になったのが Visual Studio と同じだったが代替が解らない。
とにかく結果。

なんだかよく解らないのに変換されとる。
後は比較関数を作って実験して上手くいったら…
Python で使うんだが、ctypes しか手が無いかな?

Default argument

Python という言語は関数のオーバーロードができない。
何って、つまり引数が違うだけで同じ関数名を利用する多重定義のことである。
慣れると関数やメソッド量を少しでも減らそうとよく利用するようになる。

だからといっていくつも別名の関数を用意するのは効率が悪い。
結果似たようなことができるデフォルト引数を利用するようになるわけだ。

ん、そういえば C++ や C# もデフォルト引数って使えたよな。
色々な言語を行ったり来たりしている私は同じように書いたほうがいいのでは?
それにデフォルト引数のほうがコードの記述量が減らせるメリットがある。
コンパイル後の機械語では似たような結果になるのだろうけど…

コードが短くできるのは魅力なので C++ や C# でもデフォルト引数をなるべくやろう。
オーバーロードはよく使うから覚えているけどデフォルト引数は C++ でどう書くの。
一つの cpp 内での書き方なら簡単に見つかる、Python とまったく同じか。

けど別ファイルにするには?
やってみた。

Tool.h

#pragma once
extern int messagebox(HWND hWnd, LPCWSTR msg, LONG button=MB_OK, LONG icon=MB_ICONEXCLAMATION);

Tool.cpp

#include "StdAfx.h"
#include "Tool.h"

#define MSG_TITLE L"確認 - Y901w"

int messagebox(HWND hWnd, LPCWSTR msg, LONG button, LONG icon)
{
	return MessageBox(hWnd, msg, MSG_TITLE, button | icon | MB_SYSTEMMODAL);
}

を用意してメインウインドウで使ってみる。

#include "Tool.h"
//略
messagebox(hWnd, L"ウニコード", MB_OKCANCEL);

extern 宣言で使う場合は extern 宣言のほうにだけデフォルトを書けばいいようだ。
本当は名前空間か class で static にするほうがイイと思うけどコレが一番簡単。
Python のように自作関数は小文字と掟を作っておけば間違えることも無いだろう。

しかし今になって昔のコードを見るとメンバ変数に m_ を付けていないとかで迷う。
自分が書いたコードなのに似たような変数名をローカル変数にしていたら迷ってしかたがない。
だから m_ プリフィクスみたいな書き方を推奨しているのね、そうなることが解っているから。
Python の self 強制って実はありがたいと思った、C++ も this 強制でいいくらいだ。

y901w-0.0.0

Linux 飽きた。
Python もなんか気が乗らない、というか開発系 Blog が軒並み止まっているような…
時期的に .NET Framework 4 前というのもあるし C# 屋達もイマイチだね。

ならばしばらく Windows で C/C++ といこう、なんて久しぶりな。
せっかくだからずっと放置の Cinema の更新でも。
いやいや Y901w と名前を変えて Y901x にデザイン等を合わせるほうがいいと思う。
というより x64 対応ビルドを少しやってみたい。

問題は Visual Studio を VirtualBox 上の x86 Vista に入れていることだ。
x64 で debug できないし VMR9 が動かない、まぁビルドはできるからなんとかなるさ。

とりあえずファイルドロップで再生できるだけのスケルトンを Cinema から抜き出し。
抜き出したわりにはファイルがイッパイある、SDK だけで作るとこうなるんだよなぁ。
ということで x64 ビルドプロジェクトを含めてソースコードのバックアップ。

y901w-0.0.0.zip

x64 で再生できるか試してみる。
って Windows 7 64bit だと wmv 以外はドエリャァ面倒くさいのね。
ffdshow を入れて haali ってのを入れてやっと H.264 が再生できる。

Linux ならリポジトリからアッサリとデコーダーを導入できるのに…
つか WMP は標準で H.264 を再生できるのにサードには提供してくれないという…

普通に検索すると怪しさ全快なページばかり当たるので wikipedia から辿る。
そうだった、Windows でこの手は既に無法地帯化しているんだったよなぁ…
やっぱりヤメようか、まぁ x64 で DirectX の実験だと思えばいいか。

おぉ x64 ネイティブで普通に動いた。
後は部品を付けてチマチマやればなんとかなりそうだ。
ところで今頃気がついたのだが…

Opera って GStreamer 使っているの?
というか Windows から使えるのなら使ってみたいわな。

glade

覚書ページの整理が全然進まない。
PyGtk はどの順番で widget 解説を進めるか考えると頭がおかしくなりそう。
TreeView や TextView の前に Scrollbar や Scale の前に Adjustments の知識が必要で…

それより、もう使わなくなった Glade 関連の解説なんかはどうしようかと。
なんたって今では普通 libglade ではなく GtkBuilder を選ぶだろうし。
最初の GUI アプリ作りのとっかかりは Glade ほど解りやすいものは無いだろうし。

いやまてよ。
C 言語から Glade を使う方法てか GTK+ コンパイル方法も併記すればいいんでない。
なんたってソレは私自身もやったことがないので勉強にもなる。

よし Mandriva One に Glade や GTK+ ヘッダをインストールしてみよう。
C でやるには別途でコンパイラの他に GTK+ ヘッダを入れる必要があるんだよね。
Ubuntu での需要ばかりだろうから Ubuntu には後で入れる。

libgtk+2.0_0-devel を導入。
依存関係で他のパッケージも沢山インストールされるが気にしない。

devhelp も導入。
/usr/share/gtk-doc 以下の doc はコレで見られるようになる。
libgtk+ を入れた後はこんな感じになる。

glade も一応入れてと。
んで海外からチュートリアルを探してみたら強烈なとこを見つけた。

GTK+ and Glade3 GUI Programming Tutorial – Part 3

とにかく tutorial.xml を落とし C コードをコピペしてコンパイルしてみる。

普通にコンパイルが通って動かせた。
ふむふむ、C から Glade ファイルを使うにはこうすればいいのか。
しかしこんなトコを見た後では何を書くのも気後れするわ。

でもコンパイルオプションが長くてメンドクセ!
メモリの解放処理をいちいち書かなければいけないのがメンドクセ!
つーかメソッドではなく関数を使うのがメンドクセ!
PyGtk がどれほど楽チンなのか改めて思い知る。

C 言語で文字列メンドクサイ

最近の Linux なら locale は ja_JP.UTF-8 でイケるようだ。

scanf – Wikipedia
scanf ってこんなに面倒だったかなぁ…
gets だと思いっきり警告だし。

wchar_t って Linux では 4 バイトなんだね。
Windows つか Visual Studio では 2 バイトなのですけど。

最近の Windows SDK のようにセキュリティ関数が存在してくれないと怖いなぁ…
文字列処理って簡単にバッファオーバーランが起こせるからね。
malloc で動的処理すればなんとかなりそうだけど std::string のほうが(略

日本語の文字数カウントとかをするには UNICODE にするのが一番なわけで。
とりあえずバッファオーバーラン等を考慮しないでうまくいったコード。

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

int 
main (int argc, char *argv[])
{
    /* set locale */
    setlocale( LC_CTYPE, "ja_JP.UTF-8" );

    /* おまけ、変数バイト数チェック */
    printf("int     サイズ = %d\n", sizeof(int));
    printf("char    サイズ = %d\n", sizeof(char));
    printf("wchar_t サイズ = %d\n", sizeof(wchar_t));

    /* バッファ */
    char cin[256];
    wchar_t s[256 * 4];
    char c[4] = {0};

    /* 何か入力させる */
    printf("何か文字列を入力して Enter\n");
    scanf("%s", cin);

    /* UNICODE に変換 */
    const char *cc = cin;
    size_t t = mbsrtowcs(s, &cc, strlen(cc), NULL);
    printf("文字数は %d です\n", t);

    /* 一文字ずつ書き出ししてみる */
    int i=0;
    for (i; i<t; i++)
    {
        wctomb(c, s[i]);
        printf("%s\n", c);
    }
    return 0;
}

あーくそ!Python ならたったコレだけ、import も無しで同じことができるんだが。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

s = raw_input("何か文字列を入力して Enter\n")
u = unicode(s, "utf8")
print "文字数は %d です" % len(u)
for c in u:
    print c.encode("utf8")

しかもバッファオーバーランの心配は無いと思うし。

※追記、GLib を使えば簡単だった
gunichar | PaePoi