Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

01月27日のココロ日記(BlogPet)

ココロ、むいさんの影響で、最近店内を作るのが好きになりました。
何回やってもあきません。
…ヘンですか?

*このエントリは、ブログペットのココロが書いてます♪

久しぶりにゲームを買った

ryo_oh.png

さて、自分でプレイするか、面倒だからプレイ動画だけ見るか……

そう言えばこれを買いに行ったとき、店内ポスターを見てみさおピンのキャラクターソングが3月に出ることを知った。
背景コンビは解消ですか?(´Д⊂ヽ

動画版読者投稿ページ?

角川、YouTubeに公式チャンネル開設。新たなクリエイターの場を創出へ - BroadBand Watch

「著作物認識システムに十分な信頼性があることを確認できたので、角川はYouTubeを著作権侵害サイトとは捉えず、協業していくことにする」というお話。

目新しいのは次の点。

ただし、ユーザー投稿による動画を無制限に公開中止にするのではなく、角川グループ側で認証できる動画に関しては公開を認めたことを示す、同社ロゴ(鳳凰マーク)を視聴ページ右に表示していく。

おお、映像切り貼り形のMADを公認するのか?
と思ったら

一方で福田氏は、オリジナル映像に対して手を加わった投稿動画に関しては、「著作権者同士が了解して作成した映像などを除けば、他者が勝手に手を加えるのは失礼なこと」と発言し、MAD動画に対しては否定的な考えを示した。

言葉通りに捉えると、映像に字幕を加えるファンサブも否定している感じ。
MADもファンサブもダメ。
じゃあ一体どんな動画なら良いのか。

ただし、角川関係者に聞いた範囲では、投稿キャンペーンなどで用意した素材を自由に使ってもらうケースも考えているという。

こういうのだけだと普通すぎて、あまり盛り上がらなそう。
版権が入り交じっているものも角川側でネゴって公認する――なんて仕組みだったら楽しそうなんだけど。

あと、気になるのはVideo IDで引っかからなそうな、映像自作の構成模倣動画の扱い。
こういうのとか。

同人誌同様、二次創作物としてスルーするのだろうか。

ユーザ空間アドレスとlong型

タグ: C++

Win32における1プロセスあたりのユーザ空間は、通常2GB
数字で表すと 0x00000000 ? 0x7fffffff となり、long型でも常に整数として扱える。
ところがLinuxの1プロセスに割り当てられるユーザ空間は 0x00000000 ? 0xbfffffff3GB
long型に格納すると0x80000000以上が負数となってしまう(かもしれない。正確には処理系依存)。

Win32でしか動作させる予定がないのであれば、long型でもおそらく問題ない(4GB RAMチューニングというのが少々気になるが……)。
だが、コードというものは往々にして制作時の意図を越えて流用されるものである。
例え「今の環境なら大丈夫」であっても、将来他の環境に移す必要が生じたとき無駄に悩まないようにするため、素直にsize_t型にするか、環境依存のコードであることを明記しておくべきである。

……しておいてください、ほんと(´Д⊂

MALLOC_CHECK_

タグ: C++ gcc

gccでコンパイルしたプログラムを実行していたら、 qsort の中の malloc でセグメンテーション違反が発生した。

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1275348048 (LWP 18592)]
0x006ca560 in malloc_consolidate () from /lib/tls/libc.so.6

どうもどこかで「二重解放」が行われている様な雰囲気なのだが……全て自分のコードならともかく、色んな人が色んな思想で組み立てたコードのため、当たりを付けるのが非常に困難。
ああ、何か簡単に二重解放している箇所を見つけるツールはないものか……と検索してみたらあっさり見つかった。

環境変数 MALLOC_CHECK_

これを

$ export MALLOC_CHECK_=2

として実行するだけで、二重解放が行われた瞬間、プログラムをAbortしてくれる。

Program received signal SIGABRT, Aborted.
[Switching to Thread -1283863632 (LWP 19201)]
0x00983eff in raise () from /lib/tls/libc.so.6

ツールどころか再コンパイルすら必要ない。
想像していたより遥かに楽な方法が用意されていた。

ニワンゴ代表取締役がギョーカイ時事放談に

偽・うpのギョーカイ時事放談SUPER!

2月7日・14日 第17・18回 ゲスト ニワンゴ 代表取締役 杉本 誠司さん

第4回放送において盗人猛々しいというか、恥も憶面もないとか平気なツラして「広告だしませんか?」なんて言える厚顔無恥。人間としての質を問いたいとまで評したニワンゴの代表を呼ぶそうで。
盗人に利用価値を見出したのか、それとも日和ったか。
いずれにしろ楽しみである。

ちなみに私は4回放送に関してはGIGAZINEの記事を読んだだけで、愚痴ばかりでつまらなそうと感じたから聴いてはいない。
言っていることは正論だし、腹を立てるのももっともだと思うけど、だからといって動画投稿サイトを潰したところでそう収入が増えるわけではないことは理解しているだろうに。
何より、DVD全巻持っている作品をコメント見るためにニコニコ動画で視聴して休日丸々つぶしたりしている身からすると、このサービスを「新しい金儲けの方法を模索するに足る場所として考えてみよう」とすらしていないことが悲しい。

アニメが売れなくなってきているという。
確かに私もあまり買わなくなってきている。
なぜって?
簡単なこと。
棚の空きがない

いやでもこれは切実な問題で、DVDが物質である以上、いずれは空間的な収容限界にぶち当たる。
そうなってしまえばもはや新しいDVDを買うことはできないわけで、DVDを買ってもらうことで成り立つこの収支モデルは破綻してしまう。
いやまあ、実際には売ったり捨てたりでなんとかやりくりするのだけど、しかしこの「空間的制約」が僅かなりとも購入意欲に影響を及ぼしてくるのは間違いない。
だからこそ私は、顧客の空間を侵害することなくお金を払って貰える収支モデルをインターネット上に作り上げ、DVDなどという旧世代のメディア(邪魔で不便で画質はTV放送に劣る)に頼った生き方を変えてくれることを期待しているのである。

「DVD買ってくれなきゃ困る」とか言われても、「DVDというメディアそのもの」に魅力を感じないから、金を払おうにも払い難くて正直困るんだよね。

bjamの引数メモ

タグ: C++ gcc Boost
  • GCC 3.2.3
  • Boost 1.34.1
  • bjam 3.1.16

で Boost.Thread と Boost.Filesystem の静的ライブラリをビルドしたときの引数メモ。

bjam runtime-link=static threading=multi --with-thread --with-filesystem stage
runtime-link を設定しないと動的ライブラリが作成される。
threading を設定しない場合、シングルスレッド用とマルチスレッド用の両方のライブラリ( Boost.Thread 等マルチスレッド前提ライブラリは除く)が作成される。

本日見かけた酷いコード5

タグ: 酷いコード
// hoge.h

class hoge
{
public:
	/**
	 * デフォルトコンストラクタ
	 */
	hoge(); ///< デフォルトコンストラクタ
};
// hoge.cpp

/**
 * コンストラクタ
 */
hoge::hoge()
{
}

いやそんな念入りにデフォルトコンストラクタを主張しなくても……
コメント付けた人、なんか意地になってないか?

01月20日のココロ日記(BlogPet)

恋ってなんですか?ない感傷を見てドキドキする気持ちと似てますか?

*このエントリは、ブログペットのココロが書いてます♪

Spotlightのファイル名変更バグ

タグ: Mac Leopard Spotlight

うちのLeopard(Mac OS X 10.5.1)だけの現象か分からないが、「Spotlightのウィンドウでファイル名が意図せず変更されてしまう不具合」を見つけたので、とりあえず再現手順をメモしておく。

まず、以下の構成でファイルを配置する。

フォルダ構成

次に、「baz.txt」「bar.txt」「foo.txt」の順にファイルを開き、「bar.txt」以外を閉じる。
これで、Spotlightでこれらのファイルを検索したとき、「bar.txt」が真ん中に来るようになる。

Spotlightウィンドウ

そしたら、今度はSpotlightウィンドウの「bar.txt」をダブルクリックし、テキストエディタがアクティブなのにFinderはファイル名称変更待ちという状態にする(おそらくこれがバグ)。

非アクティブなのにファイル名の変更

最後に「bar.txt」を保存し、Spotlightウィンドウをアクティブにする。

「bar.txt」は「foo.txt」よりも後に開かれた(保存された)ので、両者の並び順は入れ替わる。
そしてこのとき、どうやらファイル名の変更が確定されるらしく、「foo.txt」のファイル名が「bar.txt」にこっそり変更されてしまう。

保存後のSpotlightウィンドウ

当然、普通にフォルダ階層で見てもこの通り、名前が変わっている。

保存後のフォルダ構成

両ファイルが同じフォルダに存在している場合、同名ファイルが存在する旨を伝える警告が出るので、実際にファイル名が変更されることはない。
しかし今回のように別のフォルダに存在していた場合、「あれSpotlightの表示がバグってる……と思っていたら本当にファイル名が変わっていたことに後で気付いてショックを受ける」なんてことになるだろう。
ファイルが消えるわけではないのが救いだが、「間違ってコピーしたファイルだと勘違いして自分の手で削除」したりしそうなのが怖いところ……

Spaces設定変更スクリプト

タグ: Mac Leopard Spaces AppleScript

システム環境設定を開くことなく、アプリケーションの操作スペース割り当てを手早く切り替える方法を模索していたところ、 MacScripter で面白そうなものを見つけた。

http://bbs.applescript.net/viewtopic.php?id=23453

ここに上げられているスクリプトを実行すると、こんなダイアログが表示される。

操作スペース選択ダイアログ

「All」をAssignすると、最前面のアプリケーション(この画像の場合はスクリプトエディタ)は「すべての操作スペース」に割り当てられる。
各数字「n」を選んだ場合、アプリケーションは「操作スペース n」に割り当てられる。
そして「None」は、おそらく操作スペースの割り当てを解除するためのものだと思うが、私の環境では選択しても特に何も起こらなかった。
スペースの割り当てに成功した場合、画面はF8キーを押した状態(すべての操作スペースを表示した状態)に遷移する。

以上、そのまま実行したときの挙動はこれで全てだが、他にもSpacesに対する操作はあらかた記述されているので、SpacesをAppleScriptから操りたいと考えたときには参考になるだろう。

さて、機能的には申し分ないが、私としては「None」と「All」が欲しかったので、「None」が動作しない現状には些か不満が残る。
何故動作しないのか、イベントログを確認してみると、文字列系の問題であることを臭わせるエラーが発生していた。

run script "{safari|:1, |com.apple.scripteditor2|:1} のタイ}" (*choose_space_for_application (com.apple.scripteditor2) Error (-2741): “,” または “}” があるべきところですが "|" が見つかりました。*)

そしてエラー箇所の近くにはこのようなログが残っている。

{|com.apple.safari:1, |com.apple.scripteditor2:1}

で、分かったのだが、このスクリプトは

get application bindings of spaces preferences of expose preferences

の結果を文字列化するために、一度わざと文字列化を失敗させ、そのエラー文字列から必要な部分だけを抜き出すという手法をとっている。
しかしそのエラー文字列は環境によってフォーマットが異なるため、日本語環境では「のタイ」などというおかしな抜き出し方をすることになってしまったのだ。
というわけで、日本語のエラーメッセージ

{|com.apple.safari:1, |com.apple.scripteditor2:1} のタイプを string に変換できません。

に合わせて文字列抜き出し箇所を修正する。
これは二箇所ある。


- set app_bindings to my string_to_list(text 13 thru -20 of error_string, ", ")
+ set app_bindings to my string_to_list(text 1 thru -24 of error_string, ", ")

でまあ、これだけで良さそうなものだが、なぜかもう一箇所別の修正が必要なので、そこも書き換える。


- my set_spaces_application_bindings(run script "{" & (my list_to_string(new_bindings, ", ")) & "}")
+ my set_spaces_application_bindings(run script my list_to_string(new_bindings, ", "))

これでめでたく日本語環境でも「None」が動作するようになった。
あとは自分が使いやすいように加工して、スクリプトメニューにでも置いておこう。

スクリプトメニュー

Boost 1.34.x の binary_wiarchive 不具合

タグ: C++ Boost
#include <fstream>
#include <boost/archive/binary_woarchive.hpp>	
#include <boost/archive/binary_wiarchive.hpp>	

class Hoge
{
	friend class boost::serialization::access;

	int n;

	template <typename Archive>
	void serialize(Archive& ar, const unsigned int ver)
	{
		ar & n;
	}
};

void write()
{
	Hoge hoge;
	std::wofstream ofs("hoge.txt", std::ios::binary);
	boost::archive::binary_woarchive oa(ofs);
	oa << const_cast<const Hoge&>(hoge);
}

void load()
{
	Hoge hoge;
	std::wifstream ifs("hoge.txt", std::ios::binary);
	boost::archive::binary_wiarchive ia(ifs); // 例外発生
	ia >> hoge;
}

int main(int argc, char** argv)
{
	write();
	load();
	return 0;
}

このコード、 Boost 1.33.1 では問題なく動作するが、 Boost 1.34 ではコメントの個所で例外が発生する。
何がいけないのかと調べてみると

Boost mailing page: [boost] [serialization] typo in basic_binary_iprimitive::load_binary

typo……('A`)
しかも1.34RCで発覚しているのに、1.34系のブランチでは修正されていない('A`)

所詮、 wchar_t の扱いなんてこんなものか……

はじめに権利者ありき

権利者団体が「Culture First」宣言、文化保護で補償金の拡大求める - INTERNET Watch

興味があるので読んでは見たのだが……うーん、個々の主張に論拠が乏しく(記事化されていないだけかもしれないが)、ただ新しいコンセプトを立てて「こちら文化様です有り難いんです補償金くれよ」と言っているだけにしかみえない。

「文化の視点で補償金制度の見直しを考えてもらいたい」と語るのは、日本音楽著作権協会(JASRAC)常務理事の菅原瑞夫氏。「権利者は文化の担い手だが、文化を享受する国民は、単に文化を消費するだけでなく、文化の後援者であるべき。そこには、経済的なスポンサーシップも必要になる」。

補償金というものが特定の団体に加盟する権利者に分配されるものであることを考えると、この主張は、そこに加盟する者こそが「文化の担い手」であり、それ以外は皆「文化の消費者」である、と言っているように思える。
つまり「権利者団体に加盟せざる者は文化の担い手たる資格を持たない」ということだ。

まあそれは曲解としても、国民を単なる「経済的消費者」に落とし込んでしまうのは文化的に考えたら損失なのではないかね。
真に文化的な国を目指すのであれば、国民全員が文化の「消費者」であり「発信者」であることを望むべきだろう。
「はじめに文化ありき」と謳っているけれど、実際に言っていることはまるっきり「はじめに経済ありき」の論理だよねぇ。

新作アニメ第一印象 2008/1/14放送開始分

ヤッターマン

第1話 ヤッターマン 誕生だコロン!

お約束コント型アニメ。
よく考えてみると、旧作は「懐かしのアニメ特集」のような番組でしか見たことがない。
そんなわけで「ぽちっとな」や「ブタもおだてりゃ?」などの代表的シーンよりも、その前のどうでもよさそうな「ヤッターマンの日常」が新鮮で面白かった。

物語の展開は流石に「時代が違う」と感じる。
しかし時代に沿ったものはそれはそれでどれも似たり寄ったりな感じがするので、敢えて今、こういう作品を置いておくのもいいんじゃないかな。

ココロの料理初成功

昨日、ココロさんが初めて料理を成功させた。

cocolo_suki.png

そして今日のココロ日記。

ココロ、海に行きたいです!むいさん、つれてってください?

昨日の料理はおねだりのためか!

……まあ、冬の海のうら寂しい感じは好きだけどね。

01月13日のココロ日記(BlogPet)

ココロ、海に行きたいです!むいさん、つれてってください?

*このエントリは、ブログペットのココロが書いてます♪

AmazonおまかせリンクとGoogle Adsence

サイトの賑やかしと実益を兼ね、コンテンツ連動広告を2つ設置してみた。

1つはAmazonおまかせリンク(R)
Amazonはよく利用するので、見事私の琴線に触れるものを上げてくれたら喜んで買いに行くのだが、果たしてどうか。

設置して最初の頃は、リロードする度に表示される商品がころころ変わっていた。
全く見当外れのものが表示されることもあったが、興味を持てるものも多かった。
だがしばらくすると、表示される商品はページごとに1つのもの(例えばこの記事を書いている時点のトップページであれば『ef』)に固定されてしまった。
これにはちょっとがっかり。
もうちょっと揺らいでくれた方が、設置したこちらも楽しいし、欲しいものに巡り会える機会も増えると思うのだけれど。

でもまあ、新しく書いた記事にどんな商品が割り振られるかというのは、割と楽しみな要素ではある。
この記事とか『サラダレシピ』だし。
何故。

もう1つは Goolge Adsence
こちらはよく見かけるので馴染み深い。
馴染み深すぎて、貼られていないと逆に何か寂しく思えてしまうほどだ。

そんなコンテンツ連動広告の定番である Adsence だが、実際のところ余所のページで「面白い」「クリックしたい」と思う広告を表示しているところを見たことがない。
それでも、自分のページなら自分向けの広告が出てくるのではないかと期待して貼ってみたのだが……うーん。やはり代わり映えのしないものばかり出てくる。
まあ、例え面白そうな広告が出てきても、「自分で自分のページの広告をクリックしてはならない」というルールがあるから、「自分向け」には全くもって使えないわけだが。
やっぱりこれは完全に対外向けの広告ツールと考えるしかないのかな。

SyntaxHighlighter

現在このBlogで使っている「cool_black」テンプレートで <pre><code> を使うと、下と右に必ずスクロールバー用の白いスペースが発生する。

白枠

前々からこれが気になっていたのと、またそれとは別に、コードに色付けしたいという気持ちあったので、各種サイトを参考にしながらSyntaxHighlighterを導入してみることにした。

まず必要なファイルをBlogにアップロード。
今のところはC++とHTMLにさえ対応できればよいので、上げたのは以下の5つ。

  • SyntaxHighlighter.css ※サイトの雰囲気に合わせて多少変更有り
  • clipboard.swf
  • shCore.js
  • shBrushCpp.js
  • shBrushXml.js

次に、HTMLテンプレートの後ろの方に以下のコードを追加する(ファイル名を記述している部分は実際は絶対パス)。

これは「記事部分のすぐ後ろ」に記述するとレンダリングが早くて良い、気がする。

あとは、普段C++のコードを記述するときに

<pre><code>
	:
</code></pre>

としていた部分を

<pre name="code" class="C++">
	:
</pre>

とすればOK。

試しに過去の記事を色付けしてみたが、なかなか良い感じにレンダリングされている。
(自動改行しているのにスクロールバー付きなのが謎だが)

またこのスクリプトでは、オプションによってレンダリングする項目を調整できる。
例えばこの記事の場合、一番上のコードは「記号の実体参照化が面倒」だったので

<textarea name="code" class="html">
	:
</textarea>

と記述し、それ以外は「行番号とか邪魔」だったので

<pre name="code" class="html:nocontrols:nogutter">
	:
</pre>

と記述している。
この辺りの自由度も魅力の1つである。

というわけで。
ようやくこのBlogも <pre> の白枠から解放されることになった。
めでたしめでたし。

と、感慨深く過去の記事を記事を読み返してみたら、なぜか全ての <pre> から白枠が消えていた。あ、あれぇ?
個別に overflow:hidden; を設定しているものもあるけれど、それ以外は overflow:auto; のままだから枠は消えないはずなのだが……
あれぇ?

新作アニメ第一印象 2008/1/11放送開始分

のらみみ

第1話 居候の世界/うたうコトリ

居候キャラパロディほのぼのアニメ。
昔懐かしい子供時代の思い出深いアニメをごった煮的にパロっており、「アニメ版三丁目の夕日」とでも言うべきノスタルジックな感傷を呼び起こしてくれる。
かなり好みな作品。

上書きしない上書きアップロード

昨年アップロードしたXLSファイルをファイル管理で「上書き保存」したところ、ファイルのURLが

http://blog-imgs-16.fc2.com/i/d/l/idlysphere/ファイル名

から

http://blog-imgs-23.fc2.com/i/d/l/idlysphere/ファイル名

に変化した。
当然、以前のURLでアクセスすることはできないので、そのファイルを参照している過去記事はリンク切れ状態に。

似たような現象はユーザーフォーラムにも上げられていて、2007/12/1にFC2スタッフが以下のように回答している。

画像サーバが一杯になったので保存先サーバが切り替わったために起きた現象との事です。
最後に保存したサーバ番号はデータベースに記録されていますので、上書きはそのサーバに行うように変更致します。
完了しましたらこちらで報告致します。

そして「完了しました」というレスはないので、この現象は依然として続いているのだろう。

うーん、しかし迷惑な挙動だ。
ファイル名が同じでも、URLが変わってしまっては削除されたも同じこと。
せめて「上書き保存できません」といって拒否してくれたら良いのだが。

新作アニメ第一印象 2008/1/10放送開始分

墓場鬼太郎

第一話

とりあえず左上邪魔。

和紙フィルター(とでも言うのかな)の効果もあって、絵はかなり綺麗。
『まんが日本昔ばなし』のような懐かしさを感じる。
この作品は「人外から観た人」と「人外そのもの」のどちらを主体に描いていくのだろう。

新作アニメ第一印象 2008/1/9放送開始分

狼と香辛料

第一幕 狼と一張羅

旅商人と地方神格狼娘の旅情物語。
主人公の声が何か浮いている感じ。
旅物語のようだから、次回以降の世界演出に期待。

新作アニメ第一印象 2008/1/7放送開始分

ARIA The ORIGINATION

第1話 その やがて訪れる春の風に…

いつも通りのゆったり非日常的日常物語。


GUNSLINGER GIRL -IL TEATRINO-

第1話 二人の距離 兄弟

お兄様べったりアニメ。
前期の鬱々とした作風から一転して「ふつー」な感じ……というか安っぽくなった。
制作会社はもとより声優も総入れ替えな上、前期の演技を踏襲する気がまるでないため、その違和感は『みなみけ おかわり』の比ではない。
まあ、今期だけで考えれば声と絵柄はマッチしているので、前期とは完全に別の作品であると捉えた方が良いだろう。

privateな仮想関数

タグ: C++

仮想関数のアクセス制限をprivateにしてはならない。
そうすればprivateに関して知るべきはそのクラス自身のみとなり、基底クラスについて派生クラスが気に病まなければならない部分から完全に抜き去ることができるのだから――

というようなことをどこかで読み、「なるほど一理ある」と今までそれに従って過ごしてきたのだが、どうもgoogleの検索結果を見回した限りではこの考えは劣勢らしい。

たしかにNVIイディオム(名前付いてたのかこの手法)を使うときに純粋仮想関数をprotectedにするのは何か中途半端な感じはしていた。
派生クラスで実装するとはいえ、派生クラスからその関数に直接アクセスすることはないのだから。

C++の規格では、メンバアクセス制御で制御されるのは、メンバ及び基底クラスへのアクセスであって、可視性ではない。としている。
その点から考えても、純粋仮想関数をprivateにするのは妥当と言える。

今まで仮想関数をprivateに置きたくないと思ってきたことについては、Doxygenがデフォルトの設定ではprivateメンバをドキュメント化しないからということもある。
もっとも、デフォルトの設定では広域関数すらドキュメント化されないので、可視性云々とはまた話が違ってくるのだが。

新作アニメ第一印象 2008/1/6放送開始分

AYAKASHI

第一話 はじまりの血

超能力バトルアニメ。
ライトなPERSONA?
何かいろいろとどこかで見たような気がする作品。

みなみけ おかわり

第1話 温泉、いただきます

日々是漫才アニメ。
前期は第1話だけ視聴。
何か記憶にあるものと比べて「ふつー」になった印象。

ココロの投稿カテゴリ

さっそくココロさんが投稿してくれた
いたずらっ子そうで良し。

投稿時、この日記のカテゴリは「未分類」だった。
デフォルトの投稿カテゴリはココロ用のものにしていたのだが、ここを考慮しているわけではないらしい。
一番上のカテゴリ固定なのかな?
……とかいっていたら、日によってはちゃんとココロカテゴリに入れてくれた。
よくわからないなー。

あと、ココロ日記は「自動改行」前提だが、投稿設定で「HTMLタグ以外は無視」することにしていても、投稿時に「改行の扱い」を「自動改行」にしてくれるので問題ない。

01月06日のココロ日記(BlogPet)

むいさんの困る顔が見たいですっ

*このエントリは、ブログペットのココロが書いてます♪

新作アニメ第一印象 2008/1/5放送開始分

……多すぎだよ今日は。

PERSONA - trinity soul -

第1話「特A潜在」

サイコミステリー、というのかな。
超能力バトル付きの。
特徴的な要素はこれといって、シュール(バケツとかひまわりとか)なエンディングくらいしか見当たらない。
淡々と見るのに向いている。

久しぶりに『全ての人の魂の詩』を聴けた(ちょこっとだけど)のが嬉しい。

俗・さよなら絶望先生

第一話

前期同様、独特の演出と予想の付かない展開が特徴的なアニメ。
意図しているのかいなのか、CMまでもが演出に手を貸している。

true tears

第1話「私…涙、あげちゃったから」

学園恋愛アニメ。
一部登場人物を見分けにくい。
遠くから映した人物を積極的に3DCGで動かすという、あまり見ない手法を使っている。
でも、正直不気味。
オープニングの出来は良い。
「ながら聴き」に良さげ。

破天荒遊戯

第1話 永遠のともしび

異世界逆ハーレムの旅。
面倒なこと(旅の連れを集める仮定とか)は全て都合良くスルーする世界。
とにかく展開が早く、ラノベ一巻分の内容を30分にまとめたような、あるいは読み切り作品のような一話だった。
こういう演出方針なのか、あるいは本格的に演出したい場面ではないから必要最低限の映像化で済ましているのかは量りかねる。

君が主で執事が俺で

第1話 君が主で執事が俺で

執事系ギャグパロアニメ。
初っぱなからハヤテGガンパロに新スネオ+旧ジャイアンと、作品の方向性を明示してくれる。
紛う事なき、ニコニコ動画向きのハイテンションネタアニメ。

シゴフミ

第1話 コクハク

天使的存在が人に介入する系統の作品。
同系統の『しにがみのバラッド』と対比すると、イメージカラーが「白」に対し「黒」、使い魔が「猫」に対し「杖」、介入のタイミングが死の「前」に対し「先」。
そして物語展開が「ハートフル」に対し……えーとなんだろこれ、ちょっと予想外。
てっきりこれも、一話完結のハートフルなものだとばかり思っていたのが。

しかし巧妙な引きだ。
一体誰が手がけたのかとスタッフ見れば、今話の脚本は大河内一楼だそうで。
あー『プラネテス』。さもありなん。

numeric_limits<int>::min()

タグ: C++

numeric_limits の静的関数 min() が返す値は、整数型版と浮動小数点型版で意味が異なっている。

std::cout << std::numeric_limits<int>::min() << std::endl;
std::cout << std::numeric_limits<double>::min() << std::endl;

このコードの実行結果は以下の通り。

-2147483648
2.22507e-308

整数型版の min() は「最小有限値」(その型で表現可能な最小の値)を返す。
それに対し、浮動小数点型版の min() は「正規化された最小の正値」(その型で表現可能な最小の正の値)を返す。

これは正直、酷い仕様だと思う。
例え違うクラス同士であっても「直感的に同じ意味を持つ結果が返ることを期待してしまう同名関数は避けるべき」であろうに、ほぼ同じクラス同士でこれは紛らわしいことこの上ない。
おそらくC言語の INT_MINDBL_MIN の関係をそのまま引き継いでいるのだろうが……
ここに関してはCのそれらとは別物と考えて、C++から入った人に優しい仕様(整数型でも浮動小数型でも「最小有限値」を返す仕様)にしてほしかった。

継承したクラスのメンバ変数はどこに配置されるか

タグ: C++
struct Base
{
	char a;
	int b;
};

struct Derived : Base
{
	int c;
};

このような構造体Derivedがあったとき、基底クラスBaseのメンバ変数abDerivedのメンバ変数cの記憶域の「前」にくる(a、b、c)か「後ろ」にくる(c、a、b)か。

↑のケースだけ考えると、DerivedからBaseに型変換したときでも先頭アドレスをそのまま使える分「前」の方が良さげに思えるが

基底クラスの部分オブジェクトが最派生オブジェクトの中で割り当てられる順序は,規定しない。

『JISX3014:2003』では「規定されていない」

多重継承や仮想クラスの存在を考えると、C++でこれを規定するのは面倒だし、そもそも無駄なことなのだろう。

Appendix

タグ

Blog内検索

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。