• ベストアンサー

ForteCとProC

普段、何気なく使っていたUnixCに、いくつか種類があり、 結構、違いがあるらしい事にようやく気づきました。 種類がある事は、以前に気づきましたが、それは単なる コンパイラの種類であり、使う側が意識する事はないと 思い込んでいました。今考えれば、コンパイラが違えば、 使用する際にそれを意識するのは当たり前な気もします。 しかし、未だに明確な違いや特徴が良く分かりません。 コーディングする上で、またコンパイルする上で、何か 意識すべきこと、注意すること等、ご存知の方がいらし たら、御教授下さい。

質問者が選んだベストアンサー

  • ベストアンサー
  • a-kuma
  • ベストアンサー率50% (1122/2211)
回答No.4

> こういったノウハウは、実践で身につけるものなのでしょうね。 やる気があれば、全てドキュメント化されていることなので、座学のみで習得する ことは可能です。 また、実際に複数のコンパイラを使うはめに陥らないと、なかなかやる気にならない ということも事実です。 > 注意点や「仕様上不変な部分」の見極めに、何か良いアドバイス(書籍とか)等 > ありましたら、後学の為、御教え頂きたく候ふ。 ANSI の規格書が一番です。 規格書に「不定」とか「未定義」とか書いていないところ(*)が「仕様上不変 な部分」です。   (*) 明示的に『実装により定義された(implementation-defined)動作』と記述されているところもある

ike_aqc
質問者

お礼

大変、理解が深まりました。ありがとうございました。 これからは、少しコンパイラを意識してコーディング する様にしてみます。

その他の回答 (3)

  • terra5
  • ベストアンサー率34% (574/1662)
回答No.3

>これに関しては、コンパイルが両方で通ればOKということでいいのかな。 不十分だと思います。 a-kumasさんが書いている他にも、片方は正常に動くが片方が異常終了するとか, 結果が異なるとか無いとは言えません。 また、構造体のサイズが絡む場合、通信時のデータサイズが変わったりとか,データファイルのサイズが変わったりとかで 問題がでる場合があります。 >コーディングする上では、さほど意識しなくて良いと認識しましたが。 言語の仕様上不変な部分が身についていれば, 注意すべきところはすぐわかってそこは注意する, そうでないところは特別に意識しないということはありますが、 なんらかの形で意識はしていると思います。 また、意識しないでうまくいった時はいいですが、 問題が出てから苦労すると思いますが。

ike_aqc
質問者

お礼

ありがとうございました。 注意点や「仕様上不変な部分」の見極めに、何か良いアドバイス(書籍とか)等 ありましたら、後学の為、御教え頂きたく候ふ。

  • a-kuma
  • ベストアンサー率50% (1122/2211)
回答No.2

> これに関しては、コンパイルが両方で通ればOKということでいいのかな。 そうでもありません。最近の unix (あなたがお使いの Solaris のように) では、 ライブラリは静的にリンクするのではなく、動的にリンクするのがデフォルトに なっているのが多いです。 例えば、実行時の LD_LIBRARY_PATH が別のところを指していると、きちんと 動かない、ということがありえます。 > コーディングする上では、さほど意識しなくて良いと認識しましたが。 「さほど」の加減が難しいところ。 ANSI と POSIX の範囲だけにとどまっており、ポインタに関する正しい理解が あるひとであれば、さほど意識しなくても良いと思います。 でも、最近までコンパイラが複数あることを知らなかったのであれば、何が「普通」な のかが分からない(今まで自分が普通にやってきたことと同じとは限らない)です から、一概には言えません。 私の経験では、ひとつのコンパイラしか知らない人が作ったプログラムを、他の OS (もちろん、コンパイラも違う)に持ってゆく場合には、それなりの覚悟をして かかります。   ※ すんなりとはいかないことが多いです 因みに、これが c++ になると、もっと違いが深刻になってきます。

ike_aqc
質問者

お礼

ありがとうございました。 こういったノウハウは、実践で身につけるものなのでしょうね。

  • terra5
  • ベストアンサー率34% (574/1662)
回答No.1

いろいろありますが、思いついたことをその順であげてみます. 1) ライブラリ,インクルートファイルの違い ANSI規格に沿った部分は同じでしょうが,それ以外の物は同じライブラリ、関数があるとは限りませんし,インクルードファイルも名前や中身が違う可能性があります。 2) 言語の実装依存部分の違い 例えば,intのサイズは決まっていません。 そこまで極端なことは無いかも知れませんが, その手の違いがある可能性があります。 構造体も定義によってはサイズが違ってくる可能性がありますね。 3) コンパイラ依存部分 #pragma なんていうのを使っていると,書き換える必要があるでしょう。 また、言語使用を独自に拡張している場合もありますので、 そういう機能を使わないようにする必要があるでしょう。 4) コマンドライン引数の違い -cなんかは同じでしょうが,細かいところで違っていると思います。 必要に応じて直す必要があるでしょう。 5) 共存問題 両方同時に使う場合は、それぞれの環境がまざらないか注意がいるでしょう。 .objファイルは混同出来ないかもしれません。 LIBという環境変数でライブラリが参照できる必要があるばあい、それが使っているほうのCコンパイラのそれになっている必要はあるでしょう。 まあ、コンパイルしたプログラムの実行速度やサイズが違うこともあるでしょうが、 実行するうえで問題にはならないですよね。

ike_aqc
質問者

お礼

ありがとうございます。 細かいところでは、それぞれ独自のものがあり、注意が必要ですね。 これに関しては、コンパイルが両方で通ればOKということでいいのかな。 コーディングする上では、さほど意識しなくて良いと認識しましたが。 以上、私の認識に勘違い等があったら、御指摘頂きたく。

関連するQ&A

  • 昔C言語で作成したAPが64ビット版OSで不動作

    以前C6とWindowsSDKで作成したソフトがWindows7 64ビットOS上で動きません。 XPモードでは動作します。 Windows7 64ビットOS上で動かしたいのですが、32ビット又は64ビットのコンパイラでコンパイルし直せば動くと思うのですが、なんせ昔の事なので最近の情報がよく解りません。 どなたかコンパイラの種類、SDKキット、LINKの種類等開発環境をどうすれば良いのか丁寧に教えて戴きたいのですがよろしくお願いします。

  • 無料コンパイラの比較について

    現在、C言語の学習を行っています。 とりあえず1からプログラミングを始める前提でメモをするためにコンパイラに関して自分で調べているのですが、無料で入手できるコンパイラで以下のものを見つけました。 ・LSIC-86試食版 ・Borland C++Compiler 5.5 とりあえずどちらも入手して、簡単なプログラムのコンパイルを試してうまくいきました。 ここで上記2つのコンパイラにはどのような違いがあるのかが気になり調べていたのですが、Web上では見当たりませんでした。 どちらもCpadを使用して簡単にコンパイルができるようになり、 適当にどちらも使っては見ているのですがどちらも使い勝手としては同じようなもので、これといった違いが今のところ見当たりません。 (これはまだプログラミングの内容がたいしたものではないのが原因でもあると思いますが…) どなたか上記2つの違い(長所、短所)などをご存知の方いましたらご教授いただけたらと思います。 よろしくお願いいたします。

  • IEEE754と浮動小数点定数同士の演算について

    ■質問 浮動小数点の標準規格IEEE754に、浮動小数点定数同士の演算に関する規定はありますか? ■背景 とあるマイコンで組込みソフト開発をしています。 このマイコン用のコンパイラ(IEEEに準拠)で以下のCソースコードをコンパイルしたところ、コンパイラのバージョン1とバージョン2で演算結果が異なりました。 double d_val = 6.6f * 10.0f; ○コンパイルバージョン1でコンパイルしたソフトの演算結果 →d_valには66.0が代入されました。 ○コンパイルバージョン2でコンパイルしたソフトの演算結果 →d_valには65.999999…(詳細は失念)が代入されました。 コンパイラメーカーに問い合わせたところ、「バージョン1から2へのアップグレードにおいて、浮動小数点定数演算に関連する変更を行ったが、その影響は浮動小数点演算における誤差の範囲内である」との回答でした。 誤差の範囲内であるとはいえ、コンパイラのバージョン違いで演算結果が異なるのは困るので、これがIEEE754規格違反なのであれば、それを根拠にコンパイラメーカーへ対応を求められるのではないかと考えています。 しかし、浮動小数点定数同士の演算結果の正確性についての規定がないのであれば、開発側で対応するしかありません。 いろいろと調べてはいるのですが、これといった情報に行き当たっていないので、こちらで質問させていただきます。どうぞよろしくお願いいたします。

  • クラスパスとMANIFEST.MF

    いつも楽しく拝見させて頂いています。 現在3点お聞きしたいことがあります。内容的に3点共にパスのことなので一つの質問としてお聞かせください。 現在Eclipse3.1にてstruts1.2.4を使って勉強しています。 1.WEB-INFの直下にMANIFEST.MFというファイルがあります。googleとかで調べてみたところ、パスを通すためのもの?っていう感じだったのですが具体的にどういうものなのでしょうか?それが原因でEclipse上でコンパイルできなくなっています。(Could not find the main class.Program will exit.というエラーがでます。)エラーの直し方も含めてMANIFEST.MFについてお聞かせ願えませんでしょうか? 2.現在環境変数にはJAVA_HOME=C:\j2sdk1.4.2_12 path=%JAVA_HOME%\binという設定になっています。私はクラスパスというものはコンパイラーに「コンパイルするファイルを探すときはまずはここから探してね」ということを明示的に伝えるものだと思っていました。ですがDOS上でcdし、デスクトップまで移動後、デスクトップ上で(つまりカレントディレクトリ上で)テキストにjavaのコーディングをしてコンパイル...javac hoge.java した後、java hoge とやるとNoClassDefFoundErrorと表示されてしまいます。cdでjavaのソースファイルがある所まで移動しても無理ってどういうことなんでしょうか?コンパイラーはクラスパスを指定しないと同じフォルダであっても(javacコンパイラとは違うフォルダにはなりますが)探してはくれないんでしょうか。 ・環境変数でClasspathを設定する際、カレントディレクトリ(.;のような記述)の記述がなぜ必要なのか。必要な時と必要でないときがあると思いますがどういうときに必要でどういうときに必要でないかを教えてくださるとわかりやすくてうれしいです。 賢明な方がいらっしゃいましたらどうかご教授宜しくお願いします。

    • ベストアンサー
    • Java
  • VC60とVC70の違いは?

    コンパイル環境のVC60とVC70の具体的な違いってありますでしょうか? 今までVC++6.0を使っており、最近.NETに環境を変えたのですが、6.0で動いてたものが.NETでは動きません。 具体的に言うと、SOAPでWSDL指定のサーバーとの通信を行うのですが、.NETでは通信を行わず、UNKNOWN ERRORと返ってきます。 SOAP通信の方法ですが、SOAPClient生成から、Invokeメソッドで通信を行っています。 6.0と.NETでの違いはコンパイラの違いと思っているのですが。。どなたかご存知の方、ご教授お願いできないでしょうか?

  • 後方互換モード(HTML+CSSコーディング)

    はじめまして、cats4です。 普段標準モードでHTML+CSSコーディングをしているのですが、後方互換モードでコーディングすることになりそうです。 後方互換モードで組む際、注意することは下記サイトで紹介されているのと逆の説明でパディングやボーダーを幅として計算しない(内寸が小さくなる)という事でいいでしょうか? 以前から互換モードだと内寸が小さくなるようなことは聞いたことがありましたが、殆ど意識したことがありませんでしたのでご返答をいただけるとありがたいです。 また、下記の内容以外にも注意点があれが教えていただけると嬉しいです。 http://www.hp-webmagic.com/wordpress/archives/124 逆に下記の説明を見ていると「(XML 宣言を省略しない )XHTML 1.0 Strict 文書」で組む場合は、標準準拠と余り変わらないように見えるのですが、私の読み間違いでしょうか?かなり急な話でやや慌て気味に色々なページを飛ばしながら確認しているので・・・ http://2xup.org/log/2007/07/27-2111 幸い今回は「(XML 宣言を省略しない )XHTML 1.0 Strict 文書」で組むことができそうなので、もし殆ど変わらないのであれば助かるんですが・・・ 以上です。よろしくお願いいたします。

    • 締切済み
    • CSS
  • 致命的なエラー C1043について

    こんにちは。お世話になってます。 コンパイラはMicrosoft Cです。 ある時点から、通常のnmakeコンパイルを実行した際、タイトルのようなメッセージがログに表示され、EXEファイルはもとより、OBJファイルが生成できなくなってしまいました。まったくもって原因が掴めません・・・ここ数ヶ月Cのコンパイルを行っていなかったのですが、以前はもちろん上記のコードでエラーを発生させたことはありませんでした。環境変数も変更は行っていません。 現状でマニュアルに記述されている指示(TEMPフォルダ内の掃除と属性確認)は済んでいます。 ちなみに、過去の作成資産を再コンパイルしても同様の現象が起き、現在はどんなPGも全くコンパイルが通りません。 Microsoft Cの動作環境です。 OS:Windows2000 他に使用している処理系:Visual Basic 4.0~6.0 です。 対処法をご存知の方がおられましたら、ご教授ください。

  • コンパイラエラー C2872 あいまいなシンボル

    コンパイラエラー C2872 あいまいなシンボルです。 コンパイルエラーが解消出来ません。 ご教授下さい。 ■コンパイルエラー内容 error C2872: 'MarketplaceWebServiceProducts' : あいまいなシンボルです ■やりたいこと AmazonのAPI「Marketplace Web Service API (MWS)」のHello world 以下ページの右上 オレンジ色の「Download」ボタンから入手できる 「MWSProducts_2011-10-01_v2017-03-22.dll」の使用 https://developer.amazonservices.jp/doc/products/products/v20111001/cSharp.html ■DLLの使用 Visual Studioの対象プロジェクトのプロパティから、 上記DLLの参照を追加しました ■コーディング using namespace MarketplaceWebServiceProducts;//←ここはコンパイルOK using namespace MarketplaceWebServiceProducts::Mock;//←★ここで上記コンパイルエラー ■ご質問 上位の「MarketplaceWebServiceProducts」が正常なのに、 下位の「Mock」を付けるとあいまいなシンボルになるのはなぜでしょうか。 解決策をご教授ください。(可能であれば実装をご提供ください) ■環境 Visual Studio .Net 4.0 C++/Cli

  • コンパイラ、インタプリタ、クロスコンパイラについて

    インタプリタについて質問があります。 色々と調べたところ、perl、php、rubyなど、ソースをインタプリタで実行する言語の利点は以下なのだと思います。 ソフトを作っている環境と実行環境の間でcpuやos等が異なる場合は、 ソースは互いに異なる機械語に翻訳されるので、翻訳は実行環境で行わなければならない。 その際、コンパイラの場合はわざわざ手動で翻訳を実行しなければならないが、 インタプリタの場合は勝手に実行時に翻訳してくれるので楽。 1.それで質問なのですが、 コンパイラは環境に対応した機械語を出すらしいですが、 何故そんな事ができるのでしょうか。 コンパイラが、自身が置かれた環境を分析して、それに対応した機械語を出すのでしょうか? それとも、そもそも環境毎に対応したコンパイラを使うという事でしょうか? 2.また、世の中にはクロスコンパイラというものがあると聞きました。 クロスコンパイラがあれば、ソフトを作っている環境でそのままコンパイルできるので、 インタプリタはいらないのではないでしょうか? クロスコンパイラの短所や長所などを教えてほしいです。 3.翻訳後の話として、機械語はcpuやosによって違うという話ですよね。 つまり、機械語にコンパイル済みのソフトを配布する際は環境毎に対応したソフトを それぞれ配布しなければならないのですよね。 しかし、ネット上でダウンロードできるフリーのソフトなんかは、 特定のOS向け、あるいはOS別に違うファイルを配布、というのはよく見かけますが、 cpuやその他の環境毎に配布物を分けているのは見たことがありません。 機械語は、本当にos以外にも依存するものなのでしょうか?

  • C言語での変数宣言の場所

    今まで2年ほどJavaを使っていましたが、最近になってCを使う必要が出てきました。Cは大学の頃に授業で学んだ程度のレベルです。 それはさておき。 JavaやC++ではメソッド内のどの場所ででも、新たな変数を宣言して使用できますが、Cでは関数内の最初の方でしか宣言できないですよね? 先日、その事を意識せずに、Javaと同じように変数を関数の任意の場所で宣言しているようなCのソースを書き、gccでコンパイルしたところ、コンパイルが通ってしまいました。 その時のファイルは「.c」ファイルです。 このソースはC++のソースとして、コンパイラが認識してしまったのでしょうか?拡張子が「.cpp」ではなく「.c」のままでしたが、コンパイラは拡張子ではなく、ソースを読み込んでから、そのプログラムがCなのかC++なのか判断しているのでしょうか? いまいちピンと来ないので、どなたか解説お願いします。