C言語なら俺に聞け 141 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/07/17(月) 21:06:47.63

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
http://mevius.2ch.net/test/read.cgi/tech/1494508803/
http://www.geocities.jp/c_cpp_cs/about_c/

**デフォルトの名無しさん** · 2017/07/18(火) 23:26:17.54

>>68
惜しいな。

> fscanf(fp,"weight:%d",&b);

ヒント: % の後。

**デフォルトの名無しさん** · 2017/07/18(火) 23:30:58.21

>>68
もう一箇所。

> fscanf(fp,"e-mail:%s",&str);
> printf("Eメール:ichiro@foo.bar\n",str);

惜しいな。strに読む所は良い。その後、それを出す所。これだと固定の文字列が出るだけだよね。

**デフォルトの名無しさん** · 2017/07/18(火) 23:36:18.53

専門学校一年です
プログラム言語っていくつも必要？応用性ある最強言語一つあればいいんでないの？

**デフォルトの名無しさん** · 2017/07/18(火) 23:48:43.24

>>46,48
なんか実装している奴いるぞ。
http://www.nurs.or.jp/~sug/soft/super/longjmp.htm
http://www.nurs.or.jp/~sug/soft/java/java25.htm

**デフォルトの名無しさん** · 2017/07/18(火) 23:49:23.68

>>54
Perlは出来るぞ。
Rubyは出来ないようだが。これは予想外だった。つかMatzはこっち側のはずだが。
luaは出来ないね。LiveDemoで確認した。
http://d.hatena.ne.jp/perlcodesample/20080615/1213501216
https://soudan1.biglobe.ne.jp/qa776599.html

JavaScriptが文だけなのは全く問題ない。以下コードは動く。
代入は他文と同様上から順に評価されるだけであって、シンボルは見えてる。

(function(){
say_hello();
var say_something = say_world;
say_something();
function say_hello(){console.log('hello');}
function say_world(){console.log('world');}
})()

> JavaScriptの「巻き上げる」っていう仕様は結局わかりにくくて
これは俺は「分かりにくい」というのが理解不能で、単に関数スコープなだけだ。
Cで言うANSI以前の｢ド頭で全部宣言しとけ｣でしかない。(C89と言うのか？)
ここで間違ったらCはSyntaxErrorだったはずだが、
JavaScriptの場合はそこらへんがユルくて、
｢どこで宣言しても頭で宣言したことにして、エラー無しで動作｣となるだけ。

Rubyが出来ないのはMatzが方針を間違えてるね。
「全部先に宣言した方が読みやすい」ってのはMatzの意見であって、
全員がそう思っているわけではない。だからRubyの思想なら制限しては駄目だ。一貫性がない。
逆にPythonはユーザーごとのばらつきこそが可読性を低下させるという思想だから、
制限するべきだし、実際にそうなっているから問題ない。こちらは一貫性がある。
結果、俺にとってはRubyも糞だと判明しだだけだな。

**デフォルトの名無しさん** · 2017/07/18(火) 23:50:25.98

>>55
> 機械学習とか数値処理とかの学術系
あまり詳しくはないが、MLとかは当てにならん。
あれらはループがえぐいだけで中身は大した事はない。
大半が下位コード、1k行か精々3k行程度のはずで、俺なら使い捨てにする。
しかも自分の環境で動けばいいだけのイージーモードだ。
がっつり保守されてる奴を見ないと実用上の向き不向きは分からん。
ウォーターフォールで作ればアホでも綺麗に作れるのは当たり前であって、
問題はそこからの耐性だから。
本来のOOPもそこからのスタートだったろ。
最近のOOPは若干暴走気味で、設計の設計の設計みたいな感じになっている奴も多いが。

で、教えてもらって文句を言うのも悪いんだが、、、
> pandoc
マークアップコンバータは再帰で実装できるからHaskell向きかもしれん。
ただこれもかなり簡単で、しかもどの言語でも実装できる代物でしかない。
要するに再帰とストリング系が強ければいけるから、
LL言語ならどれを使っても問題ないし、苦労もしないだろう。
Haskellを使ったからこそ生きる、というものではないと思う。

Cが使われている現場は、Cでしか書けないから、だ。
それはお世辞にも生産性が高いとはいい難いことの裏返しではあるが、
linuxKernelについてはLinus自身がC++では無理だったと言っているし、
Gitについても同様だ。
> gitのような、効率を第一の目的としたのには、C++の「利点」とやらは大失敗なんだよ。
> 実際のところ、LinuxではC++を試したことがある。1992年のことだった。
> 結果はクソだった。マジで、カーネルコードをC++で書くのは、ド低脳の考えだ。
> https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html
実際Git全盛だし、Linuxについても
｢安全なOOPでカーネルを書き直そう！｣という話が10年程前には在った筈だが、
今全く聞かないので、完全にポシャったのだろう。
結果的にLinusの意見の正しさを証明している。

**デフォルトの名無しさん** · 2017/07/18(火) 23:51:25.94

Haskellの売りは遅延評価だろ？
ならば、遅延評価がビルトインで提供されているからこそこれだけ簡単に実装できる、
そうでない言語ではかなり辛いことになる、というところで戦わなければ意味が無い。
マークアップコンバータは違うし、そこに挙げられている他12種も同様だ。
Linusの言葉を借りるなら、
> (c) 授業でそういう課題を与えられた者
でしかない。他言語を既に十二分に使えるときに、それらアプリでHaskellを選択する理由がない。

遅延評価の利点は、俺が思うに、適当に書いても速いことだ。
具体的には、超大富豪プログラムを動的に貧民プログラムに変身させられる事だ。
だからチャキチャキ書けないと意味が無いのだが、Haskellはお世辞にもそういう感じではないだろ。
だからHaskell使いがあの程度のアプリしか作れない時点で将来性はないよ。
彼らもそれなりに優秀なはずで、仮に俺が学んだとしても、彼ら以上のものを作るのは容易ではない。
それで作れるものがあの程度？そそられねーな、って感じ。
あのラインナップなら今でも他言語で作れるし、多分そんなに苦労もしない。

とはいえこれはサンプルとしては素晴らしい。ありがとう。
保守されているし、俺が確認したい中位コードは大量に含まれているはずだ。
俺自身が他言語で実装できるだろうというのもいい。オレオレ実装と比較できる。
つまり、言語比較という意味ではかなりいい素材だ。
ただそれ以前に俺はHaskellをほぼ読めないので、読むのはずいぶん先になりそうだ。
これについては申し訳ないね。

**デフォルトの名無しさん** · 2017/07/18(火) 23:52:11.26

> Ansibleやyum
お手軽スクリプトの域を出ないと思う。最悪、シェルスクリプトでも出来る範囲だろ。
C++の現場、たとえばブラウザでは、本当にエグイほど仕様変更が入って、
結果的にソースコードはぼろぼろになっていって、それでも保守している。
だからやっぱりLL言語はLL言語なんだと思うよ。
これだからスクリプターは、、、というのも当たってる。戦場の厳しさの次元が違う。

一通り動かすところまではどの言語を使っても出来る。
その過程で、例えばHaskellの遅延評価のような言語独自のフィーチャーがあり、
それを生かせれば素晴らしい。
しかしPythonにはそもそもそれがない。特に可もなく不可もなく、的な言語だ。
そして問題はそこから先で、
当初想定してなかった仕様変更が入ってきたときどこまで耐えられるかなのだが、
これに関してはPythonは不可も無いのだからそれなりではある。(悪くはない)
(なおJavaScriptはデタラメなパッチで一時しのぎする方法には事欠かないため、
俺はこの点も気に入っている)

エコシステムが云々、というのはおいておいて、
言語自体の能力で言えば、Pythonを積極的に選ぶ理由が一つもない。
とはいえ他言語は色々尖っていることも多いので、消極的にPythonってのもありだとは思うし、
実際そこにポジションしているとも思うが。Javaに近いというか。
両言語ともそれで繁栄しているのだから間違いでもないわけだが。

**デフォルトの名無しさん** · 2017/07/19(水) 00:28:57.41

>>75
金鎚だけで家が作れるかね？

**デフォルトの名無しさん** · 2017/07/19(水) 00:53:51.97

>>75
そーいう発想は大事
大きいプログラムも小さいプログラムも
スケーラブルに書けるほうが良い！
というのが動機で出来た言語があるにはある

**デフォルトの名無しさん** · 2017/07/19(水) 01:09:15.68

Cは大も小もなんでも書けるよ
ただ工数がかかるけど

**デフォルトの名無しさん** · 2017/07/19(水) 01:28:24.97

確かにCはなんでも書ける。
きめ細かくハードウェアに密接するようなのも書ける。
OSやデバイスドライバも書ける。
OSなし環境向けの組み込み用マイコンボードのROMに書くプログラムなんかも書ける。

逆にいうと、きめ細かくしか書けない。それなりのライブラリが用意されてないと作るのが大変。

**デフォルトの名無しさん** · 2017/07/19(水) 01:36:11.94

つアセンブリ言語

**デフォルトの名無しさん** · 2017/07/19(水) 03:29:33.92

>77
perlのやつは勘違いだった、すまん

>「分かりにくい」というのが理解不能で、単に関数スコープなだけだ。
関数の巻き上げは、ブラウザの種類、バージョン、strict modeの有無の組み合わせで位置と動作が不安定になったりするのはかなりわかりにくいと思う
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Functions_and_function_scope

>Rubyの思想なら制限しては駄目だ。一貫性がない
Rubyは「その場にメソッドを定義する」という機能を持つ文が用意されているだけ
「すべてはオブジェクト」という思想的に一貫してる

その結果、javascriptではできない関数の中身や別ファイル、if文の中とかでもメソッド定義が比較的自然に行える
hoge = □

def hoge
　■
end if true

みたいなこともできないと仕様上不自然。
javascriptみたいにifをつけると巻き上げが起こらないみたいにすると、この場合では
ifなし→□
ifあり→■
みたいに非直感的な挙動になって一貫性が失われる。そう考えると、言語全体の仕様の見直しが必要になって・・・
と考えてくと、評価時に定義されるというのはそれはそれで合理的。

**デフォルトの名無しさん** · 2017/07/19(水) 03:52:13.57

>>85
それの場合CPU毎に覚える必要があって面倒。
C言語コンパイラはだいたいのCPU向けに素早く実装される傾向にあると思うのでアセンブリ言語よりは良いと思う。

**デフォルトの名無しさん** · 2017/07/19(水) 04:35:20.40

>>78-80
Haskellはちょうど具体例を知ってたから上げただけで全然わからないから詳しくはわからんので申し訳ない
人から数学系とHaskellを極めればいろんな界隈で需要があるらしいという噂だけ聞いたことはあるが

他の話は結局何が言いたいのかわからん
PythonはLL言語なんだから「お手軽スクリプト」として使うのは当たり前じゃん
機械学習とかの研究分野は、実装を素早く作って考えた手順を評価してを高速に繰り返すんだからC言語では無理。

それこそgitでも最初期の仕様を考えてるときはperlとか使ってたし
http://gihyo.jp/dev/serial/01/alpha-geek/0040

>消極的にPythonってのもありだとは思うし、実際そこにポジションしているとも思うが
大体の人はそれを理解してるのに突然「Pythonはクソ！使ったことないけどクソ！」ってやつがわいてきてみんな頭の中？？？
Haskellについてのやつを見ても思うけど、断片的な経験と情報、ネットで見た内容とかを元に理解したと思いこむ癖があるんだろう
個人のソフトはともかく、Googleとかパッケージマネージャとかで積極採用されるからにはそれなりの評価点があるはずなんだから、自分の考えは常に疑って更新したほうがいいぞ

**デフォルトの名無しさん** · 2017/07/19(水) 04:42:21.33

要するに「なんでも書ける」は言い過ぎだということ
C言語がハードウェア寄りの記述が得意な言語であることは確かだけれど
それでも大抵はわざわざインラインアセンブラという抜け道を用意している
その理由はどうやっても書けないこともあるから

**デフォルトの名無しさん** · 2017/07/19(水) 04:43:24.78

アンカ忘れた
>>89は>>87へのレス

**デフォルトの名無しさん** · 2017/07/19(水) 05:21:02.93

>>89
割り込み関係みたいに特権命令を使うところは
「きれいなC」だけじゃ絶対書けないな

**デフォルトの名無しさん** · 2017/07/19(水) 08:01:13.73

使ったこともない言語をディスり、同意しない相手は無知だと思っているガイジに汚染されたスレはここですか？

**デフォルトの名無しさん** · 2017/07/19(水) 08:13:15.18

>>89
ああ。書けないものもあるな。
そうなるとインラインアセンブラで無理矢理埋め込んだりする事になるとは思うが、そういうのは普通は全体からすればほんの少しだよな。

**デフォルトの名無しさん** · 2017/07/19(水) 08:23:52.23

>>53
Haskell処理系のGHCがまさにHaskellで書かれてるし、モナディウスっていうゲームはHaskeller界隈じゃ有名。
そもそもHaskellが有名になったのはPerl本家より早くPerl6の実装したのがキッカケ。
それまで知る人はほとんど居なかった。

**デフォルトの名無しさん** · 2017/07/19(水) 08:29:05.26

>>93
その通り

>きめ細かくハードウェアに密接するようなのも書ける。
>OSやデバイスドライバも書ける。
>OSなし環境向けの組み込み用マイコンボードのROMに書くプログラムなんかも書ける。

こういうのは全体からすればほんの少しだよ

**デフォルトの名無しさん** · 2017/07/19(水) 08:39:40.95

>>75
そうだよ、みんなわかってないんだよ

PL/1, Ada ...

**デフォルトの名無しさん** · 2017/07/19(水) 08:42:04.13

>>92
そうだよ
こいつにレス返すと終わりが見えないぞ？っていうタイプ
それを無邪気に触っちゃうのがこのスレだよ

みんなさすがに今回ので学習したと思うけどｗ

**デフォルトの名無しさん** · 2017/07/19(水) 09:21:43.24

>>72
変数を使いたくないってことです

**デフォルトの名無しさん** · 2017/07/19(水) 09:28:45.98

>>98
例えばどう書きたいの

**デフォルトの名無しさん** · 2017/07/19(水) 10:08:57.54

>>91
組み込み用コンパイラとかは拡張構文できれいに書けたりするけどね

**デフォルトの名無しさん** · 2017/07/19(水) 10:35:07.29

プラットフォーム依存のレジスタいじったりする必要があるから
綺麗なCってのは難しい
綺麗なCの定義にもよるけど
まぁ関数化するなどして隠蔽化はできるけど

**デフォルトの名無しさん** · 2017/07/19(水) 10:41:07.44

>>75
誰かが自分には分かりやすく書いた言語が、他人には分かりやすいとは限らない。
で、書ける奴は他人の言語押し付けられるなら自分用言語作っちゃう。
今も増え続けてる。

**デフォルトの名無しさん** · 2017/07/19(水) 10:50:02.60

>>100
組み込みはPICアセンブラで遊んだだけだけど、PC向けよりもハードがまだ完成してないと言うか、SoCでCPU(MPU)とメモリは用意するから後は自分で追加してねって感じだし、返って文法としては単純かもね。
結局CPUとしては計算以外じゃポートやメモリに読み書きするだけだし。

ハード作りながら入出力の関数も自作する感じですかね？

**デフォルトの名無しさん** · 2017/07/19(水) 11:04:35.78

>>99
HOGE := hoge piyo fuga
all: $(HOGE)
clean:; rm *.o $(HOGE)

みたいなのをたとえば

all: hoge piyo fuga
clean:; rm *.o ★(all)

みたいにすっきり書きたい

**デフォルトの名無しさん** · 2017/07/19(水) 11:06:41.55

コンパイルするときにmakeとかcmakeとかありますけど他にもあるのかもしれませんけど
今ならどういうのが定番ですか？

**デフォルトの名無しさん** · 2017/07/19(水) 11:13:41.95

>>105
makeなんか捨ててninja使おうぜ

**デフォルトの名無しさん** · 2017/07/19(水) 11:49:17.31

>>104
ターゲットの依存ファイルを再帰的に展開すると言う事になるが、途中で止めたいとかわがまま言いだすだろ .hとか
例えそれが可能になったとしても、依存ファイルは、そのアクションを実行するために必要なので
削除するために作成すると言う極めて頭の悪い状況が発生する

**デフォルトの名無しさん** · 2017/07/19(水) 12:36:53.34

>>104
うーん正直上の方がわかりやすいと思うけどなあ
とりあえず下みたいなことをする方法は知らんわ。力になれなくてすまんな

**デフォルトの名無しさん** · 2017/07/19(水) 13:37:37.50

>>107-108
無理なら無理であきらめるぜー！センキュー！

**デフォルトの名無しさん** · 2017/07/19(水) 21:27:36.88

cleanは、固定的に削除したほうがいいよ。でないとその内ゴミが混ざる。

まぁ、無理矢理やるなら
allに含めるターゲットを処理するときに中間リストへもファイル名を追加しといて、xargsに食わせるのが無難かと。

**デフォルトの名無しさん** · 2017/07/19(水) 23:08:55.17

時代はRubyのrake

**デフォルトの名無しさん** · 2017/07/19(水) 23:40:47.89

>>86
JavaScriptについては、Webリソース(というか個人ブログが多いが)も間違いが多いから注意した方がいい。
> strict modeの有無の組み合わせ
これが要らん。実際見りゃわかるが、全員 strict mode 使っている。
MDNは準仕様書みたいなものだから、非strict modeについても言及する必要もあるだけ。

> javascriptではできない関数の中身や別ファイル、if文の中とかでもメソッド定義が比較的自然に行える
いや、できるぞ。ただしやる必要もないし、意味もないが。
(strict mode の場合はif文中では禁止)

動的にクラス構成を変える必要があるケースはまずないが、(手抜きパッチを除く)
やる場合はプロパティとして差し込むので、それはただの文だ。どこにでも書ける。
function定義そのものではなく、関数ポインタを差し替える。
というか、ここら辺の流儀は他言語と同じだ。
俺は特に疑問を持ったこともなく、分かりにくいとも思わないが。

**デフォルトの名無しさん** · 2017/07/19(水) 23:41:35.90

> javascriptみたいにifをつけると巻き上げが起こらないみたいにすると
これが違う。(内容自体ではなく、考え方が違う)
プログラミングを暗記で済ませようという馬鹿はJavaScript界隈に多いが、
そうとしか捉えられないのなら、向いて無いから止めた方がいい。(君が上達することはない）
それは「数学は暗記だ！」と言っているようなものだ。
或いはどうにも高校の物理に全く付いていけなかった奴とか。
あれは今にしたら分かるが、抽象思考が出来ない奴には無理だったということだ。
そしてプログラミングではその抽象思考こそが重要であり、逆に、それ以外は大して必要ない。

順に評価されるべきものは順に評価され、(巻き上げなし)、
そうでないものはC的に静的に評価されるだけ。(巻き上げあり)
俺は疑問を感じたことはない。
「巻上げという仕様ガー」とか言い出すから余計に意味不明になるのであって、
そもそも最初から直感的だ。後方参照できるだけでしかない。
JavaScriptはC(正確にはC++)以上に文法が抽象化されているから、暗記には向いてない。
結果的にC++並みのことがC並みの文法で出来るようになっている。俺はここも気に入っている。

それとは別に、君が｢全部上から順に評価してくれなきゃヤダ｣ならRubyの仕様をマンセーすればいいが、
JavaScriptの仕様はC等コンパイル言語を使ったことがあるやつにとっては非常に直感的だ。
俺にとってはRubyの仕様はウザいだけだね。

**デフォルトの名無しさん** · 2017/07/19(水) 23:42:29.67

>>88
要するにスクリプト言語はラピッドプロトタイピングには向いているんだよ。
そしてPCの能力が十二分に上がったので、
その遅いコードでも十分実用的だし、問題ないからそのまま使われてる。
俺も、もう低位コードだけCのDLLにして、
中上位コードは全面的にスクリプト言語で行った方がいいと思っている。楽だから。
NumPyはまさにこれでしょ。俺からみてもgoogleの動きは全然不思議じゃない。
ていうか多分、マトモなプログラマならgoogleの動きを不思議に思う奴はいない。
君がそんな言い方をする時点で君は色々分かってないと自白しているようなものなんだが。

> Googleとかパッケージマネージャとかで積極採用されるからにはそれなりの評価点があるはずなんだから
評価点はないね。ビジネス上の観点でしかない。
googleは社内言語を絞ってる。C++/Java/JavaScript/Pythonだ。この中ならPythonだろうさ。
だから、仮にRubyやHaskellがgoogle社内で評価されたとしても、
それらで書かれたツールが出てくることはない。

**デフォルトの名無しさん** · 2017/07/19(水) 23:43:14.27

>>94
> GHC
サンクス、そうであったか。これもサンプルとしてはいいね。
> モナディウス
Haskellってexeかよ！やってみた。グラディウスにしては速すぎる、、、左手が辛い、、、

> Perl6
つかそれってどういうことだ？
構文解釈等に関しては、実は圧倒的に単純に実装できたりするのか？
pandocもそっち系だ。俺には遅延評価とは無関係としか思えないのだが。

**デフォルトの名無しさん** · 2017/07/19(水) 23:50:34.51

知識のない奴程語りたがる好例

**デフォルトの名無しさん** · 2017/07/19(水) 23:51:34.81

C始めるためにVS2017インストして苦C見ようとしてるんだけどどこをどうすればソースを書けるのかちんぷんかんぷん
そもそもCの内容をC++で書けるのか怪しい
スレチかもしれないけど助けて詳しい人

**デフォルトの名無しさん** · 2017/07/19(水) 23:52:22.89

な、長ぇ…

**デフォルトの名無しさん** · 2017/07/19(水) 23:55:40.31

完全な初心者？

**デフォルトの名無しさん** · 2017/07/20(木) 00:08:04.51

ラピッドプロトタイピング用に作られたのがスクリプト言語なんだから向いてて当たり前
ハードではFPGAなんかがASIC前のラピッドプロトタイピング用だね
しかし中上位コードしかかけん奴らがプログラマ気取る風潮はいかがなものかと危惧する
Cでの低位コードもスクリプト言語での中上位コードも書けんとな

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/20(木) 00:09:55.72

>>117
適当な場所(フォルダ)にプロジェクトファイルを作成します。
プロジェクトにソースファイルを追加します。
ソースファイルにソースを書きます。
ビルドします。
デバッグ実行して、正しく動作するか確認します。
バグがあれば修正します。
リリースビルドして、EXEを作成。
exeを配布します。

**デフォルトの名無しさん** · 2017/07/20(木) 00:15:44.40

任意のエディタでソースを書きます。CL.EXEでコンパイルします。以上

**デフォルトの名無しさん** · 2017/07/20(木) 00:16:25.56

>>116
にわかなやつほど語りたがる、ってやつだな
何が動機なんか知らんけど
愚にもつかない長文いっぱい書いちゃう子おるよな
これはもう、定期的に出てくるとすら言っていい現象だけど

>>121みたいな簡潔なレスのほうがよっぽど好感度あるわ

**デフォルトの名無しさん** · 2017/07/20(木) 00:32:04.78

https://ideone.com/
http://codepad.org/

こういうサイト利用して、色々試してみたら？

**デフォルトの名無しさん** · 2017/07/20(木) 00:32:44.03

>>120
上二行は後付。sed->awk->Perl->その他もろもろ、だろ。PLD->FPGAでもあるし。
下二行は時代の要請。
> MITがSICPを教えなくなった理由
> https://cpplover.blogspot.jp/2016/05/mitsicp.html

俺は中上位コードだけでもいいと思うけど、書き捨てばっかやってるのは駄目だと思う。
こういうことをすると保守ではまるのかーがないと、回避する能力が育たない。

**デフォルトの名無しさん** · 2017/07/20(木) 00:36:40.77

>>115
関数型全般に言えるけど、言語やテーブルゲームの問題解かせたりし易い。
遅延評価はwebアプリでHTMLの長さを気にしないで読み込める無限リスト便利って読んだことあるな。
んなのどの言語でもそんな変わらんとは思うが。
どっちかと言うとIO部分分離してるから自然とMVCとかMVVMな設計になるってのがメリットに感じる。

**デフォルトの名無しさん** · 2017/07/20(木) 01:40:25.59

>>126
なるほど言語向きなのは関数型の特性か。
確かにbisonが一体化しているようにも見える。

遅延評価で無限リストがーってのは多分Webライタのデタラメ。
実際、無限リストなんて使おうと思ったことないだろ。
HTMLは多分頭からパースしないと悲惨なことになるだろうし。
(一部曖昧なところがあるらしい)

遅延評価は後払い方式のため、
読み込んだものの、結果的に使わずに捨てたデータが多い場合に負荷が軽くなる。
もちろんオーバーヘッドはあるので、全部使うのなら正格評価の方が軽い。
だから理想的にはどれを使うかきっちり管理して正格評価することだが、
これが面倒な場合は遅延評価にしておけば勝手にそうなる。
ノリとしてはGCと似てる。(管理が面倒なら遅延評価にしとけ)

で、マークアップコンバータとかも、全文書を評価することが分かりきっているのだから、
管理も要らず、普通に考えて正格評価の方が適している。だからあのラインナップは謎だった。
関数型言語の特性だということなら納得だ。

> 自然とMVCとかMVVMな設計になる
これはなあ、、、Cでも苦労するわけでもないので、言語特性ではなく、意識付けの問題かと。
実際にHaskell使おうって奴らはここら辺についても意識高いだろうし、
いい方向に寄与しているとは思うよ。

**デフォルトの名無しさん** · 2017/07/20(木) 03:16:53.07

>>112-115
>全員 strict mode 使っている。
新しいソースはね。破壊的変更だから古いソースはstrictじゃない場合も多い。

>俺にとってはRubyの仕様はウザいだけだね。
俺もメインでやってるのは静的言語だけど、JavaScriptもPythonもRubyも関数に関してはうざいと思うことはないな
単純に慣れの問題でお前のRubyやPythonの経験が不足してるだけだと思う

Pythonやる前はインデントって不便だろうって思ってたけどすぐなれたし、使ったこともない言語を適当にディスるのはよくないぞ

>最初から直感的だ、後方参照できるだけでしかない
初心者なら直感の理解でいいかもしれんが、ちゃんと仕様を理解するに越したことはない
undefinedが予約語じゃない、typeofの結果が意味不明みたいにjavascriptも含めどの言語にも直感に反する仕様が存在するし、それを利用したライブラリとかのソース読むときにある程度理解してないと困る

>俺からみてもgoogleの動きは全然不思議じゃない。
ID:LYlgQVUQとかID:tZS7qvyeとは別の人？
「Pythonは馬鹿用言語」「Pythonなんてキチガイ馬鹿用言語」っていう人にそんならGoogleみたいなところも使ってるよって言っただけなんだが

>googleは社内言語を絞ってる。C++/Java/JavaScript/Pythonだ
知識が更新されてないな。現在はC/C++、Java、JavaScript、Python、Go、TypeScriptのはず

>評価点はないね。ビジネス上の観点でしかない。
ビジネス上の観点も大事な評価点でしょ

**デフォルトの名無しさん** · 2017/07/20(木) 03:42:11.85

そもそも「文法が抽象化されている」ってどういうことだろう
javascriptはIE6時代から見てるからかもしれんが、文法からライブラリまで欠陥だらけで、現在の具体的な実装こそが正義な言語というイメージなんだけどな
クラスやプロトタイプチェーンの仕組みとか、thisがどこを指すかとか、for inとオブジェクトや配列がらみの仕様とか直感で完全に理解できる人はいないはず

言語仕様に関しては、C言語も//コメントは使うのに関数先頭以外で変数を宣言できないと思い込んでる人とか結構多いんだよなぁ・・・

**デフォルトの名無しさん** · 2017/07/20(木) 09:24:07.80

複合文の中で変数を宣言できるのを知らないやつはたまにいるが
printf("aho");
int boke;
これ知らねえやつはいねえだろ
逆に制限のある環境でこれをやってエラー吐かれるアフォがいるくらいで

**デフォルトの名無しさん** · 2017/07/20(木) 09:29:55.18

ガイジがスクリプト言語に対する感想を述べる場となったC言語スレ

**デフォルトの名無しさん** · 2017/07/20(木) 11:37:31.64

for( int i=0; i<10; i++) {
print i;
}

で、「i のスコープは for ブロックの中」って言うけど
ブロックって、中括弧の中だよね？

**デフォルトの名無しさん** · 2017/07/20(木) 11:48:22.63

i++ が中括弧の外にあるようだが？

**デフォルトの名無しさん** · 2017/07/20(木) 12:04:35.30

そうそう。
だから、中括弧の外にもう一つ別のスコープがあるんだね。試してみた。

**デフォルトの名無しさん** · 2017/07/20(木) 13:59:07.50

i のスコープより
> print i;
の方が重大な問題だろ

**デフォルトの名無しさん** · 2017/07/20(木) 14:01:49.38

関数呼び出し演算子無しで呼べるとはC言語では無いな

**デフォルトの名無しさん** · 2017/07/20(木) 14:54:53.75

すまん、最近 Quick BASIC 始めたからつい。

**デフォルトの名無しさん** · 2017/07/20(木) 15:15:43.25

もうプチコンで開発するわ！

**デフォルトの名無しさん** · 2017/07/20(木) 15:47:57.27

>>134
ああそうか、i++が中括弧の外にあるのに
ブロックの中という説明はおかしいだろうと
言いたかったのか

あんまり関係ないけどISO/IEC9899:2011 6.8.5 Iteration statements を
読んでいたら、
for (expression opt; expression opt; expression opt) statement
って書いてあってびっくりしてる
改行の位置は単なるtypoとしても、それを修正すると
for (declaration expression opt; expression opt) statement
になる
制御式のセミコロンが1つって、いつそうなったんだ？

**デフォルトの名無しさん** · 2017/07/20(木) 15:48:59.77

訂正
for ( expressionopt ; expressionopt ; expressionopt ) statement for
( declaration expressionopt ; expressionopt ) statement
って書いてあってびっくりしてる

**デフォルトの名無しさん** · 2017/07/21(金) 10:48:58.02

unsigned int を uint32 みたいに書くやつ
あれの標準ヘッダができたの C99 から？

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/21(金) 11:23:14.96

uint32_tね。そうだ。

**デフォルトの名無しさん** · 2017/07/21(金) 23:40:03.14

>>141
そう。C99から。stdint.hね
自分もありがたく使わせてもらってる。
というか、もうintとか使わなくなった。

**デフォルトの名無しさん** · 2017/07/22(土) 13:45:26.72

C11とかC99とか似合わせてチェックしてくれるツールってありませんか？

**デフォルトの名無しさん** · 2017/07/22(土) 14:09:07.67

なにを？

**デフォルトの名無しさん** · 2017/07/22(土) 15:36:12.70

>>143
サンキューありがとう
stdint.h かー
C99をうちでも標準にすべきかどうか悩むなー

**デフォルトの名無しさん** · 2017/07/22(土) 17:15:23.73

お隣はもうC11ですってよ！
うちも11にしましょうよ。ボーナスでたんでしょ。

**デフォルトの名無しさん** · 2017/07/22(土) 17:42:54.52

C++を使えないかあるいはあえて使わないポリシーなのでなければ、C++をbetter Cとして使う方が
いろいろ楽だと思うがな。

**デフォルトの名無しさん** · 2017/07/22(土) 17:56:47.93

>>147
そうは言うけどなお前・・・
うちはまだローン(C89必須案件)だって残ってるんだぞ

**デフォルトの名無しさん** · 2017/07/22(土) 18:58:02.33

隣のC99は青くみえる

**デフォルトの名無しさん** · 2017/07/22(土) 19:03:04.98

俺はstdint.h相当のヘッダファイルを自作してるけどな。
C89コンパイラだったら自作をincludeするようにしてる。

**デフォルトの名無しさん** · 2017/07/22(土) 22:05:24.77

>>148
betterCとしてC++使ってたら今度は「今時生ポインタなんてありえない、unique_ptr使え」と圧力がかかって、どこまでC++の機能使うか悩む

**デフォルトの名無しさん** · 2017/07/22(土) 22:20:17.19

ベターCとしての使い方は、C++という名のとおり、設計どおりの使い方だ
基本的にCとの共通部分だけ、C++のみの拡張機能は欲しいところだけつまみ食いは、邪道ではない
unique_ptrも例外ではなく、欲しければ使い、いらなければスルー
それでいい、至極真っ当な使い方だ

**デフォルトの名無しさん** · 2017/07/22(土) 23:32:49.28

いいこと言うなあ
C with lambdaとして使う踏ん切りがついたわ

**デフォルトの名無しさん** · 2017/07/23(日) 00:22:49.43

>>154
それならスクリプト言語の方が手っ取り早いと思うがな。
全部shared_ptrやRAIIならほぼGCだろ、とも思うし。

というかC++erの生ポ嫌いは一体なんなんだ？
元々メモリリーク自体はそんなに苦労しないよな？今時ツールで検出できるみたいだし。
Cで何らかのタスク(演算等)をこなす場合、
構造化プログラミングだから同一関数内での確保＆解放が多いし。
(というか、そのように書きたければ大概の場合はできる)

**デフォルトの名無しさん** · 2017/07/23(日) 00:32:19.27

>>155
そう
作り方が下手なだけで言語やツールのせいする奴多すぎ
技術屋としてのレベル/精度が低いだけ

**デフォルトの名無しさん** · 2017/07/23(日) 01:06:53.41

ちょっと補足しておく。

俺が思うに、容量的に問題がないのであれば、
大体の場合はmallocではなくallocaで実装でき、当然、管理する必要もない。
だからCはもうちょっとalloca推奨でもいいとは思うし、
そのためにもうちょっとスタック領域に多めに割り当ててくれとも思う。
(コンパイラがallocaをmalloc+freeに分解し、呼んだ関数の末尾でfreeしてくれてもいい。
そうすれば容量の心配ないallocaが手に入るから。
てかこれやってるコンパイラないんか？誰でも思いつきそうだが)

**デフォルトの名無しさん** · 2017/07/23(日) 01:43:34.81

んー、イメージ的には、組み込み系が多そうだしcならヒープ使った方がいいきがする。

小メモリで済むのはc最大のアドバンテージだと思うんだ。

**デフォルトの名無しさん** · 2017/07/23(日) 02:13:19.95

>>155
なんでC with lambdaならスクリプト言語の方が手っ取り早いのか全くわからん

**デフォルトの名無しさん** · 2017/07/23(日) 08:51:27.89

> 構造化プログラミングだから同一関数内での確保＆解放が多いし。

このフワフワした一文だけで、今後こいつからは何の情報も得られないのが分かる

**デフォルトの名無しさん** · 2017/07/23(日) 11:07:58.09

>>155
生でもきちんと管理していれば問題は起きないが
いちいち気にしなければならないことが多いので
もうずっと付けてた方がいいよねという話ですよ

**デフォルトの名無しさん** · 2017/07/23(日) 15:05:48.85

>>153
designated initializerが使えないのでワースCだ

**デフォルトの名無しさん** · 2017/07/23(日) 16:32:54.76

>>162
これか。
https://stackoverflow.com/questions/18731707/why-does-c11-not-support-designated-initializer-list-as-c99
つか入れない理由ないし、ClangとVSでは使えるとも書いてあるが、
C++仕様自体は無駄に意識高くて無視しているといったところか。

一部C++がCの完全上位互換ではない部分があると聞いたが、これか。
他にあれば、キーワードだけでも教えてくれれば助かる。

**デフォルトの名無しさん** · 2017/07/23(日) 16:48:41.41

tentative
restrict
_Imaginal
_Thread_local
_Generic
_Bool
extern const
storage class "auto"
pointer to register

**デフォルトの名無しさん** · 2017/07/23(日) 17:18:38.88

>>164
サンクス。感想は以下。
俺には我慢できる範囲だな。

tentative <- 要らん、つか廃止の方がいい
restrict <- ねえのかよ！しかし自動並列化とかしない限り要らん
_Imaginal <- class があるから要らん
_Thread_local <- これはC++にあってもいいと思うが、、、
_Generic <- マクロがらみか？価値は俺にはよく分からん
_Bool <- boolが既に拡張済みだから要らん
extern const <- 個人的にはconst派ではないからいいや
storage class "auto" <- なんだこれ？いわゆる自動変数って全部これだと思うが、、、
pointer to register <- registerそのものが最早要らんし

**デフォルトの名無しさん** · 2017/07/23(日) 17:56:02.81

>>163
コンパウンドリテラル
(float[2]){1,2}

**デフォルトの名無しさん** · 2017/07/23(日) 19:12:51.83

>>166
designated initializerと同じに見えるが違うのか？
前者は初期化、後者はリテラルとして使ったときの呼称か？
http://seclan.dll.jp/dtdiary/1999/dt19991101.htm
http://d.hatena.ne.jp/taiyo/20080412/p1

**デフォルトの名無しさん** · 2017/07/23(日) 19:28:51.61

全く違う

**デフォルトの名無しさん** · 2017/07/23(日) 19:30:48.75

>>165
tentativeがないくせにテンプレート具現化の統合という
同じベクトルでもっと面倒くさいのがあるわけだが

**デフォルトの名無しさん** · 2017/07/23(日) 19:38:30.48

>>167
ファッションとして「ベターC」と言いたがってた事はよくわかった

**デフォルトの名無しさん** · 2017/07/23(日) 20:01:31.75

「ベターC」を名乗るのになんか条件ってあるのかね？
個人的には、K&Rは時代遅れのC、C89が普通のC、それより改善されているのがベターC、ってな感覚だが。

**デフォルトの名無しさん** · 2017/07/23(日) 20:09:09.26

>>171
俺の理解では、C99がC、
それにC++の機能(class等）をつまみ食いした「ほぼCだけど、、、」がbetterC。