[迷信] double の出力書式は”%lf” ｜ 株式会社きじねこ
この迷信ないしは事実誤認はあまりにも根が深く、あまりにも多くのプログラマが間違いを犯し続けていました。遂には標準規格の方が折れて、迷信を追認することになったという”暗い歴史”があります。 printf系の関数でdouble型の実引数に対応した書式指定は”%lf”ではなく”%f”が正解です。同様に、”%le”や”%lg”ではなく、”%e”や”%g”を使うのが正解です。 この迷信の原因になっているのは、ほぼ間違いなくscanf系関数の書式との混同です。そして、悪いことには、迷信を信じて疑わない人々が、さらにその迷信を部下や後輩や学生に広めているのです。 C言語の仕様が分かるのであれば、少し考えればprintf系関数の書式指定がfloat型とdouble型で区別する必要がないことは容易に理解できるはずです。可変個実引数は、既定の実引数拡張によってfloat型の値はdouble型に暗黙的に型変換さ
![[迷信] double の出力書式は”%lf” ｜ 株式会社きじねこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/853790067919a834250849115c8df4649e125793/height=288;version=1;width=512/https%3A%2F%2Fwww.kijineko.co.jp%2Fwp-content%2Fuploads%2F2021%2F05%2F4950885_s.jpg)
4.1 構造体メンバのオフセットを返す。 | 株式会社きじねこ
株式会社きじねこは大阪のソフトウェア開発会社です。組込み系・業務系のプログラム開発から電子回路の設計までおまかせください。 これは、テンプレートではありませんが、offsetof マクロを用いるのが定石です。offsetof マクロは <cstddef> ヘッダで定義されますので、（組み込み用などの）自立処理系であっても、必ず提供されることが規格上保証されています（非標準処理系は別ですが）。 仮に、offsetof マクロを自作する必要がある場合、Cでは、 #define offsetof(type, member) ((size_t)&((type*)0)->member) とすれば十分でしたが、C++ではそうはいきません。なぜなら、& 演算子が多重定義されている可能性があるからで、正しく動作させるためには、 #define offsetof_(type, member) \ (rein
[迷信] 'A'～'Z' の値は連続している | 株式会社きじねこ
やろうとしていることは簡単です。標準入力から 1 文字読み込み、アルファベットの大文字であれば小文字に変換して標準出力に書き込んでいます。 ここで、アルファベットの大文字かどうかの判別には isupper を使うべきだと主張する方がおられるかもしれませんが、その主張は必ずしも正しくありません。なぜなら、isupper の挙動はその時点で設定されているロケールに依存するからです。確実に、'A'～'Z' の範囲に収まっているかどうかを判定するには、やはり自前で処理を書かなければなりません。 というわけで、isupper ではなく、自前で判定を行っていること自体は間違いではないわけですが、問題はその判定方法にあります。ASCII や ASCII と（ほぼ）互換性のある文字コードの場合、多バイト文字さえ考慮しなければ上のコードでも問題ありません。しかし、このコードには少なくとも移植性がありません。
shared_ptr の排他制御を抑止する。 | 株式会社きじねこ
スマートポインタ boost::shared_ptr は非常に便利であり、おそらく Boost C++ Libraries の中でもっとも多く使われている機能のひとつです。boost::shared_ptr は、普通は何も考えずにデフォルトのまま使っていても問題はないのですが、いざ効率のことを考え始めると、問題点が浮き上がってきます。 shared_ptr はスレッドセーフな設計がされており、参照カウンタの増減の際は当然排他制御が行われます。排他制御を行うかどうかは、Boost.Config で決定するわけですが、Visual C++ 2005 のようにシングルスレッドをサポートしない処理系では、常に排他制御が行われることになります。 しかし、現実には、シングルスレッドで十分なアプリケーションも多数ありますし、仮にマルチスレッドであったとしても、shared_ptr をスレッド間で共有する
[迷信] fflush で入力バッファをクリア | 株式会社きじねこ
のようにすると、入力バッファに改行文字が残ってしまうため、直後に getchar などを呼び出すと期待した動作にならないことがあります。 これを何とか回避しようとして、fflush(stdin) を使用しているサンプルをよく見かけます。しかし、fflush 関数というのは、出力ストリーム、または直前の操作が入力ではない更新ストリームに対して使用するものであり、それ以外の場合は未定義の動作になります。 少なくとも複数の有名な処理系のマニュアルには、fflush(stdin) を入力ストリームに対して使用できる旨の記述があるため、上のように書いてもなかなか信用していただけないかもしれません。そこで、Cの標準規格から該当部分を引用したいと思います。 7.19.5.2 fflush 関数 形式 #include <stdio.h> int fflush(FILE *stream); 機能 stre
Account Suspended
Account Suspended This Account Has Been Suspended
Account Suspended
Account Suspended This Account Has Been Suspended
C/C++ 迷信集 | 株式会社きじねこ
C/C++ を使うプログラマは大勢います。しかし、その多くは OJT を通して言語を学んだのではないでしょうか？ 実はそこに大きな落とし穴があります。 コンピュータや工学のことをよく知らない人たちは、時代の先端を歩むプログラマには「迷信」など無関係だと信じて疑わないかも知れません。しかし、迷信や誤解はどんな世界にも常に存在しています。 というわけで、ここでは C/C++ にまつわる迷信、誤解、よくある間違いを採り上げていきます。非常に後ろ向きな企画ですが、暇つぶし気分転換に読んでみてください。もしかすると、ご自身が迷信にとらわれていたことに気付くかもしれません。 追記(2009/03/15) このコーナーでは、C/C++ にまつわる迷信、誤解、よくある間違いを扱っています。決して「迷信」だけではないのですが、タイトルにはすべて[迷信]を付けています。 これは、主に検索エンジンでタイトルを見
第5回 名前のマングリング | 株式会社きじねこ
C の場合、コンパイラが出力したオブジェクトファイルを逆アセンブルするか、コンパイラが出力したアセンブリ言語のソースを見ると、C のソースで書いた関数名などの識別子が、ほぼそのままラベルになっていることが分かります。処理系によっては、元の識別子の前に、アンダスコアなどの記号が付く場合もありますが、ほぼ元のままの名前がラベルになっているはずです。 一方、C++ の場合はどうかというと、必ずしもそんな単純なことにはなっていません。具体例を挙げた方が話が早いでしょう。 という C++ のコードを GCC でコンパイルすると、関数の入り口に相当するラベルは、__Z4funcv という名前になります。この名前の中ほどに、func という文字列は見つかりますが、C の場合に比べれば、かなり大掛かりに変形されています。 C の場合とは異なり、C++ では、同じ名前を持つ関数が複数存在することになります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Account Suspended