アカウント名:
パスワード:
Java から C へ移ったわけではないと思いますよ。
Web アプリを書くのに Java 以外の言語の利用が増えていたり、Java でもフレームワークの普及で開発規模が抑えられるようになっていたりで、動員される人数が減っていても不思議じゃないですね。ターゲットが Windows サーバ方面だと、C# と .Net Framework に移ったところもあるようです。
組み込みではアセンブリ言語から C 言語への移行がようやく落ち着いてきた感じなので、当分は C が廃れることはないでしょう。asm イメージが描ける Portable Assembler としての C ですから、代替できる言語がないのです。
価格がこなれてきて、今まで、コンパイラの使用を想定していないアーキテクチャの組込みプロセッサを採用していた分野にまで、それなりのプロセッサがおりてきたっていうことじゃないでしょうか?
本当に高機能が必要ない部分にまではおりてこないでしょうが、他社の製品との差別化のためにプロセッサを少し高性能なものにして、ソフトウェアで機能を追加するっていう分野は増えてるんじゃないでしょうか?
> 世の中のデファクトがCになってしまっているから、非技術的な理由で他の言語はどうやっても受け入れられないだけ
それは今回C言語が「返り咲いた」理由としてはおかしいと思いますよ?ずっと1位だった理由というなら納得がいきますが……
門外漢なのでよく分からないのですが、実質としてプログラム込みの単機能の部品扱いではないのですか?
Microchip の PIC10 系列 RAM 16 ~ 24 bytesRenesas 4203 1 word が 4 bits で RAM が 64 wordsTexas Instruments TMS370 RAM 128 bytes ~
かなり胡散臭い(と言うか何というか)使い方しないと駄目ですけど、処理ルーチンをC文法で記述する事は今でも出来るのでは…?アセンブラでガシガシ書くよりはソースコードの可読性が上がってデバッグが楽になる…筈。但し、制約条件を外れると動かないコードになったりコンパイルが破綻したりしますが…
# まぁ、頭が最適化されてたらアセンブラに勝る物はないのですが、# 比較的複雑な制御シーケンスを最初からアセンブラで記述するような時代でもない気がする。てか、もうやりたくない…
ワークRAMの大きい小さいは瑣末な事でしょう…スタックが使えない(><)とか言っても、ごくごく小さなRAM領域のマップを抽象化したり定数やミドルウェア的な部品化されたサブルーチンの類を多数(あくまでも比較的)リンクしてROMに焼き込む方が数段ややこしい訳で(デバッグ工程では特に)。
そういう用途に、C言語というのは本来的には使いやすい筈なんですけどね。(実際、15年近く前の某国内大手マイコンメーカでは、4bit MPUにたいしてCスタイルの開発環境を用意してはいた…タダでも高価な開発環境の某社の中でも突出して高価なので、アセンブラしか使ったことはありませんでしたが)今時はGCCのようなリッチ過ぎる仕様の物が主流なのでわかりにくいかもしれませんが。
ユーザ側です。startup code 以外もっぱら C なんですが、生成コードを意識するために、プロジェクト初期に asm 出力してチェックしてます。以下のような C ソースで asm 生成コードを確認して所要クロックを数えるのはお約束です。
unsigned short cond;if (cond) hoge();if (cond!=0) hoge();if (!!cond) hoge();
あと、コンパイラの更新で生成されるコードサイズが変わってしまい、EEPROM に収める配置を見直す事態になって泣きつかれたこともあります。
C というより Macro Assembler を使ってる気分。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
意外な結果 (スコア:0)
逆に、JavaScriptやPL/SQLなどのように、一般的に使われていると思い込んでいた言語が、さっぱり不人気なのはもっと驚いた。
世間様はCでWebアプリを作ったり、日次バッチ処理を作っていたりするんだろうか?
Re:意外な結果 (スコア:1, 興味深い)
Java から C へ移ったわけではないと思いますよ。
Web アプリを書くのに Java 以外の言語の利用が増えていたり、Java でもフレームワークの普及で開発規模が抑えられるようになっていたりで、動員される人数が減っていても不思議じゃないですね。
ターゲットが Windows サーバ方面だと、C# と .Net Framework に移ったところもあるようです。
組み込みではアセンブリ言語から C 言語への移行がようやく落ち着いてきた感じなので、当分は C が廃れることはないでしょう。
asm イメージが描ける Portable Assembler としての C ですから、代替できる言語がないのです。
Re: (スコア:0)
Re:意外な結果 (スコア:1)
私の高校時代にはCの勉強をするために、コンパイラの吐くasmを見たものだが...。
当時はオプティマイズなんて全然出来てなかったので、どういうプログラムを書くとどういうコードが出るかよく分ったんだよね。
ところで、-O2ではなく-O0 (すなわちオプションなし)の方が良くない?
小さい関数だとstack frameの生成がなくなるから-O2の方が分りやすいということかな?
Best regards, でぃーすけ
Re: (スコア:0)
世の中にはそもそもコンパイラの使用を想定していないアーキテクチャとメモリ容量の組込プロセッサがまだまだたくさんあるのですが...........
大昔からターゲットと用途に応じてアセンブラが適していればアセンブラを、C言語が適していればC言語を使ってますよ
>>asm イメージが描ける Portable Assembler としての C ですから、代替できる言語がないのです。
んなぁこたぁ~ない
世の中のデファクトがCになってしまっているから、非技術的な理由で他の言語はどうやっても受け入れられないだけ
俺はCしか出来ないとか(あるいはRuby最高・他の言語は知らないとか、Javaしかやったことが無いとか)いうプログラマが多いのよ
そんな連中を再教育する手間を費用を考えてくれ!
Re:意外な結果 (スコア:2, 興味深い)
価格がこなれてきて、今まで、コンパイラの使用を想定していないアーキテクチャの
組込みプロセッサを採用していた分野にまで、それなりのプロセッサがおりてきた
っていうことじゃないでしょうか?
本当に高機能が必要ない部分にまではおりてこないでしょうが、
他社の製品との差別化のためにプロセッサを少し高性能なものにして、
ソフトウェアで機能を追加するっていう分野は増えてるんじゃないでしょうか?
Re:意外な結果 (スコア:1)
> 世の中のデファクトがCになってしまっているから、非技術的な理由で他の言語はどうやっても受け入れられないだけ
それは今回C言語が「返り咲いた」理由としてはおかしいと思いますよ?
ずっと1位だった理由というなら納得がいきますが……
Re: (スコア:0)
煽りじゃなくて本当に興味があるんで教えて欲しいんだけど、
たとえばどのプロセッサ?
Re:意外な結果 (スコア:3, 興味深い)
RAM 16 ~ 24 bytes
Renesas 4203
1 word が 4 bits で
RAM が 64 words
Texas Instruments TMS370
RAM 128 bytes ~
Re:意外な結果 (スコア:1)
門外漢なのでよく分からないのですが、実質としてプログラム込みの単機能の部品扱いではないのですか?
Re: (スコア:0)
BASE言語とかDOH-Cとか…_| ̄|○(Re:意外な結果 (スコア:1)
かなり胡散臭い(と言うか何というか)使い方しないと駄目ですけど、処理ルーチンをC文法で記述する事は今でも出来るのでは…?
アセンブラでガシガシ書くよりはソースコードの可読性が上がってデバッグが楽になる…筈。但し、制約条件を外れると動かないコードになったりコンパイルが破綻したりしますが…
# まぁ、頭が最適化されてたらアセンブラに勝る物はないのですが、
# 比較的複雑な制御シーケンスを最初からアセンブラで記述するような時代でもない気がする。てか、もうやりたくない…
ワークRAMの大きい小さいは瑣末な事でしょう…スタックが使えない(><)とか言っても、ごくごく小さなRAM領域のマップを抽象化したり定数やミドルウェア的な部品化されたサブルーチンの類を多数(あくまでも比較的)リンクしてROMに焼き込む方が数段ややこしい訳で(デバッグ工程では特に)。
そういう用途に、C言語というのは本来的には使いやすい筈なんですけどね。(実際、15年近く前の某国内大手マイコンメーカでは、4bit MPUにたいしてCスタイルの開発環境を用意してはいた…タダでも高価な開発環境の某社の中でも突出して高価なので、アセンブラしか使ったことはありませんでしたが)
今時はGCCのようなリッチ過ぎる仕様の物が主流なのでわかりにくいかもしれませんが。
Re: (スコア:0)
プログラムの工数も比較にならないから,PICなどのマイクロコントローラが生み出すプログラムの需要は小さいと思う.
もちろん,プログラミング言語の人気がニーズに一致しているとは限らないけど.
Re: (スコア:0)
各社割拠している8-16bitマイコンのPIC単独とARMの天下の32bitを比べちゃ…
最近は8bitクラスでもC使うけどね。
Re: (スコア:0)
16bit以上なら10年以上前にC言語が主流になっている感じだが。
# オレは供給側
Re:意外な結果 (スコア:2, 参考になる)
ユーザ側です。
startup code 以外もっぱら C なんですが、生成コードを意識するために、プロジェクト初期に asm 出力してチェックしてます。
以下のような C ソースで asm 生成コードを確認して所要クロックを数えるのはお約束です。
unsigned short cond;
if (cond) hoge();
if (cond!=0) hoge();
if (!!cond) hoge();
あと、コンパイラの更新で生成されるコードサイズが変わってしまい、
EEPROM に収める配置を見直す事態になって泣きつかれたこともあります。
C というより Macro Assembler を使ってる気分。