!C言語知らない奴ってプログラマじゃなくね？ - 神様なんて信じない僕らのために
そういえばC言語を知らない人に 「C言語って文字列型がないんだよ」 と言ったら驚いていた。 確かにC言語は配列は自身の長さを知らないし、 文字列も自分の長さを知らない。 正規表現だって標準ではない。 僕はこれが当たり前と思うけれども、 そうでない言語から入った人は文字列型があるのが普通で 配列だって長さがわかるのは当たり前で、 正規表現だって使いたいし……、 「なんでそんな不便なの？」って思うだろう。 nativeなCはそれ自体が豊富なライブラリや機能を持つわけではないので 「新ANSI C言語辞典」を片手に何か作ろうとしても限度がある。 初心者がnativeなCで役に立つツールを作ろうとすることに既に無理がある。*1 まだプログラマに成り立てな人に簡単なGUIツールをつくって貰おうとしたとき、 「nativeCでつくって」とは口が裂けても言わないだろう。 実際C言語でやりたいことなんてい
すべての漢字を取り出す正規表現 - 神様なんて信じない僕らのために
totonの日記さんに詳しいようです。 すべての漢字を取り出す正規表現 - totonの日記 「すべての漢字を取り出す正規表現」の続き - totonの日記 とはいえぐぐっただけです。 既に2005年に通過されていた模様。 mpt = [re.compile(u'[一-龠]')] def main(): target = u'漢字正規表現亜腕一十百千万億兆京' for mp in mpt: print "pattern = %s, target = %s" % ( mp.pattern.encode('utf-8'), target.encode('utf-8')) ml = mp.findall(target) for m in ml: print '%s' % (m).encode('utf-8'), print pass pattern = [一-龠], target = 漢字正規表
思いこみでBlogを書いてはいけないか？ - 神様なんて信じない僕らのために
きっと余計なお世話なんでしょうけれど、思ったことだけつらつらと。 Blogを好き勝手書いているとどうしても意図せずに嘘情報や誤認されやすい情報が混ざってしまうことがあります。 要するに単に調査不足や書き方に問題があったり、 書き手の周囲や経験では正しいとされているからだったりします。 で、実際これは、 思いこみかどうかを自身が判断できないからこそ思いこみであり、 要するに書き手は「正しい」ないしは「正しいだろう」という気持ちで書いている筈なんですよね、きっと。 誤認されやすい場合には「読み手にはこう受け取ってもらえるだろう」という楽観的な観測もあると思います。 所詮は個人のBlogでは 何を書こうとも書き手の自由であり、 それをどう受け止める、 汲み取るかは読み手にも常に依存している訳で。 極論を言ってしまえば「正しい事が書いてあってすら正しく伝わるかどうかは不確定」だと思います。 文脈を
コードとの対話 - 神様なんて信じない僕らのために
某開発のMLで ぶっちゃけて言ってしまうと、 コピペ臭が漂うコードは見ただけで気分が悪くなるということです。 もちろん、必要があってコピペしているとか、 ここは本来そうすべきだが手間をかけたくないのでといった表明があればOKです。 危惧するのは、当人がそれが正しいコーディングだ、と思ってしまっていないか否か、ですので。 共感した。 まぁ、僕自身もへたれコード書きでバグを埋め込むわ、 冗長なコードを入れ込むわ、コピペすることもあるのですが、 意味がわからNEー！ というコードに出会うとやっぱりイラッと来ます。 なんでコードを散らかすかな！ なんで色んな場所で同じことしてんだYO！ とか叫びたくなることもあります。 コードとは理想的に言えば対話可能であらねばならず、 言い過ぎかもしれないですが、 開発しているコードと対話するために人とのコミュニケーションがある、 のかもしれないなと思うところが
オブジェクト指向とはなにか、カプセル化とはなにか - 神様なんて信じない僕らのために
Exceptional C++ Styleの記述に非常に感銘を受けたので引用しておきます。 オブジェクト指向におけるカプセル化の位置づけ オブジェクト指向による設計とプログラミングにおいて、それはどれくらい重要か？ カプセル化は、オブジェクト指向プログラミングの最重要概念である。以上。 ・カプセル化はほとんど常にデータ隠蔽を意味する。 ・仮想関数における実行時ポリモルフィズムは、基本クラスによって提供されるインターフェースを、（コードが書かれた時点では存在する必要さえない）派生クラスによって提供される実装から完全に分離する。 ・テンプレートによるコンパイル時ポリモルフィズムは、インターフェースを実装から完全に分離する。必要な操作を持つクラスは、継承やその他の関係がなくても自由に交換して利用できる。 カプセル化が常にデータ隠蔽を意味するわけではないが、データ隠蔽は常にカプセル化の一種である。
カプセル化と情報の隠蔽が別物で、カプセル化＝クラスそのもの？ - 神様なんて信じない僕らのために
まとめること＝カプセル化 隠すこと＝情報隠蔽 カプセル化ってのは、フィールドとメソッドを一緒に定義する、ぶっちゃけクラスそのものの機能ですね。 2007-03-09 - 人類みんなごくつぶし カプセル化＝クラスそのものだなんてあり得ないと思います。（それは流石にぶっちゃけすぎかと） カプセル化は「オープン・クローズドの原則」（モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない）を守るために「も」必要で、これを守るために用いられる一つの方法が「情報隠蔽」である筈です。 機能を拡張する際には内部や外部のコードの追加に対応でき、仕様変更に耐えられるようになっていなければならず、 機能を修正する際には内部でいかに異なった振る舞いをしようともカプセル化されている以上、外部には影響を与えず修正されなければならない。 これらが外部に（内部にも）対して何
拡張 for 構文ってあんまり好かれてないのかな - 神様なんて信じない僕らのために
今は仕事でJ2SE5.0を使っていることもあって、for文は拡張forで書いているんですが、あんまり拡張forを使っている人みないですね。 Hoge[] hoges = hogeDao.selectByFooId(fooId); for( Hoge hoge : hoges ) { hoge.xxxx(); } とか書けてとても便利なのですが。 後方互換性の観念とすると「ソースを再利用する気ならば」J2SE5.0より前のバージョンで動かないソースになるわけで、デメリットにはなるけれど、 そもそもこのシステムはJ2SE5.0前提な訳でソースの再利用とかは放置でかまわない気がする訳だし。 って、考えてよくみたらGenericsは各所で使ってた。 となるとこれは単に好みの問題かしらん。認知度の問題かしらん。 ここはいっそ、Python的にJavaも従来のfor(;;)は廃止で、拡張forだけにし
re:比較関数 - 神様なんて信じない僕らのために
これは……うえええ、と思ったので思わずトラックバックを。（＋引用記法を試したいという邪念） odz bufferさんの比較関数について ええと、普通にこんな比較関数は大変にまずいと思うのだが、誰からも指摘されないものか？有名なあの猫のページもこんなのだったし。大丈夫かおい？ http://d.hatena.ne.jp/odz/20070212/1171345311 例えば、こういう配列のソート。（OSXのgcc4.0.1で確認） int compare_int(const int* a, const int* b) { return *a - *b; } ... int data[] = { 2140000000, -2100000001, 2100000002, -2100000003, -2100000004, 2100000005, 2100000006, 2100000007, -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
邪推は推測の一部分でしかない、と思うが - 神様なんて信じない僕らのために
職人はテストと保守のための設計を心がけている - 神様なんて信じない僕らのために