「C言語:「学問」と「実務」」の編集履歴(バックアップ)一覧はこちら
「C言語:「学問」と「実務」」(2006/02/08 (水) 00:10:46) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
C言語に限ったことではないんですが。
C言語には学問としてのC言語と実用としてのC言語があると思います。
どういうことかというと、
【学問としてのC言語】
・ANSI規格への理想的な準拠とみなす
・アルゴリズムの探求
・C言語のみで記述する
【実用としてのC言語】
・ANSI規格と合致しているとは限らない
・まず納期と仕様
・場合によってはアセンブラも併用する
こんな感じで言いたいことつかんでいただけるでしょうか?
学校なんかで習うC言語は前者だと思います。
入門書なんかのC言語も、そうですね。
しかしながら。
実際、業務においてC言語を使用する場合は後者であることがほとんどです。
実際、現作業で使っているWindRiverのTornado環境では
printf( "Hello "
"C "
"World\n");
という記述がエラーにされてしまいます。規格ではOKなのに。
実際VC++などでさえ、完全な「ANSI対応」ではありません。
また、かなり下回りの(ハードに密着した)I/O部分などはいまだにアセンブラを使用したりします。
特にセンサとのやり取りなど。
他にもアセンブラを使用する局面があります。
それは、「コンパイラのバグを疑う」時です。
99%まではまあプログラマのミスなのですが、本当にまれなケースとしてコンパイラのバグによってプログラムが正しく動作しない、ということが起こります。
こんなときはいくらソースファイルを修正してもまったく無駄としか言いようがありません。正しいC言語プログラムを書いても、正しい実行ファイルにならないのなら、吐き出されたアセンブラコードを解析するしかありません。
この場合は該当部分をインラインアセンブラなどで記述するか、またはアセンブラで作成したオブジェクトファイルを作ってCで書いたほかのモジュールとリンクするしかないでしょう。
コンパイラにバグがある、というのは組み込みの世界では割とよくあることのようです。私自身はまだ経験したことはありませんが。
組み込みの世界ではターゲットにあわせてCPUを選定します。
それはコスト面で決定するのかもしれませんし、機能面で決定するのかもしれません。
それら多様なニーズに合わせて、多種多様なCPUが存在します。(興味のある方はNECやルネサスのマイコンチップのページをご覧になれば、いかに多くの種類のCPUがあるかわかっていただけると思います)
そして、そのような星の数ほど種類が存在するCPUは、それぞれ命令セットが異なります。
そうなると当然、C言語をコンパイルしてマシン語に落とす際にそれぞれのCPUの命令セットにあわせてコンパイルする必要があるわけです。つまり、その数だけコンパイラを作らなければいけません。
技術の進歩の早いこの業界においては、日々新しいCPUがデビューしています。
当然、そうなると時間もあまりかけていられませんし、数も膨大です。そのような状況でコンパイラにバグがある、というのはむしろ当たり前なのかもしれません。
そこらあたり、正直とても泥臭いとは思います。
また、学校でC言語を学んできた学生が戸惑うところではないかと思います。また、学問としてのC言語を生業としている人(情報科の教授さまとか)にも理解していただけないかもしれません。
とはいえ、あくまで業務でのC言語とは「手段」であって、「目的」ではありません。
「目的」とはこの場合、「仕様を満たすこと」「機能を実現すること」であるので、コンパイラに文句を言っても仕方ありません。
たとえアセンブラが混じろうが、ロジックとしてエレガントでなかろうが、「納期」と「仕様」を満たすことが至上命題なのです。
やっぱり、泥臭いなあ。。
表示オプション
横に並べて表示:
変化行の前後のみ表示: