俺はこの本を楽しみにしていましたよ - 神様なんて信じない僕らのために
きじねこの高木さんの本です。 http://www.kijineko.co.jp/node/444 組込み現場の「C++」プログラミング 明日から使える徹底入門 作者: 高木信尚出版社/メーカー: 技術評論社発売日: 2009/03/23メディア: 単行本購入: 3人 クリック: 16回この商品を含むブログ (10件) を見る いやはや、これをどういったら良いのでしょう？ C/C++で組込をやっている人は必読であり、 そうでない人には全く用事がないという、そんな本です。 自分が特に良いなと思ったのは、 例外を有効にしている際に、組込環境にとってどのような影響があるかということ。これはでかい。 例外なんて切っちゃえ、と思っている自分ですが、 例外を適切に使えるなら例外は正義です。 しかし、大抵の人が使いこなせません。使いこなせないなら、使わないでおくのが正義というものです。 例外の他にも、C
C++はひどい言語だ - 神様なんて信じない僕らのために
STLは実装依存*1だし、 Boostだってうぎゃああああ、 RTTI？ exception？ そんなものまともに動くのかい？ boostをincludeしたらRTTIがdisableで怒られる！ exceptionがdisableで怒られる！ ああああああ、.textはもう一杯だ。 だって、templateで似たようなコードが型の違いで.textにたくさん落ちるから！ メモリだって空いてないよ。空いてないよ？ ヒープもスタックも一杯だ！ 多重継承？ だってInterfaceはないんだよ！！ 単一継承のC++なんて死んでしまえ。 virtual継承だってなんだってやってやろうじゃないか！ Observer？ Command？ State、Strategy、Factory、えとせとらえとせとら、 Cでまともにこれらを書ける人がどれだけいるんだろう。 型安全はどこいった、 ジェネリクス！ ジェ
Cだけプログラマの憂鬱 - 神様なんて信じない僕らのために
それ、C関係ないのでは - プログラミング言語を作る日記 それC関係ないよね、というのはきむら(K)さんや、id:minekoaさんにも言われたことですが、 実行時のチェックがない。よって、配列のオーバーラン、不正なキャスト、開放されたメモリを参照する、といった理由でのバグが発生し、原因追及が非常に困難。 GCがない。 それ、C関係ないのでは - プログラミング言語を作る日記 うーん、ここは少し観点が違うかなと思います。 C++でも、配列はオーバーランするし、Cスタイルキャストで苦しむし、 解放されたメモリを参照するなんてことは日常茶飯事に起こるわけで、 これらを解決する手段として、C++では、 可変長配列としてstd::vectorを利用する 固定長配列としてboost::arrayを利用する キャストはstatic_castだけを使う（reinterpret_castはCの構造体を読み
ソースを再利用するんじゃない、構造を再利用するんだ - 神様なんて信じない僕らのために
なんだかソースを書くお仕事をしていると、 ソースを再利用するんだ！ なんていう声が聞こえる。 ホントに？ 実績もないソースを再利用する？ ホントに？ いいよいいよ、しなくて良いよ。 再利用するのはソースじゃない、構造だ。 勿論、オープンソースのような多人数に対して開かれており、 テストされており、実行されており、実績のあるソースは再利用すべき、 でもさ、 テストもされてなく、メンテナンスを誰がするのかも解らず、 イミフなソースを再利用する意味ってないんだよ。 同じような機能を再実装している、 それは車輪の再発明だ、なんてことをいうこともある。 でもさ、 車輪は常に再発明されてる。 車輪は常に新しい何かから生まれてくる。 新しい何かから経験を持って、新しい車輪を生み出すんだ。 必要のある構造なら再発明すべきなんだよ。 腐ったソースを立て直すなんてまっぴらだ。 どんなソースだって、 どんな構造
静的よりも無名、グローバルインスタンスよりグローバル関数 - 神様なんて信じない僕らのために
最近、やっと意識していること。 static HogeManager hogeManager_; ではなく、 namespace { HogeManager hogeManager_; } とする。 HogeManagerは静的でありたいわけではなく、 ファイル内アクセスをしたいだけに過ぎないから正当な機能である無名名前空間を使う。 （Cだとstaticにせざるをえないけど） Hoge* hoge = HogeManager::getInstance()->create(...); ではなく、 Hoge* hoge = ::CreateHoge(..); を使う。 Hogeをつくるために、 HogeManagerのインスタンスをグローバルにする必要はない。 関数で十分。 グローバル関数は悪ではないが、 グローバル変数は悪だ、という理念に従えばこれは当然の理となる。 CreateHogeの中
悪いプログラマはなぜ作られるのか？ - 神様なんて信じない僕らのために
きむら(K)さん経由！ What makes a bad programmer? I work with about 30 developers and everyone has strengths and weaknesses, but I can't say that any of them fall into that "bad" programmer category. So what really makes a bad programmer? 404 Not Found 何が悪いプログラマを作るんだろうね、というお話。 皆に長所と短所があって、そのどれが悪いプログラマをカテゴライズするためのもの、 ということができないですよ、と。 で、じゃ、何が悪いプログラマを作るんでしょうね？ それによる幾つかの定義。 プログラミングに対して情熱的ではない 詳細に注意を向けない ユーザーが何
余暇にコードを書くべきか？ - 神様なんて信じない僕らのために
書くべきだと思いました、自分は。 家でプログラミングしたり、コードなんて書かないよ、 っていう人は案外多いんだけれど、 じゃ、家で実装を思いついたり、こういう時はどんな動作になるんだろう、って思ったとき、 どうするんだろう？ 気になった事を確かめたりしないんだろうか。 それとも、頭の片隅にそんなことは全くなくて、仕事のときと余暇のときとではスイッチが切り替わるんだろうか。 そんな疑問があります。 自分が理想のプログラマ像として思い描くのは「可能であるならば一切プログラミングをしないで適切に目的を達成してしまう」プログラマです。 で、なぜ、わたしがそれを理想とするのか察しのよい方はすぐに思い当たることかと思いますが、プログラムは一般的に短いほうがよいとされます。それはプログラムを１行でも書けばそこにはバグが潜む可能性が生まれ、コードが長ければ長いほど含まれるバグは増え、テストやデバッグ、メン
Subversionのロックに悩む - 神様なんて信じない僕らのために
作業上、元々使っていたのがVSSであったこともあり、 ロック必要じゃない？ みたいな話があがった。 VSSは、 ・チェックアウト（編集権利取得） ・チェックイン（サーバに反映、編集権利放棄） なんだけれど、 Subversionは、（svn:needs-lock ・ロックを取得（編集宣言＝ローカルの読み取り専用が外れて、他の誰かはロックできなくなる ・コミット（変更されていたならば、ロックを開放して変更をサーバに反映。変更されてなければ何もおきない＝ロックは開放されない ・ロックを開放（編集終わりましたよ宣言＝コミットを忘れていても、ロックは開放されてしまう。変更されてなければローカルは読み取り専用に戻る。 となってる。 VSSのモデルと違い、 ・コミットしても「変更がなければロックは開放されない」 ・ロックを開放しても「変更があっても何も言われない」 ということがある。 VSSではこれら
Cはワンマン向け - 神様なんて信じない僕らのために
だと考えるようになった。 いや、あくまで自分の中ではです。 今、Cで作られたものを参考にしてC++に移す作業をしていたりするんだけれども、 至る所に出現する、 void* コールバック 謎フラグ hoge->foo->bar->ptr ううーん。 これだけをして、ダメというのは何かもしれないけれど、 void*は至る所で何かに化ける。 根底にあるのは汎用ワークだからして、 その場その場で姿が変わる。 メモリマッピングとしてはそれが当然だからして当然なのだが、 型安全性とは真逆。 コールバック、 StateやStrategy風なことをしようとしてコールバックの嵐になるんだけれども、 あっちやそっちやこっちに飛んだりして遷移が読みづらい。 何でもかんでもコールバックで指定すりゃ良いってもんでもない。 謎フラグ、 至るところにあるhoge_flag & HOGE_FOO_BAR、 フラグの名前だ
漸くCを切り離したぞ！ - 神様なんて信じない僕らのために
……ということで、漸くCを切り離しました。 １ヶ月かかった。 ちかれた。 そして今さらの反応。 どんだけゆとりですか(笑) 各ビットのネーミングとかはそりゃああるだろうけど、 その程度のビット演算で悩んでどうするのかと。 あとはまあ、マクロでくるむくらいはしていいとは思うけどさ。 404 Not Found うーん、ビット演算ではなくて、 そのビット演算の結果、どうなっているのかが読み取りづらいんですよねえ、と思った訳なのです。 「で、そのビットはどんな効果を及ぼすの？」という感じで。 いや、過去の自分が読んだら、こいつはゆとりだ！ とか思うんでしょうけれども。 hoge_flag |= HOGE_FLAG; ... if (hoge_flag & HOGE_FLAG) { hoge_flag &= ~HOGE_FLAG; } が至るところに出現するんですが、これが立っているとどうなるの？
C++に実行時の型なんてものはない - 神様なんて信じない僕らのために
は嘘でした。k.inaba さんの指摘で修正。 と、まで書くと言い過ぎか？*1 また、オーバーロードされた演算子の動作を特別に考える必要もない。 演算子オーバーロードした演算子はメンバ関数と同じ動きをする。 virtualでない演算子は、演算子を呼び出した対象オブジェクトの「変数の型」によって決定される virtualな演算子は、演算子を呼び出した対象オブジェクトの「実行時の型」によって決定される 要するに、メソッドと同じ C++で演算子オーバーロードしたときの演算子決定基準について調べた - 矢野勉のはてな日記 ちょっと違う。 単に同じ動きをするだけでなく、同じものだ。 クラスに対しオーバーロードされた演算子はメンバ関数のシンタックスシュガーに過ぎない。 また、メンバ関数であるとは限らないので、メソッドと同じとすべきではない。 あと、少なくとも、C++は実行時の型情報を元にメンバ関数を呼
ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない？ - 神様なんて信じない僕らのために
ある程度経験を積んだC++プログラマは絶対にvirtualデストラクタのないクラスを継承しない C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ はよくある間違い。あるいはC++初心者の勘違い。 継承する可能性のあるクラスにはすべてvirtualデストラクタを作る C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ ということが否定されていることは言われるようにEffective C++を読んでいればわかること。 C++では、コピー不可にするために以下のようなクラスを書いたりするが、 （コピーコンストラクタとコピー代入演算子を無効にする） class Uncopyable { protected: Uncopyable() {} ~ Uncopyable() {}
[c/c++]死に至る言語
→元ネタ 漢の言語 - みねこあ C++の何が難しいって、わかってないのに解ってるという奴が多いとか、実は自分もわかってませんとか、 そもそも適当に書かれると依存性高くなり過ぎなんだよ、バーロー。 ヘッダにちょっとメンバ関数を付け加えたら、 500ファイルビルドにいくとか阿呆だろ、バーロー。 リンクも時間かかりすぎなんだよ、 どうなってんだ、バーロー。 でも、そこが好き。（←頭に蛆虫がわいてきた） と、まさにid:minekoaさんも書かれているように、 C++は下手に書くと依存性が莫迦みたいに増える言語であり、 それをいかに低下させるかは永遠の課題と思われる。 記述順とかにこれほど気を遣う言語は他にないよね！ 例えば、Pimplのようなコンパイラファイアウォールテクニックなどもあるが、 なかなかそううまくはイカンザキ、 であり、 friendともなかなか仲良し度を下げられない言語でもあ
![[c/c++]死に至る言語](https://cdn-ak-scissors.b.st-hatena.com/image/square/e297899d5a7d7fea969884688c1c78556cfc2d40/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673884669%2F12704591929886794748%2F1341545546)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
