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/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。

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

>>171
条件はない
"Cの後置増分"とは、"最初はC"でよいという意味だ
そこから段階的にソフトランディングで移行できることが
C++の売りなので、気まぐれにつまみ食いすることは
実はC++らしい使い方の1つといういことだ

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

C99以降の機能を使いだすとC++でビルド通らなくなるし
Cを使わずベターCとしてC++使うなら、C99/C11を知るは必要ないでしょ
Cっぽいものが書ければ十分

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

ベターな部分がないのに「ベターC」 w

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

あぁなるほど、C99が基準だとC++は劣化Cに見えるわけか。
ただ、一般には「ベターC」という言い方がされたのはC++に対してだと思うがなぁ。

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

ヒント：　煽り耐性

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

>>175
よく分からんが君は生C派なのか？
正直俺はbetterC派とC++派しかもう居ない（生C派は絶滅済み）と思っていたのだが、
昨今のC++の暴走を見てると生C派が健在なのも分からんでもない。Linusもそのようだし。

ただ、classとかtemplateとかは「控えめに使っている限りは」便利だと思うぞ。
C++erは無理に活用しようとしておかしなことになっているが。

>>176
俺の理解では、
Cでは機能が足りないが、C++の機能は行き過ぎ（やりすぎ）、と思う人達が、
CとC++のちゃんぽんをbetterCと呼称している。

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

>>175
関数オブジェクトとラムダ式

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

>>176
あ、もしかしてそれ以前のことか？
それなら、Objective-CとC++の対比で使われ、以下wikiの通りだ。
> Objective-CはCを拡張してオブジェクト指向を可能にしたというよりは、
> Cで書かれたオブジェクト指向システムを制御しやすいようにマクロ的な拡張を施した言語である。
> したがって、「better C」に進んだC++とは異なり、「C & Object System」という考え方であり、
> ある意味2つの言語が混在した状態にある。
> https://ja.wikipedia.org/wiki/Objective-C

ただし、Objective-Cはかなり前から実質的に死亡していたので、
最近「betterC」って言われているのは「CとC++のちゃんぽん」のはず。
要するに「いいとこ取り」をしようとしているのがbetterC。
C++の流儀で全部書け、というのがC++。
うるせえC++なんて全部ゴミだ、というのがC。

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

>>178
今のC++は、かつてのC++の暴走に対する反省でできているぞ
void func() throw(std::bad_exception); みたいな馬鹿げた話が
void func() noexcept(false); で済むとか
std::bind1stだのstd::bind2ndで3rdや4thがないなんて馬鹿げた話が
std::bindだけで済むだけでなくstd::mem_funとstd::mem_fun_tもクビ
char* port = (char*)0x40044000; みたいな二度手間も
auto port = (char*)0x40044000; で済む

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

C++普及始めはベターCって言うとC++使いこなせなくてC++でもC文法を良く使うって意味だったみたいなんだが、今はオブジェクト指向も浸透して、その長所短所も洗い出されて来たからいいとこ取りって意味って理解。
でも、今も昔も両者が混在してるんだと思う。

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

>>181
上2つはそれでも暴走中だとは思うがな。
GC無いと関数型は辛くね？
例外は俺は積極的には使ってないのでよく分からない。

下1つは、俺はC的記述、
> char* port = (char*)0x40044000;
の方が好きだな。
キャスト無しで書かせてくれとは思うが、型は左辺側に書きたい。
それとは別に、autoの価値も認める。リフレクションとかでマジで死ねる。(VC++/CLI)
だけと他言語と揃えてvarにしろよとは思うよ。なぜauto？

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

Cじゃなくて全くの別物を「ベターC」と謀って何をしたいんだ?

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/23(日) 23:29:44.60

>>183
昔、autoというキーワードがあったが、あまり使われなかった。そこで新しいキーワードを作るよりも、
使われていないキーワードを再利用した方がいいと判断された、らしい。

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

registerもそのうち使い回される

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/07/23(日) 23:35:53.82

キーワードが増えると、キーワードと同じ変数名や関数名はコンパイルできなくなるという問題がある。

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

>>183
さあ？　俺はGCがないことにストレスを感じたことがない
あんなもんいらねえ、つーか却って迷惑
機械という奴隷は完全に支配したいんで

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

>>185,187
> 記憶クラス指定子としての auto の使用が非常に少ないとの調査結果などから、当該用途は直ちに廃止となった。
> https://cpprefjp.github.io/lang/cpp11/auto.html
> storage class "auto" (>>164)
K&Rも確認して、なるほど状況は分かった。autoはまあ許せる範囲か。

しかしこれ、autoとregisterがあったということは、
元々のコンセプトのデフォはもっと遅い外部メモリかよ。（コアメモリとか？)

**デフォルトの名無しさん** · 2017/07/24(月) 00:18:45.69

>>189
autoは記憶クラスのデフォルト
省略可能で、むしろつける理由がなかったのでだれもつかわなかった

registerは変数をレジスタに置いたほうがいいというコンパイラへのヒント
しかし、コンパイラの改良が進みコンパイラに任せたほうが良くなった
人間による指定は不要なばかりか、むしろ最適化の邪魔になるのでコンパイラは無視するようになった

**デフォルトの名無しさん** · 2017/07/24(月) 00:28:47.24

betterCは明確な定義はないだろうけど、
http://www.kijineko.co.jp/tech/betterc/1
で言われてるのが大体の認識なんじゃない？

（ライブラリの内部だけとかではなく）クラスとかを使うならそれはもうC++でしょ
メモリ管理とかvtableの仕様とかもしっかり確認する必要があるので適当にクラスを使うのはおすすめしない

**デフォルトの名無しさん** · 2017/07/24(月) 01:07:47.78

>>188
君はおそらくbetterC派だよな？（ただしほぼC++の)
ちなみにどういう組み合わせで使ってる？

GC言語と非GC言語ではそもそも組み方が違う。これは全く>>156の指摘どおりで、
しかもその後3匹馬鹿が現れて(159-161)彼の言い分が証明されてしまったw

さて関数型だが、どれくらい使っている？
俺はマトモには関数型をやってはいないが、それでも分かる範囲で言うと、
関数型言語はGC+型なし（型推論）が多い。
これに対しC++で関数型的アプローチを取ると、
型が爆発してtemplateで書くにしても大変でウザい。マジでvarくれよ、になる。
そして決定的に異なるのは資源のライフタイム管理で、GC言語はこれをやらない。
C++は一応自分でやることになっているのだが、
上記の通り、他関数型言語はGC前提なので組み方が異なっており、本来は参考にならない。
そしてC++のラムダはスタック方式に強引に載せている、なんとも中途半端なものだ。
これは全く他関数型言語のスタイルにはフィットしない。

だからC++で関数型アプローチをする現実路線としては、
C++をGC言語側に寄せる手法、つまり、
・ラムダは完全に関数オブジェクト扱いで、クロージャ変数は主にヒープ上
・スマポ、RAII徹底
という、いわゆる今のC++erが目指しているものに近くないと辛いはず。
ほぼC++寄りのbetterCというべきか。

君のスタイルはこれで合ってるか？合ってたらGCイラネってのも納得だ。
合ってなければ、どの組み合わせで使っているのか教えて欲しい。参考にする。

**デフォルトの名無しさん** · 2017/07/24(月) 01:33:19.39

>>190
autoがデフォか。なるほど了解だ。

>>191
> クラスとかを使うならそれはもうC++でしょ
> メモリ管理とかvtableの仕様とかもしっかり確認する必要があるので
ここはちょっと微妙。
まずvtableはプログラミングモデルとしては見えないので知っておく必然性はない。
（もちろん知っておいたほうがいい）
次にメモリ管理だが、C++に関してはclassとstructがほぼ同一なので、
C的に自前classをnewして自分でdeleteするという使い方も出来る。(A)
そうではなくて、デストラクタとかやりだすとややこしくなってくるが、(B)
最終的なC++erの目標、コンテナ等にも問題なく載るように、となると、
ムーブコンストラクタ等のC++的お作法を全て実装しておかないといけない。(C)
俺は(A)ならC、(B)ならbetterC、(C)ならC++と呼ぶね。

多分CとC++のコンセプトの根本的な違いは、
Cは厳密に「書いてないことはやらない」なのに対し、
C++は「出来る限り全自動を目指す」だと思う。
だから、「どこまで自動化しようとしているか」で測ればよいと思う。

**デフォルトの名無しさん** · 2017/07/24(月) 02:16:26.89

>>193
うーん、その定義のbetterCは誰向けなんだ

初心者はC++の仕様（fwriteをvtableのあるクラスに使っちゃったり、newしたのをfreeしたりみたいな）にはまるだろうし
中級者はどこまでがbetterCなのかで混乱しそう（参照は？とかスマートポインタは？とかstringは？とか）
上級者はbetterにすることなく快適にCかC++で満足してそう

クラスとかデストラクタだけ使うみたいな方針で書かれてるソフトって何があるの？