そろそろ枯れて来た感のあるC++

ふと思うのは、関数アダプタって本当に使っている人いるのだろうか？

いや、いるといえば、いるのだろうが・・・普通にforで回して｛｝の間に書いちゃダメなのか？って処理まで関数アダプタで書かない方がいいだろうと。

構わないんだが、関数アダプタで書かれると、レビューする時にコードがforとちがう遠いところにあるので、検索するなりジャンプするなり一手間必要。

書いている本人にすれば便利なのかも知れないが、レビューする方としては迷惑きわまりない。

レビューする方は下手すれば100人、200人のコードを見なければいけないわけで・・・。そういう僅かな差が積もり積もって効率に影響してくる・・・ねぇ？

それが本当に必要なケースなら関数アダプタを使うのも悪くないだろうが、それ以外のケースでは可読性を落とすだけだと、思うわけで。

さて、そうなったときに、関数アダプタって本当に使っている人いるのだろうか？というのも、関数アダプタが必要なケースなんてあまりないだろうなぁと。

関数アダプタにするからには、関数化するぐらいに十分長いアルゴリズムであって、かつ、2つ以上の箇所で再利用されていて、かつそれが、別のタイプのコンテナである場合だ。

大抵の場合は、そんな長いアルゴリズムならば、関数アダプタ化ではなく、クラス化してコンテナごと隠蔽した方が楽だろう。

そう考えると、関数アダプタって本当にレアケースだなぁと思う。論理的には面白いが、工業製品としては使いにくいなぁと。

絵を１枚書くのに数日かかるっていっても・・・プログラマの人は信じてくれないだろうなぁ

いや、おれプログラマだけど、かかるんだよ・・・絵は

ましてや、その絵を高度に扱う、アニメーション付きのプログラムなんて、微妙な表現まで実装したらどんだけかかると思ってるんだろうと。でも、理解はされないだろうなぁ。

簡単だろ？ちょちょっとやってよって言われるんだろうなぁ。

ある意味、Flashは強い。とはいえ万能じゃないし・・・

fprintf(stderr,”Do you love me now?”);

gcc main.c
a.out 2＞/dev/null
(http://anond.hatelabo.jp/20100214000712)

STDERR.puts “I love you!”
ruby main.rb 2＞/dev/null
http://anond.hatelabo.jp/20100214003927

これまた切ないコードを書いたもんだ。
http://anond.hatelabo.jp/20100214001742

結構、良いソースコード、悪いソースコードを逆に思っている人が多い。

悪いソースコードとは、簡単に書けるのに、無里に難しく書いて、おれこんなに難しい書き方できるんだぜカッコいいみたいな自画自賛ソースコード。

よいソースコードとは、シンプルで難しくなく書いてあるベタなソースコード。それでいて、ちゃんとエラー処理やキャシュ処理などもれなくな書いてある。余計なこともしない。


ようするに、地味なソースコードの方がメンテナンスしやすく長持ちする。

どっちみち、機械的なコードの美しさでアセンブラに敵うものはない。それと比べればC/C++ましていわんや、ライトウェイトをや。

サービスを動かすためにプログラムを書くのであって、プログラムを書くためにサービスを作るのではない。
そう考えれば、プログラム自体は地味な作業なのである。その地味な作業に無里に華々しさ、かっこよさ、テクニックなどを求めるから、コードが自画自賛になる。

プログラムは主従で言えば、従である。主役であるサービスよりも目立つものではないし、競うものでもない。ただ、路傍の石のように。それが、本来あるべきコードの美しさか・・・

-pedantic

Gcc の言語拡張機能をすべて無効にする。
エラーComma at end of enum listsなどが出るようにもなる。
これは、一般的には列挙子の一番最後が,で終わっているのを普通は許容するが許与しなくするなど、基準を厳しくする場合につける。

–ansi

厳格な ANSI 仕様でコンパイルする。このとき、 __STRICT_ANSI__ マクロが定義される。

–traditional

従来の C 仕様でコンパイルする。

この２つも同様。古い形式でコンパイルする。

-std=c99

その逆、C99という新しい仕様に基づいてコンパイルする。

(続きを読む…)

人生を書き換える者すらいた。: 人材獲得作戦・４　試験問題ほか

プログラムの問題が出ていた。

迷路問題らしい。
しかも、経路がなくて、太い通路だけ＝内側に壁が無い迷路もとけること。つまり１０ｘ１０のマスなら、壁以外ないので、直進して曲がって直進と言うルートもとけること。

らしい。

頭の良いGoogle大先生的には、最短経路 アルゴリズム – Google 検索ダイクストラ法とか、A*法とか、あるらしいですが、

そんなの、入力された地図を、経路データーに落とすのがめんどくさいですし
太い通路の場合、分岐が多くなりすぎて、めんどくさい。
ついでに、見ていて楽しくないで

力技に任せて、総当たりで全部歩けば、ゴールに着くよ！ｗ
で、たどり着いたルートのうち、もっともはやかったものが、最短ルートだよ。

的な、バカの発想をもとに、非常にシンプルにときました。

作業時間はデバッグ含め９０分でした。Linux環境がちょうど無いのが痛かったです。VisualStudio使いにくい。

では、コードなどははてなでどうぞ。
配列だけで説いているので、僕みたいなバカにもわかりやすい！？

じゃぁ、みんな、やってみて！

http://d.hatena.ne.jp/kokorohamoe/20100112

こんなオバカプログラマーでもできましたー。

※元ネタは、高学歴超優秀というネタから始まっていたので、FランにはFランの解き方があるということでｗｗｗｗ

バカはバカなりに一歩一歩あるいていくのさー
ログで、アルク様子が見えるのでオススメだぉー

いっちにちっぽー、みいかでさんぽー、さーんぽあるいて、１８０度たーん。

じーんせいは、わんつーまーち、べそかき、べそかき、あるこうよー　OpenCL勉強したいなぁ

銀行の暗証番号は４桁で平文で保存しているのに、ネットはダメなんですか？

こういう疑問を持つ人と、銀行系の天下りの人が、普通のネット企業で、平文で保存しちゃいそうなので一言。

まず、銀行系は鬼のような隠しカメラがATMおよび、その近隣に仕掛けられていて、悪いことをした人を突き止められるようになっています。
Web系のシステムには、そういった、物理的防御がありません。

他にも例を上げればキリがありませんが、基本的に銀行の暗証番号は、キャッシュカードという物理的な媒体との並行運用で守られている。という事も忘れてはいけません。

要するに暗証番号以外が強固なセキュリティになっていれば、暗証番号は４桁でも大丈夫というのは、良くは無いしにろ、悪い議論ではありません。

ただ、高々IDとパスワードだけのシステムが、数字４桁の平文保存などを行うのは、セキュリティーリスクから勧められたものではありませんし、そもそも、平文保存が勧められません。
あなたのところは、監視カメラまで仕掛けて内部犯・外部犯の犯行を防いでいると言うのでしょうか？と

Pangoとは

まぁ、フォントのレンダリングライブラリですね。
フォントのレンダリングエンジンであるFreeType単体だと、フォントの管理やサーフェイスへのレンダリング・レイアウトまでは面倒見てくれないのですが

Pangoだとfontconfigを呼んで、フォントを管理しPango自信のレイアウトエンジンにより、フォントを適切にレイアウトしてくれ（フォントの向きや回転など）たうえに、最終的にはcairoなどのサーフェスイス管理レンダラに向かってレンダリングしてくれるという優れもの。

うん、綺麗なフォントレンダリングよこんにち・・・

うん、実は会社なんだ・・・なんか・・・人生ってつらいね。
なんか、いろんなフリーのソースコードみられるのは楽しいけど、フリーソースのデバッグまでしないといけないのは、つらいわね・・・明日はケーキ　半額の日！　がむばる。

プログラムの試験で加速試験ってあるのをご存じですか？

たとえば、ユーザーからのアクセスが１０秒に１回で設計するプログラムがあった場合に
１秒間に１００回ぐらいの厳しい条件で動かして、試験を行うもの。

こうすることによって、不具合が出やすくなる。
こういう不具合には２種類あって
１つは単純に負荷が高すぎで動けなかったもの。
こういう場合は、本番では高負荷時にはエラーを返すなどのビジー処理を入れることで、品質を保つことができる。

もう１つは、単純に普段は出にくいが低確率で出るタイミング系のトラブルが出やすくなる。
１万回に１回しか出ないようなレアバグを、要求基準通り１０秒に１回で試験すると、デバッグで洗い出すのに、１０万秒＝１日かかってしまうが、１秒に１００回なら１００秒＝２分で見つけられる。要するにバグのあぶり出し

こうやって、普段よりも高い基準で試験することで、レアなバグを見つけ出して、直すことができる。これでも、レアなバグがなくなるわけじゃないけど、普通に１０秒に１回の利用では、基本的には出なくなる。

基本的な試験の技法です。