知らなかったけど Python 2.6 から format メソッドが使えるんだね。
3.0 系だけだと今まで思っていたよ、IronPython 2.6 も同様。
"{0}: {1}+{2}={3}".format("calc", 1, 2, 1+2)
"%s: %d+%d=%d" % ("calc", 1, 2, 1+2)
のように値に対する書式指定がいらない、くらいしかメリットは無いけど。
引数の順番が変更できたり同一の値を参照…なんてやる人少ないだろうし。
少なくとも C# からプログラミングに入った人なら判りやすいのではないかと。
今は「どっちでもいい」なので好きなほうで書けばいいわけだ。
ただ書き方ごときにあーだこーだなら Ru…（以下略
しかし春の陽気のせいかヤル気が出ない…
Y901w はもう現行 Cinema のまんまでいいじゃないかとか…
とはいえ今になってコードを見ると自身で寒いので全部書き直したいし…
なんんてやっていたら全然進まねぇや、そろそろ Windows 用を何か作らないと干されそう。
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 強制でいいくらいだ。
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 ビルドプロジェクトを含めてソースコードのバックアップ。
x64 で再生できるか試してみる。
って Windows 7 64bit だと wmv 以外はドエリャァ面倒くさいのね。
ffdshow を入れて haali ってのを入れてやっと H.264 が再生できる。
Linux ならリポジトリからアッサリとデコーダーを導入できるのに…
つか WMP は標準で H.264 を再生できるのにサードには提供してくれないという…
普通に検索すると怪しさ全快なページばかり当たるので wikipedia から辿る。
そうだった、Windows でこの手は既に無法地帯化しているんだったよなぁ…
やっぱりヤメようか、まぁ x64 で DirectX の実験だと思えばいいか。
おぉ x64 ネイティブで普通に動いた。
後は部品を付けてチマチマやればなんとかなりそうだ。
ところで今頃気がついたのだが…
Opera って GStreamer 使っているの？
というか Windows から使えるのなら使ってみたいわな。
Linux でホームに作成されるデフォルトディレクトリ名は
~/.config/user-dirs.dirs
で指定及び確認ができることは大半の人が知っているだろう。
自分の都合で名前変更しても自動で追従する嬉しいのか迷惑なのかよく解らな（以下略
Windows も準拠してくれれば嬉しいのに…
というのは置いておいて英語表記のデフォルト名は
/etc/xdg/user-dirs.defaults
で私が知るかぎりでは確認できます、全部の Linux がそうなのかは知りません。
ということで。
アプリを自分で作るとデフォルトディレクトリ名を探したくなる場合がある。
自身が使う範囲のみであれば決め打ちでいいけど公開する場合は考える必要がある。
user-dirs.dirs を自己解析すればとも思うけどこの位置さえ決め打ちでいいのだろうか？
画像関連アプリで画像ファイルを保存しているだろう場所を指定みたいなくらいしか（以下略
glib に get_user_special_dir なんてメソッドがある。
コレを使えば PyGtk の GUI アプリでユーザー指定のディレクトリが見つけられそうだ。
get_user_cache_dir メソッドも後々で使いそうだし覚えておいたほうがいいかなと。
#!/usr/bin/env python
#-*- coding:utf-8 -*-
import glib
xdg_default = (
"Desktop",
"Documents",
"Download",
"Music",
"Pictures",
"Public",
"Templates",
"Videos"
)
user_conf = (
glib.USER_DIRECTORY_DESKTOP,
glib.USER_DIRECTORY_DOCUMENTS,
glib.USER_DIRECTORY_DOWNLOAD,
glib.USER_DIRECTORY_MUSIC,
glib.USER_DIRECTORY_PICTURES,
glib.USER_DIRECTORY_PUBLIC_SHARE,
glib.USER_DIRECTORY_TEMPLATES,
glib.USER_DIRECTORY_VIDEOS
)
for i in range(len(xdg_default)):
print "%s: %s" % (xdg_default[i], glib.get_user_special_dir(user_conf[i]))
うん、これでいいんじゃない。
とにかくコレでフルパスが得られるので処理が簡単。
自身で何も指定していないなら None が戻るので処理が簡単。
よし、これで Y901x の初期選択ディレクトリを（理由はソレかい…
私が付けている名前を晒しているけど気にしない
動画の保存先名デフォルトは Videos より Movies のほうがイイと思うんだけどなぁ…
Linux で端末から trash というコマンドでファイルをゴミ箱に捨てるアプリを新規公開。
いや自分で使いたかったんで、ちなみに中身はコレだ。
たったの 19 行w
man も pydoc も絶対にイラネェw
なんと親切なことにインストールスクリプト同梱w
GNOME だけでなく Mandriva KDE でもわざわざ動作確認済みw
Linux ゴミ箱を日本語で検索すると結構ヒットするんだけど…
g_file_trash を日本語でググってもウチしか当たらないんだが…
つーか Linux アプリを更新してもアクセス数は全然カワンネェwww
私は方向を間違えたのだろうか…