C言語なら俺に聞け 142 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
むしろ Ruby で自由にコードを書ける人を尊敬する今日この頃。
最近やってるんだけど、どうしても馴染めない。普通には組めるけど、違和感が残るというか抵抗があるというか。 リフレクションを使う気がなければリフレクション自体がウンコだよ。
・ソースコードがだだ漏れ
・実行体が無駄に膨らむ（ソースコード情報を含むため）
・リクレクションが必要な用途なら、動的言語でついでに型無しの方が断然楽
GUIとかね。
ウンコと言われ続けたJavaScriptを誰も殺せず、
ついにはElectronとか言い出してデスクトップ側にも進出してきてるだろ。
やれば分かるがGUIに関しては動的型無しHTML(=JavaScript)は最強。
C言語はC言語が目指した範囲での仕様は美しいよ。
ただそこには今後ともリクレクションは必要ないね。
唯一引っかかるのは>>122か。
>>133
どの辺が？
俺はRuby使いではないが、それよりも酷いとされるJavaScriptには馴染んでしまったから、
ある程度は答えられるかも。 lua等の組込み言語とやり取りする container生成用補助構文群が有ってもいい
関数では前方宣言とか scopeが邪魔して対処しきれないだろうから
うまくすれば文字列操作表示も標準libraryから追い出せる pr(test_t, (test_t){.i=999; .s="abc";}); >>134
javaでアノテーションいじり始めるとリフレクションまじ便利で欲しくなるけど、c系にはなくてもいいかなというのも思う。
テバグ目的ならgdbでいいしな。 >>134
規模が大きい場合は型があって静的に検査できるほうが便利だねというのが世間の流れだと思うが
TypeScriptとかFlowとか
速度を稼ぐ目的でwasmも今後主流になっていくだろう
巨大ストレージ、OSSが主流な時代にメタデータのサイズやソース隠蔽は気にしなくなったし >>138
> 規模が大きい場合は型があって静的に検査できるほうが便利だねというのが世間の流れだと思うが
違うね。今の流れは「選べる」だ。つまり、
・型無し言語に型情報を付加し、恩恵を受ける---TypeScript
・型あり言語に型推論やジェネリックを追加し、型情報を記述する煩わしさを回避---C#/C++/Java
どっちも出来ることはほぼ同じ。ほぼ全ての言語がここを目指してるでしょ。（Cを除く）
要するにいいとこ取りを目指しているわけで、自然な流れだ。
型があった方が助かるのなら書け、煩わしいだけなら書かなくて済む、という方向に進化しつつある。
なお、GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。
> 速度を稼ぐ目的でwasmも今後主流になっていくだろう
ならんと思うし、C使いにとってはなったとしてもああそうですか、でしかないと思うが。
> 巨大ストレージ、OSSが主流な時代にメタデータのサイズやソース隠蔽は気にしなくなったし
OSSについては歪んでいて、本来は選べるべきだよ。
JavaScriptのようにソース曝露必須というのは問題ではある。
富豪どころか大富豪プログラミングを自由に出来る時代ではあるが、
何だかんだで速度＝バッテリの持ち/快適さなので、実際は、「気にしなくていい環境も増えた」だよ。
とはいえCレベルでのチューニングが必要なこともそうないが。 >・型無し言語に型情報を付加し、恩恵を受ける---TypeScript
>・型あり言語に型推論やジェネリックを追加し、型情報を記述する煩わしさを回避---C#/C++/Java
後者は型を明示的に書かなくてもいというだけで最初からすべて型検査してるぞ。
型検査について言えば、動的型付け言語に静的な型検査を導入する流れはあるが逆はない。 動かす前にバグが見つかる仕掛けがちゃんとあるなら
動的型付けでも構わんよ option explicit ＋中間言語コンパイル，なら使えそうだ >>140
> 型検査について言えば、動的型付け言語に静的な型検査を導入する流れはあるが逆はない。
これは事実としてはその通りだが、理由はこれが型あり言語の正義だからであって、
現実は型検査がウザイだけの時も多いだろ。
C++のtemplateとか、varで書いたら勝手にtemplate化してくれ、という場合も多い。
込み入ったことをやるとコンパイルを通すだけの為に苦労したりするが、
あんなのは完全に時間と手間の無駄だ。
また、他でもよく言われているが、確かに関数ポインタを常用し始めた場合、
型あり『しか出来ない』言語は壮絶にウザイ。どうでもいい型が氾濫するだけだし。
言語として出来る/出来ないではなく、
ユーザーがやりたい時には出来る/やりたくない時には切れる、が正解なんだよ。
型無し言語はこれを認めていて、欠点を修正し始めてる。
型あり言語はこれを認められず、まだ自分たちの正義（型検査は必須）を押し売りしてるだけ。
C（と言うかC++）ではconstがこの状況に近いのではないかな？
通説ではconstは付けるべき、となっているが、俺は付けてない。理由は、
・そもそも俺はconstで苦労したことがない（必要性を感じない）
・中途半端に付けてると余計に面倒になるだけ
・const_castとか、ただの馬鹿としか思えない
なんだが、同様の意見の奴もある程度はいるだろ。
過剰な型検査ってのはあるんだよ。それが人によって異なるってだけで。
やればいいって物ではない。 なんだ？>>139の「違うね」ってのは現状認識が違うって話じゃなくてあんたの理想と違うってことか？
そりゃ正解はあんたにしかわからんわ。 >>147
現状認識も間違っていると思うけど。
日本語が不自由ならさようなら。
そもそも「型検査」が欲しいわけではなくて、静的チェックが欲しいだけなんだよ。
君は最初からずれている。>>141が正しい。 > コンパイルを通すだけの為に苦労したりするが、
> あんなのは完全に時間と手間の無駄だ。
そうだねえ
自分の考えがはっきりしてなくて筋が通らないのを
コンパイラに突っ込まれ、そのたびに右往左往じゃ
下手の考え休むに似・・いや如かずってやつ 「今の流れってこうだよね」
「俺の欲しいものは違う」
会話にならねぇ。 >>150
そうとしか取れないのは君が未熟だからだね。
「流れ」ってのは原因ではなく、大多数が希望した「結果」なんだよ。
君は初心者だから、毎日コード書いている連中が何を求めているのか分からない。
それだけだね。 >>139,146
>GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。
見てわかる程度の規模の場合は型無しでもよいだろうね
>型検査がウザイだけの時も多いだろ
どんな時？C#には動的に型解決するdynamicがあるけどほとんど使わないな
COM除けばJSONやXMLの処理で楽するときぐらい？それでも本番用ならちゃんと書くなぁ
>どうでもいい型が氾濫
ジェネリックで型指定するだけだから氾濫しなくね？
あと、constはプログラマーがミスを防ぐためのものであると同時にコンパイラーへのヒントでもある
const修飾されていれば大胆な最適化が可能な場合も多い >>151
俺も>>150と同じように読めた。
自分の希望を大多数の希望だと決め付けるのは止めろよ。 >>152
> >GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。
> 見てわかる程度の規模の場合は型無しでもよいだろうね
規模にかかわらず、見ずにチェックするGUIなんて無いだろ。
> どんな時？C#には動的に型解決するdynamicがあるけどほとんど使わないな
おー、C#はやはり進んでいるというか、痒いところに手が届いているね。
要するに楽をさせてくれでしかないのだが、ぱっと思いつく遭遇したケースは、
・callbackでdelegateの型チェックがウザイ。グダグダ言わずにcallbackしてこい。
・リフレクション時がかなり最悪。(C#なら問題ないが、
VC++2008とかだと、MSDNで型を調べながら型を書くという本末転倒の事態になる）
以下にはJSONガーとか書いてあるけど、JSONをC++で受けたことはないので実感はない。
http://ufcpp.net/study/csharp/sp4_dynamic.html#what
後は型無しだとデタラメなパッチが可能だというのもあるし、俺は常用してるけど、
これ自体はあまり推奨されることではないね。
俺はJavaScriptで型をかかないことに慣れてしまったので、
再びVC++で型を書く時にウザくて仕方ない。
(ただしこれはVC++しかやってない時には全く感じなかった）
要するに型情報は具ではなく、ただのチェック用付加情報でしかないんだよ。
例えれば、当たり前に読める漢字にもいちいち全部ルビを付けている感じか？二度手間がウザイ。
ただし二重チェックをしたい部分もあるので、そういうところは書かせろ、とも思うが。
コンパイラにプログラマが合わせるのではなくて、プログラマにコンパイラが合わせるべき。
> ジェネリックで型指定するだけだから氾濫しなくね？
C#は多分そうだね。C#では解決済みかも。
> const修飾されていれば大胆な最適化が可能な場合も多い
この説はよく聞くが、具体的にどういうケースよ？ >>141
こういうやつってユニットテストしらないのか？
Cでも今時は書くだろ 型どうこうで考えるべきは依存関係なんだが
静的型言語はすぐに依存関係ができる
そのためにやれ継承だのインタフェースだのデザパタだのとごちゃごちゃ考えなきゃならん
しかもデザパタで実現できる疎結合は完全じゃないからね >>156
それは型ではなくてラムダの利点だと思うが。
ただ、ラムダを積極活用すると型が邪魔だってのはあるし、
結果的に関数型が型無しor型推論に突き進んだのはこれが理由だと思うが。
しかもデザパタって使い物にならんだろ。
というか元々Javaという関数ポインタもラムダもない言語で(ｷﾘｯされても、
他の言語ならもっとマシに出来るんじゃね？ってのが多いというか、
なんで縛りプレイに付き合わないといけないの？っていうか、
だいたい説明自体もイミフなのが多いし。 >>154
コンポーネントとかイベントの引数の型を間違えたり変更時に修正漏れが出たりはよくあるでしょ
>callbackでdelegateの型チェックがウザイ
async/awaitがある言語だとコールバックを使うことはあまりないしなぁ
どういうのを望んでるのかよくわからんが、型安全と最適化を投げ捨ててまでやることには見えん
コールバックの処理が適切なことはテストとかで保証するとか考えるとそっちが面倒そうに見えるが
>リフレクション時がかなり最悪
VC++でリフレクションって、どの話だ
>チェック用付加情報・二度手間がウザイ
どうせドキュメントとかテストに書いてくんだから二度手間は避けられん
定義が面倒な分、静的型言語では戻り値の型やメンバーが即座に確実に補完されるので非常に快適
全参照を書き換えるリファクタとかもできるし
新しい言語はそこら辺かなり解決されてる >>157
酔ってんのか？Java？意味不明だ
レス付けるなら何を話してんのか特定しろ >>154
constはどちらかというと、x + y = zみたいな変な呼び出しを禁じたいからつけてるから、最適化についてはパッとでは極端な例しか思いつかんな・・・
hoge(&a,&b);
c = a + b
でhogeの引数がconstなら処理を無視してa+bを静的に確定できるとか
根本的にC++は「型安全とバイナリの性能>>>楽をしたい」という発想の言語だから静的な型の確定を妨害するような機能は理念に反するでしょ
javascriptにポインタが欲しいぐらいの不自然さ すいません
Windowsでvirtualboxとかcygwinとかmsysみたいな名前のをインストールする予定はないんですが
WindowsでCを書く場合はVC++を使うのが定番なのでしょうか？
gccとclangを使うのはあんまりおすすめしないですか？ GUIあってもgcc使えるぞ
gcc your_program.c -luser32 -mwindows
-luser32ってのがインポートライブラリuser32.libを使う指定な
他に色々kernel32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.libなんかがいるんで適宜追加しる mingw 入ってない環境だとバイナリ使えないよね。
コンパイルして実行したいだけなのに。 実行ファイルの配布の意図？
mingwでコンパイルできれば、実行もできる環境が整ってるんじゃないの？ >>169
よくごっちゃにしてる人がいるけどそれはcygwinを使う場合
mingwはランタイムにmsvcrtを使うのでcygwin1.dllは不要 あのなー・・・
cygwinがそういう批判を受けていたのを踏まえて
「本当のミニマリスト」を目指したのがmingwなんだよ
それすらいやなら、あとはM$純正のbashくらいだぞ >>167
The Perl for MS Windowsって言うのがある。
これインストールすると、gccも入る
普通にコマンドラインで使える
http://strawberryperl.com/ >>168だって本当に最小限のmingwが黙って入るから意識せずに使えるぞ
で最小限じゃないmingwが欲しくなったらmsys2とか入れるんだよ こういう枝葉でゴチャゴチャやるぐらいなら、さっさとVC入れたほうが良い
windowsで開発するなら、VCさえあれば十分 コンソールアプリくらいならgccでコンパイルできても良さそうなもんだけどな。
関係ないけど .NET に JS コンパイラが入ってるの知らなかった。 >>168 >>171
知らなかったです。
いいですね、MinGW >>158
> 引数の型を間違えたり変更時に修正漏れが出たり
ねえよ。正確に言うと、『これが型検査で都合よく引っかかるのは』ねえよ。
型があってコンパイル時に落とせるのは明確なtypoだけで、それ以外は期待出来ない。
xxxx2とxxxx3とかを間違えた場合、通常、型は同じでしょ。
ただそれ以前にJavaScriptだと修正漏れ自体がないっつうか、修正しなくていいというか。
型検査は基本的にソース全体で辻褄が合っているかを検査する。
だから例えば機能追加で関数の引数が増えた場合、コンパイラは修正漏れを全て検出し、修正を促してくる。
ところがJavaScriptにはそういう機能はないから、漏れてしまう、というのがそちらの意見だと思うが、
そもそも漏れても動作するように作られてるから問題ない、というのがJavaScriptの思想。
具体的には、
・同じ関数が引数の数が違っても呼べるから、エラーにはならない。（引数の型/個数はシグニチャに入らない）
・足りてない引数は、undefind(falsy)になっているから、if (addedParameter) で簡単に対応出来る。
だから修正するパス（その機能が追加される動作パス）の部分だけ修正して、後は放置で問題ない。
もちろんこれだとソース内で引数の数の一致なんて無くなってしまう。
これでいいのか？とも思うが、俺が試した範囲では特に問題はなかった。
C#はIDEがいいから、全ソースをリファクタとかも簡単に出来るようだ。これはこれで一つの完成形だ。
そうではなく、手修正だと漏れる、だからコンパイラがそれを検出する、というのも一つの手だが、(C++)
漏れる漏れない以前に、関係ないところは修正の必要がそもそも無い、というのも一つの手だよ。(JavaScript)
ちまちま全修正するのが面倒だし危険だから、
受け側で引数違い毎にラップ（オーバーロード）してたらなんだかなぁ（俺的C++)、
みたいなのとは発想が逆だった。 async/awaitはJavaScriptにもあるが、あれはC#とかで必要なのであって、JavaScriptでは要らないね。
理由は、
・外側関数（上位階層）の変数は全部クロージャになっていて読み出せる。
・関数はどこにでも書ける。
から。C的に関数毎に変数が完全に分離している時にはasync/awaitでないと変数が共有出来ないけど、
JavaScriptの文法だとcallbackでも変数共有出来るから、要らん。具体的には、文法は適当だが、
function someTask {
var x = xxx;
var a = await funcA(x);
var b = await funcB(a,x);
}
みたいなのを、
function someTask {
var x = xxx;
var a, b; // 共有変数は上位で宣言しておく。これでクロージャから捕捉出来る。;
function funcA(){}
funcA(funcB); // funcBはcallback、funcA内でxは使える、aにも書ける
function funcB(){} // funcB内でa,xは使える、bにも書ける
}
だからawait毎にぶった切ってcallbackしても、上から順に実行するだけの単純ソースにしかならない。
JavaScriptなら、どっちでもいいや位でしかないんだよ。
C#ではこれができないから、async/awaitが必要だってだけで。
ただ俺もcallbackと言ったがこれは間違いだった。VC++では非同期のcallbackはやってないわ。
ウザイと思ったのは関数ポインタを差し込む時に型チェックがあることだった。
上記の通り、JavaScriptでは関数ポインタでさえあれば引数の型と個数は関係なく呼んでくるので、
関数ポインタを差し込む時にいちいち考える必要がないんだよ。
そして機能追加は追加パスだけの変更で済む。
C++の型チェックだと変更がソース全体に及ぶしこれを断れない。
引数の型とか個数を間違えた場合、普通は根本的に動かないなら、テストでは当てさえすれば検出出来る。
そんな簡単なエラーチェックの為にコンパイルを通すだけの為にいちいち型を合わせたり、
変更がソース全体に波及するのが危険でウザイって事。 > コールバックの処理が適切なことはテストとかで保証するとか考えると
どのみちテストはやらんと駄目でしょ。と言うか、逆に、
「コールバックの処理が適切なことは『型検査』で保証する」ってのは無理でしょ。
Haskellのキチガイ共はそういう思想らしいが。
「型安全」ってのはバグの一つの形「インタフェース（接続部）の間違い」を検出するだけであって、
処理の中身が間違っている場合は全く検出出来ない。つまりテストは省略出来ない。
それで「型安全」にするために払うコストと、それによって受ける恩恵を考えた場合、
俺にとっては「無いよりマシ」程度で、「投げ捨ててまで」って程の価値はないね。
とはいえtypoを検出する機能だけは欲しいんだが、逆に言えばそれだけで十分だ。
>>160
多分、constで最適化ガーってのはやっぱり無いんだよ。
想定されるケースはそちらの挙げたとおりで、
void someFunc(){
// (A)
hoge(&a, &b); // (B)
// (C)
}
で、(B)で変更されないことを保証されれば、
(A)時点の&a, &bのキャッシュ（というかローカル変数に取ったもの）が
(C)でも有効です、ってだけだが、そもそもこのケースがないだろ。
自関数内で変更してるかどうかはコンパイラには明確に分かるんだから、
考えられるのはこのように他関数をまたいだケースなんだけど、
それなら最初から(A)(C)(B)の順に処理しろ、でしかないし。
(（B）で変更されるから(C)は（B）の後ろなのであって） ただmsvcrtを使うということはvcがサポートするC規格に引きずられるのを留意しておくこと
最新のmsvcrtでもたしかC99止まりでinttypes.hをインクルードしてもPRId64とか使えない
C11の機能が欲しければ素直にlinux+gcc|clangの環境をオススメする 最適化かけないと通るけど、最適化かけるとセグフォ
プリントデバッグしたらプリント文置いたり減らしたりするだけで最後に表示されるものが変わる
なんだこれ >>185
一切使ってないっす……
引数で配列の大きさ渡してるのがまずいのかもしれない 配列の代入とは関係ないところで死んでるっぽいこともあるんだけど、それでも配列の範囲外アクセスとかあるものかなあ…… >>188
そこそこ依存ファイルあるし、一応研究室の研究で書いているので、失礼ながらソースは上げられないです よく考えたらそんな状態で相談することが間違いか
やっぱり撤回します。スレ汚しすいませんでした 最適化の有無で変わった事と言うと、この前こんなことがあった。
(以下の A, B は typedef された構造体)
A *p = NULL;
B *q = NULL;
if (...) {
A x;
/* x の初期化などをする。 */
p = &x;
}
if (...) {
B y;
/* y の初期化などをする。 */
q = &y;
}
この後で p が NULL でなければ p の指す先を使おうとして死亡。
まあ、ブロック(というかスコープ)から外れた所で使ってるんだから当然と言えば当然ではあるが、
最適化しない場合は x, y はその他のブロック外の自動変数と同じようにスタックに領域が取られ
ていて変化する事がなかった。そのため内容は保たれた。
しかし最適化したら A の領域は A のあるブロックから外に出たら破棄されたと解釈され、そして
B のあるブロックの B の領域として上の A の領域を使用するようになっていた。そのため x と y
の指す先は union のように重なってしまっておかしくなったと。 >>179
いや、もっと単純に、APIの仕様変更で取得できる情報や型が変化したけど、エラー処理とか偶然うまく見える場合とかは目視では見落としがあるよねということ
テストを書く前に簡単に修正箇所がわかれば便利みたいな話だけど、まぁ、やり方やライブラリによって違うのかもね
少なくともAngularとかはTypeScript採用だし、型あったほうが便利派は少なからずいるよとだけ >>180,181
C#でも同じようにラムダ式やローカル関数で変数をキャプチャできるぞ
というかC++でもできるはず
コールバックは階層が増えたりエラーや例外処理、分岐などが生じるとどんどん複雑になって単純には行かなくなる
それを解決するのがPromiseで、それを更に単純に記述するのがasync/await
新しいライブラリとかはPromiseで返すのが当たり前になって来てるし、今後の言語もasyncに舵をきるんじゃないかな
>関数ポインタを差し込む時にいちいち考える必要がない
C++でどうやって実現すんの？
char *を受け取る関数ポインタにとconst char*で受ける関数ポインタを入れてエラーにしなかったらややこしくて危険なだけでしょ
コンパイルエラーじゃなくてテストで保証するとになればなおさら変 >>181
>最初から(A)(C)(B)の順に処理しろ
何言ってんだBとかCに副作用があるなら入れ替えちいかんだろ
コードは適当だけど、
void test(a,b)
{
hoge(&a,&b);
piyo(a+b);
}
test(1,2)
みたいに静的に確定するなら、piyoの引数をコンパイル時に計算してpiyo(3)みたいなコードをはいてくれたりもする スタックフレームの破壊は明白なんだから関数内で宣言してる配列全部の
範囲チェック入れてみな やりそうなこと
□ 要素数 n=10 の配列 int array[10];
アクセス可能なのは array[0] 〜 array[n-1] まで
なのに array[n] を利用してる
□ 文字列による配列の初期化で 終端記号(\0)含んだ分の領域を用意してない
× char text[3] = "123"; // 終端記号含めると 4要素の空間が必要なのに 3要素にしてる
○ char text[] = "123"; // コンパイラにおまかせで
□ 要素数を求めるのに sizeof(a) / sizeof(a[0]) を使ってるけど
そもそも論で a が配列ではなくポインタだった為
処理したい要素数が渡っていない >>183
研究室から出せない秘伝のソース、
なら特殊なハードウェアで、実はvolatileが欠かせない、とかじゃねえの
ソースの向こうのハードウェアが実は核分裂制御装置でした！……とかでももう驚かねえよ 半分使って、半分継ぎ足しを繰り返すと79回目あたりで
アボガドロ定数の逆数くらいに薄まるよね 何か、酵母とか菌糸とか入ってて熟成されるんよ。ただ混ざるだけじゃないんよ。 >>194
> 型あったほうが便利派
半分くらいはインテリセンス目当てだと思うぞ。
そして俺自身も型を否定はしないが、C++の型検査も過剰気味だと感じている。
だからconstは使ってないし、関数ポインタの型検査もウザイ。
つーか、型を間違えること自体がほぼ無いだろ？
引数の順番を間違えたりした場合に型検査で引っかかるってだけで。 >>195
> ローカル関数で変数をキャプチャできるぞ
ローカル変数しかできんだろ。しかも明示しなければならない。(全指定も出来るが）
JavaScriptの場合は上位関数の変数をどこまでも辿れるので、（レキシカルスコープ）
入れ子になっていても破綻せずに分解して展開出来るんだよ。
C++方式の場合はawait内にawaitが入れ子になっていると、展開出来ないだろ。
> コールバックは階層が増えたりエラーや例外処理、分岐などが生じるとどんどん複雑になって単純には行かなくなる
> それを解決するのがPromiseで、それを更に単純に記述するのがasync/await
これは通説だが、俺はこれが嘘だと思ってるんだよね。
JavaScriptで言われているcallback地獄ってのは、非同期処理をその場で入れ子で書いている。
それよりawaitの方が見やすいってのは、上から順に読める形式だから。
でも>>180に書いたとおり、JavaScriptの文法ではcallbackを常に展開して書けるので、
その気になればawaitと同じ順で処理を書けるんだよ。（非同期がネストしない）
つまり、レキシカルスコープ＋クロージャなら、awaitが無くてもawaitと同じ順で処理を書けるわけ。
C#やC++はレキシカルスコープがないからawaitが必要なだけ。
だからここら辺は実は文法との相性もあるんだよ。
C++はそんなのお構いなしに何でもかんでも入れてる感じだが。
（とはいえ、選択肢が増えること自体は悪いことではない）
> char *を受け取る関数ポインタにとconst char*で受ける関数ポインタを入れてエラーにしなかったらややこしくて危険なだけでしょ
そりゃconstの有無をテストで落とすのは無理だろうさ。
まあ、俺はconst自体が意味無い（無駄な手間が増えるだけ）という認識だが。
（ただし本当の意味でのconst（「定数」）の場合は使う。Cならマクロで与えていたケースとか）
そもそも君はどこまでconstを使っているんだ？
C++のconstは「定数」ではなく「再代入禁止」だ。
現実的には無駄に再代入することもないので、ローカル変数の大半にconstを付けられるはず。
これをやっているのか？
やっていないのなら、君自身も「過剰な型検査」が存在することを認めていることになるが。 >>196
コードを流用するとね、
void test(a,b)
{
// (A)
hoge(&a,&b); // (B)
piyo(a+b); // (C)
}
で、(B)をconst指定にした時のみ(C)で大胆な最適化を行えるケースは、
・(B)が(C)に影響する副作用を持っていないと「const指定した時のみ」分かる
場合だけだが、これはconst指定ではどうにもならんだろ。
これはプログラマが上位の仕様（test関数の仕様）として規定するものであって。
例えば構造体配列で、(B)は[i]への書き込み、（C)は[j]からの読み出しで、i!=jが上位で保証されているとか。
この場合は、プログラマが最初から(A)(C)(B)の順に書けるんだよ。
そうではなくて、(B)が（C）に対しての副作用を持つ可能性がある場合、つまりi!=jが保証されていない場合、
当然(B)(C)の順にする必要があるけど、
これをconst指定で最適化(=(B)が(C)に対しての副作用を持たないことを保証）することは出来ないでしょ。 >>204
ん、C++のconstは、Cのconstよりも「定数」だぞ
int const a = 1;
switch(1) [
case a: ; //valid in C++, invalid in C
} case ラベルに const な変数の変数名
C++ ならばリテラルと等価となりセーフ
C は変数のままの扱いでアウト C++は使える範囲を広くしただけでconstの意味はCといっしょ
constによる最適化の話には関係しない 違う
constはもともとC++発祥のもので、
Cでパクるにあたり微妙に改変した
constは最適化に関係するが
今この流れでは最適化とは全く無関係の話をしている ttps://regmedia.co.uk/2011/02/18/dennis-richie-and-brian-kernighan-pdp-11.jpg
こういう時代の揮発性のメモリ
揮発しないメモリもあるんですよ コード中の文意では変わってなくても、他の要因で変わる可能性あるような
割り込みやマルチスレッド等で共有してる変数とか > C++のconstは「定数」ではなく「再代入禁止」だ
代入と初期化を混同してませんか 外からは見えないように、そして、なくさないようにするエロ本 一口にstaticと言っても、そのキーワードは用法で意味が変わるからなあ static に背負わせすぎな気がする
関数内変数の static
関数スコープ外の static
C++ ならばクラスメソッドのstatic
クラス変数の static もあったかな‥多すぎだ‥ ポインタ関連で*と&の記号を使っているのも
初心者を遠ざけているよな
素直にpointerとかrefとかの予約語作ればよかったのに >>225
もともと高級アセンブラとして生まれた経緯を考えたら、ポインタ関連の基本的な記述のためにはくどいキーワードではなく最もシンプルな演算子が割り当てられるのは自然なことだと思う。 >>225
C# の ref 宣言のように，宣言だけでなく呼び出し側でも ref が必要だという文法はあってもよかったかな >>228
ISO/IEC9899:1999
6.7.5.3 Function declarators (including prototypes)
21 EXAMPLE 5
void f(double a[restrict static 3][5]); 以下の三つの操作に違いはありますか
NはMと比べて十分大きいとします
char s[M];
wchar_t ws[N];
mbstate_t state = {0};
// 1
scanf("%s", s);
wbsrtowcs(ws, &s, N, &state);
// 2
scanf("%ls", ws);
// 3
wscanf(L"%ls", ws); ■ このスレッドは過去ログ倉庫に格納されています
