アカウント名:
パスワード:
今の状況では，Cを使う機会はないんですが，死ねとは思わないなあ。まあ，最近の緩い言語の型システムでCを使うとイタイ目にあうことは確かだけど，言語の違いと特色みたいなもんだからなあ・・・原始的なプログラム作るには，Cが一番だと思うけどなあ。早いし。まあ，使わないけどｗ
企業の裏で動きながら、山ほど飛んでくる電文をひたすら処理してるUNIXのシステムとか…
そういう所だと、パフォーマンスの話は定期的に聞こえてくるので、無難な所でCを選んでるんでしょう。無難になる理由の中には、人を集めやすいってのもあると思いますが。
それと、昨今はメモリをたっぷり積むことができるので、新しいシステムではメモリテーブルを使って云々…となったとき逆にCを選ぶ理由になるんじゃないかな？と思っています。Cじゃなくてもできるじゃねーかと突っ込まれるかもしれないけど、別にCでいいんじゃね？Cは30年以上前から有るけど、たぶん30年後もどっかで生きてるよ
カーネルや言語処理系にC言語が必要な箇所があるというのは重々承知ですが、もうちょっとC言語以外で書けるところは別のもので書けたら楽になるんじゃないかなぁと思います。yaccやANTLRといったパーサジェネレータというのはそういう考え方なんでしょうけど
Cは、高級アセンブラと呼ばれていましたね。（それもPDP-11用の）C++が世に出たとき、Cを置き換えるのがC++だ ってジョークもありましたが。
ちょいっとライブラリに細工して特定の条件（速度重視でオプティマイズとか）時に、関数内の変数の特定バイト目に、別の変数内容を書き込んだりさせたりするの。それにより特定演出パターン番号時に大当たり確率を上げたり下げたりするのに便利。ソース調べても解らんしそれを実行してもあちらはデバッグオプション付けてテストするから同じ状況には成らない。長時間試験ならトータルでは確率内に収まるしな。
> 何のせいで毎月のようにWindowsやらさまざまなアプリやらのパッチを当てさせられているのか認識していますか?少なくともC言語のせいではないんじゃない？
新しい言語に変えればパッチを当てずに済むようになるなら、MSの膨大な人的リソースを使って、とっくに書きなおしてるでしょ。何時までもメンテナンスするよりコストも削減できるのでは？
> 少なくともC言語のせいではないんじゃない？C言語以外にバッファオーバーフローやらformatバグやらで割り当ててもいないメモリに書き込み放題の高級言語ってありましたっけ?
> 新しい言語に変えればパッチを当てずに済むようになるなら、> MSの膨大な人的リソースを使って、とっくに書きなおしてるでしょ。ええ、とっくに書きなおしていますよ。.NET Frameworkと呼ばれています。
> C言語以外にバッファオーバーフローやらformatバグやらで割り当ててもいないメモリに書き込み放題の高級言語ってありましたっけ?「C++」は置いといて、インタプリタやVMで動く処理系でも、バッファオーバーフローしたときに適切な例外処理をしなければ問題になりますよ。高級言語だからパッチが必要ないという結論にはなりませんよね。
>ええ、とっくに書きなおしていますよ。.NET Frameworkと呼ばれています。今のWindowsが.NET Frameworkの上で動いているか知らないけど、.NET Framework上でWindowsが動いているなら>>>何のせいで毎月のようにWindowsやらさまざまなアプリやらのパッチを当てさせられているのか認識していますか?↑はC言語の問題ではないですよね。
.NET FrameworkはWindowsのコードと関係ないのであれば、・C言語以外にWindowsとしての要件（互換性とか？パフォーマンスとか？移植コストも？）を満たす処理系がない。・C言語以外で書きなおしても大して変わらない。あたりが理由で今でもC言語を使ってる判断なんでしょうから、C言語を責めるのはお門違いかと。
やっぱりWindowsやアプリケーションがパッチだらけなのは、C言語の問題じゃないと私は思います。
> バッファオーバーフローしたときに適切な例外処理をしなければ強制終了するだけです。任意コードの実行などにはつながりません。MSも単なるDoS攻撃は緊急パッチの対象にはしていません。.NET Frameworkとそれ以外のコードに対するセキュリティパッチの数を数えても、安全性の違いは歴然としています。> 今のWindowsが.NET Frameworkの上で動いているか知らないけど、Windows Vistaでやろうとしていたようですが見事に失敗したようです。>>> MSの膨大な人的リソースを使って、というのはMSを買いかぶりすぎってことです。ちなみにAppleも(Obj-
何のせいで毎月のようにWindowsやらさまざまなアプリやらのパッチを当てさせられているのか認識していますか?
んだもん、MSのせいに決まっとろうが！
ドライバやらなんやらもC#で書けるようにしてやるぜー！って言ったけど、「やっぱむり」って言ったのＭＳじゃね？
ドライバをバイナリではなくソースで配布し、ドライバのインストール時あるいは起動時にコンパイルする、っていうのはどうよ。適切にコーディングされていれば、x86でしかテストしてなくてもARMでも問題なく動くって。
つ【DKMS】
しかし、バイナリでしか配布されてないものが混ざってると駄目なのであった。しかも、エンディアンやバスタイミングやキャッシュの取り方に代表されるプロセッサ毎の「些細な」違いでデバッグする羽目になるのでした＿|￣|●
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:2)
今の状況では，Cを使う機会はないんですが，
死ねとは思わないなあ。
まあ，最近の緩い言語の型システムでCを使うとイタイ目にあうことは確かだけど，
言語の違いと特色みたいなもんだからなあ・・・
原始的なプログラム作るには，Cが一番だと思うけどなあ。早いし。
まあ，使わないけどｗ
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1)
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1)
企業の裏で動きながら、山ほど飛んでくる電文をひたすら処理してるUNIXのシステムとか…
そういう所だと、パフォーマンスの話は定期的に聞こえてくるので、無難な所でCを選んでるんでしょう。
無難になる理由の中には、人を集めやすいってのもあると思いますが。
それと、昨今はメモリをたっぷり積むことができるので、
新しいシステムではメモリテーブルを使って云々…となったとき
逆にCを選ぶ理由になるんじゃないかな？と思っています。
Cじゃなくてもできるじゃねーかと突っ込まれるかもしれないけど、
別にCでいいんじゃね？
Cは30年以上前から有るけど、たぶん30年後もどっかで生きてるよ
Re: (スコア:0)
カーネルや言語処理系にC言語が必要な箇所があるというのは重々承知ですが、
もうちょっとC言語以外で書けるところは別のもので書けたら楽になるんじゃないかなぁと思います。
yaccやANTLRといったパーサジェネレータというのはそういう考え方なんでしょうけど
K&Rの時代から (スコア:1)
Cは、高級アセンブラと呼ばれていましたね。（それもPDP-11用の）
C++が世に出たとき、Cを置き換えるのがC++だ ってジョークもありましたが。
Cじゃないとやり辛いんだよな (スコア:0)
ちょいっとライブラリに細工して特定の条件（速度重視でオプティマイズとか）時に、関数内の変数の特定バイト目に、別の変数内容を書き込んだりさせたりするの。
それにより特定演出パターン番号時に大当たり確率を上げたり下げたりするのに便利。
ソース調べても解らんしそれを実行してもあちらはデバッグオプション付けてテストするから同じ状況には成らない。
長時間試験ならトータルでは確率内に収まるしな。
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1)
> 何のせいで毎月のようにWindowsやらさまざまなアプリやらのパッチを当てさせられているのか認識していますか?
少なくともC言語のせいではないんじゃない？
新しい言語に変えればパッチを当てずに済むようになるなら、
MSの膨大な人的リソースを使って、とっくに書きなおしてるでしょ。
何時までもメンテナンスするよりコストも削減できるのでは？
Re: (スコア:0)
> 少なくともC言語のせいではないんじゃない？
C言語以外にバッファオーバーフローやらformatバグやらで割り当ててもいないメモリに書き込み放題の高級言語ってありましたっけ?
> 新しい言語に変えればパッチを当てずに済むようになるなら、
> MSの膨大な人的リソースを使って、とっくに書きなおしてるでしょ。
ええ、とっくに書きなおしていますよ。.NET Frameworkと呼ばれています。
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1)
> C言語以外にバッファオーバーフローやらformatバグやらで割り当ててもいないメモリに書き込み放題の高級言語ってありましたっけ?
「C++」は置いといて、
インタプリタやVMで動く処理系でも、バッファオーバーフローしたときに適切な例外処理をしなければ問題になりますよ。
高級言語だからパッチが必要ないという結論にはなりませんよね。
>ええ、とっくに書きなおしていますよ。.NET Frameworkと呼ばれています。
今のWindowsが.NET Frameworkの上で動いているか知らないけど、
.NET Framework上でWindowsが動いているなら
>>>何のせいで毎月のようにWindowsやらさまざまなアプリやらのパッチを当てさせられているのか認識していますか?
↑はC言語の問題ではないですよね。
.NET FrameworkはWindowsのコードと関係ないのであれば、
・C言語以外にWindowsとしての要件（互換性とか？パフォーマンスとか？移植コストも？）を満たす処理系がない。
・C言語以外で書きなおしても大して変わらない。
あたりが理由で今でもC言語を使ってる判断なんでしょうから、C言語を責めるのはお門違いかと。
やっぱりWindowsやアプリケーションがパッチだらけなのは、C言語の問題じゃないと私は思います。
Re: (スコア:0)
> .NET Framework上でWindowsが動いているなら
.NET FrameworkはJavaの実行環境と同様、Windowsの上で動くランタイムです。
Re: (スコア:0)
> バッファオーバーフローしたときに適切な例外処理をしなければ
強制終了するだけです。任意コードの実行などにはつながりません。MSも単なるDoS攻撃は緊急パッチの対象にはしていません。
.NET Frameworkとそれ以外のコードに対するセキュリティパッチの数を数えても、安全性の違いは歴然としています。
> 今のWindowsが.NET Frameworkの上で動いているか知らないけど、
Windows Vistaでやろうとしていたようですが見事に失敗したようです。
>>> MSの膨大な人的リソースを使って、
というのはMSを買いかぶりすぎってことです。ちなみにAppleも(Obj-
Re: (スコア:0)
デスクトップで使うアプリケーションに限ると、あまり聞いたことがない気がする。
Re: (スコア:0)
うちの会社は数百人の規模で業務システムをあれこれ作ってますが、今は.NET(C#)とJavaが7:3くらいです。
(古いシステムを保守する案件では一部C、C++、COBOLにVBもありますが)
.NETの生産性・保守性は高いです。
DB接続や画面周りを中心に有用な部品が多いので以前ならガリガリ書いていたコードがわずか数行で実現できたりしますし、フレームワークやコーディング規約を固めておけば出てくるコードはブレることもなく(勿論レビューもしています)、開発メンバーがプロジェクト間を渡り歩いても戸惑わずに済みます。
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1, おもしろおかしい)
んだもん、MSのせいに決まっとろうが！
Re: (スコア:0)
ドライバやらなんやらもC#で書けるようにしてやるぜー！
って言ったけど、「やっぱむり」って言ったの
ＭＳじゃね？
Re: (スコア:0)
ドライバをバイナリではなくソースで配布し、ドライバのインストール時あるいは起動時にコンパイルする、っていうのはどうよ。
適切にコーディングされていれば、x86でしかテストしてなくてもARMでも問題なく動くって。
--
FreeBSDのIA64版では、書いた本人がIA64でテストしていないドライバも平然と動いてましたよ。
Re:まあ，現代のアセンブラ言語みたいなもんやね。 (スコア:1)
つ【DKMS】
しかし、バイナリでしか配布されてないものが混ざってると駄目なのであった。
しかも、エンディアンやバスタイミングやキャッシュの取り方に代表されるプロセッサ毎の「些細な」違いでデバッグする羽目になるのでした＿|￣|●