09/08/22 06:46:30
C/C++が早いというのは誤解
URLﾘﾝｸ(scienceblogs.com)
370:デフォルトの名無しさん
09/08/22 07:11:18
コードも出さないでベンチ結果だけ貼る馬鹿の記事を真に受けて貼る馬鹿
371:デフォルトの名無しさん
09/08/22 07:58:09
C/C++の構文的な不満は、多次元配列と配列の配列が同じ表現ということぐらいかな
372:デフォルトの名無しさん
09/08/22 08:05:05
俺は基本的にCにどっぷり浸かっちゃってるから別に不便とまでは行かないな。
他の言語を使ったらこんなに簡単にできるのかってのはあるだろうけど、
やっぱりCが自由度が高いからその点だけでこの先ずっと生き残ってくれればいい。
373:デフォルトの名無しさん
09/08/22 08:15:41
うむ。
Cに代わる高級アセンブリ言語が出ないうちはCは死なん。
使ってて面白いのはCだな。
374:デフォルトの名無しさん
09/08/22 09:30:52
いやだから、死なないのは悪いことだろ。
老害なんだからさぁ
375:デフォルトの名無しさん
09/08/22 09:38:38
組み込み機器とかの開発もCで可能かが1つの選択基準になる。
やはりgccの存在が大きい。業界標準言語としての地位は揺るぎようがない。
>>374は何使ってるんだい？
376:デフォルトの名無しさん
09/08/22 12:20:43
>>371
377:デフォルトの名無しさん
09/08/22 14:03:11
取り合えず会話に参加したかった初心者さんだよ、きっとｗ
378:デフォルトの名無しさん
09/08/22 14:40:36
>>369
OCamlなんで早いん？
FORTRANみたいに配列をベクトル化してしまってるの？
379:,,・´∀｀・,,）っ-○○○
09/08/22 15:20:50
SIMD化っぽいね
ICCで-fastオプション使ったらええんちゃうの
380:デフォルトの名無しさん
09/08/22 15:27:27
それよりも、CとC++でなんであんなに差が出るのかがわからない。
CってC++に無い高速化機能とかあったっけ？
381:デフォルトの名無しさん
09/08/22 15:27:34
OCamlだけ気になるな。
他はまぁ理屈は分かるし、それ結局今んとこ全然速くないから、ってオチなんだけど、
OCamlは単純にコンパイラが優秀そうな気がする。
まぁ、C++がCより極端に遅いところを見ると、何も考えないコードを書いた場合の
ベンチだろ。つまり、速度が本気で欲しい時の比較じゃない。
C/C++との速度競争はアセンブラとの速度競争にほぼ等しい。
アセンブラが速度競争で負けるとしたら、ランタイム最適化くらいしか無い。Java
みたいな奴。もちろんランタイム最適化もアセンブラで書けるけど、そこまで言い出す
と反則だしな。
ただ、動的最適化を含むVM機構そのもののオーバーヘッドが痛い。長時間走るような
コードほど有利だが、そんな重いコードを底辺コーダーが何も考えずに書くような
状況では有利、ってことだろ。まさにそこのブログがそれをやったんだろうけど。
382:,,・´∀｀・,,）っ-○○○
09/08/22 15:31:52
>>380
逆じゃね？STLとか、たとえばvectorコンテナにイテレータでアクセスとか使ってるんじゃないの？
あれがCスタイル配列より早い理屈は無い
383:デフォルトの名無しさん
09/08/22 15:36:45
MPLできっちり最適化されてれば同等にはなりそうだが、まぁやってないライブラリが
ほとんどだろうな今んとこ
384:デフォルトの名無しさん
09/08/22 15:42:47
vectorはMPLで頑張ってもCの配列と同等は無理だな。
arrayならCの配列より早くなる。
ライブラリ作者は死ぬ。
385:デフォルトの名無しさん
09/08/22 17:22:16
最近はコレクション使う事がプログラミングだと勘違いしてるバカ多すぎ
386:デフォルトの名無しさん
09/08/22 17:31:44
まずは意味が明確に通じる文章を書けるようになってくれ
387:デフォルトの名無しさん
09/08/22 17:34:02
ゆとりの俺にはクラスライブラリという積み木を使って、
なんか組み立てるって認識しかないな。
388:デフォルトの名無しさん
09/08/22 17:36:34
その論法なら大抵の物作りは積み木レベルだな
389:デフォルトの名無しさん
09/08/22 17:36:37
コレクションという概念を理解できない老害よりはましだろう。
390:デフォルトの名無しさん
09/08/22 17:41:36
なんでもかんでもforでまわすことしか思いつかないんだよな。
391:デフォルトの名無しさん
09/08/22 17:42:43
積み木遊びなめんな
代数学や論理の基礎を養う大事な訓練なんだぞアレは
392:デフォルトの名無しさん
09/08/22 17:51:06
だったら家や学校でやれ
393:デフォルトの名無しさん
09/08/22 18:05:44
理解してないものを上から目線で駄目出ししようとする老害の典型だな
394:デフォルトの名無しさん
09/08/22 18:29:02
なにこの流れｗ
395:デフォルトの名無しさん
09/08/23 04:01:33
>>391
aho hakken
396:デフォルトの名無しさん
09/08/23 06:16:14
>>395
まさか御大がこんなところで遊んでるわけないだろ。
397:デフォルトの名無しさん
09/08/23 06:57:50
Aho氏が積み木を推奨してるスレはここですか。
398:デフォルトの名無しさん
09/08/23 16:08:19
やっぱRubyだな。
399:デフォルトの名無しさん
09/08/23 16:13:08
Ruby儲は口出すな
趣味言語と同様に扱われては困る
400:デフォルトの名無しさん
09/08/23 16:20:21
Ruby on Railsはやってんだろ
旧時代の石頭乙
401:デフォルトの名無しさん
09/08/23 16:32:31
流行ってたのは２年前だな。
402:デフォルトの名無しさん
09/08/23 18:16:53
Cについて語ってるのに、いちいち信仰言語を提示する人はなんなの
403:デフォルトの名無しさん
09/08/23 18:21:04
信者
404:デフォルトの名無しさん
09/08/23 22:04:28
落ちまくりの糞Railsとかいつの話だよ
結局実用にならないことが分かって大半は逃亡済みだろ
405:デフォルトの名無しさん
09/08/23 22:43:21
>>324
え？じゃあこんなコード、C++で動くの？
foo();foo(bar)int bar;{return bar;}main(){int new = 0;return foo(new);}
406:デフォルトの名無しさん
09/08/23 23:02:03
それただの揚げ足取りじゃね
407:デフォルトの名無しさん
09/08/23 23:06:32
PS1の上位互換なPS2だって、PS1のゲームすべてが遊べるわけじゃないし。
408:,,・´∀｀・,,）っ-○○○
09/08/23 23:17:57
PS3に相当する言語ってあるかな？
途中で下位互換無くなっちゃったような
409:デフォルトの名無しさん
09/08/23 23:24:19
>>406
実際、全くの手直しなしで動くか、若干の手直しが必要かは結構でかい違いだぞ。
さすがに古い引数の書き方なんてのは、今時殆どないし、変数名が予約語ってのも、機械的に置換すりゃいい話だし、
プロトタイプ宣言の型が省略されてるのも、ちょっと工夫すりゃ置換できそうだが、
型チェックが厳格化されたのは、結構面倒だと思うよ。
今までがいい加減だったといえばそれまでなんだけど、無駄に厳格だ。
410:デフォルトの名無しさん
09/08/23 23:32:51
型検査はC++でようやく常識的なレベルになったと思う
少なくとも無駄に厳格というほどではない
411:,,・´∀｀・,,）っ-○○○
09/08/23 23:33:19
現行規格のプロトタイプ宣言はC++から逆輸入されたんだよな
412:デフォルトの名無しさん
09/08/24 00:26:19
C++位に型チェック厳しくないと、逆に怖いんだが。
413:デフォルトの名無しさん
09/08/24 01:53:08
gccとかオプションでいくらでもできるだろ
414:デフォルトの名無しさん
09/08/24 04:34:48
大抵はCとしてコンパイルすりゃ通るだろうに
新しく書くコードでも「C++だけで引っ掛かるんだよな」なんてことが多発するなら
お前が珍種なだけ
415:,,・´∀｀・,,）っ-○○○
09/08/24 04:44:11
extern "C"
416:デフォルトの名無しさん
09/08/24 05:10:01
団子夏休み
417:デフォルトの名無しさん
09/08/24 06:00:03
C以外も使える >>> Cしか出来ない >>>越えられない壁>>> Cが使えない
418:デフォルトの名無しさん
09/08/24 06:09:10
C++が複雑な言語であるのは事実だけど、
進化はゆっくりしているから
のんびり学んでいればいつかは理解できるときが来る。
急速な進化を繰り返すC#は
立ち止まったその瞬間にもう使えなくなる。
419:デフォルトの名無しさん
09/08/24 06:10:15
古いソースのまま新しいコンパイラ通せるからそれはない。
次期標準候補、次期標準、標準が混沌としてるほうがついていきにくいよ。tr、boostとか
420:デフォルトの名無しさん
09/08/24 06:11:13
みなさん今でもC++のみで直接Windowsアプリケーションを作ってますか？
それともC#とC++併用でGUIとコア部分を書き分けて作ったりしてますか？
421:,,・´∀｀・,,）っ-○○○
09/08/24 07:18:09
GUIはHTML+CSS+Javascript
鯖サイドはRailsだったりPHPだったりJavaだったりC#だったりします。
Web屋でごめんね。
でも日曜C++プログラマです。
GUIはWTL
422:デフォルトの名無しさん
09/08/24 07:56:13
あんた色んなスレでみかけるもんな
423:デフォルトの名無しさん
09/08/24 09:51:03
C厨のマヌケっぷりがよくわかるスレ
424:デフォルトの名無しさん
09/08/24 11:58:46
むしろアンチのほうがマヌケ
425:デフォルトの名無しさん
09/08/24 15:24:55
自分はスクリーンセーバを作るときに
大部分をVB 2005で作り、浮動小数点画像の演算だけを
VC 2005でSSEを使って作っていた。
426:デフォルトの名無しさん
09/08/24 15:35:28
色々使ったが、今ではほぼC++オンリー
ごく簡単な処理は、その時にコードの浮かんだLLで
427:デフォルトの名無しさん
09/08/24 20:01:42
2Kbyteに収まるようなプログラムを書くときなんかはやっぱCかな
428:デフォルトの名無しさん
09/08/25 09:18:09
ゆっくり進化していってね！
429:デフォルトの名無しさん
09/08/26 01:42:03
HSP最強説
430:デフォルトの名無しさん
09/08/26 01:49:08
C言語はASCIIを扱うことを前提に設計されている。
SJISやEUC、UNICODEとなると、もうお手上げで、
簡単な言語処理プログラムさえ、ポインタ計算が面倒くさすぎて
やりたくなくなる。
明らかに欠陥言語と言えるだろう。日本語的に。
431:デフォルトの名無しさん
09/08/26 01:59:06
430に欠陥が・・
432:デフォルトの名無しさん
09/08/26 02:00:26
たとえば、
C言語は糞！C言語はダメです！絶対！
と言う文があった場合、
C言語は善！C言語はイイです！絶対！
に変えるには、５文字目と１１～１２文字目を置換しなければならない。
しかし、C言語という単語にはASCIIとSJIS、またはEUC、またはUNICODE、
UNICODEでも8BIT、16BIT、32BITがある。
それぞれポインタ演算が異なり、ポインタ位置がズレる。
こういう下らない処理に脳を使うだけアホ。
単純な配列処理ですら、最初に8BIT前提に初期化するか、16BITか、32BITかと頭を悩ませる。
バッファーオーバーフローは無いだろうか、改行文字の処理系はどうする、処理速度は、メモリ量は、
色々考えなきゃならない。
日本中でこれが繰り返されている。
どれだけの経済損失が発生しているのだろうか。
どう見ても糞です。
433:デフォルトの名無しさん
09/08/26 02:03:37
You are light !
434:デフォルトの名無しさん
09/08/26 02:05:55
>>432
それはライブラリの問題だね。
言語の問題じゃない。
435:デフォルトの名無しさん
09/08/26 02:34:20
>>432
で、それらを気にしないでいい言語は何？
C++なら基本的にそこに書かれてる問題ほとんど全部気にしないで済む上に、ほとんどの
処理系の中で最速の部類だけど。
つーか文字列処理にいちいち処理速度だのメモリ効率だのを煮詰める必要のある案件自体
少ないけどな。煮詰めたい案件ならそれこそC/C++を選ぶし。
436:デフォルトの名無しさん
09/08/26 03:06:52
>>432
生まれた国を間違えたようだな
リセットすればいい
437:デフォルトの名無しさん
09/08/26 03:11:55
つーかポインタ演算そのものは同じコードだよな
Cが基本的に分かってないだけじゃねーかｗ
438:デフォルトの名無しさん
09/08/26 03:25:43
>435
推奨のエンコーディングがUnicodeか何かに決まってる言語がなかったっけ？
439:デフォルトの名無しさん
09/08/26 04:32:04
推奨の文字コードセットが決まってたら>>432が解決するの？
440:デフォルトの名無しさん
09/08/26 05:17:19
文字コードの問題はC固有の事例であり、C以外の言語に乗り換えれば
全て解決されるというのなら>>432の主張も一理ある
実際にはそんなわけないんだが
441:デフォルトの名無しさん
09/08/26 06:17:31
何か根本的に、どの言語でもASCIIもSJISもEUCもUCS-2もISO-2022-JPもEBCDICも
扱えるし、必要なら扱わざるを得ない、ってことを分かってないんじゃ。C言語だけが
色々文字コードがあると思ってるとか。
あとUTFとか普通はC/C++の文字列置換とかで直接触らないし。ストリームの状態で
吐き出すブツでしょう。だから、8-bitがある、というのもおかしい。
で、ポインタ演算はどれも同じだし。ポインタへの加減算は、中身のサイズを自動的に
掛けるんですよ。常識以前の常識。ポインタも使えずに諦めた人にしか見えない。
処理速度だのメモリだの心配するなら他の言語なんかほとんど使えなくなるし。
バッファオーバーフローのとこだけ書けばボロも出なかったかもね。
442:デフォルトの名無しさん
09/08/26 09:14:18
長い文章書くとボロが出る典型的な例
443:デフォルトの名無しさん
09/08/26 10:35:50
モダンな言語なら、文字列は文字のシーケンスであって、バイト列ではないからな。
その辺り、Cの古臭さは否めない。
ライブラリで解決できる話だと思うんだが、標準的な手法は無いのかな？
444:デフォルトの名無しさん
09/08/26 10:41:28
今だとUNICODEに変換して扱うって手順じゃないかなぁ
445:デフォルトの名無しさん
09/08/26 11:27:38
>>434
一々ライブラリを使わなきゃならない時点でウンコだなｗ
標準で文字すら加工できない時点でウンコ。
446:デフォルトの名無しさん
09/08/26 11:34:30
プログラミングWindows第5版には
Unicodeは65536文字も格納できるから、世界中のすべての文字を十分扱えるんだぜ！
って書かれていて（p.51）、おいおいって思ったよ＾＾
ところで、msdnにはマルチバイト文字を扱うと処理速度が落ちると書かれている。
あと、オライリーのC++ランゲージリファレンスには、ロケール関連の関数は遅いので、
文字コードの変換はなるべくまとめて（バッファリングするなどして）やったほうがいいと書かれている。
文字コードを統一しないのには速度重視という側面もあるのかしら。
447:デフォルトの名無しさん
09/08/26 11:34:32
アホだなぁ。
たとえば、これと似たような処理を１０００回とか１０万回同時並行で繰り返す
あるいは再帰する場合、初期のバッファが何バイトかで相当速度が変わってくる。
使用するメモリ量も変わってくるし、処理時間も変わってくるからな。
さらにこの処理を何百とこなす事になれば（ｒｙ
というわけで、速度を気にしない奴はニワカを晒してる訳でｗ
448:デフォルトの名無しさん
09/08/26 11:43:44
大体、アメリカ製の言語は糞なんだよ。
言語は8bit！アルファベットは26文字！大小合わせて52文字！それだけありゃ十分だ！
8bitで脳内を固定して、全ての文字は8bitの倍数で組んでおけば良いんだ！
みたいな設計だから、16bitになると途端にエラーが連発する。
作ってる奴の脳がダメ。そういうのを許可している言語自体がダメ。
というか、基本設計が8bitで、
「あ？16bitも使えるようにしときゃ良いんだろ？ま、俺はつかわねーし。苦労しててもｼﾗﾈ」
って態度がそもそもな。
だから、文字の長さを調べる関数に8bit固定発想で8の倍数掛けときゃイイや的なコードが
入り込んだりする。その時点でもうダメ。
449:デフォルトの名無しさん
09/08/26 11:52:04
文字列クラスがあるLL使えばいいじゃんよ
なんでC言語で全部やろうとするかなぁ
450:デフォルトの名無しさん
09/08/26 13:27:05
そういや、英単語列クラスってないのかなあ
451:デフォルトの名無しさん
09/08/26 13:30:30
>>450
vector<string>でも使っとけ
452:デフォルトの名無しさん
09/08/26 13:38:19
!
| 丶 ＿ .,! ヽ
> ｀`‐.｀ヽ、 .|、 |
ﾞ'． ,ト ｀i､ ｀i､ .､″
| .,.:/"" ﾞ‐,. ｀ /
` .,-''ヽ"｀ ヽ,,,、 !
､,､‐'ﾞl‐、 .丿 : ':、
､/ヽヽ‐ヽ､;,,,,,,,,,-.ッ:''｀ .,"-、
,r"ﾂぃ丶 ｀｀｀｀｀｀ ..／ ｀i､
,.ｲ:､ヽ／ー｀-､-ヽヽヽ､－´ .lﾞ｀-、
_,,lﾞ-:ヽ,;､、 ､､丶 ﾞi､,,、
,<_ l_ヽ冫｀'｀-､;,,,､､､､.............,,,,､.-｀": │ ｀i､
､､::|､､､ヽ,､､. ｀｀｀: : : ｀｀｀ ､.､'｀ .|丶、
.l","ヽ､,"､,"'､ぃ､､,､､、、.、、、.、、､_､.,,．ヽ´ lﾞ ﾞ).._
,､':ﾞl:､､｀:ヽ､｀:､ : ｀"｀｀｀￢―'''"｀ﾞ＾｀ : ..､丶 .lﾞ ｀ヽ
,i´.､ヽ".､".､"'ヽヽ;,:､........、 ､､...,,,､－‘｀ ､‐ |ﾞﾞ:‐,
,.-l,i´.､".`ヽ,,,.".｀ ｀ﾞﾞ'"｀'-ｰ"｀｀"｀｀r-ｰ｀'": _.‐′ 丿 ,!
j".､'ヽ,".､".､"`''｀ｰ､._､、、 、._,、..-‐:'''′ .､,:" 丿
ﾞl,"`"`''ヽヽ"`"｀ ｀｀｀ﾞ'''"ヽ∠、､、､ぃ-｀''''": ｀ ､._.／｀ ._/｀
｀'ｉ｀ヽヽヽ｀''ｰi､､、: : 、.,-‐'｀ 、／｀
｀`ヽン'`"｀ : ｀~｀｀―ヽ::,,,,,,,,,,.....................,,,,．ー'｀｀＾ ,､‐'"｀
`"'ﾞ―-､,,,,..､、 : ..,､ー'"'｀
: ｀‘"｀―---------‐ヽ｀｀"''''''""
453:デフォルトの名無しさん
09/08/26 13:42:19
>>445
コード系を一切考慮しないで文字を直接操作できる言語ってなによ
454:デフォルトの名無しさん
09/08/26 13:46:39
!
| 丶 ＿ .,! ヽ
> ｀`‐.｀ヽ、 .|、 |
ﾞ'． ,ト ｀i､ ｀i､ .､″
| .,.:/"" ﾞ‐,. ｀ /
` .,-''ヽ"｀ ヽ,,,、 !
､,､‐'ﾞl‐、 .丿 : ':、
､/ヽヽ‐ヽ､;,,,,,,,,,-.ッ:''｀ .,"-、
,r"ﾂぃ丶 ｀｀｀｀｀｀ ..／ ｀i､
,.ｲ:､ヽ／ー｀-､-ヽヽヽ､－´ .lﾞ｀-、
_,,lﾞ-:ヽ,;､、 ､､丶 ﾞi､,,、
,<_ l_ヽ冫｀'｀-､;,,,､､､､.............,,,,､.-｀": │ ｀i､
､､::|､､､ヽ,､､. ｀｀｀: : : ｀｀｀ ､.､'｀ .|丶、
.l","ヽ､,"､,"'､ぃ､､,､､、、.、、、.、、､_､.,,．ヽ´ lﾞ ﾞ).._
,､':ﾞl:､､｀:ヽ､｀:､ : ｀"｀｀｀￢―'''"｀ﾞ＾｀ : ..､丶 .lﾞ ｀ヽ
,i´.､ヽ".､".､"'ヽヽ;,:､........、 ､､...,,,､－‘｀ ､‐ |ﾞﾞ:‐,
,.-l,i´.､".`ヽ,,,.".｀ ｀ﾞﾞ'"｀'-ｰ"｀｀"｀｀r-ｰ｀'": _.‐′ 丿 ,!
j".､'ヽ,".､".､"`''｀ｰ､._､、、 、._,、..-‐:'''′ .､,:" 丿
ﾞl,"`"`''ヽヽ"`"｀ ｀｀｀ﾞ'''"ヽ∠、､、､ぃ-｀''''": ｀ ､._.／｀ ._/｀
｀'ｉ｀ヽヽヽ｀''ｰi､､、: : 、.,-‐'｀ 、／｀
｀`ヽン'`"｀ : ｀~｀｀―ヽ::,,,,,,,,,,.....................,,,,．ー'｀｀＾ ,､‐'"｀
`"'ﾞ―-､,,,,..､、 : ..,､ー'"'｀
: ｀‘"｀―---------‐ヽ｀｀"''''''""
455:デフォルトの名無しさん
09/08/26 14:50:30
サロゲートペアとかCP932固有の文字とか
まったく気にしないで使える言語ってあるの？
456:デフォルトの名無しさん
09/08/26 15:00:30
UTF-8
457:デフォルトの名無しさん
09/08/26 15:33:07
UTF-8が標準の言語なら問題ないってことか～
でも文字コードの変換は必要なはずだし、変換上の問題をも意識せず・・・
って、この辺は言語の話じゃないかもしれない
458:デフォルトの名無しさん
09/08/26 15:57:44
言語の問題じゃない、って >>434 の時点で言われてんのに
引っ張るような話じゃねぇな。
459:デフォルトの名無しさん
09/08/26 16:38:01
str型は標準機能なので、それで日本語を使えないという時点で既に馬鹿にしてるよ。
普通に扱うと漢字が真っ二つに割れる。
どうしようもない欠陥言語。
460:デフォルトの名無しさん
09/08/26 16:51:20
>>459
>str型
アホには使えない言語ですｗ
461:デフォルトの名無しさん
09/08/26 17:41:17
つーか>>430が大本なのか。あまりにバカすぎて記憶から抜け落ちてたわ。
文字コードが糞みたいな仕様なのは、Cのせいでも何でもないよ。「DirectXが初心者に
扱えないのはC/C++のせい」ってくらい的外れ。
文字コードの厄介な問題を気にしなくていいように見える言語が稀にあるけど、それは
Cで自前で書いてる処理を言語側が勝手にくっつけてくれるだけなので、処理速度でCが
劣るって話じゃないよ。
それを理解した上で、そういう糞みたいな文字コードの仕様を気にしない言語じゃなきゃ
駄目ってことなら、C/C++は使うな。ただし処理速度を口にする権利は無くなります。
C++はstd::wstringでいいなら気楽なもんだけど、>>430みたいなアホには他の部分で
扱えないだろうから間違ってもお勧めしない。
つーかこのスレ、アホだから使えません、って話ばっかじゃねーか。
462:京大生
09/08/26 19:27:47
東大の教養で学ぶ言語はRuby
東京大学教養課程の第一プログラミング言語がRubyに - sumiiの日記
URLﾘﾝｸ(d.hatena.ne.jp)
東大の電気系ではPythonの処理系を作る授業がある。
講義資料 - PukiWiki
URLﾘﾝｸ(www.logos.ic.i.u-tokyo.ac.jp)
何この差は・・・orz
東大と京大の格差が、教育の質レベルで広がっている。ひどい。
すでに話したけど、MITはPython
京大はPythonを使うべき。Cの時代は終わった。教育になってない。
463:デフォルトの名無しさん
09/08/26 19:28:00
オレたちみたいな欠陥人間がホイホイ釣られそうなスレタイだもんな！
464:デフォルトの名無しさん
09/08/26 19:47:37
確かに学生の質が落ちたなぁ。
言語なんてなんでも良くて、アルゴリズムを実装できるアタマを養うのが基礎プログラミングだろうに。
それを言語のお勉強だと思ってるなら相当学生の質が悪いと言えようw
465:デフォルトの名無しさん
09/08/26 19:50:21
抽象的な概念をあるていど扱える言語のほうがいい、ってのは確かだな。
いきなりC言語だと、リスト構造みたいなものを教えるまでに、
教えなきゃいけないものが多すぎる。
466:デフォルトの名無しさん
09/08/26 19:57:40
京大クラスなら、CPU製作するからC言語でも大丈夫でしょ。
467:デフォルトの名無しさん
09/08/26 20:00:09
いてもたってもいられない。
京大電気系ではPythonを教えるべきだった。
そうすれば、研究室全体での作業効率は１００倍になったはずだ。Pythonの制約から、コードの可読性はあがり、平均３年というサイクルの中で、引き継ぎにかかるオーバヘッドは減らせた。
Pythonを使えば、C言語の場合より、作業効率は１０倍になり、コードの共有容易性などから、全体での作業効率は１００倍程度にはなった。
Pythonを使えば、もっと大きな成果を出せる。また、電気系全体で一緒くたになって取り組むプロジェクトも立ち上げることが出来る。
C言語を教えてるのは完全なる失敗である。C言語は仕様が簡単だし、Pythonを勉強していれば、C言語を勉強するのは簡単だ。逆はそうでもないと思う。
低レベルな言語を知っていれば、高レベルの言語は簡単に勉強出来るという人がいるが、それは嘘だと思う。
むしろ逆で、高レベルの言語を勉強していれば、その基底となっている言語を想像するのは簡単だ。
Pythonでも、組み込み関数などはかなりプリミティブだ。また、低レベル言語では、コードが汚いのが当たり前ということになってしまう。
Pythonならば、きれいなコードを書くように強制されていく。パフォーマンス的な要因で、そこからCやJavaに入っていくのは、さほど難しいことではない。
よって、入門者は高級言語を勉強するべきであり、電気系はPythonを勉強すべきなのだ。
せめて、Cのプログラミング講義とPythonのプログラミング講義の両方を用意するなどの対処があってもいい。
そこから、受講者がどのようなパスを通っていったかを見れば分かるはずだ。Pythonを学んだ学生の方が確実にコードを書くのが速く、効率よく研究が進められていたという実態が明らかになっていくはずだ。
まとめると、C言語は人類が生み出した負の遺産であり、大学など、将来豊かな人材を育てる場所では隠されるべき害悪である。
C言語は人間を育てないが、Pythonは人間を育てる。Pythonは高い作業効率を提供し、その結果、より入念な検証作業などが行える。
実験系であっても、データの処理はプログラミングを使う。そこでいかに速く出来るか、いかに柔軟に対応出来るかということがキーになる。
Pythonでのプログラミング講義を提供しない理由はどこにもない。
468:デフォルトの名無しさん
09/08/26 20:01:23
>>467
言語マターで語るとバカなのがバレるからよしたほうがいい。
469:デフォルトの名無しさん
09/08/26 20:07:15
ていうか、こんなところで語ってないで、しかるべき筋に提案しなさいよ。
470:デフォルトの名無しさん
09/08/26 20:19:06
シラバス見たけど、C入門書をなぞるだけになっちゃってるのか。
そりゃアカンわ。
昔はFortranでやってたけど、Fortranのお勉強ではなくこういうルールのゲームで強いアルゴリズムを作れとか
とりあえず、自分の考えをコンピュータで実現させてみろってのが主旨だったんだけどな。
次が数値解析の基礎だし、言語のお勉強なんてものはやらなかったんだがな。
(言語自体のお勉強は自分でせぇって感じだったけど、ユトラーには無理かなw)
471:デフォルトの名無しさん
09/08/26 20:21:37
今のゆとりの大多数は自分から進んで考えながら勉強しないからなあ
472:デフォルトの名無しさん
09/08/26 20:34:36
>>471
まあ「ゆとり」とか言ってるお前さんが受けた教育も間違いなくゆとり教育だけどな。
そんなことも知らない無知蒙昧に馬鹿にされる「ゆとり」が気の毒だわ。
っていうか、俺の経験上、無能な奴ほど若い奴を根拠なく見下すのな。
まあそれだけ不安なんだろうが、その程度の自己分析をして自分の認知的歪曲に
フィードバックをかける程度の知性もないわけだ。
473:デフォルトの名無しさん
09/08/26 20:46:20
日本語でおk
474:デフォルトの名無しさん
09/08/26 20:47:16
つまり、理詰めで議論出来なくなって、「○○で採用されてます！」を引っ張ってきた訳だ
虎の威を借る狐そのものだな
475:デフォルトの名無しさん
09/08/26 20:47:55
下らん書き込みにいちいち反応してる時点で必死さが伝わってくるなｗ
476:デフォルトの名無しさん
09/08/26 20:49:56
採用実績も何気に重要
477:デフォルトの名無しさん
09/08/26 20:57:29
そういう採用実績で言ったらC/C++の圧勝になるんだがな
Googleのシステムのコアとなる部分は全てC/C++が採用されています（必要なところ
ではJavaが、お気楽なところではPythonが採用されていて、その他の言語は基本的に
特別な許可が必要となります）
最近のOSの記述言語にはほぼ全面的にC/C++が採用されています
東大の電気系にはPythonの処理系を作る授業もあります（笑）
478:デフォルトの名無しさん
09/08/26 21:01:14
東大の電気系は情報も含むが、京大の電気系は情報工学を含まないからね。
処理系の作製みたいなのが電気になくてもむしろ当然。
479:デフォルトの名無しさん
09/08/26 23:28:14
折角λ山があるんだから京都の大学生はHaskellとかScheme使えよ
480:デフォルトの名無しさん
09/08/26 23:29:27
俺の勝手なイメージだが、工学＝C系で科学＝ML・LISP系。
純粋にアルゴリズムを学びたいならC系列はダメだな。雑音が多すぎる。
でも、ハードウェアまで絡めてやるなら、C系列しかないと思う。
481:デフォルトの名無しさん
09/08/26 23:46:00
科学系でも演算を実際に走らせる必要があるならC++までは使えるようにしておきたいな
どれか一つで一杯一杯って人は知らん
482:デフォルトの名無しさん
09/08/26 23:55:32
>>462
KMCってまだあんの？
483:デフォルトの名無しさん
09/08/26 23:56:40
文字コードっていっちゃってるが
本質的な問題はすでに出てる通り、バイト列はあるけど文字列がないことだろ
文字コードを並べたのは知ったかぶりたかっただけだと思う
484:デフォルトの名無しさん
09/08/27 00:10:18
>>480
雑音と言うのは違和感があるな。
自分で作らないといけない物が多いとは思うが。
自分で作るのが当然と思うか、誰かが作ってくれるのが当然と思うか
の違いなのか？
485:デフォルトの名無しさん
09/08/27 00:30:53
prolog使いの俺としては、お前らの議論が
とても矮小的に見える。
486:デフォルトの名無しさん
09/08/27 00:43:42
>>484
本題のレベルより低いレベルに気を使わなきゃいけないって意味で、雑音。
俺は、Cのパワーは他では出せないと思ってるけど、使うべきでない場面で使われすぎてると思ってるから。
487:デフォルトの名無しさん
09/08/27 01:41:50
>>462
OCaml使えよ
488:デフォルトの名無しさん
09/08/27 02:30:33
しかし、何でCは雑音が多いんだろ。
純粋なオブジェクト指向じゃないから？
489:デフォルトの名無しさん
09/08/27 02:39:35
>>486
その「雑音をいかに隠蔽するか」が最重要事項なんだよなｗ
本題をどこに設定するかは人それぞれだが、
雑音が多い言語から始めれば、最重要事項を最初に学べると思う。
その後は適材適所で言語を選べるようになっているはず。
490:デフォルトの名無しさん
09/08/27 02:41:03
>488
オブジェクト指向はそれほど関係ないんじゃないかな、メモリ管理が大きいと思う
それがC言語の最大の利点でもあるんだが、OSや組み込みなどはともかく
そうでない場合は雑音になってしまう
491:デフォルトの名無しさん
09/08/27 03:20:04
さすが欠陥人間が集うスレだ
492:デフォルトの名無しさん
09/08/27 03:31:31
やっぱり、Ｃはシステムプログラミング用の言語で、高度なアルゴリズムや
アプリケーションを記述するための言語じゃないね。
一応できるけど、効率は酷く悪い。
OS環境がこれだけ整備された時代で、一般的にＣやC++の生き残る領域って
かなり限られるべきなのではないかな。
493:デフォルトの名無しさん
09/08/27 03:44:34
まぁ>>220でほとんど事前に突っ込まれてるんだけどな
494:デフォルトの名無しさん
09/08/27 03:45:04
高度なアルゴリズム実装するには、メモリ直接弄れたほうが便利なわけだが。
495:デフォルトの名無しさん
09/08/27 03:47:47
はぁ？？？
496:デフォルトの名無しさん
09/08/27 03:56:10
Cはともかく、C++ほど高度なアルゴリズムを「実際に使うのに」便利な言語はあんまり
無いんじゃね？
ダックタイピングもいけます、関数型もいけます、Cにもなります、インラインアセンブラ
でもご自由に、メタプログラミングもきっちりチューリング完全です、だからなぁ。
実行時効率を無視していいなら、Lisp系は強烈だけど。
ああ、Pythonは高度なアルゴリズムには全然向いてません。
497:デフォルトの名無しさん
09/08/27 03:56:36
JavaやC++は拡張容易性という面では利があるように見えるけど、
それならPythonやRubyでも可能だよな。
スクリプト言語だからコードの隠蔽とか著作権の問題があるけど。
498:デフォルトの名無しさん
09/08/27 03:57:45
遅くていいならそれでもいいんじゃね
実際LLは楽だし
499:デフォルトの名無しさん
09/08/27 03:58:31
>>496
C++でできることは大体Rubyでもできるよ。
メモリ管理はできないけど。これってシステム領域でアルゴリズムとは関係無いし。
500:デフォルトの名無しさん
09/08/27 03:59:48
じゃC++と同じ速度をRubyで出してください
これって「かなり」需要の多い要求なんで、是非
501:デフォルトの名無しさん
09/08/27 04:01:04
何だ、ageてるのはRuby信者か。
502:デフォルトの名無しさん
09/08/27 04:08:00
チューリング完全ならできるだろうさ。やろうとすれば。
503:デフォルトの名無しさん
09/08/27 04:12:36
Rubyのライブラリ性能の問題でしょ。
言語的には、アルゴリズムを組むならRubyが最適。
ただし、C++に比べればライブラリの充実度が劣り、汎用性に問題がある。
これは時間と資力が解決する問題。
504:デフォルトの名無しさん
09/08/27 04:14:56
まつもとに聞いてこい、C++とRubyはライブラリさえ充実すれば同じ速度で走りますよね、って
是非聞いてきてくれ
505:デフォルトの名無しさん
09/08/27 04:15:39
rubyのライブラリってCじゃなかったか？
ruby自体が遅すぎるってことだよ
506:デフォルトの名無しさん
09/08/27 04:21:31
環境毎に最適化してないから遅いだけでしょ。
あと、C++がライブラリ充実してるのは、結局、ハッカーの共通言語だからなんだよな。
デファクトスタンダード、国際標準言語みたいな。
言語的にはRubyの方が優れてるのに。
507:デフォルトの名無しさん
09/08/27 04:23:53
> 環境毎に最適化してないから遅いだけでしょ。
全然違います。
そろそろ帰れよ。さすがにあまりにもバカすぎて話になんねぇから。
508:デフォルトの名無しさん
09/08/27 04:24:46
環境が最適化してないからって、rubyって何年前からある言語だよ
一体いつ最適化されるんだろうねｗ
509:デフォルトの名無しさん
09/08/27 04:32:35
なんだい。
コンパイルして中間言語でも吐き出せば良いのかい？
510:デフォルトの名無しさん
09/08/27 04:34:42
Rubyで書いてけば次第にRuby自体がボトルネックだと気づく
このage信者も数年、いや数ヶ月や数日後には使ってないんじゃないか
主張をこんなとこで繰り返すよりも使い続ける事が大事だよ
がんばってね
511:デフォルトの名無しさん
09/08/27 04:35:11
さすがにガチ信者でも引くレベルの馬鹿
512:デフォルトの名無しさん
09/08/27 04:41:51
何必死になっちゃってんの？ｗ
自然と語気が強くなってるよね？ｗ
513:デフォルトの名無しさん
09/08/27 04:43:44
顔を出してはもぐら叩きされて「必死だな」と言った瞬間にまたもぐら叩きされてるような感じ
514:デフォルトの名無しさん
09/08/27 04:54:56
ルの字も出てこなくなったらそろそろ引き際だろう
この程度の信者の次の行動パターンは予想は付くが、
まあやめた方がいい
515:デフォルトの名無しさん
09/08/27 04:55:35
釣れた釣れた、くらいなら平和でいいけどな
別にこんなスレ潰れても全く問題無いがｗ
516:デフォルトの名無しさん
09/08/27 06:22:34
RubyはCより速い（キリッ
517:デフォルトの名無しさん
09/08/27 06:42:43
>494
メモリを直接弄ることで高速になる部分だけをC/C++で書くかな、俺なら。
518:デフォルトの名無しさん
09/08/27 07:05:33
その他の部分はどの言語で？
519:,,・´∀｀・,,）っ-○○○
09/08/27 07:20:45
RubyはCで書かれたインタプリタで逐次解釈して実行するものだ
直接解釈できるマシン語を生成するC/C++そのものに実行時性能で勝てるはずがない。
> 言語的には、アルゴリズムを組むならRubyが最適。
これも無理だな。Rubyはどっちかというとアルゴリズムを「使う」側だな。
ハッシュにせよソートにせよ
リアルRailsプログラマだが何か？
520:デフォルトの名無しさん
09/08/27 09:14:07
w
521:デフォルトの名無しさん
09/08/27 10:10:40
Cのアルゴリズムって、直感的じゃないよね。
関数型のコードのほうがよっぽど分かりやすい。アルゴリズムを直接コードにしている感じ。
パフォーマンスだって悪くないし、マルチコアならなおさら。
522:デフォルトの名無しさん
09/08/27 10:25:14
CはCPUとメモリがあることを前提にアルゴリズムを実装するための言語。
523:デフォルトの名無しさん
09/08/27 10:46:32
マルチコアのCPUがあることを前提にする言語よりよっぽど直感的だね。
524:デフォルトの名無しさん
09/08/27 10:48:29
アルゴリズムをどういうレベルで実装するか、の差だな。
クイックソートをほぼ直感的に実装するなら、LLやらHaskellのほうだが、
ピボット選択や、使用するメモリ量やらをきっちりチューニングした、
きわめて高効率な実装（岩波ソフトウエア科学「アルゴリズムとデータ構造」に
出ている）を実現するには、Cみたいな低水準の言語でないとできない。
525:デフォルトの名無しさん
09/08/27 11:18:13
C/C++の雑音は技術的な雑音
PythonかRubyかHaskellかという自由度は、宗教的雑音だ
せっかく雑音を分離したのに、別の雑音が入ってるなんて
がっかりだな
526:デフォルトの名無しさん
09/08/27 11:20:26
雑音のない世界なんてないさ。
527:デフォルトの名無しさん
09/08/27 11:26:34
haskellとか純関数で配列ソートするとか
効率悪そうで吐き気がするんだけど
528:デフォルトの名無しさん
09/08/27 12:06:41
憶測で物言ってんじゃないよ
529:デフォルトの名無しさん
09/08/27 12:11:45
じゃあ、憶測でないことを証明できるデータを持ってきてください
530:デフォルトの名無しさん
09/08/27 13:43:35
>マルチコアのCPUがあることを前提にする言語
はどの言語で実装されているの？
そのOSはどの言語で実装されいるの？
とC/C++を馬鹿にしている人を見ていつも思うよ
531:デフォルトの名無しさん
09/08/27 13:48:36
>>1はポインタも理解できない欠陥人間
532:デフォルトの名無しさん
09/08/27 13:52:34
ポインタは理解できてるぞ。マルチスレッドはあまり理解してないけどな。
533:デフォルトの名無しさん
09/08/27 13:54:28
行末に；はあって欲しいんだがｗ
534:デフォルトの名無しさん
09/08/27 13:59:37
いらなくね？改行記号があるのに何故に；か？
文を繋げるときだけ何か記号的な物があればよくね？
535:デフォルトの名無しさん
09/08/27 14:33:38
流石に文末を改行にするか記号にするかはどっちもどっち
>518
適宜、その場に応じて適切な言語。または得意な言語。
536:デフォルトの名無しさん
09/08/27 14:38:15
>>534
> いらなくね？改行記号があるのに何故に；か？
> 文を繋げるときだけ何か記号的な物があればよくね？
VBの改行仕様は糞
537:デフォルトの名無しさん
09/08/27 14:39:43
そういう話は下のスレでやるといいよ
死んでるから
新C言語を作ろう
ｽﾚﾘﾝｸ(tech板)
538:デフォルトの名無しさん
09/08/27 16:31:52
というか、話戻すけど、Rubyが遅いのって、CPUの拡張命令とか
OSのAPIを使いまくって高速化してないからだろ。
実装の問題であって言語の問題じゃないと思うよ。
539:デフォルトの名無しさん
09/08/27 16:43:42
いや、Rubyは、動的にメソッドの再定義とかが可能だから、
JITコンパイルとかでカリカリの機械語に落としたりとかができない、
という、言語として、最適化に向かない面がある（Javaとかに比べて）。
ばりばり数値計算とかやるならCで書いて外部ライブラリでやってね、
ってのがrubyのデザイン。
540:デフォルトの名無しさん
09/08/27 16:57:25
Rubyは「楽しく」オブジェクト指向するのがコンセプトだから
速さを追求するために言語仕様をダーティにすることはないじゃろな。
541:デフォルトの名無しさん
09/08/27 17:14:59
素直に設計に失敗しているとは言えないRuby信者達であった。
542:デフォルトの名無しさん
09/08/27 17:18:17
>>541
インタプリタなんてそんなもんだろ。
適材適所がわからんやつがこういうスレを立てたりする。
543:デフォルトの名無しさん
09/08/27 17:20:07
適材適所という話をしてるのに信者あつかいする馬鹿ってw
544:デフォルトの名無しさん
09/08/27 17:44:39
>>539
じゃあ、インラインＣコンパイラとか組み込んだらよくね？wwww
545:デフォルトの名無しさん
09/08/27 17:49:07
あと、動的メソッドの再定義がボトルネックになるなら、
このメソッドは上書きできませんって感じのオプション、
例えば上書き禁止属性を設けてそこだけ最適化を許容するとか、
いくらでも方法論はあるよね。
今のところそういうのはないけど。
というか、Ruby自体がパフォーマンスを気にしてない感じ。
546:デフォルトの名無しさん
09/08/27 18:00:27
>>539
動的になんでもかんでも再定義できるJavaScriptでも
JITコンパイルしてる処理系(TreaseMonkeyとかV8とか)は存在しているんだけど
547:デフォルトの名無しさん
09/08/27 18:05:39
>>539 は「向かない」つってるだけで、
別に「できない」なんて言ってないようだが。
548:デフォルトの名無しさん
09/08/27 18:10:34
>>544
Javaみたいにコンパイルするタイプの処理系なら、コンパイル時に
Cコンパイルもやればいいけど、インタプリタだと実行するたびにCコードの
コンパイルもすることになる。
あと、呼び出しのオーバヘッドを考えたら（性能を気にするような処理なら）、
結局インラインで細切れにC言語化するより、まとめてモジュール単位で
C言語にしたほうがよい。
> 例えば上書き禁止属性を設けてそこだけ最適化を許容するとか、
> いくらでも方法論はあるよね。
Javaのfinalみたいな。
後付けでfinalに設定できるようにするとか、そういうことをできるように
するということになると思うけど。
549:デフォルトの名無しさん
09/08/27 18:13:40
コンピュータが現実にどうやって動いているのか、の仕組みを分からない人が頑張ると
こうなるんだなぁと思った
どうやってRubyやその他の言語が走っているのか、の仕組みをとことん勉強すれば、
やがては機械語に行き着くし、そこまで理解してないと速度や効率が語れないのは
残念ながら今の時代も同じなんだよな
まぁ、分からないのに議論するな、現実に速度が出るようになってから言え、でおｋか
550:デフォルトの名無しさん
09/08/27 18:19:59
言語仕様とかそういう側面を理解せずに機械語一辺倒の奴も痛いけどな。
551:デフォルトの名無しさん
09/08/27 18:59:36
速度を語るなら機械語の知識は必須だろ
552:デフォルトの名無しさん
09/08/27 21:32:26
>>546
V8はJITコンパイルしてるけど最適化らしい最適化はしてないらしいよ
553:デフォルトの名無しさん
09/08/27 21:37:32
>>549
話題についていけません。って言っちゃえばいいのに。
554:デフォルトの名無しさん
09/08/27 23:51:02
>>552
へぇー。それでもあれだけの速度が出るんだからすごいんだなー
本気で最適化しだしたらどうなるんだろｗ
555:デフォルトの名無しさん
09/08/28 00:08:03
コンパイル時間短縮のためかもしれないらしい
URLﾘﾝｸ(lucille.atso-net.jp)
556:デフォルトの名無しさん
09/08/28 02:38:49
このスレを流し読みしてみたら、
唐突にRubyの話題が出すヤツが定期的に現れててウケた
557:デフォルトの名無しさん
09/08/28 03:18:21
じゃここからはRubyスレって事で
558:デフォルトの名無しさん
09/08/28 05:00:04
まあ、Rubyだけが完全無欠の最強言語だしな。
559:デフォルトの名無しさん
09/08/28 05:00:58
Cでマルチスレッドのプログラミングで
ふたつのスレッドの時間的な同期をとって
同時に同じファイルを開くにはどのように書けばよいですか
560:デフォルトの名無しさん
09/08/28 05:13:13
RubyってDLLの関数を直接呼べんの？
俺の使ってる某関数型言語はいちいちCと言語側でラッパー書かないと駄目なんだけど
561:デフォルトの名無しさん
09/08/28 05:25:48
>>559
対象OSにどういった同期手段が用意されているかによる
562:デフォルトの名無しさん
09/08/28 05:35:52
どの程度同時性を求めるかにもよるし、それはつまり何のために同時でなきゃならないのか
にもよる
とりあえず他の言語でやれることは全てやれる、手間を問わないならな
563:デフォルトの名無しさん
09/08/28 05:37:43
ああ、アセンブラは無しな
564:デフォルトの名無しさん
09/08/28 08:22:20
>560
Ruby本体には無いんだが
DLLを呼ぶためのライブラリが標準であるから
それを中継すればCを弄る必要はないね
565:デフォルトの名無しさん
09/08/29 06:00:43
ルビやるくらいならハスケルやるわ
566:デフォルトの名無しさん
09/08/29 08:51:11
どうでもいいよｗ
567:デフォルトの名無しさん
09/08/29 11:14:06
そこでrubiskellですね
568:デフォルトの名無しさん
09/08/29 16:41:08
名前センスないよな
日本発なんだから紅玉でいいじゃないか
569:デフォルトの名無しさん
09/08/29 16:52:22
中国に媚売る名前はやめろよ。
570:デフォルトの名無しさん
09/08/29 17:01:27
赤旗
571:デフォルトの名無しさん
09/08/29 17:51:56
くれない
572:デフォルトの名無しさん
09/08/29 18:10:12
>>2
Cは型チェックゆる過ぎると思うんだが。
573:デフォルトの名無しさん
09/08/29 18:11:23
>>5
確かにgcc2.xの頃は。
いまバージョンいくつだっけ？
574:デフォルトの名無しさん
09/08/29 19:07:59
結局何がいいんだよ
575:デフォルトの名無しさん
09/08/29 19:23:31
ニートってのは、そういったおっさん(上がりを決め込んだおっさん)に対抗するために、自発的に始めたテロ行為なんだろ
576:デフォルトの名無しさん
09/08/29 23:13:02
信徒のいない教祖は狂人と呼ばれる
577:名無しさん＠そうだ選挙に行こう
09/08/30 13:49:26
Cのような高級アセンブラと、Rubyのような超高級言語で、言語自体の使いやすさを比べてどうする。
Ruby信者: ほんだし使えば、醤油も鰹も不要。
C信者: ほんだしは使えない場面があるが、基本的な調味料からなら何でも作ることができる。
Ruby信者: ほんだし使った方が、簡単に早く料理が出来上がるし、醤油と鰹使うよりも美味しくできた。
C信者: ほんだし使った方が美味しいのは、作ったお前が能無しだから。
C信者: まともな料理人が作れば、醤油と鰹で作った方がずっと美味しい。
C信者: ほんだしはまだしも、他の人工調味料は発売中止になったり、新しくなったりして、今までのレシピが使えなくなることがある。
C信者: それに比べて、鰹も醤油も砂糖も、今までのが全く手に入らなくなる心配はほとんどない。
Ruby信者: 調味料入れる順番なんぞ、料理の本質ではない。「さしすせそ」とか、自分でそうする必要がない。
Ruby信者: ちょっと、だし使いたいだけなのにわざわざ湯沸かして鰹節から煮出してしないといけないなんて、実際に使うのに現実的じゃない。
C信者: そういうのも含めて料理だし、それをきちっとやっている料理は全然味が違う。
578:名無しさん＠そうだ選挙に行こう
09/08/30 14:03:59
C信者：俺のプログラム能力最高。コンパイラの最適化とか目じゃないし、ライブラリ製作者とかカス以下。
579:名無しさん＠そうだ選挙に行こう
09/08/30 14:05:32
Ruby信者：強力な言語仕様のおかげで工期を短く出来た。余った時間は勉強に充てよう。
580:名無しさん＠そうだ選挙に行こう
09/08/30 14:06:10
C信者：RubyはC言語で書かれているんだからガタガタ抜かすな
581:名無しさん＠そうだ選挙に行こう
09/08/30 14:09:43
俺：今の所Cのが面白いねん後々Rubyも勉強しようと思ってるからほっといてくれ
582:名無しさん＠そうだ選挙に行こう
09/08/30 14:24:59
Ruby信者：強力な言語仕様のおかげで工期を短く出来た。余った時間は2chに充てよう。
583:名無しさん＠そうだ選挙に行こう
09/08/30 15:10:49
Ruby信者：強力な言語仕様のおかげで工期を短く出来た。余った時間はﾓﾙﾓﾝﾅﾑﾅﾑ
584:名無しさん＠そうだ選挙に行こう
09/08/30 16:56:56
>>577
うまい例えだ。
Ruby信者をWindows信者に、C信者をUNIX信者に置き換えても違和感ないな。
585:名無しさん＠そうだ選挙に行こう
09/08/30 16:57:06
あれ？やっぱ最強なんじゃね？ｗ
586:名無しさん＠そうだ選挙に行こう
09/08/30 17:10:04
>>578
C信者を騙った知ったか君
587:名無しさん＠そうだ選挙に行こう
09/08/30 17:14:15
最強はアセンブラだろ
588:名無しさん＠そうだ選挙に行こう
09/08/30 17:22:43
厨房が好きな単語 「最強」
589:名無しさん＠そうだ選挙に行こう
09/08/30 17:24:12
そういえば最近「最強」って言葉使ってないな。厨房から片足くらいは抜け出せたかな
590:名無しさん＠そうだ選挙に行こう
09/08/30 17:30:28
アセンブラでちまちまFPUを叩くのはなかなか面白いよ
Cの標準関数よりかなり速い速度が出るし
ただしわざわざアセンブラを立ち上げるのは面倒なので
Cのソースの中で __asm で使ってる
591:名無しさん＠そうだ選挙に行こう
09/08/30 18:24:53
欠陥人間が必死に自己弁護するスレですねわかります
592:デフォルトの名無しさん
09/08/30 20:29:09
デバイス制御にC、アプリケーションにRubyを使っているので両方必要。どちらも素晴らしい。
593:デフォルトの名無しさん
09/08/31 03:50:39
アプリは正直Rubyである必要は全く無いな
以上、Cを称えるフリをしてドサクサにRuby（笑）を持ち上げるという
擁護失敗レスでした
594:デフォルトの名無しさん
09/08/31 05:31:55
∧∧
（´･ω･） おやすみ・・・
＿| ⊃／(＿＿_
／ └-(＿＿＿_／
￣￣￣￣￣￣￣
595:デフォルトの名無しさん
09/08/31 15:52:46
Ｒｕｂｙｗｗｗ
596:デフォルトの名無しさん
09/09/01 00:24:24
今日も楽しくRubyでプログラミング～♪Yeah！Yeah！
高度なアプリもたったの１時間！改造も５分で終了！
正直、Cなんてタルくってやってらんねーよｗ HA！ HA！ HA！
597:デフォルトの名無しさん
09/09/01 00:32:50
URLﾘﾝｸ(blog.takeda-soft.jp)
598:デフォルトの名無しさん
09/09/04 15:24:28
>>596
その生産性に対話シェルをくわえたのがPython
RubyはPythonの劣化コピー
599:デフォルトの名無しさん
09/09/04 23:08:29
>>598
irbしらんのか？ ipythonも便利だ。
600:デフォルトの名無しさん
09/09/06 07:42:50
馬鹿といわれればそうかもしれない
スクリプトを書くようなノリで描ける言語じゃない
ソースコードの1文字目をタイプ時点から、
全体を把握するように神経張り巡らしながらコーディングする
けど多分それでいいんだよ！！！
エラーチェックがゆるいスクリプト言語なんか使ってると、自分が真剣にやってないから
ひどいソースになってることが多い
601:デフォルトの名無しさん
09/09/06 07:54:10
何行か打つ度に自動で裏でコンパイラ走らせて、
みつかったエラーを表示を表示させる環境使ってるのでそこまで神経つかわない
つうかコーディングなんて打つだけだろ、
それまでにホワイトボードを使ったりして証明まで終わらせておくべき
602:デフォルトの名無しさん
09/09/06 12:32:10
C++は別にそんな細かい神経使わんよなぁ…
新しいパラダイムを取り入れようとすると慣れるまではコケまくるけど、コンパイラが
引っ掛けてくれないような典型的なミスのパターンを何個か覚えるってだけの話だし
603:デフォルトの名無しさん
09/09/06 15:01:56
>>602
それはぜひ詳しく聞きたい
典型的なメモリリークのパターンは何個あるんだ
604:デフォルトの名無しさん
09/09/06 15:19:21
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(www.ipa.go.jp)
RAIIを守っていればメモリリークは99%潰せる。
マルチスレッドなんかで、オブジェクトを生成するスレッドと破棄するスレッドが違ったりする場合は、
RAIIでは対応できないけど、boostのshared_ptrがあれば楽勝。
変なバグがない限りこれでほぼ100%リークは潰せる。
605:デフォルトの名無しさん
09/09/06 15:32:53
今時C++でメモリリークとか起こしてる人って…
606:デフォルトの名無しさん
09/09/06 15:43:06
C言語に比べたら、C++のメモリリーク対策はかなり楽
shared_ptrのようなスマートポインタもあるし。
Cだとデストラクタがないから、メモリ解放が面倒臭いｗ
エラー発生時にgoto文でメモリ解放処理へ飛ばしている始末。
607:デフォルトの名無しさん
09/09/06 15:55:21
コンストラクタ・デストラクタの中で例外が発生するパターン
デストラクタにvirtualつけ忘れるパターン
代入は初期化じゃないよパターン
608:デフォルトの名無しさん
09/09/06 15:59:04
どっちにしろ普通のC++だとメモリリーク＝deleteし忘れだから、まともなスマポを
まともに使えば、例外安全性すらいい加減でもメモリリークだけは無いんだよな
609:デフォルトの名無しさん
09/09/06 16:02:07
仮想デストラクタが呼ばれた時にはもう仮想メンバ関数が破壊されているパターン
610:デフォルトの名無しさん
09/09/06 16:13:58
>>607>>609ですら、newをshared_ptrに全部突っ込んでればメモリリークは
しないよな？
メモリ以外はリークするけどな
611:デフォルトの名無しさん
09/09/06 16:20:34
newするものをラップするproxyを作ればいい。
char *に対するstringのように。
612:デフォルトの名無しさん
09/09/06 16:30:52
リソース管理用のクラス作っておけば、メモリ以外もリークしないと思うが
613:デフォルトの名無しさん
09/09/06 17:05:56
なるほどつまり
C++の半分は参照カウントでできている？
614:デフォルトの名無しさん
09/09/06 17:11:38
スタック使えばいいところでもnewしまくるJava脳ならそうなるかもな
615:デフォルトの名無しさん
09/09/06 17:19:52
shared_ptrってポインタ以外のリソースも管理できたと思うが
616:デフォルトの名無しさん
09/09/06 17:57:44
ポインタ経由でだろ？
617:デフォルトの名無しさん
09/09/06 20:44:46
thisの分は参照カウントしなくて大丈夫かなあ
618:デフォルトの名無しさん
09/09/07 02:25:22
>>616
deleterを指定すればdelete以外の方法で開放されるリソースも扱える。
619:デフォルトの名無しさん
09/09/07 09:50:45
しかしgcに類することを他人任せにしてかまわないなら、C++使う必要性も少ないな
620:デフォルトの名無しさん
09/09/07 10:15:02
RAIIとGCはまるっきり別物だぞ…
621:デフォルトの名無しさん
09/09/07 10:28:37
意味が分からないなりに何とか叩こうと必死なんだろ
622:デフォルトの名無しさん
09/09/07 11:58:46
C++にはいろいろと欠陥が有るのは事実だけど、
約15年前の「C++の設計と進化」からつい最近の
URLﾘﾝｸ(indico.cern.ch)
まで、まるで設計理念がブレてないのは凄いと思うよ。
623:デフォルトの名無しさん
09/09/07 12:20:39
まぁ、他に「ゼロ・オーバーヘッドでどこまで出来んの」ってのを突き詰めてる言語が
無いから、良くも悪くもぶれにくいんだろうな
ゼロ・オーバーヘッド原則＝アセンブラマクロ路線の継続でもあるから、コンパイラが
どんなコードを吐くか分かってないと扱いづらい、というC言語からの伝統も継続して
しまう訳だが
624:デフォルトの名無しさん
09/09/10 00:34:05
Objective-CもそういうCの欠陥としてよく挙げられる部分は引きずってると言えるの？
それともなにかしらカバーする方法は用意されてるのかな
625:デフォルトの名無しさん
09/09/10 00:43:48
Cの欠点＝Cの利点でもあるからなぁ。
結局、適材適所ってことで落ち着いてしまう気がする。
626:デフォルトの名無しさん
09/09/10 01:11:52
Objective-CはCの利点を引き継いでるとは言い難いな
627:デフォルトの名無しさん
09/09/10 06:21:40
Obj-Cはあの見切り発車的な仕様が絶妙だな
628:デフォルトの名無しさん
09/09/10 06:48:26
開発言語の選択は消去法になりがちだから、適所が分かりやすい言語は生き残りやすいな
Objective-Cは言語特性で見た時の適所が分かりづらい
政治的特性で言えばApple周辺が適所だけど
629:デフォルトの名無しさん
09/09/12 14:12:55
C++の構文でおかしいのは参照の定義くらいかな。
このせいでポインタがわからないという類の人が増えるだろうと思う。
630:デフォルトの名無しさん
09/09/12 14:20:16
バカに合わせて言語仕様を切り捨てなきゃならない開発形態もある
言語仕様に合わせてバカを切り捨てていい開発形態もある
まぁ結局は程度問題だが、「ポインタ分かりません」なんて奴は、C++の開発現場なら
たぶんそいつの方を切り捨てるべき
631:デフォルトの名無しさん
09/09/12 15:38:07
ポインタなんて百害あって一利なし、諸悪の根源
切り捨てろ
632:デフォルトの名無しさん
09/09/12 15:58:10
>>631
そんな事はない
ランダムアクセスイテレータを引数に取るアルゴリズムに
ポインタを渡せるのは活用しないと
633:デフォルトの名無しさん
09/09/12 16:10:53
ポインタの害しか理解できないようなのは底辺コーダー
634:デフォルトの名無しさん
09/09/12 16:29:07
参照抜きでポインタについて勉強すりゃいいだろ。
ポインタに関して不可欠なものじゃないんだから。
635:デフォルトの名無しさん
09/09/12 16:47:31
>>629
コンストラクタに引数渡す変数定義を書いたと思ったら、
関数宣言と解釈されるやつは結構な罠だと思う。
636:デフォルトの名無しさん
09/09/12 17:08:58
あれは互換性を考えたら仕方ない
そのまま動いちゃったりもしないから、罠としては小物ではある
637:デフォルトの名無しさん
09/09/12 19:18:30
罠といえばこれだな
__int64 cbSize;
hr = pStream->Read((void*) &cbSize, sizeof(cbSize), NULL);
BYTE *pbArray;
HRESULT hr = SafeArrayAccessData(psa, reinterpret_cast<LPVOID *>(&pbArray));
hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);
I’ll give you one more clue – it’s a one character typo.
Give up? Look at the last line. The first argument is incorrect. It should be:
hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);
「IE」に対する最新攻撃の原因、たった1つのタイプミス--MSが認める
URLﾘﾝｸ(japan.cnet.com)
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(msdn.microsoft.com)
Active Template Library (ATL) のセキュリティ上の脆弱性からコンピューターを守る
公開日: 2009年7月30日
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
（1）［MS09-035］Visual StudioのActive Template Libraryの脆弱性により、リモートでコードが実行される (969706)
（2）［MS09-034］Internet Explorer用の累積的なセキュリティ更新プログラム (972260)
638:デフォルトの名無しさん
09/09/12 19:54:30
キャストに頼りまくると地獄を見るという実例だな
639:デフォルトの名無しさん
09/09/12 19:57:45
void*は糞
640:デフォルトの名無しさん
09/09/12 20:17:37
pdfもflashも全滅か
641:デフォルトの名無しさん
09/09/12 21:03:07
ActiveXなんか一切使わなければいい！
これからはfirefoxだなｗ
642:デフォルトの名無しさん
09/09/12 21:49:04
件の部分に役立つのはなかったけど、IID_PPV_ARGSとかtemplate<class Q> HRESULT QueryInterface(Q** pp)とか
最近のWindows APIのヘッダはキャストを隠蔽する方向に動いているのは確か。
643:デフォルトの名無しさん
09/09/13 05:19:32
もしかしてATLとActiveXを混同してる人がいる？
644:デフォルトの名無しさん
09/09/13 17:21:45
>>643
げ。オレもすっかりActiveXの記事と思い込んでいた。
ActiveX=脆弱性という固定観念がそうさせたのか。
645:デフォルトの名無しさん
09/09/13 17:37:38
ATLの不具合によって、多数のActiveXコントロールが影響受けると
いう内容じゃないの？
もうATLやらCOMやら、わけわかめな技術は使うな！
646:デフォルトの名無しさん
09/09/13 18:44:04
ActiveXをCだけでゴリゴリ書いてもいいが非効率
最近はほとんどのActiveXがATLで書かれてるだろうから
ATL ≒ ActiveXで医院で内科医
647:デフォルトの名無しさん
09/09/13 21:31:46
その理屈で行くと、ほとんどのエロゲー用システムはC/C++で書かれてるから
C/C++ ≒ エロゲー用システムでいいんだな
648:デフォルトの名無しさん
09/09/13 21:46:20
病気になって死んだ人間のほぼ100%がパンを食ったことあるので
パンは万病の元だみたいな言い方
649:デフォルトの名無しさん
09/09/14 00:58:50
今回の場合パンを食った人が死んでるんだからそれでいい
650:デフォルトの名無しさん
09/09/14 01:13:03
必要十分条件を再勉強しよう
651:デフォルトの名無しさん
09/09/14 01:24:15
ATLでActiveX以外のもの作ってる例は？
652:デフォルトの名無しさん
09/09/14 01:26:15
>>650は>>647へのレス
スマソ
653:デフォルトの名無しさん
09/09/14 02:41:18
>>651
WTLと組み合わせると、普通のウィンドウズアプリケーションを作るライブラリとして使える代物になる。
CWindow/CWindowImpl, CString, CHandleなどなど。
もっとも、例の部分はActiveXコントロールを作るのでもない限り縁のない箇所だけど。
654:デフォルトの名無しさん
09/09/14 04:19:30
>>650は>>646に言うべき
655:デフォルトの名無しさん
09/09/14 20:34:35
さすが欠陥者だらけの負のオーラ漂う糞スレ
656:デフォルトの名無しさん
09/09/14 20:49:29
おかえりRuby
657:,,・´∀｀・,,）っ-○○○
09/09/14 21:32:40
さよならRuby
658:デフォルトの名無しさん
09/09/14 22:56:58
>>607
きじねこ見て出直せ
659:デフォルトの名無しさん
09/09/14 23:44:53
ええと、スマポのC-torが例外を投げないっていう前提があれば
スマポ以外のC-torが例外を投げてもいいかな
660:デフォルトの名無しさん
09/09/15 00:22:31
いいよ。
661:デフォルトの名無しさん
09/09/15 00:48:41
言語使用が糞だとしても、代用できる位置の言語が他に無い。
662:デフォルトの名無しさん
09/09/15 01:11:38
欠陥のない言語ってあんの？
663:デフォルトの名無しさん
09/09/15 01:39:37
Ruby
664:デフォルトの名無しさん
09/09/15 01:59:13
使うべきところでない場面で使われすぎ。
言語の欠陥というよりは、利用者が悪い。
665:デフォルトの名無しさん
09/09/15 02:00:47
windowsでrubyとかね
666:デフォルトの名無しさん
09/09/15 07:26:21
ｗ
667:デフォルトの名無しさん
09/09/17 00:07:23
X
668:デフォルトの名無しさん
09/09/17 05:41:47
Y
669:デフォルトの名無しさん
09/09/17 09:03:58
>>668 を見る限り発毛前なのだから
>>666 は
・・
であるべき
670:デフォルトの名無しさん
09/09/17 10:54:52
それは前方参照だからスレッドのコンテキスト上では不可能
671:デフォルトの名無しさん
09/09/18 16:43:02
Ruby(笑)
672:デフォルトの名無しさん
09/10/13 06:54:41
多くの人が協力して建設している塔があるとする。
塔は下から造っていくものだから、すでに下の方はかなり強固に固められており、
最新の建設作業は最上部で行なわれているわけである。
従って建設作業に参加するには、最低限、まず最上部まで
登っていかなければならない。
しかし多くの者にとっては、建設に携わることはおろか、
現場にたどり着くことすら全く容易でない。
このとき、ひたすら現場を目指して一歩一歩登り続ける者はまともである。
また、やむなく中途で登攀をあきらめたとしても、そこからの眺望を楽しんだり、
付近のちょっとした破損を修理したりするのは、やはりまっとう活動である。
ところが一部の者は、最下部の土台付近をウロチョロしただけで
「この土台はダメだから、この塔にも価値はない。それを見抜いた俺様は、
上の方でチマチマ造ってる連中全部より優秀である。」と豪語する。
ひどいのになると、爆弾を投げつけて塔全体を破壊しようとしたりするのである。
673:デフォルトの名無しさん
09/10/13 10:38:42
ブリューゲルの「バベルの塔」を観ると、正しくそのような状況が発生しているように見えて面白い。
もしかすると、バベルの塔は神の怒りではなく「一部のもの」によるテロ行為によって破壊されたのかも知れないとまで想像できよう。
674:デフォルトの名無しさん
09/10/13 11:12:07
>>672-673
で、何？それでC言語を擁護しているつもり？
使いにくいものは使いにくいんだよ、C++になってやっとプログラマの
ケアレスミスを大幅に削減できるようになった
675:デフォルトの名無しさん
09/10/13 11:13:44
C++は正しくCを拡張してるだろ。
>>672-673はこのスレの上のほうに出てるバカどもに向けたものだと思うが。
676:デフォルトの名無しさん
09/10/13 13:51:44
いやいやCが欠陥言語ならC++も欠陥言語ですよ。
Cのほとんどの仕様を引き継いでる以上。
677:デフォルトの名無しさん
09/10/13 17:21:57
>>1
噴飯した
678:デフォルトの名無しさん
09/10/13 22:51:13
スレタイ見てスレ開いて、>>1を見てズッコけるパターン
679:デフォルトの名無しさん
09/10/13 23:32:06
頭のいかれたとても恥ずかしい人は放置した方がいいぞ
680:デフォルトの名無しさん
09/10/14 11:56:35
「行末に改行とかｗ」
くらい言い返してやれ。
681:デフォルトの名無しさん
09/10/15 20:20:52
そもそも神はバベルの塔を破壊してないわけだが
682:デフォルトの名無しさん
09/10/16 18:39:53
バベルに例えるほど言語仕様が巨大だとも思えない
683:デフォルトの名無しさん
09/10/16 23:01:42
Cから入って色々言語使ってきたけど、Cが一番落ち着く(´・ω・｀)
684:デフォルトの名無しさん
09/10/21 22:16:36
使いどころでどの言語が良いか、
使い分ければ良いだけの話じゃないの？
685:デフォルトの名無しさん
09/10/22 01:57:54
C言語はアセンブリほどまでしたくないけど高級過ぎると困る時に使う言語として君臨してるな
686:デフォルトの名無しさん
09/10/22 02:13:38
そりゃ最初からそうでしょう。
687:デフォルトの名無しさん
09/10/22 07:50:22
C++は、バカ切り捨ての方針で構わない場合は、高級から低級まで扱える便利言語。
バカ切り捨てができない場合は地雷言語。
688:デフォルトの名無しさん
09/10/26 03:53:42
Cを高級言語だと思うから話がおかしくなるんだ
Cは高級アセンブラだぜw
689:デフォルトの名無しさん
09/10/26 06:54:51
Cは低級言語だろjk
690:デフォルトの名無しさん
09/10/26 09:56:08
高級アセンブラとか言う奴に限ってアセンブリ言語でプログラミングしたことない
691:デフォルトの名無しさん
09/10/26 10:05:55
ＣはどんなＣＰＵ，アーキテクチャ、ＯＳ下でもコンパイルできる可能性を秘めている
最強の互換性を秘めた言語。
692:デフォルトの名無しさん
09/10/26 10:10:54
アセンブラで8086のDOS用COMを数本作ったことはあるが、Cは高級アセンブラで
いいと思うぞ
693:デフォルトの名無しさん
09/10/26 12:49:11
高級アセンブラってのはPL/Mみたいなのを言うんだ。
694:デフォルトの名無しさん
09/10/26 12:53:53
アセンブラの条件てオペコードとニーモニックが1対1であることだと思うんだが。
695:デフォルトの名無しさん
09/10/26 12:57:20
かつてはCのコードとニーモニックが1対1だった
696:デフォルトの名無しさん
09/10/26 13:17:30
高級言語とアセンブリの中間ぐらいの言語だから高級アセンブラとか言われるんだよな
697:デフォルトの名無しさん
09/10/26 15:59:45
>>694
では「高級 “マクロ” アセンブラ」ということで。
698:デフォルトの名無しさん
09/10/26 19:15:20
何をもって高級だか低級だか言っているのかわからん。
多分、ライブラリの充実度程度の話なんだろうけどさ。
データ型がCPUの扱える型に近いとかいう話だと型付変数を持つ言語は全部低級だし。
699:デフォルトの名無しさん
09/10/26 19:19:11
>>698
「高級言語」でググれ。
低級言語という語はないけど。
700:デフォルトの名無しさん
09/10/26 19:20:37
…ごめん自分でググったら低級言語もあったw
701:デフォルトの名無しさん
09/10/26 19:27:10
一見もっともな疑問で実は無知を晒しているだけというのは本当に萎えるな
702:デフォルトの名無しさん
09/10/26 21:32:06
low-level, high-level だから、忠実に訳すなら低水準、高水準、だな。
site:ipsj.or.jp とか site:ieice.org を付けてググると、
低級言語 - ヒットなし
低水準言語 - たくさんヒット
高級言語 - 高水準言語より多い
高水準言語 - 高級言語より少ない
という非対称な結果が出てくる。
703:デフォルトの名無しさん
09/11/30 03:48:15
C、C++のことを高級アセンブラと呼ぶのって褒め言葉だぜ。
704:デフォルトの名無しさん
09/11/30 09:54:41
仕様で保証されてない裏技使わないとスタックに手を出せない言語の
どこがアセンブラだかw
705:デフォルトの名無しさん
09/11/30 10:13:19
処理系関係なく共通の「仕様」が存在する点でアセンブラと違うってか
706:デフォルトの名無しさん
09/11/30 11:48:51
大概の高級言語は裏技使ってもスタックなんぞ手は出せんぞ
707:デフォルトの名無しさん
09/11/30 11:57:10
BASICさん……
708:デフォルトの名無しさん
09/11/30 11:57:40
ハードウェアスタックなんて存在するとは限らない
709:デフォルトの名無しさん
09/11/30 14:45:07
スタックに標準で手を出せたら互換性なくなるだろ。
互換性無くていいならインラインアセンブラで十分だろ。
710:デフォルトの名無しさん
09/11/30 16:56:13
インラインアセンブラがあって当然みたいな言語だからな
無いと何かが足りない感じになるくらい
711:デフォルトの名無しさん
09/11/30 20:29:44
そうなったのは90年代からじゃないか？
712:デフォルトの名無しさん
09/11/30 21:22:10
そうだな。Cはもともと今のJAVAみたいな、共通(クロス)プラットフォーム的な
使い方をするための物という感じだったし。
713:デフォルトの名無しさん
09/12/01 09:39:41
いや、エンディアン依存しまくりとか、ぜんぜんクロスプラットフォームじゃない
コードも書かれまくっているわけだが。
714:デフォルトの名無しさん
09/12/01 10:01:07
>>712の意図を無視しすぎな話だなｗ
Javaでだってエンディアン依存しまくりなコード書けるし。
715:,,・´∀｀・,,）っ-○○○
09/12/03 23:34:42
高級アセンブラってインラインASM使う人のための言葉だと思ってた
716:デフォルトの名無しさん
09/12/05 12:24:19
インラインは高級も糞もなくて
ただのアセンブラそのものだろ
分かったんだったら良かったね
717:デフォルトの名無しさん
09/12/05 12:27:54
86で言えば
mov ds:bx[4]w, 123
が
int *p;
*(p+4)=123;
って書けるって話？
718:デフォルトの名無しさん
09/12/05 14:41:24
PL/M-86 を先にやってて C に触れた俺にとっては
C は「汎用性を重視するあまり、フラグも参照できない駄言語」だった。当時。
719:デフォルトの名無しさん
09/12/06 09:17:08
Cは楽だけど、コードが何KBも膨れるんじゃちょっとなぁ、って思ってた頃はあった
720:デフォルトの名無しさん
09/12/13 18:31:50
Cはウンコだから
721:デフォルトの名無しさん
09/12/14 02:06:34
Turbo C のインラインアセンブラは、でてきたとき衝撃でした。
722:デフォルトの名無しさん
09/12/14 08:35:25
インラインアセンブラって TC が初出なのか？
MSC にもあったけど、あれ最初のバージョンからあったんじゃないの？
723:デフォルトの名無しさん
09/12/14 09:39:36
x64でインラインアセンブラを削ったのはやり過ぎだよな
SSEx命令が使いにくくなる
724:デフォルトの名無しさん
09/12/17 04:09:41
2038年問題が一番の欠陥
725:デフォルトの名無しさん
09/12/17 07:22:11
C言語が原因だと思ってるならお前の頭に欠陥
726:デフォルトの名無しさん
09/12/17 13:45:18
インランとか汗ブラとかＣとかいやらしい話はよそでやってよ
727:デフォルトの名無しさん
09/12/17 14:36:06
なんでC vs JavaやＤ言語、になってるんだろ。
CもJavaもDもＣ系列なのだからここでは批判の対象だろう。
例えば、C系列の行末に;などの悪習はC信者に移りやすいようにするための配慮だろ。
未だにC信者がCと似た言語じゃないとヤダヤダって言ってるので
新言語もC信者のご機嫌取りに徹しているクソ言語ばかり登場する。
いい加減この負の連鎖を断ち切るべきだ。
728:デフォルトの名無しさん
09/12/17 14:39:09
>>724
C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが
2038年問題 - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)年問題
より引用
729:デフォルトの名無しさん
09/12/17 14:47:34
この問題は現在普及しているC言語処理系の実装による。
730:デフォルトの名無しさん
09/12/17 14:48:37
最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。
731:デフォルトの名無しさん
09/12/17 15:16:29
>>727
>例えば、C系列の行末に;などの悪習
ターミネータで行の終わり、じゃなく
継続行に _ をつける方がいい、って？
流石ヴビ厨。
732:デフォルトの名無しさん
09/12/17 16:03:15
行末に、とか言ってるあたりでなんもわかってないだろ。
; は幾種類かの「文」のターミネータだ。
733:デフォルトの名無しさん
09/12/18 15:09:33
PascalとCのセミコロンの微妙な扱いの違いに戸惑う
734:デフォルトの名無しさん
09/12/18 16:27:21
構文糖衣で；をCRLFに置き換えられないものかな
735:デフォルトの名無しさん
09/12/18 16:48:46
古くはawkとか、最近ではJavaScriptとか、
; が来るかもしれないところに改行が来たら ; があると思う、
みたいなことをやってるけど。
736:デフォルトの名無しさん
09/12/18 17:04:41
URLﾘﾝｸ(offgao.no-ip.org)
HPのタイトルが「セミコロンのないC言語」ということで、
本当に「セミコロンの無いC言語」でプログラムを作れるか、試してみました。
戻り値がある関数でないと使えませんが、if ( 関数 ) { } と書けば、
セミコロン無しで関数を使うことが出来ます。
void main(void){
if(printf("TEST\n")){}
}
737:デフォルトの名無しさん
09/12/18 20:46:16
>736
一通り読んだがC89やC99の規格に準拠したコードになっていない
詰まるところ文(Statement)を式(Expression)にできれば良いわけだがカンマ演算子やビット積、論理積などで式を繋げていくこともできる
また、(void)式(正しい呼び方は知らないが、VOID式とでも呼ぼうか)をif()の中で使いことができるようにするためにVOID式とスカラをカンマ演算して繋げてif ( VOID式, スカラ )のようにすれば良い
こうすることで戻り値がvoidな関数を呼び出すことができる
具体的には
1 #include <stdio.h>
2 #include <stdlib.h>
3
4 void
5 foo(
6 int *x
7 ) {
8 if ( (*x = 10) ) {}
9 }
10
11 int
12 main(
13 int c,
14 char **v
15 ) {
16 if ( foo(&c), printf("%d\n", c) ) {}
17 if ( exit(0), 1) {}
18 }
のようになる
cf:ｽﾚﾘﾝｸ(tech板:25-26番)
738:デフォルトの名無しさん
09/12/19 19:16:28
なにそのカンマ演算子最強説
739:デフォルトの名無しさん
09/12/19 23:56:53
なんというネタにマジレス。
740:デフォルトの名無しさん
09/12/20 11:50:40
ごめんね
自称C言語ハッカーの血が騒いだんだよ
ネタだったのか、僕は純粋にC言語が僕に挑戦してきたのかと思ったよ
規格書を読まない一般プログラマには理解できないだろう
僕はC言語が好きだ大好きだ
C++でもLISPでもPerlでもない
C言語が好きだ
C言語は奥が深い
初心者はC言語を使わないで欲しい
もし、本当にC言語を使いたいなら規格書をしっかり読んで欲しい
それが嫌なら、C++でもLISPでもPerlでも好きな言語をやればいい
741:デフォルトの名無しさん
09/12/20 18:21:45
そして
Ｊａｖａのほうが奥が深いことに気がついた
Ｊａｖａ信者となり、現在に至る。
742:デフォルトの名無しさん
09/12/20 21:38:59
結果
Scalaのほうが言語としての完成度が高いことに気がついた
Scala信者となり、現在に至る。
743:デフォルトの名無しさん
09/12/20 21:42:20
>>740
おい
C＞C++とか馬鹿な事を言うなヴォケ
744:デフォルトの名無しさん
09/12/20 21:45:44
別に言ってなくね？
ただたんにCとC++は別作者の別言語でしかないってコトでしょ。
745:デフォルトの名無しさん
09/12/20 21:49:10
>>740
C言語って何？ プログラミング言語Cとはどう違うの？
746:デフォルトの名無しさん
09/12/21 05:41:37
The C Programming Language（プログラミング言語C）は解説書の書籍名。
C Programming Language（C言語）はプログラミング言語名。 ※たんに“C”とも
ISO 9899 Programmin Language-C（JIS X 3010 プログラム言語C）は標準規格書名。
>>740の話題だと規格書よりも言語がメインだからC言語でいいんじゃね？
747:デフォルトの名無しさん
09/12/21 10:33:29
Smalltalk書けないやつはコンピュータに使われてるだけの奴隷ってアラン・ケイが言ってた。
748:デフォルトの名無しさん
09/12/21 10:41:25
とある言語の説明書
749:デフォルトの名無しさん
09/12/21 16:06:33
老害なんかしらねー
750:デフォルトの名無しさん
09/12/21 16:30:53
>>747
もう過去の人。
751:デフォルトの名無しさん
09/12/21 16:58:05
本当に説得力のある言葉は、名前を出さなくても通じるもんだからな
752:デフォルトの名無しさん
09/12/21 17:00:54
口だけの奴にだまされた経験のない奴が、しばしばそう言うな。
753:デフォルトの名無しさん
09/12/21 18:03:32
どっちにしろ>>747は通用するコンテキストが一般的じゃない上に時代も外れている
754:デフォルトの名無しさん
09/12/21 18:32:39
NHKかなんかでそいつの番組見たとき
そんなバリバリ抽象化されたものより
Cやマシン語書くのがよっぽどPC理解してるだろw
と思ったわ。
755:デフォルトの名無しさん
09/12/21 18:37:02
まぁ高レベルと低レベルを両方分かってた方がいいのは確かだがな
片方だけを究極と思って得意げに語る奴が多すぎるが
756:デフォルトの名無しさん
09/12/21 18:52:16
高レベルやるならSchemeでもやった方がいい
アラン・ケイが自分主導で作ったSmalltalkを褒めるのは当然だが
低レベルやるならアセンブラは理解しなきゃならない
アセンブラを使いこなせる奴ならCはほぼそのまま使える
それらを両方理解した上で、中間にある一番適した言語を使うのが正解に限りなく近い
757:デフォルトの名無しさん
09/12/21 19:33:50
>>756
高水準側、HaskellとかPrologだろJK
758:デフォルトの名無しさん
09/12/21 22:34:00
高水準の勉強には現状じゃLisp系が最強だろ常考
759:デフォルトの名無しさん
09/12/21 22:42:55
>>758
ML系は？
760:デフォルトの名無しさん
09/12/21 23:04:29
>>759
さあ
761:デフォルトの名無しさん
09/12/22 16:02:15
＼
＼
. ＼
. ＼ ＿＿＿＿＿＿＿
＼ r'´￣￣￣ ￣￣￣｀､::. ＿＿＿
l} ､:: ＼ﾍ,___,＿ ＿＿＿＿＿＿/::.＿＿| .|＿＿＿＿＿＿＿＿＿_＿
|l ＼:: | | ｜､:.. | [], _ .|: [ニ]:::::
|l'-,､イ＼: | | ∧,,,∧ . ｜::.. ﾍ￣￣,/:::(_＿)::
|l ´ヽ,ノ: | | （´・ω・｀） ,l､::: ￣￣::::::::::::::::
|l | :| | |,r'",´￣￣￣￣￣｀ヽ､l:::::
|l.,＼＼| :| | ,' :::::... ..::ll:::: Haskellが完成したら何を作ろうかなあ
|l | :| | | :::::::... . .:::|l:::: そうだ安定したOSを作ろう
|l＿＿,,| :| | | ::::.... ..:::|l:::: その前にFireFoxに対抗できるブラウザだな
|l￣｀~~| :| | | |l:::: やっぱFlashやJavaの動く見栄えのいいブラウザがいいよなあ
|l | :| | | |l:::: そしてゲームも欲しいよな
|l | :| | | ''"´ |l:::: もちろんモンハンやMGSみたいなメジャータイトルだよなあ
|l ＼＼[]:| | | |l::::
|l ｨ'´~ヽ | | ｀`' |l:::: ふと気がつくと布団の中にいた
|l-''´ヽ,／:: | | ''"´ |l:::: この脱力感は何なんだろうか
|l ／:: | ＼,'´＿___..:::::::::::::::_`l__,ｲ:::: そうか全て夢だったんだ・・・
l}ィ:: | `´::::::::::::::::::::::::::::::`´:::::: いい言語だねって褒められたこと以外は・・・
762:デフォルトの名無しさん
09/12/24 12:33:28
アセンブラ最強。他言語は全部ウンコ。
763:デフォルトの名無しさん
09/12/28 17:27:12
定年間際の上司がそんな事言ってました
主任止まりの独身です
764:デフォルトの名無しさん
10/02/13 01:40:32
規格に反しない範囲で、最も奇妙な動作をするCの処理系って、どんなんだろう。
意図的に変な処理系にして、できる限りコンパイルエラーを出して、できる限り実行時強制終了を起こして、
できる限り予期しない動作を返すような処理系って、どんなのになるんだろう。
charが8bitじゃないとか、文字コードがASCIIじゃないとか、NULLが0でなく1と定義されてるとか、
int a[2], *pt;としたときpt+2==0は0だけどpt+2+1-1==0は1を返すとか。
765:デフォルトの名無しさん
10/02/13 02:13:16
組み込みならよくある
766:デフォルトの名無しさん
10/02/13 04:04:03
NULLは常に0または(void*)0
ビットパターンが0でない処理系なんぞ普通
767:デフォルトの名無しさん
10/02/13 04:50:28
>int a[2], *pt;としたときpt+2==0は0だけどpt+2+1-1==0は1を返すとか
イミフ
768:デフォルトの名無しさん
10/02/13 05:19:22
つーかヌルポを全く理解してないな>>764は
769:デフォルトの名無しさん
10/02/13 20:10:38
>>767
ポインタは、確保した範囲と、その1つ先までしか値があることを保証されていない。
なので、pt+2までは有効だが、さらに1足した時点でptの値の妥当性は保証されなくなる。
>>766
(int*)0 == NULLが1となることは保証されているが、NULL自体が0であることは保証されてたっけ？
770:769
10/02/13 20:16:03
ごめ、勘違いだわ。NULLは0か((void*)0)のどちらかと保証されてるわ。
771:デフォルトの名無しさん
10/02/14 02:40:21
>>769
そうじゃなくて pt に * が付いてないから訳がわからないｄねす
772:デフォルトの名無しさん
10/02/14 04:25:40
頭の悪い奴が適当に作った言語だな
とは思う
773:デフォルトの名無しさん
10/02/14 05:02:57
頭の悪さについては置いといて、適当に作ったのはガチだよな
774:デフォルトの名無しさん
10/02/14 10:36:55
>>769
>なので、pt+2までは有効だが、さらに1足した時点でptの値の妥当性は保証されなくなる。
有効でなくなるのと、有効でない場合にヌルポになるかどうかはまた別問題だろう。
775:デフォルトの名無しさん
10/02/14 12:06:46
int a[2];
int *pt = a;
って言いたいのかな
別にptなんか使わなくても右辺値なんだからa+2とか書いていいと思うけど
776:デフォルトの名無しさん
10/02/14 16:56:41
アホのオナニーレスに付き合うなよ
777:デフォルトの名無しさん
10/02/14 18:19:10
>>774
別問題だが、なっても問題がない。
778:デフォルトの名無しさん
10/02/15 19:28:04
ポインタ演算に領域サイズなんて一切無関係。
malloc, freeの時しか領域サイズに関する情報は扱わない。
double a[5];
を
void aho(double *b);
に
aho(a+3)
とかで渡してahoが領域情報とかわかるわけないのに勝手にポインタ演算の結果に確保された領域が反映されるわけないだろ。
779:デフォルトの名無しさん
10/02/15 19:34:41
日本語で
780:デフォルトの名無しさん
10/02/15 21:11:51
C言語で
781:デフォルトの名無しさん
10/02/16 02:25:27
778は動的に範囲チェックしろと言いたいんだろうけど、
そのためのオーバーヘッドがない言語というのも必要なんだよ。
範囲チェックが必要になったらvector::atを使えばいいし。
782:デフォルトの名無しさん
10/02/16 02:25:35
>>778
普通に実装するなら、まぁ、俺もそう実装するだろなぁ。
783:デフォルトの名無しさん
10/02/17 01:27:13
ポインタ演算に領域サイズなんて一切無関係。
malloc, freeの時しか領域サイズに関する情報は扱わない。
int *pi = 0x00000000;
char *pc = 0x00000000;
pi++;
pc++;
// pi = 0x0000004
// pc = 0x0000001
784:デフォルトの名無しさん
10/02/17 09:58:54
char (*p)[10] = 0;
p++;
// p == ?
785:デフォルトの名無しさん
10/02/17 11:01:39
初心者の素朴な疑問を垂れ流すスレじゃねぇ
配列の初期化でググれ
786:デフォルトの名無しさん
10/02/17 11:46:57
>785
配列?!
>784
p == (char (*)[])((char *)0 + sizeof(char [10]))
787:デフォルトの名無しさん
10/02/20 03:09:47
配列じゃなく関数ポインタだろ
788:デフォルトの名無しさん
10/02/20 03:10:41
間違えた
関数ポインタの配列だろ
789:デフォルトの名無しさん
10/02/20 03:11:31
じゃあ配列じゃねーか
ごめん間違えたもういいや
790:デフォルトの名無しさん
10/02/20 14:07:59
普通は複雑なデータは構造体使うから
複雑な配列ポインタはあんまり使わない。
791:デフォルトの名無しさん
10/07/04 20:14:23
じゃあ、もうめんどくさいし、Cは高級でも低級でもない、ミドルクラスの中級言語ということでFA？
ドライバとかファームとか、なんかハードウェアとアプリケーションの中間に使われるじゃない。
かといって、アセンブラほどローレベルではないという感じで。
ミドルクラス言語と呼ぼうではないか。
792:デフォルトの名無しさん
10/07/04 21:02:10
高級アセンブラとか揶揄されることもあるな
793:デフォルトの名無しさん
10/07/04 23:08:20
C系列の中でもJavaの糞さは際立っている。