Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

.cソースを#includeしてはいけない理由について

お世話になります初心者IKUZOと申します
これまで、便宜上、#includeで.cソースを列挙してやっていました
一部例外もありますが、とても便利に思っていますが

ディレクティブ等では、
「つまり、構文1は<stdio.h>などの標準ライブラリ用、
構文2は自分で作ったヘッダファイル用と思えばよろしい。
さて、ファイル名には何が指定できるのかといえば、
#include "mydir/header.h"という具合に、
相対パスも書ける(絶対パスも書けるが決して書いてはならない)。もうひとつ、
#include "mysrc.c"とも書けるが(昔はよく、共通部品などをこうやってインクルードしていた)、
分割コンパイルが基本であるから、
ソースファイルをインクルードするのはいまやご法度である。
理由は、自分で考えよう。
できるからといって、何でもしてよいというわけではない。」
この中でソースファイルをインクルードするのはいまやご法度である。
とされています、理由は、自分で考えよう。となっています
しかと思うのですが、その理由はなに?
この初心者に教えていただけませんか?

  • >> ソースファイルをインクルードするのはいまやご法度である。
    >> 理由は、自分で考えよう。
    >> できるからといって、何でもしてよいというわけではない。」
    > しかと思うのですが、その理由はなに?

    書いてる人が無知だからでしょう。
    .c をインクルードすることで期待できることはあるしそれを目的として行うことはご法度でも何でもありません。
  • www.k-cube.co.jp/.../format.html
    > 出力フォーマット指定子
    > printf(),fprintf(),sprintf()などで使用する指定子である。
    > %f float 実数を出力する "%5.2f"
    > %lf double 倍精度実数を出力する "%8.3lf"

    printf() すらよく分かってない人が書いてる頁のようですが真に受けないのが賢明と思います。
  • .cをincludeする事はできてしまうのですが、私はあまりやりません。
    理由をいくつか考えてみました。

    ・.cファイルは基本的なコンパイル単位だと誰でも普通は思う。
     そのため、うっかりプロジェクトに登録したりする。
     しかし、.cファイルの書き方により、ビルドエラーとなるかもしれない。
     自分の手の内でソースを転がしている間は良いが、
     しばらく時間がたったり、自分の手を離れて使用された時に例外的で問題を起こしやすい。
     .cはコンパイルする単位という秩序を持っているソース群は扱いやすい。

    ・includeする.cはそのソースを見ただけでは、意味不明かもしれない。
     includeされる状況がわからないと理解できない。

    ちなみに、私がたずさわったプロジェクトで数千のファイルがあり、Linuxのカスタムmake環境で.cをディレクトリに置くだけでビルドしてくれるというものがありました。このようにビルド環境で拡張子に意味を持たせているような場合では、トラブルが起きやすいです。
  • In reply to fujita nozomu:

    fujita nozomuさんアドバイスありがとうございます
    少し安心しました、自由な発想で良いということですね
    小さなプロジェクトの場合、.cをインクルードすると
    コンパイル速度は少しだけ遅くなりますが
    ヘッダーファイルをその都度インクルードするに比べ
    手っ取り早いので、これまで多用してきました
    「ご法度」なにか特別な理由でもあるのかと思いましたが
    fujita nozomuさんでさえ「ご法度でも何でもありません。」
    ですから、そんなに気にしなくて良かったんですね。
  • In reply to Higetaka:

    Higetakaさんアドバイスありがとうございます
    ・.cはコンパイルする単位という秩序を持っているソース群は扱いやすい。
    ・includeする.cはそのソースを見ただけでは、意味不明かもしれない。
    なるほど、オブジェクトで独立させるということですよね、よくわかります
    自分一人でなく多くのプログラマがかかわる場合は規律性がないといけませんよね
    CS+の場合はエクスプローラにたくさんのファイルを登録しないといけないので
    それが100以上ある場合等見にくいですよね、そのためにフォルダーを作成して格納したり
    そのためC++というような規格が生まれたのでしょうね
    .cをインクルードさせてやるとCS+のプロジェクトエクスプローラには
    登録したものしか表示されないですし、表示されなければエミュレータでデバックも
    できないので、まーしかし小さなプログラムでは便宜上とでも、
    どちらでもという気がしてきました、
    だけど本来は独立させてコンパイルすべきなのでしょうね。
  • Fujitaさんの見解に賛成します。

    かふぇルネで書き込んで良いものか自問してます。しかし、参照しているHPを見るといい加減な知識で子供を相手のビジネスにしているように感じます。アマチュア無線などでも非常にいい加減な通信教育や書籍を見かけますが、アマチュア無線衰退の一因と思ってます。私が子供の頃には、生意気な中学生を許容する・利害の無い・見返りを求めない・フェーストゥフェースの助けがたくさんあったように思います。最近は子供だけでなくフェーストゥフェースを避けられるようです。少し心配で残念に感じます。

    開発計画書やスタンダードやSCMの話に思えます。CS+で未確認ですが、HEWではサブプロジェクトの作り方やVSSを組み込んでみたりといろいろと試してみたことがあります。VSSはHEWと連携しますがベースラインの考え方を上手く組み込めないし、SynagyChangeやClearCaseはHEWとの連携が難しいです。ファイル間の関係性を持たせるためにさらにReqtifyやmicroTRACERなども組み込んでいくとニッチもサッチも身動きの取れない状態になります。この辺りはIDE開発者に頑張ってほしいところです。3人以上あるいは100を超すソースファイルのソフトウエア開発は推進に関して十分に事前検討が必要と思います。開発計画書やスタンダードを十分に検討してソースファイルのインクルードを許可したなら恐れることはないと思います。

  • In reply to kijo:

    kijoさんアドバイスありがとうございます
    SS+HEWでいろいろ経験されてますね、とても複雑なプロジェクトにかかわられたのですね
    私の場合は、孤立無援で自分だけで終わるようなソフトばかりやってます
    それで進歩がないのでしょうか?いまだに初歩の領域をぬけられません。
  • 「include は何をしている、何のために使う」と言う事が分かれば、使い方も分かります。
     「おまじないで、ヘッダーファイルをインクルードする」と言うのでは駄目です。
     仕事で必要な書類が100枚も有ったら、当面見ない書類は袋に入れ手元には数枚にしておきますね。
     この袋が、インクルードのファイルと同じです。

     仕組みが分かれば、プログラムの1行だけインクルードして実験する事も出来ます。
     拡張子がHでもCでもコンパイラには関係無いと分かります。
     用途によって分かるように、人間のために拡張子を分類しているだけです。拡張子がTXTでも良いのです。
     しかしエディタにC言語の予約語を色付けする機能が有ったときに、その機能が利かない。タブ数も同様です。
     TXTでも良いとは入っても、実験としてです。自分で実験して裏付け取った事あったかな?実験してみて。
     
     そのような事を理解して、実験してみたらどうですか。
     「世の中で広く使われているのが、洗練された良い方法」とは限らないので、自分なりの工夫や実験が必要です。

     本で言えば10個の章に分かれるようなプログラムだったら、スタート・プログラムには全体が見通せる目次のような事を書いておき、10本のC言語ファイルをインクルードしても良いのです。
  • In reply to リカルド:

    リカルドさんアドバイスありがとうございます
    「わけもわからずそうしてあるのでやるというのでは駄目ということですよね」
    自分なりに研究を積んで最も適したやりかたを探求するということですよね、
    うちの会社でもC言語規約とかありまして、
    コメントタイトル表示フォーマットとか、それこそinclude、スペース、タブ、かっこ
    等々あるみたいでーす^^!それを意に介さないわたくしは馬鹿なんでしょうか?
    いや独自性を求める研究熱心なものがいるんだぞ!ということで、
    自分に便利なように勝手にやらせてもらっています、
    リカルドさんに一票です。
  • In reply to IKUZO:

    > うちの会社でもC言語規約とかありまして、
    /* 略 */
    > 自分に便利なように勝手にやらせてもらっています、

    決められたルールがあるならそれに従うべきで、ルールの内容が納得のいかないものであればそれを変える様動くべきと思いますよ。
  • In reply to fujita nozomu:

    fujita nozomuさん
    会社組織もたいへんなんですよ、ルールなんていうものが、たくさんあってみんなそれに板挟みになってやっているんですよね、一生懸命我慢して、まーそれが上達の一助にもなるんですが、ストレスも相当なものらしいですよ、「変える様動くべき」fujita nozomuさんもスタミナがあるのですね、私なんか最も少ないエネルギーでやりくりすることを考えます、そんな考えでは会社が傾きますかね。
  • In reply to IKUZO:

    チョット愚痴ります。
    私の周囲は、わざと分かり辛いコードを書いたり、ドキュメントを作らないプログラマが非常に多くいます。長い付き合いで分かってきたその建前は、オリジナルティですが、本音は少ない投資しで長期の高い報酬の確保です。新たな技術習得もなく簡単な同じことの繰り返しだけで大きな報酬を得るには、過去の仕事を抱え込むのが一番です。ドキュメントも作成せずにわざと解りずらい記述で修正時に不具合が発生しやすくしておきます。皆が悩んでいるときに救世主のように現れて「やっぱり、○○さんは違うな!」と高い評価をもらいます。
    ルール違反も言い訳はたくさんあります。プライドも人間性もなくしてもマヒしてきます。お金にこだわるならルール違反は良い選択です。

    IKUZOさん、麻痺してませんか?頑張ってますか?

  • In reply to kijo:

    kijoさんの人柄がわかるような気がします
    信頼がおけて、でもちょっと気難しい時もある。
    「わざと分かり辛いコードを書いたり」この気持ち
    kijoさんにとっては理解しがたいことかもしれませんね
    私はその気持ちがよくわかります、
    「人にそう簡単に理解させてやるものか、取れるものならとってみろ!」
    ですね、根っからの職人かたぎとでもいうのでしょう、
    会社としての方針は職人であってはならないとしていますね
    つまりソフトウェアというのは技術とかノウハウのようなものが
    あってはならず単なる作業としての評価です、つまり時間単位の価格ですね
    愛着とか個性とかソフトウェア上に出ることがあっては一切ならないということですね
    わたくしはどう方向をまちがえたのか、美しい合理的なものが
    たとえソフトであれそれはひとつの文化だと思うのです、だから
    包丁研ぎ職人か、小説家あるいは芸術家にでもなってたほうが良かったのかな
    という気もしておりますが、しかしソフトウェア作成やシステム構築は
    やりがいがあって楽しいですね、これからも自分を貫いていきますよ
    どんな結果であれ
  • In reply to IKUZO:

    チョコです。
    ちょっと,愚痴も入ってしまいました。

    >「人にそう簡単に理解させてやるものか、取れるものならとってみろ!」
    >ですね、根っからの職人かたぎとでもいうのでしょう、
    そういうのを,職人かたぎとは言いたくありません。
    同じことをやっても,すごく小さいだとか,処理時間が短いなど,何らかのメリットがあってこその技術力であり,それ等にこだわったものが職人かたぎだと思っています。
    分かりにくいプログラムは,使用している変数の定義がいい加減だから,本質的でないおかしな処理が増えていってしまっていると考えています。

    >会社としての方針は職人であってはならないとしていますね
    会社の組織論からはそうかもしれませんが,ソフトは人による効率の差が非常に大きいものなので,属人生を排除するのはこれからの人不足の時代には,時代遅れになるかもしれません(そう願っています)。
    と,言うか,昔からプログラマは不足していることが慢性化している中で,よく考えないで,やっつけ仕事でやっているだけのケースが多いのでは。
  • In reply to チョコ:

    >やっつけ仕事で
    そんな感じでしょうね。
    目の前の仕事をさっさと片付けて、早くストレスから逃れたい。
    コードが綺麗でも汚くても給料は変わらないんだし動けばOK・・・こんなところかも?

    自分は37歳で初めてソフト屋としてサラリーマンになったんですが、その会社(今は潰れてる)に入ったころ、元から居た若者ソフト屋同士で「俺も苦労して覚えたんだ、お前だって苦労しろ」と言ってるのを聞いて呆れました。
    「俺のところに来い、全部教えてやるから」と部屋中に聞こえる大声で言ったことを思い出しました。
    やっぱりシステム作りが趣味の人間と、給料稼ぎのためにやむおえず働いてる人間は別物ですよね。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page