質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
C

C言語は、1972年にAT&Tベル研究所の、デニス・リッチーが主体となって作成したプログラミング言語です。 B言語の後継言語として開発されたことからC言語と命名。そのため、表記法などはB言語やALGOLに近いとされています。 Cの拡張版であるC++言語とともに、現在世界中でもっとも普及されているプログラミング言語です。

Q&A

解決済

17回答

15774閲覧

C言語はなぜほとんどの環境下で実行することができるのか 教えてください。

kazuyakazuya

総合スコア193

C

C言語は、1972年にAT&Tベル研究所の、デニス・リッチーが主体となって作成したプログラミング言語です。 B言語の後継言語として開発されたことからC言語と命名。そのため、表記法などはB言語やALGOLに近いとされています。 Cの拡張版であるC++言語とともに、現在世界中でもっとも普及されているプログラミング言語です。

0グッド

7クリップ

投稿2019/08/23 07:21

#質問
C言語はなぜ非C言語環境下でも動かせるのでしょうか?

自分はRubyを使っていますが
もちろん、Ruby実行環境を用意しないと
Rubyコードを実行できない。

ただ、記事を見ているとC言語は
ほとんどの環境下で動かすことができると
書いてあるのですが
なぜでしょうか?


まず、RubyとC言語の違いについて調べたのですが(意外に結構あった)
イメージ説明
まず目に止まったのが
イメージ説明

string

1ruby ・・・プログラムを部分的に機械語に変換しながら実行。 2 3c系言語 ・・・プログラム全体を機械語に変換して実行する。

でも、どちらもコンパイル作業が実行されるのは
プログラム実行命令が出された後なのだから

非C言語・Ruby環境下ではコンパイル作業はできないはず・・・

基礎がわかりません。 
C言語がほとんどの環境で実行できる理由を知りたいのですが
どのようなキーワードから引っ張りだせばいいかわかりません。

分からないので どういうワードで調べればでてくるのか、または
参考になるリンクまたは説明をお願いします。

追記
どのようにしてプログラムが実行されるのか?
というワードでもいったのですが
おいしい情報は手に入りませんでした。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答17

0

どの環境下でも動くアプリケーションは、石(CPU)やライブラリー(内蔵装置・外部接続装置のドライバーやフレームワークのAPIなど)が適切に選択されリンクが成功することによって実現されます。ただしこれらがそろわなければ動かないわけでもなく、原始的なOS下で動かすのであれば直接ポートを操作して(よく叩くという)やりたいことをやってのけることができます。MS-DOSやN88(86)BASICのころは、OSを無視して直接BIOSをコールしてC言語プログラムを動かすことができました。
これらは、C言語の成果物がすでにそれぞれの環境で動作する条件を満たしたものになっていると言い切る証拠のようなものだと思います。

C言語はなぜ非C言語環境下でも動かせるのでしょうか?

誤解があって、まずC言語環境下というものはありません。しかしC言語のビルド環境はあります。ホストがWin/Unix/Linuxであることに関係なくターゲット機器上で動くように作成できます。
大昔にPC98上でHigh-C386など駆使してFM-TOWNS用のアプリケーションをビルドしたりしましたが、どちらかと言えばビルド環境の整ったホストがそこにあれば、仕向け(ターゲット環境)の差分だけをMakefileに織り込めば、どれ向けのアプリケーションでも作成できるという考え方だったと思います。この考え方は今でも存在していると思います。
.net Framework、React Native、Flutterなど、共用できる度合いが変わりますが、基本的に同じコードで仕向けを複数持たせることができます。
これらに比べると、C/C++はターゲットUIが変わると基本的に共用できなくなりますから、いろんな仕向けを用意できるものの、コードを共用するには割とコストが掛かります。

Rubyはフレームワークでもあるので、Ruby自体がOSの差分を吸収した上で動いていると思います。逆に言えばOSの差分を吸収しきれない場合リリースは困難でしょう。

ポテンシャルとしては、中身のないmain関数をそれ自体動かせるC言語に対して、フレームワークの導入が求められるRubyでは、マイコンなどでまず動かしてみることの敷居が猛烈に高いということになると思います。
またC言語は環境にフィットさせることを自前で行う必要があり、その面ではまず動かす敷居が高い場合もあるかもしれません。Rubyはその安定稼働が保証された環境下においてはコマンド一発で導入できるため敷居が極限まで低いといえるかもしれません。

以上は、おおむね論なので一部細かい指摘はあり得ます。そこに反論はありません。現実が事実です。

その他はみなさんおっしゃる通り。

これ長いなあ。
最後まで読んだあなたは努力家です。

投稿2019/08/27 00:05

編集2019/08/27 14:42
kendji

総合スコア92

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 00:13

ありがとうございます。
maisumakun

2019/08/27 02:16

> マイコンなどでまず動かしてみることの敷居が猛烈に高いのがRubyということになると思います。 最近はmrubyといって、組み込み向けのRubyも作られています。 https://github.com/mruby/mruby
kendji

2019/08/27 02:56 編集

はい、補完ありがとうございます。 Windows10のIoTなどもありますが、かたくなに動かないマイコンもありますし長くなるので省きました。 ラズパイとかのLinuxが動いてHDMI出力できるほどVRAMが載ってるマイコンですよね。
guest

0

ベストアンサー

非C言語・Ruby環境下ではコンパイル作業はできないはず・・・

はい、そのとおりです。ただ、C言語の場合、コンパイルされた後のコードだけを持っていって動かすことが可能です。

投稿2019/08/23 07:29

maisumakun

総合スコア145183

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/23 07:32

そういうことなのですね!ありがとございます
kazuyakazuya

2019/11/01 01:59

あの、いまさらなのですが コンパイルされた実行ファイルというのは コンパイルされた環境で実行するための実行ファイルなのだから つまり、・・・windowsでコンパイルされた実行ファイル はLinuxでも使えるのですか? (機械語レベルではちょっとわからないけど アセンブリ言語だと、OSによって依存してしまっていますし ・・・)
maisumakun

2019/11/01 02:04

> つまり、・・・windowsでコンパイルされた実行ファイルはLinuxでも使えるのですか? 「Windows上でLinux用の実行コードをコンパイルする」こと(クロスコンパイルといいます)は可能です。
kazuyakazuya

2019/11/01 02:06

ありがとうございます。
guest

0

C言語はその環境で動くような機械言語に変換してくれるからです。

C言語は一般にコンパイラ言語、Rubyはインタプリタ言語と呼ばれます。
コンパイラ言語はその言語で書かれたプログラムを直接その環境で動くように変換(コンパイル)します。Windowsで言えば.exeとか、.dllとかのファイルですね。
それらのファイルをメモ帳で開いても文字化けして我々人間はほとんど読めないはずです。しかし、機械にとっての言語なのです。

直接、機械で実行できますので、インタプリタ言語よりもコンパイラ言語は一般に早いと言われます。しかし、コンパイラ言語で作ったプログラムは他の環境(他のマシン)に持っていくと動かなくなることがあります。Windows同士であれば、ほぼ問題ありませんが、同じLinuxでもCPUが違えば動きません。同じWindows でも64bitのアプリケーションは32bit環境では動きません。
コンパイラ言語はプログラムを動かしたい環境に合わせて機械向けのアプリケーションを作ります。

逆にRubyなどのインタプリタ言語については、機械向けのアプリケーションは作りません。基本はruby xxx.rbなどファイルを直接Rubyに渡しています。
Rubyはファイルを渡されるとそのプログラムを動作している環境向けに変換(コンパイル)して実行までします。

つまり、
コンパイル言語はプログラムを1.コンパイル、2.実行と2段階に分けて実行するのに対し、
インタプリタ言語は1.コンパイル&実行としてくれるわけです(本当はコンパイルまでで止める事も可能ですが、簡単のために省略)

さて、質問についてですが、結論から言うとC言語のようなコンパイル言語(C++やPascalなど)は直接機械言語にしているからCを動かすソフトがインストールする必要がないのです。
Rubyなどはプログラムから動かす言語なので、機械言語に変換処理などが必要なので、プログラムだけでは動作せず、Rubyをインストールする必要があるのです。

この話は今の先端の技術ではそうでないことも述べていますが、知識としては無駄ではないはずです。

コンパイラ言語、インタプリタ言語ときたら次は中間言語となり、面倒な話になりますが、そこは今回の話とは関係ありませんので割愛します。

投稿2019/08/26 12:37

impepc

総合スコア86

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

hayataka2049

2019/08/27 03:38

>インタプリタ言語は1.コンパイル&実行としてくれるわけです(本当はコンパイルまでで止める事も可能ですが、簡単のために省略) 広義の「インタプリタ言語」の記述としてはこれは誤っています。特にナイーブなインタプリタの実装の場合、コンパイル(バイトコード生成)は行いません。 JITを前提とするのであれば良いですが、前提として書いておく必要があるかと。
bleis-tift

2019/08/27 14:01

言語を「コンパイラ(ル?)言語、インタプリタ言語」と分類するのは言語(仕様)と処理系を混同していませんか。 C言語のインタプリタだってありますし、機械語にコンパイルするRubyを作ることだってできますよ。
impepc

2019/08/27 22:46

>> hayataka2049 さん おお、確かにインタプリタ言語なんてないって書かれてますねー https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%97%E3%83%AA%E3%82%BF?wprov=sfti1 下調べをせずにプログラムを始めた頃の遠い過去の記憶で答えてました。 言語と処理系が混じった質問だったのでそれっぽい言葉で答えてしまいました。 勉強になりまひた >> bleis-tift さん 混ぜてますねー。一般にとか言ってるし 言語って言った瞬間にJVMやら.Net(CLR)やら、さらにはLLVMとかどーすっかなとは思ったんですが、TypeScriptとかm4とかのトランスレータ、アセンブリ言語まで考えるといよいよ崩壊しそうなので勉強し始めた頃の簡略化した説明にしようと落ち着きました。 ただ、不適切な言葉の選択でした。
guest

0

他の回答に異論があるわけではないのですが、異なる視点から回答してみたいと思います。

C言語はなぜ非C言語環境下でも動かせるのでしょうか?

自分はRubyを使っていますが
もちろん、Ruby実行環境を用意しないと
Rubyコードを実行できない。

ただ、記事を見ているとC言語は
ほとんどの環境下で動かすことができると
書いてあるのですが
なぜでしょうか?

現在流通しているOSの大半はC言語で開発されていて、OS上で動くコマンドの多くもC言語で開発されています。なので、OS自体が「C言語が動く仕組み」を元々持っているわけです。そうじゃないと、C言語で開発されたコマンドが動かないですよね。
具体的には、Linuxはglibcというライブラリが元々ありますが、これは(主に)C言語から呼び出されるライブラリです。
なので、大半のOSは元々「C言語環境」なのだと言っても間違いではないと思います。ただし、そのような言い方を現実にするわけではないのでご注意ください。

投稿2019/08/27 02:44

ockeghem

総合スコア11701

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 03:08

ありがとうございます。 とりあえずイメージとしてそう思うことにします。
pepperleaf

2019/08/27 14:09

> 大半のOSは元々「C言語環境」なのだ 細かい話ですが、最近の OSはですね。 C言語が普及しだした頃、バイトとワードでアドレスが異なるマシンの C言語サポートは大変でした。
guest

0

英語は、なぜ 殆どの国で通じるのか?

昔は オープンソースなものも ソースコードから make configure から始めて
動作環境に合わせた設定を用意してからこコンパイルして使うのが普通でした。

いつのまにか CPU が同じで、ある程度 OS が似ているなら、バイナリーをもってくるだけで動作するようになりました。

ruby コードも C と同じようにこコンパイルして exe や 実行形式バイナリーしてしまうという方法もあります。この場合は ruby 環境がなくても プログラムは動作します。

shell スクリプトは、スクリプト言語ですが、 /bin/sh がある linux なら、ほとんどの環境で動作するでしょう。

ある形式に沿ったバイナリを動かす仕組みが、多くの環境で共通になっているというだけのことです。

投稿2019/08/28 15:18

katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/29 05:26

ありがとうございます。
guest

0

ただ、記事を見ているとC言語はほとんどの環境下で動かすことができると書いてあるのですがなぜでしょうか?

一言で言えば、「C 言語を使いたいという需要が多いから」となります。
ではなぜ需要が多いのか。

C言語はその生い立ちから、直接機械語を出力することを目的としており、さらにアセンブラとの親和性が高いという特徴を持っています(C言語ソース内に直接アセンブリを書けたりする)。
これはそもそもアセンブラベースで作成されていた初期のUNIX用のプログラムを書く際に、アセンブラと同等のことができる上でより書きやすい高級言語が欲され、その解答として作られたのがC言語だからです。
そのため、C言語はメモリ空間を直接操作することができる特徴を持っています(ポインタがまさにそれです)。

さて、アセンブラの代わりができる、ということは、新しいCPUなりなんなりを使えるようにするために基礎的なプログラムを作成する際に、C言語が使えるなら作業効率が上がります。むろん、C言語ならそれなりの移植性も持ち合わせています。
であるならば、まず「C言語でプログラムを作れるようにする」=対象の環境向けのCコンパイラを用意する、のを優先した方が、後の開発が楽になります。
結果的に、「まずCコンパイラを用意する」ことになり、それはつまり「C言語で書いたプログラムが動かせる環境ができあがる」のです。

よほど特殊なCPU(例えばJavaバイトコードを直接実行するとか)でもない限り、C言語が使えないというのはありません。そんなCPUは、そもそも売り物にならないからです。
※はなからごく少数しか使わない前提のCPUとかならC使えないなんてのもあるかも知れませんが……

投稿2019/08/27 09:42

tacsheaven

総合スコア13703

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 09:59

ありがとうございます。
guest

0

すごーく比喩的にいうと、

Cでコンパイルするというのは、翻訳した本を書き上げるということ。
翻訳自体は、別にいつ、どこでやったものでも構わない。出来上がった本だけあれば読める。(その意味では、そもそも「C環境」なんていうものがないとも言える)

Rubyは、同時通訳してくれる人が側について、元本を翻訳しながら朗読してくれるもの。
ということは、同時通訳してくれる人(Ruby環境)がそこにいなきゃいけない。

もう一ついうと、Cは、プログラマに責任を負わせることでコンパイラは随分楽をしている。またそれとも関連するけどコンパイラがあれこれ手を回さずに、プログラムに書いてあるとおりコンピュータの中身を直接いじくるようなプログラムになる...
ので、コンパイラ自体は(基本としては)比較的コンパクトで、簡単に作れて、しかも対象コンピュータの能力を引き出しやすい(その分人間が苦労する)ので、どんなCPUであれ、高級言語としてCのコンパイラが用意される、ということになる。
(研究用で特定の言語に合わせたCPUというのが開発されることがあったけど(FORTHチップとか)、そういうのにCがあったかと言われるとそこまでは知りません。)

投稿2019/08/27 05:51

thkana

総合スコア7629

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 06:58

ありがとうございます。
guest

0

通常はコンパイラ及びリンカによりC言語のソースから実行形式(機械語、あるいは中間言語)にされるので、この実行形式のプログラムは非C言語環境下でも動かせる可能性があります。

但し、実行時に特定の実行時ルーチン/dll等を必要とする場合があります。

C言語は使い勝手が良いので、様々な処理系に移植されています。

様々な処理系に実行時ルーチン/dll等が移植されていれば、その処理系上で実行できると思います。

投稿2019/08/27 00:16

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 00:18

ありがとうございます。
Zuishin

2019/08/27 00:24

よく知らずに書いたでしょう。いろいろと用語が混乱しています。
tsuntsun

2019/08/27 00:40

なんか.Netの話と混ざって理解されているようですね? かなり間違った理解をされているようです。
退会済みユーザー

退会済みユーザー

2019/08/27 09:17

>なんか.Netの話と混ざって理解されているようですね? このご質問では UNIX環境とか .Net上とか実行環境を限定していないようですね。 したがって、.Netの話と混ざっているというより、一応 .Netも考慮しています。 意図はそういうことです。 まあ、要は、C言語の開発環境が無くても、実行するだけであれば適切なランタイムルーチンがあれば実行できるでしょうということですね。
Zuishin

2019/08/27 09:25 編集

開発環境もランタイムも無くて実行できるのが普通ですが。それに .NET 上で動く C はありません。上位互換性はありますが、C++/CLI という別の言語です。.NET を使うにはクラスが必須なので。
退会済みユーザー

退会済みユーザー

2019/08/27 10:05

>開発環境もランタイムも無くて実行できるのが普通ですが。 私の最初の回答では「この実行形式のプログラムは非C言語環境下でも動かせる可能性があります。」という書き方をしております。 誤解を招いたかも知れませんが、この文での「非C言語環境下」→「C言語開発環境なし」と解釈していただけると幸いです。 何が普通で何が普通以外なのかの判断基準がわかりませんが、何らかのランタイムが必要な場合があるのも事実でしょう。 ここでは、どのようなマシンのどのような環境上なのか特定できませんので、ランタイムが必要とも不要とも決められません。 必要としない場合はあるでしょうが、ランタイムが必要な場合もある、どちらもあり得るというだけです。 > .NET 上で動く C はありません。 Cとしてはないでしょうね。 .NETという名称を出し、それ以外のことも混ざった文になってわかりにくかったら申し訳ありません。
Zuishin

2019/08/27 10:41

ランタイムというのが何のことかわかりませんが、MFC や OpenGL のようなものを想定されているなら、それは C 言語環境ではなく、本題と無関係です。 .NET も無関係ですから、この回答はほぼ無関係のことのみに言及されており、質問への回答になっていません。
Zuishin

2019/08/27 10:50

> 様々な処理系に実行時ルーチン/dll等が移植されていれば、その処理系上で実行できると思います。 この部分については、 > この文での「非C言語環境下」→「C言語開発環境なし」と解釈していただけると幸いです。 を合わせて読むことで、開発環境のないところで dll のみインストールして C 言語のソースが実行できると解釈するほかありませんが、そのような環境は私は知りませんし、たとえあっても一般的とは言えず、質問の回答として不適切であろうと思います。
退会済みユーザー

退会済みユーザー

2019/08/27 11:08

>開発環境のないところで dll のみインストールして C 言語のソースが実行できると解釈するほかありませんが、そのような環境は私は知りませんし、たとえあっても一般的とは言えず 「実行時」に限定すれば、そこでコンパイル/リンク、ビルドする必要はないでしょう? コンパイル/リンク、ビルドした開発マシン上で実行するとは限りません。別のマシン上で実行する場合もあります。 実行するだけであれば、必ずしもマシン上に開発環境が存在する必要は無いでしょう? 開発マシンとは別のマシン上で実行するのは「普通」の範囲に含まれませんでしょうか? ベンダー開発ソフトを客先のマシンにインストールして実行するのは珍しく無いですし、市販のソフトでも開発マシンと実行マシンは別になります。 >C 言語のソースが実行できる ソースは実行できないですね。 インタプリタを想定されているのでしょうか。 (インタプリタでも「ソースが実行できる」とは言い難いですが)
Zuishin

2019/08/27 11:13

ビルドされたものはあなたの言う非 C 環境で動くので、ここに dll の出てくる余地はありません。dll を必要とするソフトはありますが、それは C 言語とは無関係です。
Zuishin

2019/08/27 11:17 編集

繰り返しますが、質問の答えになっていません。 それを質問に合わせて解釈しようとすると、どうしても無理が出ます。 質問関係なく知っている知識を並べただけなんでしょうか? dll 必要なソフトはあります。開発環境を必要としないソフトもあります。.NET は中間言語を使います。しかし、それが C 言語や質問と何の関係があるんでしょうか?
退会済みユーザー

退会済みユーザー

2019/08/27 11:33

ご質問は開発言語をC言語に限定していますので、それに沿ってC言語に触れているとご理解下さい。 とはいえ、回答自体は「実行することができる」ために何が必要かを記述しようとしているだけです。 1.実行時に dll を要する場合がある   ※環境によりますので「絶対に必要」というのではありません。    例として「場合がある」というだけです。 2.実行時に開発環境が絶対に必要なわけでは無い 上記項1,2はC言語に限った事では無いですね。
Zuishin

2019/08/27 11:37

この質問を要約するとどうなりますか? また、それにどう答えますか?
退会済みユーザー

退会済みユーザー

2019/08/29 06:31

>Zuishin さん 一言でいってしまえば 「C言語のソースから生成した実行形式のプログラムを実行するのに必要なもの(注1)が実行するマシン上に存在すれば実行できる」 ということでしょうか。 実行できるのはC言語に限ったことではないですが。 ※注1:ここでの「必要なもの」は開発環境、コンパイラ/リンカ等の仕様に左右されると思います。実行環境に 何らかの dll なり、何らかのランタイムルーチンが必要な場合はありますね。まあ、必要としない場合もあるでしょうけれど。 現実的には、開発マシンと実行マシンが別H/Wで別OSだったりすれば実行マシン上で再コンパイル/リンク等が必要だし、別OSだったりすれば文字コード/改行コードの違いもあるかも知れないし、コンパイラ等が異なるのでCのソースを修正する必要が生じる(関数仕様などの非互換)場合もあり色々苦労しますね。いいクロスコンパイラに巡り会えればいいのですが。(脱線失礼しました。愚痴です。)
退会済みユーザー

退会済みユーザー

2019/08/29 13:14

>Zuishinさん 2019/08/27 19:41 「ランタイムというのが何のことかわかりませんが」 についてですが、 たとえば、マイクロソフト社の呼称では .NET Framework も「ランタイム」とされています。 URL : https://dotnet.microsoft.com/download/dotnet-framework/net472 Runtime The runtime includes everything you need to run existing apps/programs built with .NET Framework.
Zuishin

2019/08/29 13:17

知ってます。そういうことじゃありません。
Zuishin

2019/08/29 13:19

何度も同じことを言うのに飽きたから黙ってただけなんですが、いい加減にしませんか? この質問の答えになっていないでしょう? なっていると本気で思っているのですか?
Zuishin

2019/08/29 13:23

> ランタイムというのが何のことかわかりませんが、MFC や OpenGL のようなものを想定されているなら、それは C 言語環境ではなく、本題と無関係です。 意味わかります? わからない? なぜ?
Zuishin

2019/08/29 13:24

.NET も無関係だと何度言えばわかるんでしょう?
退会済みユーザー

退会済みユーザー

2019/08/29 21:13

↑ 繰り返しになりますが、「C言語でのプログラム開発時に必要なもの(コンパイラ、リンカ等)と、実行時に必要なもの」が違うと言っているだけでしょう。 ランタイムは「実行時に必要なもの」の例としてあげているだけです。 同じ内容の繰り返しになっていますので、これで終わりにします。
Zuishin

2019/08/30 00:36

だから、それを踏まえて、それを回答に書く意味が無いと言ってるだけでしょう。 全く無関係な情報です。
guest

0

「C言語」は実行できないよ。直接実行できるのは機械語(バイナリの実行ファイル)だよ、ということを常識として知っておくといいですね。

機械語は人間には読めませんが、CPUには意味がわかる、というものです(厳密な話をしだすと、「機械語命令列」の前にOS宛のヘッダとか色々ついてる可能性はあるんですが、割愛。また、機械語ですらない可能性もあるのだが(Javaの方式とか)それも割愛)。

Cのコンパイラはこのバイナリの実行ファイルを生成します。

ではRubyの実行環境は何かというと、こいつ自身はバイナリの実行ファイルです(だと思います)。要は、これ自体が一つのソフトウェアです。

どんなソフトウェアなのかというと、ファイルに書かれた文字列を読み込んでそれに応じて色んな計算や処理をしてくれるというものです。こういうものをインタプリタと言います。
(実際はJITとかやり方がいろいろありますが、割愛)

投稿2019/08/23 17:02

編集2019/08/28 12:48
hayataka2049

総合スコア30933

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/23 21:59

ありがとうございます。
guest

0

There are numerous benefits from learning C; however, the most important benefit is that the C programming language is recognized worldwide and used in a multitude of applications, including advanced scientific systems and operating systems. Programming in C is fairly easy

C is one of most widely used computer programming languages. The reason C is so popular is because it is reliable, simple and easy to use.
C is what is called a compiled language.

投稿2019/08/29 04:39

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/29 05:28

ありがとうございます。 C言語は難易度が高いなど言われますが・・・
guest

0

すでに沢山の回答が上がっていますが、個人的に好きなテーマなので、整理を兼ねて書いてみました。

「正しい質問をすること」は意外に難しいことがあります。このご質問は、以下の2種類のテーマを含んでいると思います。

  テーマ1:ランタイム環境の有無の問題

  テーマ2:コンパイラとインタプリタの相違の問題

ご質問を精読すれば、前者1の質問ということになると思いますが、後者2の内容についても書いてみたいと思います。

なお、私は日頃、Ruby を使っていないので、言葉が多少、正確でない所があるかも知れませんが、あしからず。

■テーマ1に対する回答
初期のCコンパイラで開発したプログラムは、EXE ファイル単体で動いていました。ただ、Cコンパイラが生成したプログラム(EXE)には、誰もが使っているであろう printf() 関数や一連の文字列関数を処理するための共通ライブラリが、常に埋め込まれます。そうすると、C言語のプログラムが沢山出来上がったときに、同じ処理を行う共通ライブラリが、あちこちに存在することになります。

これはファイル容量の増大につながり、ディスクの無駄使いに思えます(フロッピー・ディスクを使っている時代はそうでした!)。また、共通ライブラリの中にバグが見つかった場合、C言語で開発したすべてのプログラムを、再度、コンパイル&リンクし直さなければなりません。そこで考え出されたのが、共通ライブラリを別ファイルの DLL にする方法です。DLL は、ダイナミック・リンキング・ライブラリの略で、実行時に、動的に EXE とくっついて動くライブラリという意味です。

今では、ランタイムを EXE に埋め込まず、別ファイルの DLL として配布する方法が一般的です。そして、C言語で開発されたプログラムは非常に多いため、Windows OS には、最初からC言語用のランタイムがインストールされています。ゆえに、エンドユーザが意識してC言語環境(C言語用のランタイムの DLL)を導入しなくても、C言語で開発されたプログラムは動きます。

たとえば、みなさんの Windows PC で、コントロールパネルの「プログラムと機能」を開くと、Microsoft Visual C++ 2013 Redistributable(x64) といったライブラリが見つかるでしょう。

これに対して、Ruby で開発したプログラムを利用する人は少ないので、Windows に標準では入っていません。通常は、利用者が明示的に Ruby のランタイム環境をインストールすることになります。

以上のことを整理しますと、「C言語は実行環境が不要だけれど、Ruby は必要」なのではなく、C言語の実行環境(DLL)は、最初から OS に入っているということになります。

■テーマ2に対する回答
一般に、C言語がコンパイラ言語であるのに対し、Ruby はインタプリタ言語です(インタプリタのC言語というのも、昔ありました)。インタプリタ言語を実行するときは、インタプリタがプログラムのソースコードを逐一解釈しながら実行する。だから、インタプリタ言語は、コンパイラ言語に比べて速度の面で遅いと言われます。

しかし、細かいことを言いますと、インタプリタは、プログラムの実行に合わせて、毎回毎回、if 文や while 文の文字列を解析して実行している訳ではありません。私は、Java で独自のスクリプト言語(インタプリタの言語処理系)を開発したことがありますが、ソースコードを解析するのは、最初の一度だけです。ソースコードを解析したら、それを効率よく実行するための Tree 構造(木構造)の特殊なデータに展開します。その後、その解析後のデータを使って、プログラムに記述されていた処理をスタートします。

最近のインタプリタ言語は、ソースコードを解析した後の Tree 構造のデータ(Ruby ではバイトコードと呼ぶようです)をいったん別ファイルに出力し、その後、そのファイルをインタプリタ・プログラム本体が読み込んで、実行するようになっているようです。

C言語が、「EXE」と「ランタイム DLL」の組み合わせで動くのに対し、Ruby は Ruby コンパイラが出力した「バイトコード」とバイトコードを読んで実行できる「バーチャルマシン(VM)」の組み合わせで動きます。ここで、EXE は機械語(CPU が直接実行できる命令)になっているのに対し、バイトコードは、直接 CPU が実行することはできません。バイトコードと CPU の間にバーチャルマシンが立って、両者の間で通訳しながらプログラムを実行している感じになります。

以上のように、C言語で組んだプログラムを実行するにはランタイム(DLL)が、Ruby で組んだプログラムを実行するにはバーチャルマシン(VM)が必要です。しかし、両者の仕組みには、いろいろと違いがあるという訳です。

投稿2019/08/28 12:30

MakotoHirai

総合スコア12

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/29 05:26

ありがとうございます。
guest

0

答えは単純で、c言語はコンパイルして
実行形式にして、それを動かすという一連の環境を、多くのos、cpuが対応しているからです。
rubyの場合、スクリプト言語なので、実行中に実行形式に変換していくため専用の実行環境が必要なのですが、そうした実行環境は多くのosではアディショナルな位置付けでデフォルトでは対応がない。だから一手間加えないと動かない。

歴史的にc言語は枯れた方式ですし、そもそも各osの成立時にc言語は主流の言語だったからとか、rubyは実行環境の更新が比較的多いからとか、その辺りがこの状況を生み出しているのだと思います。

投稿2019/08/27 21:06

duleuze

総合スコア16

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 23:33

ありがとうございます。
guest

0

まだまだ、続いていますね。

C言語がほとんどの環境で実行できる理由を知りたいのですが

  1. C言語用のコンパイラが、ほとんどの環境で用意されているから。
  2. C言語でコンパイルされたファイルを実行する環境がほとんどの環境で用意されているから、、、。

でしょう。
ただ、2. に関しては、C言語でコンパイルされた結果の実行形式というよりは、それぞれのOSの実行形式にコンパイルされる、というのが正しいかもしれません。

もっと、荒っぽく言えば、C言語がメジャーなコンピュータ用言語なので、多くの処理系(OSとか、、)がサポートしてるってのが正しい。

ただし、当然ながら、Windowsでコンパイルした実行ファイルは、Linuxでは動きません。また、Windows用のC言語で書かれたソースが全て Linuxでコンパイル/実行できるわけではありません。逆も同様。誤解無きように。

投稿2019/08/27 11:57

pepperleaf

総合スコア6383

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 18:29

ありがとうございます。
guest

0

もう誰も見てないかな...
多くの回答がありますが、少し足りていないように思います。
質問はつまるところ2つと理解しています。
(1) > C言語はなぜ非C言語環境下でも動かせるのでしょうか?
(2) > C言語はほとんどの環境下で動かすことができると書いてあるのですがなぜでしょうか?

(1)ついてはgvcさんの答えがズバリですね。気になるのは(2)に対する回答が十分ではないことです(tknakamuriさんとthkanaさんがそれぞれ同じ理由をひとつを述べているのみ)。直接的な答えはtknakamuriさんが述べているようにいろいろなアーキテクチャに対応したコンパイラがあるからで、さらに深くつっこんだ回答としてなぜそのような多様なコンパイラが用意されているか、なぜCが様々な環境で利用されているかなどの、Cが普及した歴史的な経緯や利点をもっと説明しても良いのではないでしょうか(gccやunix開発言語などなどについて)。ただ私はガチ素人なので説明できる知識ありませんが(^q^)。

投稿2019/08/27 08:45

tamako38

総合スコア14

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 08:59

ありがとうございます。 もう誰も見てないかな... >今日いきなりたくさんの回答がつきました。
impepc

2019/08/28 12:59

> (2) > C言語はほとんどの環境下で動かすことができると書いてあるのですがなぜでしょうか? これ書きたかったけど、忘れてたのでここにコメントします。 C言語の動作環境が多いのはC言語の仕様が他の言語に比べて仕様が簡単でゆるい部分があるからです(動作環境を作る人に委任されている部分が大きい)。 C言語はクラスやラムダ式のような高度な機能はありませんし、機能自体少ないです。また、機械言語に近いので実装しやすいです(私は無理ですけど) そんな訳で、C言語向けの環境が作りやすく、一度作ってしまうとその上で動くプログラムやOSが多いこともあり、まずはC言語のプログラムが動く環境が作られると思います。
kazuyakazuya

2019/08/29 06:38

ありがとうございます。
guest

0

>C言語はなぜ非C言語環境下でも動かせるのでしょうか?

>もちろん、Ruby実行環境を用意しないと
>Rubyコードを実行できない。

Ruby実行環境にRubyコードでプログラミング実行

>ただ、記事を見ているとC言語は
>ほとんどの環境下で動かすことができると書いてあるのですがなぜでしょうか?

非C言語環境下とは、C言語コンパイラーがない環境の事ですね

C言語は、C言語コードでプログラミングし
C言語コンパイル(C言語コードを実行環境のcpuやosで実行できるコードへ変換)し実行可能コードを書き出します

その 実行可能コードを
互換性のあるcpuやosへコーピーする事で実行できます
Ruby等のインタプリタ言語はその言語の実行環境をインストールする必要がありますが
C言語は、稼働させてい環境のCPUやOS、デバイスをターゲットにプログラミングしているからです

説明になっていますか?
自分のコードがどんな仕組みで動くのか知りたいですよね

投稿2019/08/27 01:01

編集2019/08/27 01:05
gvc

総合スコア23

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/27 02:11

ありがとうございます。
guest

0

元々C言語は UNIXというOSを出来るだけCPUに依存せずに書き、
異なるCPUへの移植を容易にするために作られた言語。

そのため言語仕様がとても小さく、様々なCPU用のCコンパイラを作るのが
他の言語に比べて容易なんです。

ただ標準ライブラリまでフル装備の移植はそんなにないはず。

投稿2019/08/26 23:44

tknakamuri

総合スコア56

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Zuishin

2019/08/27 00:20

https://ja.wikipedia.org/wiki/C%E8%A8%80%E8%AA%9E#%E8%AA%95%E7%94%9F > ちなみに、「UNIXを開発するためにC言語が作り出された」と言われることがあるが、「The Development of the C Language」によると、これは正しくなく、経緯は以下の通りである。 > C言語は、当初はあくまでもOS上で動くユーティリティを作成する目的で作り出されたものであり、OSのカーネルを記述するために使われるようになるのは後の展開である。 標準ライブラリもたいていフル装備されているんじゃないでしょうか。
tknakamuri

2019/08/28 13:34

リッチー氏の原文はお読みになられました? 既にBの段階からUNIXのrewriteが目的のひとつだったことが わかりますよ。 それから、Cは組み込み系の開発言語としてろくにOSもない沢山のCPU上で 広く使われてます。当然フル実装のライブラリは実装不能です。
Zuishin

2019/08/28 13:56

> 開発者達は、コンパイラなどのユーティリティを「システムプログラム」と呼んでいたが、それらの作成に使われる「システムプログラミング言語」は、OSのカーネルを作成するための言語という意味ではない https://www.bell-labs.com/usr/dmr/www/hist.html ということですが、Wikipedia に間違いがあるなら正しておいてください。 原文を読んだかどうか聞く場合は、原文のどこでそう判断されたのか引用お願いします。 それから、組み込み OS の開発はクロスコンパイルだと思いますが、標準ライブラリが無いというのはどういう意味でしょうか? 単に開発に使わなかったというだけではありませんか?
pepperleaf

2019/08/28 14:27

> 組み込み OS の開発はクロスコンパイルだと思いますが、標準ライブラリが無い この部分は、確かにあると思います。組込みの種類によっては、標準入出力が無い場合、てのは結構あります。(もっともサンプル提供があったりするが) ただ、それ以外はちょっと疑問。PDP-7は、当時としても、pureなマシンなんで、(初期の)C言語みたいな高級アセンブラじゃないと、実装が大変だったとか、移植性なんて、当時、本気で考えるほどの情報があったか?
Zuishin

2019/08/28 14:36 編集

あ、標準ライブラリの件、理解しました。C コンパイラに付属の標準ライブラリが無いということではなく、ターゲット用のライブラリが無いことがあるということですね。回答を読んで、コンパイラの話かと思っていました。
tknakamuri

2019/08/28 15:15

リッチーの文の骨子はこんなかんじ。 超訳ですが。 ①Multicsの野心的な目的のひとつはOSを高級言語で記述することだった。 ②BはOSとコーティリティの記述には結局向かないと判断された。 ③1973年 OSの書き換えに足るCが完成したが 1972年の構造体のない初期版でシステムコードがかき始められた。 ④OSの書き換えで我々は自信を深め、コーティリテイとツールの書き換えも開始した。 以上です。
Zuishin

2019/08/28 15:20

いやだから、オレオレ要約ではなく、どこを翻訳してそうなったか引用し、Wikipedia が間違っていると思ったなら、書き直してきてください。
Zuishin

2019/08/28 15:21

> UNIXの開発当初、Multicsプロジェクトが目指していた高級言語によるOSの開発という目標は見送られた。
guest

0

でも、どちらもコンパイル作業が実行されるのは
プログラム実行命令が出された後なのだから

違います。
細かいことは抜きにして、C言語はプログラム実行命令が出されたら機械語が直接実行されます。
事前にコンパイルし機械語を生成するためプログラム(ソースファイル)は実行時には不要です。

投稿2019/08/23 07:44

Y.H.

総合スコア7914

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kazuyakazuya

2019/08/23 07:48

ありがとうございます。
Y.H.

2019/08/30 00:35

低評価を入れた方へ ・低評価の理由をコメントにてお教えください。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問