【訃報】C言語およびＵＮＩＸの父、デニス・リッチーさんが死去 -享年７０★５

Cが普及した理由の一つが、言語仕様で扱う範囲を小さくしたってことだろうな。
I/Oや数値計算といった基本的な機能も、標準はあるけどあくまでライブラリとして扱うことで
標準が使えないような環境にも適応できるようになってる。

LispやCは規格が決まる前の方が楽しかった

ポインタは、インスタンスを作らずにただオブジェクトを代入するとオブジェクトのように
ふるまう変数として扱えてしまい、オブジェクトではなくてクラスのようなものなのに、
そこらへんの区別が文法的にあまり明確じゃないし実に粗末な仕様の言語だよ

Cは元々オブジェクト指向言語じゃないし

＞オブジェクトではなくてクラスのようなものなのに
どういうこと？多分Java使いなんだろうけど・・・
C++使いの俺からするとクラスは型、オブジェクトはそのインスタンスと捉えてるから、
あんたの言いたいことがよくわからない、もうちょっと詳しく説明もらえるかな

OOPを盲信するあまり、何でもOOPで解釈しようとする奴っているよね

ぶっちゃけC/C++でポインタの理解に挫折してからJavaに行った人じゃないかと思うけどね
多分C++/Javaにおいて、クラスのメソッド呼び出しや参照からのアクセスが内部でどういうコードになるか
全く想像が出来ないんだろうな、内部的にはアドレス呼び出しによる間接アクセス無くては計算機は動かないというのに

逆にC++に挫折したC使いがC++のOOを、知りもせずに嘘八百で否定するのも簡便願いたいんだが、
ここで言うことではないか

>>336
ああ、あったな。すっかり忘れてた。
でもそれだと結局単語をつなげるたびに毎回
a++;b++,a--;って3ステップも余分な処理が入るんじゃないの。

ああでもよく考えたら
while(*a++=*b++); a--; の方は最後に a++;b++;a--;が余分だけど
while(*b) *a++=*b++; 最初に *b != '\0' の判断が余分なのか。
差し引き2ステップ？

まあわかるような差はでないなｗｗ

歩行珍煙は逮捕でいいよ

よくわからんが、高速に文字列の連結とかしたいのであれば、それに、適したデータ構造つくればいいんでないの？
実体へのポインタと長さか、実体へのポインタと終端へのポインタとかｗ
あと連結操作時に実体を移動、コピーしなくていいようにリンクリストつけとくとかw
頻繁に追加削除があるのか、生成のみなのか目的によって最適解は変わってくるが、cなら自由自在、おまいら得意だろw

今の世の中、「小手先の速い」は不要で
それよりも「安全・確実」が求められていると思う
（forとかwhileとかも全部展開して、1本糞のようなプログラムが一番速いのは当然）

どうせ周辺機器とかネットとか、大半待ち時間なわけだし、
速さの追求は「もっと高い次元のアルゴリズムの改良」で

>>361
今の世の中ってひとくくりにするのはすごいな。
適材適所でしよ。
同じプログラムのなかでさえ、安全可読性重視と速度重視を使い分けるやつもいるよ。

カアニはんはお元気どすか？

蟹飯のコメント有った？

>>362
その通り
未だにC/C++のプログラミング多く、他の言語に置き換わらないのは需要があるから
速度の速いプログラムが求められる分野が非常に多い
ゲーム、組み込み系、通信・マルチメディアなどはC/C++から他の言語に移ることはあり得ないと
言っていいくらい安定した需要がある

Web系のように速度をあまり必要としないものにはCを採用する理由はない
C/C++以外の言語（例えばJava,C#,rubyなど）が出てきても、未だにシェアがNo.1で
揺るぎないのは何故かを考えればいい

あるいはこう考えてもいい

速度の必要としている分野は広範囲に存在する
だが、アセンブラではメンテナンスが大変だ
したがって、アセンブラの代替品としてC/C++を利用する

カーニはんは元気なのか？

>>365
c/c++？
cのみだろ。

安易にc/c++と書くのってどうなの？
特にこのスレで。
リッチーはC言語の父であって
c++は関係ない。
むしろ、リッチーの盟友がやってる
goというシステムプログラミング言語があるんだから、
c/goならまだわかる。

>>368
cとgoはだいぶ違うでしょ…

しかしgoもいまだにフリーフォーマット言語なのが解せぬ。

>>368
トンプソンの B 言語があって、リッチーの C だからね。
C(4) -> go(5) で、語呂も合ってるし。正統な後継者だな。

でも、B が普及しなかったように、普及するためには、go の次世代言語の登場が必要かな。

＞C(4) -> go(5) で、語呂も合ってる
え？／(^o^)＼

C++は他のオブジェクト指向言語の登場で、
利用者数が世界的に減少傾向にあるね。
コンパイル最適化が難しく、Cほど低レベルでなく、
JAVAやC#ほどRADでなく…マシンの進化とコンピュータのコモディティ化で
何でもできるマルチパラダイムがだんだんアダに。

古い原著から．．．

main()
{
　printf("hellow, ");
　printf("world");
　printf("\n");
}

で、
main()
{
　while(1)
　{
　　xxxx();
　}
}

この文がビギナーをことごとく駄目にしてきた。
時間のスライス表現の無い教科書をバイブルとしてきたことに問題有り！
UNIＸ創生者なのに、ディスパッチャーを彷彿とさせる表現にしなかったのはペケ！

>>370
goで書いたOSが普及すればいいんだよ。

Linuxのつぎがそれだ。
そしてまだ誰もやってないが、
Googleあたりが作ってるかも。

まあなんていうか昨今OOPだから
若い奴はそこで思考停止してる自分が認識できてないだけだろうね。

>>361
アルゴリズムを詳しく扱っている本ってあまり書店では見かけないような…
「車輪を再発明するな」というのは仕事の効率や能率の上では正しいのかも知れないけど
巧妙なアルゴリズムは、先人の知恵と工夫の結晶なんだよね。
中身を知らずに成果だけ使っているのは何か寂しい。

K&RがCのバイブルなら、The Art Of Computer Programmingはアルゴリズムのバイブル。
いつかは買い揃えたいと思っているのだが…

>>375
今はデザパタだったり、得たい機能が最初からあったりするから不要になったと思われ。
構造化プログラミング時代の本を漁るしかない。

デザインパターン　=　かつおぶし

間違ってはいないけど、袋に入ったフレークの由来に
想いを馳せれなければ、そこで道の終わり。

>>377
職人の道としてはそれが正しいと思うけど、
今はその「フレーク」より前を考えないのが流行り、主流だと思ってる。
単純な「フレーク」ならその辺に転がってるのを使うだけ。

>>376
プログラミングという枠組みじゃなくて、工学という枠組みで見れば今でもアルゴリズムは有用だよ。
専門的になりすぎて、一般的なプログラマが扱う範囲を超えてるとは思うけどね。

デザインパターンとアルゴリズムは別物だが。

アルゴリズム？
真っ当なプログラムを書くなら今でも必要だろ。

でも今はそんなアルゴリズムよりイベントドリブンで入ってきたパラメータを
処理する手合いのプログラムが多いことは確かだ。

誰も書き込まなくなったな
このスレもＣんと静まり返っている

誰にレスするでもないけど、
「うまいアルゴリズム」と
「ちょっと気の利いたコードの書き方」とが、
混同されてる感じはあるよね。
つか、もともとシームレスなもんかも知れんけど

そういう意味では、たとえば>>381後半の
パラメタの仕分けなんかも、アルゴリズムっちゃ
アルゴリズムかと。

>>379
同意。

今時は、プログラミングその物が目的じゃなくなってるから
そういう意味ではパクれる物を素早くパクって目的を達成した方が良いと思われ。

プログラミングその物が目的なら、より効率的なアルゴリズムの追求や、
コードの短縮化や小容量化で楽しめば良い。

昔はソートのアルゴリズムとか定番だったけど、
今はSTLだったり、メソッドで提供されるから話題にもならない。

それでもたまに基本的なアルゴリズムを自前で組むような場面はあって。

まぁソート機能くらいならネットを参考にすればすぐ組めるんだけど、
なんでバブルソートなんか参考にするんだよってのはよくある。
しかも、この道10年のプロとかで。

>>385
この道10年とドヤ顔する事と、クイックソートは関係無いと思われｗ

>>384
個人的には、その「パクれる物を素早くパクって」って言い方、日本人プログラマの悪いとこだと思うんだよなぁ
誰か、あるいは先人がフリーでアイデアやコードを公開してくれたからこそ、知恵を借りられるわけで。

じゃあどういう言い方すべきかってーと、「ぐぐれ」「車輪の再発明をしない」とかかな
今は目的も多様化されてるし専門外のことをやることも多いから、
細かいテクニックにこだわるより「必要な情報を調べて見つけ出す能力」の方が大事だ
ただその一方で、こだわる場面ではこだわって、また可能な範囲で知識を独占せず公開していくことも
日本のIT業界の発展には必要だと思う

全然分野の違うことなのに比較しても仕方がないだろ。
アルゴリズムに精通してる人が、長期的な保守性や可変性を考慮した
ソフトウェアアーキテクチャなどに精通してるとは限らない。

あと他人が既に作ったものは遠慮なく使わせてもらえばいい。
全部自分で作るやつなんていないだろう。ＣＰＵから全て自分で生産しないだろ。

アルゴリズムだって自分で編み出すよりも、普通はすでにあるものを使うはず。
それがコピペだろうと自分でコードを組むのだろうと、
クイックソートやバブルソートのアルゴリズム自体は既成の発明品だろ。
クイックソートやバブルソートを再発明しても仕方ないだろ。

結局すべてパクリでいいんだよ

実績があるものを使う方が
「最新」より安心だから。

25年前にc言語とアセンブラの組み合わせをマスターできたことが今の自分につながっている。

その後、何社か渡り歩いて、直接のソフト開発からは離れたけど、比較的楽な仕事で年収４桁万円をキープできて、子供も二人育てられた。

K&R本も含めて大量の技術書は実家の一部屋においてあるが、子供には迷惑をかけたくないので、いずれ処分するつもり。
でも、K&R本や初期のMacTutorなど捨てられない本は、いつか読み直すために、いずれ自炊する予定。

dmrさん、c言語をつくってくれてありがとう。

プログラミングも韓流だよね。

>>391
もちろんそのとおりです。K&RのKはKoreaのことです。

>>368
C++はCのスーパーセット
元々Cにオブジェクト指向の機能を持たせようという
目的で作られた言語だから、Cから派生したjavaなどとは
ちがって、Cとしても使える

言語としては異なるが、リッチーの作ったCを完全に
含んでいるし、「より良いC」という位置づけもある

C++プログラマにとってはこういういい方は面白くないのかもしれないが、
C++はCの部分が無くなれば価値のない言語になるのも事実

>>389
パクリは悪くない
だが、パクった内容を理解できなければ意味がない

例えていうなら、

「幾何学で証明する必要はない。だが証明する能力は必要である」

みたいな物だな
「三平方の定理を証明する必要はなくても、証明する能力は必要みたいな感じ

プログラミングで言えば、「人の作ったプログラムをコピペ」するのではなく、
「真似て自分で作れる」能力は必要
そういう意味でならパクリは大いにすべきだろう

三平方の定理ぐらいなら証明できていいかもしれんが、
もっと高度な数学になったら、利用するだけでもいい。

あらゆる分野をマスターするのは不可能だよ。

コンピューターを利用するのに、CPUの細かい挙動なんて知らなくていいのと同じ。
そんなものアセンブリや機械語でプログラムできるやつでも完全に理解してないだろ。

もちろん全てを理解する必要はない
本当にそれをやろうとしたら、チップの中の電子回路まで理解しなければならなくなる

だからと言って、イベントドリブンなプログラムをパーツで組み合わせるだけの能力だけで
プログラミングの全てを語ることも出来ないだろう

耳鼻科の医者がすい臓の知識を一切勉強しなくてもいいということがないように
ある程度の知識は必要になる

更に言えば、丸暗記した知識というのは応用が効かない
理解した知識は柔軟に対応するのに役立つ

分野にもよるよね
ウチは計測機器の開発やってるから、ソフト部隊といえど
回路図みてオシロあてたり、ロジアナでタイミングみたりはできてほしい
ソフトを組む上でのハードの不具合は、あたりぐらいはつけられるのが望ましい

アマゾンだFacebookだって世界で一番上のレイヤーばかり取り上げられるからハードとソフトが一緒に進む組み込みとか制御を知らない層がいるのもしょうがない
そういう人は下のレイヤーは完全なんだから知る必要が無いと思ってしまう