TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【Alloy】形式言語による仕様記述【VDM】
Excel Python 質問スレ
mallocの後にfree不要と言うバカいるの?Part2
Message Passing Interface (MPI) 統合スレ
テストしにくいコードをテストする方法教えて下さい
Perlについて
C++相談室 part135
■暗号技術【ROUNDsurea】■
わんくま死亡か？
Perlは10年後の2023年には消えてなくなる
C言語相談室(上級者専用）
- 1 ：2018/03/02 〜 最終レス ：2019/07/04
- C言語の話題のみ取り扱います。C++の話題はC++スレへ。
上級者専用です。10,000行程度のソースを扱えない人は以下スレへ。
C言語なら俺に聞け
https://mevius.2ch.sc/test/read.cgi/tech/1519046038/
適宜以下を使用してください。
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/
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
- 2 ：
- 修正部分について
老害が来てもウザイので「10,000行程度のソースを扱えない人は」と現在状態に変更した。
上級者には一朝一夕ではなれない。
初心者は文法事項にばかりに目が行きがちだが、
今日覚えれば明日から使える文法事項で練度を測るのはナンセンスだ。
- 3 ：
- チムポから膿が出てるんだけどやっぱ病院行ったほうがいいかな？
1週間くらい前に天神でナンパした女から貰ったらしい・・
- 4 ：
- エンディアンとアラインメントとメモリバリアについて完全に理解していることが最低条件です
- 5 ：
- >>3
泌尿器科、内科、性病科
- 6 ：
- 言語の上級者じゃなくて
ハード知ってるかどうかだけじゃね
- 7 ：
- 年齢制限はあるんですか？
- 8 ：
- >>7
年齢制限自体はないが、実質的には30前後になるだろう。
プログラミングにおいても「10,000時間の法則」は当てはまる。
勿論こなせばいいというものではないが、ある程度こなすことも絶対的に必要だ。
この点において、学生が「上級者」の域に達していることはほぼあり得ない。
一般的には、10,000時間=１日8時間*週休2日で50週*5年だから、
実働率の低さ、あるいはその分の残業等も含めて、職業マなら5-10年でここに至る。
これは主要なプロジェクトの公開時の年齢を見ても分かる。
BASIC: Bill Gates (20)
Linux: Linus Torvalds (21)
Turbo Pascal: Anders Hejlsberg (23)
PHP: Rasmus Lerdorf (27)
Java: James Gosling (30)
GNU Emacs: Richard Stallman (32)
Ruby: Matz (32)
C++: 禿 (33)
JavaScript: Brendan Eich (34)
Python:: Guido van Rossum (35)
Pascal: Niklaus Wirth (36)
ゲイツ、リーナス、ヘルスバーグは天才と称される人々で、確かに早い。
ただこれらは「実装」しただけであり、新しい「仕様」を考えたわけではない。
それ以外は軒並み30前後からだ。
これはつまり、いい仕様を考えられる人(≒上級者)が2周目に開発した結果だということ。
1周目は何かのプロジェクトに混ぜ込まれてそこで10,000時間こなしているか、
或いは1周目から新規プロジェクトを立ち上げたがゴミで終わった、ということ。
（１周目の未熟者が立ち上げたプロジェクトは物にならなかった、ということ）
なお、ラスマスはいろいろと語録が有名だが、こう並べると実は凄い。
- 9 ：
- 会社に入って惰性でやっている奴も多いが、
もし職業マになっても学生の頃の情熱を持ち続けて日々努力を重ねるなら、
多分30前後で「ああ、大体分かっちゃったな」と思えるときが来る。
そのときには、10,000行は普通に扱えるようになっている。
逆に、10,000時間をこなしていない状態で、10,000行を扱えないのは当たり前。
それは絶対的に練習が足りないだけ。そして学生はこれに該当する。
練習すればいいわけではないが、練習もしないと上手くはならない。
お前らが今一生懸命書いているコードも、数年後に見直せば全くのゴミだと分かるだろう。
そして問題なのは、その2周目に何をするかで、
まあ大体会社にガッツリ組み込まれ、公私とも忙しくてそれどころではないが、
そのときにOSS方向にも立ち上げればMatz位の立ち位置は狙えるということ。
日本の問題は「プログラマ35歳定年説」の通り、
せっかく10,000時間こなした熟練者がマネージャになり、全くコードを書かなくなってしまうこと。
結果、未熟者だらけでコーディングしており、当然生産性は低く、給料も低くなる。
だから給料を上げる為にはマネージャに昇格するしかない、という悪循環となっている。
一方、海外では、プログラマの人件費は高く保たれており、（日本の2倍）
結果、熟練者もコーディングし続けることが可能で、生産性も高く保たれ、給料も高く保たれている。
これじゃ海外に勝てないのは当たり前だ。
詰まるところ、日本ではヘボが、海外ではエキスパートがコード書いてるんだから。
ただこんな愚痴言っても始まらないのだが、とにかく俺がお願いしたいことは、
お前ら初心者がここを読むのは勝手だが、投稿はして欲しくない、ということ。質問も含めて。
君らだって、大学の研究室に幼稚園児が乱入してこられても困るだろ。
上級者/熟練者も、上級者/熟練者のみで効率よく話せる場を必要としていて、
初心者が乱入してこられると困るんだよ。
ただ逆に、俺は初心者が初心者なりの考えでワイワイやることも必要だと思うから、
君らが従来スレでやり合う分には文句を言わない。（このスレが続いている限り）
俺は自ら進んで隔離されるのだから、お互い棲み分けって事でよろしく頼む。
- 10 ：
- 今現在、また今後とも、Cが使われるのは極めてプロフェッショナルな領域のみだ。
つまるところ、「Cみたいな開発効率の悪い言語を使う理由は、Cじゃないと駄目だから」でしかない。
C以外の言語も充実している今、
「プログラミング初心者」が「独学」でCを始めるのは俺は全く勧めない。他言語にしとけ。
学校等でCを選択しているのなら、それは教師側の都合だから、（知らない言語を教えられないだけ）
逆に言えば、その先生に聞けばいい話であって、俺らに質問してくること自体が間違い。
つまり、
・直接聞ける相手がいるならそっちで聞け、それの方が絶対早い
・プログラミング一般について質問があるようなら、まず他言語で一通り学んでからCに挑め
・C特有事例で質問があるのなら、従来通り質問スレを使え
でしかない。敢えて匿名掲示板上の上級者に回答を求める場合は、例えば
・自分としては一通り出来るつもりである
・ところが上司の方針に全く納得できない。これ本当にそうなのか？ただの老害か？
という場合であって、具体的には
> 職場の人がみんなそうで、毎日変数一つにまとめろとかクラス一つにまとめろとかいろんな人から怒られたりして気が狂いそう
> javaから入ってオブジェクト指向学んだんだけど、javaと同じようにオブジェクト指向で作っちゃいけないの？
> 戻り値列挙型で定義したら戻り値二択にしてboolで返せって、戻り値によってswitch文で処理書いてたんだけどそれも全部捨てろって
> 俺そんなにおかしいもの書いたのかな？
> 共通化したりするとわかりづらい読みづらいって言われる
> https://mevius.2ch.sc/test/read.cgi/tech/1467992113/10-
これとかだね。彼は非常に上手く2chを使った。さすがにこれを職場でやるわけには行かんし。
- 11 ：
- ム板じゃなくマ板でやれって内容だな
- 12 ：
- 上級者は自己解決できるから、このスレは洋ナシなんじゃね？
- 13 ：
- >>12
その指摘は当たっている。
上級者がわざわざ質問する事はほぼ無い。当然流れない。
でも俺はそれでもいいと思っているんだよ。
上級者が集える場所がある事が重要。
何であれ、人数は初心者>>>中級者>>>上級者だから、
Web上のあらゆる場所は初心者で埋め尽くされてる。
例のコピペ「コミュニティの一生」で言えば、上級者は常に迫害される側だ。
だからこそ俺は上級者用の場所を確保しておきたい。
歴史的経緯から、上級者が人数的に一番多いのはCだと思うし、まずはお試しだ。
回答者の人数も揃っているし、俺はちょっと俯瞰しようと思っている。
C言語スレ、元々は見るからに年齢層が高かったのだが、
ここに来てド初心者が押し寄せてるのは何なんだ？春休みが理由とも思えないし。
あとやっぱり、話題になっているのは例外だけど、
あれって結局の所、今現在他言語でもいい解を見つけられてないよな？
Goは一周回ってCっぽくなってるし、
C++の「例外安全も型に含める」ってのもC++っぽいやり方だが、
相変わらず「そこまでやるか？」だし。
- 14 ：
- 上級者のおこぼれに預かろうというやましさを感じています
- 15 ：
- プログラミングは実装の手段に過ぎない。それは問題解決、「ソリューション」でなければならない。
プログラミングが複雑になるほど、全体を俯瞰する視点や、問題解決するための理論や設計が重要になる。
あなたは、C言語で何の問題を解決するのか。
- 16 ：
- というわけで、、、みんなで、C言語で実現できることを考えてみよう。。。
- 17 ：
- マイクロソフト関係者がChecked Cなるものを作っている。セキュリティが向上するらしい。#includeの代わりにコードをモジュールで管理するようだ。
- 18 ：
- >>16
ちなみに俺はそれは逆だと思っている。
他言語で出来ることは他言語で、CでしかできないことをCで、だ。
スクリプト言語は本当に色々楽なんだよ。だから俺はJavaScriptが気に入っている。
例えば、以前出ていたオセロの盤面とかも、
多分20-30行で割り込みハンドラ含めて用意できる。
勿論ブラウザに乗っているからだが、Cではこの量では無理だ。
https://mevius.2ch.sc/test/read.cgi/tech/1519046038/211
だからアプリ全体やGUI（=速度が要らない）をCで組むのはただの馬鹿で、
速度的に問題がある部分だけCのDLLを呼ぶ方向にソフトウェア全体がなっていくのではないかと思っている。
cythonやNumPyとかがまさにそうだが。
- 19 ：
- >>17
型チェックかと思いきや、境界チェックか！これは行けるかも？
現状Cの最悪なところはそこだからね。
- 20 ：
- 文章を単語に分け、文字に分け、それをラティス(lattice)、網目構造にする。それのn-gramと意味構造と発音記号とアクセントと音声データを結び付け、
深層学習を真似て関係性をマッピングする。それで、word2vecみたいなことができないだろうか。
- 21 ：
- word2vecよりも優れた成果を求めている。ここに機械学習の理論家は居ないだろうか。
- 22 ：
- >>16
それは発想が逆なのでは？何かを解決する道具の内の一つとしてプログラミング言語が作られているわけだから。
- 23 ：
- 片山博文って、ググって最上位に来る人？
本物？
- 24 ：
- ここの中の人か
http://katahiromz.web.fc2.com/
- 25 ：
- >>24
見た。
すげー香ばしい…。
真正の「自称」研究家だわ。
- 26 ：
- >>24
「フォルダでプロンプト」を便利に使わせていただいています
http://katahiromz.web.fc2.com/fdprompt/index.html
- 27 ：
- shift＋右クリックはやっぱりめんどくせーの？
- 28 ：
- http://mevius.2ch.sc/test/read.cgi/tech/1519046038/587
これは正しい？
- 29 ：
- N1570 と整合する。
- 30 ：
- >>27
最近のWin10のは、コマンドプロンプトじゃなくてPowerShellになるらしい。
- 31 ：
- >>28
知らん。
というかお前らも無意味だと思いつつ続けてるんだろ？
元気なのはいいことだとは思うが。
- 32 ：
- あれ？そういえばこのスレ、過疎ってね？
- 33 ：
- 上級者が初心者/中級者と比べて圧倒的に少ないのは自明だし、過疎るのは仕様。
- 34 ：
- てか、どの程度からを上級者と言っていいのか決まっているわけでもないし、
そもそもそういう人がこのスレを見に来るとは限らず、また見ても何かを書きたいと
思うとは限らない。
- 35 ：
- で？
- 36 ：
- こんなところで相談する時点で上級者じゃないしｗ
- 37 ：
- >>36
>>12
- 38 ：
- 老人ホーム
- 39 ：
- 雪ホーム
- 40 ：
- お達者クラブ
- 41 ：
- Cのnull安全がRustだと聞いたがRustはそもそもC++の後継であってCは念頭に置いてないと思うんだが
詭弁かな。
- 42 ：
- そりゃ認識を間違ってるだろ。
https://techacademy.jp/magazine/8735
https://www.tiobe.com/tiobe-index/
C++erはCの後継はC++だと思っているし、俺もそうだと勘違いしていたが、
実際はCとC++は別枠で扱われていることが多いし、その方が妥当だ。
今のスマポ(ｷﾘｯなC++とCは別物だ。
文法的な点については、全言語の半分くらいはC後継だし。
C->ObjectiveC->swiftこそが正統Cの系統だ！と彼らが考えていても不思議ではないし。
Rustを触ったことはないが、通常議論されているのは、
・RustはCを代替できるか？
であり、「C++を代替できるか？」なんて言っている奴はいない。理由は、
・C++は現在も旺盛に進化中であり、後継を必要としてない(C++XXの後継はC++YY)
・C++ではCを代替できないのは確定済み(Linux等）
で、どうにかしたいのはあくまでCであり、C++ではないからだろ。
- 43 ：
- 実装や機能を見る限りについてはRustはCよりC++に寄ってると思うよ
Cにこの抽象度の機能をもたせると必然的にそうなるという説はあるけども
何が言いたいかと言うと後継という立場について、そうであったC++は少なくともCの領域を完全にはカバーしなかった訳で、そのカバーしなかった領域を(C++に寄っている)Rustがカバーしたかと言われるとNoだと思っているからRustはCよりC++の後継という方が妥当に思えるという話
- 44 ：
- 申し訳ないが俺自身がRustを知らないのでつっこんだ議論は空回りしてしまうが。
> そうであったC++は少なくともCの領域を完全にはカバーしなかった訳で、
> Cの領域
これをどう捉えるからだよ。
少なくともC++の連中は「カバーしている」と思っている。
そしてLinusは「C++は全くのゴミだ」と思っている。
良くも悪しくも、Cはミニマムで美しく完成している。全く無駄がない。
そして各後継言語はこれに対して、「便利機能」を追加しようとしてきた。
C++は「クラス」「型検査」「例外」を導入した。
結果、CならCキャストやマクロですぱっと書けるところをグダグダとテンプレートを引き回したり、
或いは間接呼び出しでいちいち実行速度が遅くなったり、
はてまたスマポ(ｷﾘｯでGCの再実装を盛大にやらかしている有様だ。
Linusの意見はごもっともだ。
Rustの謳い文句は、「実行速度」「ゼロコスト抽象化」等であり、
C++の失敗を見て学んでいることは明白だ。
だから、後継になろうとしている相手はCなんだよ。C++ではなくてね。
とはいえ、そちらの指摘の通り、実際の仕様がCよりもC++に近くなるのは必然だ。
普通にやれば、C++で成功したところはそれをもらって、
C++で失敗したところは新たな方法を提案して、となるだろうからね。
Rustはぱっと見、スマポがデフォで生ポは例外的使用か？
C++は歴史的経緯から「言語的には」生ポがデフォでスマポが追加されている。
これは、「『アプリケーション用の』プログラミング言語」としては間違いだ。(Linusもそう言っている）
結果、C++erは「デストラクタ」「スマポ」「=のオーバーロード]をこねくり回して苦労しているが、
本来はこれらは言語側で完全に隠蔽すべき物だ。（ユーザが書く必要なんてない）
そしてRustはそれをやり、結果的にnull安全なんだろ。
正しい方向への進化だよ。(分岐元がCかC++かは何とも言い難いが）
C++はアプリケーションの動作と関係ないところで無駄に苦労するでしょ。俺はあれが嫌い。
- 45 ：
- >>44
その言い方、Rustを結構使っているように見えますが、違いますか？
Cが「ミニマルだ」ということには——少なくともISO C99規格を見るに——あまり賛同できないんですが、
それはまぁ、置いておいて、私がRustを触った限り、あれはC++の代替に見えます。
C++が現在も（規格を拡張する方向に）積極的に開発されているのは分かっていますし、
「だからRustが取って代わる必要はないのだ」という理論的帰結も理解できますが、
ポインタの安全性ややはり名前空間の宣言あたりを見ると（あくまで触りですが）どうしてもC++の文法を彷彿とさせるの
構造が多いように思いますね。
- 46 ：
- あ、すいません。一行目で使ったことがないと断られていました。
いや、なぜ確認しなかったんだろう、失礼しました。
- 47 ：
- >>45
> あれはC++の代替に見えます。
それは正しい。
というか、「後継」と「代替」はこの場合明確に区別して使われるべきだ。
・「○○の後継」---○○言語を発展させたもの。
上位互換であり、○○言語と共に使うことを考慮されている。
・「○○の代替」---○○言語の代わりに使うもの。
基本的に○○言語と一緒に使うことはない。排他的使用となる。
Rustの謳い文句は、「効率的なCバインディング」であって、
「効率的な『C++』バインディング」ではないんだよ。
CのDLLは当然呼べるが、C++のDLLを呼べるように出来ているか？
C++の「後継」と言うのなら、基本的にはC++の資産を全活用できる方向になってないといけない。
ただしそもそもC++は「後継」用のAPIを整備して無いと思うんだが。
C++の例外「実装」についてググッても、まともな文献が出てこないだろ。
おそらくあれは「実装」まで言及した仕様ではなく、「言語としての動作規定」しかされてないんだ。
(元々C++はそういうノリだし）
だからtry-catchを含んだ関数をDLL化できて他言語から呼べるかはかなり疑問だ。
勿論、昔からの課題だから今は解決されているかもしれんが。
> Throwing C++ exceptions across DLL boundaries is only possible when all modules use the same C++ runtime,
> in which case they share a heap as well. But this can be a maintenance burden,
> especially when libraries from multiple vendors are involved, so it is discouraged.
> https://stackoverflow.com/questions/5107948/throwing-c-exceptions-across-dll-boundaries
だからCのDLLは他言語(Rust/Ruby/C++/C#)等から直接呼べるが、
C++のDLLを呼べます、と謳っている奴はいないだろ。
この点において、C++は後継言語の存在を許していない。
だからRustはCの「後継」であり、C++の「代替」というのが妥当な見方なんだよ。
実際、RustがあればC++を使う意味がないだろ。
- 48 ：
- Cは大規模コードに対するサポートが全くない。
とはいえ、「やれば出来るだろ by Linus」なのは事実だが、実際それでは辛いわけで、
コンパイラに任せられるところは任すという方向で上手く手抜きできるように進化させたのがC++だ。
Rustも同じ方向なのだから同様の物になるのは当たり前。
当然、どちらかを使用すれば事足り、RustとC++は排他関係になる。
つまり、RustはCの「後継」であり、C++の「代替」だ。おそらくここまでは大体の人が納得するはず。
問題はCの「代替」にもなり得るか？という点であり、だからそこが議論されているわけだ。
今現在もCを使うメリットは速度面しかない。したがって速度面のデメリットがなければ良く、
「ゼロコスト抽象化」等、速さにこだわっているのはそこなんだよ。
ただ俺個人としては、全体を一つの言語で書く必要なんて全くなくて、
NumPyのアプローチ、つまりどうでもいいところ（9割以上）はスクリプト言語で書き、
必要なところだけCのDLLを呼ぶ、というのが正しい気がするが。C#もこの方向だね。
この場合、リソース管理をGC言語側に任せられ、
また個別関数単位での切り出しになり、
DLL内関数はお互い独立(非依存)で行っても1,000行とかでしかなく、
Cでも全く問題にならないんだよ。
だからRustも微妙に中途半端な方向だとは思うが、
もし仮にCを代替できるのなら、それは素晴らしいと思うよ。
- 49 ：
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
8UTJJ
- 50 ：
- 114.149.223.252
- 51 ：
- RustはCの「後継」であり、C++の「代替」
これでRust周りの（宗教戦争じみた）論争の理由が理解できた。
- 52 ：
- NTB
- 53 ：
- NTR
- 54 ：
- ポインタってさ、「指示子」と和訳したら分かりやすいと思うんだが
そうしなかった理由ってなんだろ
それとも俺の感性がおかしいだけか
- 55 ：
- 昔、筧先生ってひとがいて…
- 56 ：
- >>55
kwsk
- 57 ：
- ちょっと10回言ってみ
言い辛いよな
- 58 ：
- え？ なに？ もしかして昔なにか荒れる原因になった ANDOR 問題のある人が使ってた用語なのか。
若いもんで知らなかったわ すいません。
- 59 ：
- 「指示子のgcc拡張」みたいな早口言葉モドキができて面白いかも。
- 60 ：
- 指示子の指示子
指示子の配列
配列の指示子
配列の指示子の指示子
指示子の配列の指示子
ダブル指示子
配列の指示子の配列 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
- 61 ：
- >>60
なんかおこられてやんの
- 62 ：
- こんなので目玉付くんだなω
- 63 ：
- C99（ISO/IEC 9899:1999）で，main()関数の型がintな理由ってどこかに書いてあるっけ。
今ふと，リターンコードって0から255の整数なんだから
uint8_t main(...
としても問題ないよなと思ってさ。
- 64 ：
- すまん。途中で送信してしまった。
そうするとコンパイラにmain()の型はintだと怒られた。
- 65 ：
- 型がintというのは決まってる。
実際の範囲は実装依存。windowsだと違ってなかったか？
- 66 ：
- main()が戻す値は呼び出す側の問題だとは思うが、その部分(crt0とか)は普通はC言語に合わせてintを
返してくると想定して作られていると思う。しかしその部分まで自作するというのであればなんでもアリではある。
https://en.wikipedia.org/wiki/Crt0
- 67 ：
- シェルが受け入れるコマンドの終了ステータスの値が0-255の範囲、
てのはUNIX系もDOS系も(珍しく)一致してるのね。
unsigned char の外に出ないことは間違いないわね。
ANSI以前の古いCでの「宣言なしに使われた外部関数はintの値を返す」
という仕様が、規格化したときに互換性の問題を生まないように
main()の返り値はintと決めたんじゃないかしら。
- 68 ：
- なるほど。まあ過去互換性は重要だしね。
ただ，CはPOSIXというOSの標準規格を定めてる団体が関与して設計されてるから「リターンコードは0--255。よってmain関数の型はuint8_t」と割り切ってくれてもいいのになぁ。
とか勝手に思ったりしてる。
- 69 ：
- まあintが妥当だろう。
しかし、_exit()に渡すのがintでwait()した時も一応exit statusはintだよな。
どこで上位ビット欠落させてんだ？
- 70 ：
- >>69
OSの中だ。_exit() はシステムコールだし。
まあでも UNIX 系 OS じゃないならこれは違っているかも知れない。
- 71 ：
- ちょっとCの範疇を越えた話になるけど
リターンコードが0--255ってどういう段階で決定されたんだろう。
DOSとUnixが同じ範囲のリターンコードを持ってるって、偶然とは考えがたいんだけども
- 72 ：
- unix等の先行者を参考にDOSを作ったんだから
- 73 ：
- DOSの終了ステータスはUNIXの仕様をそのまま使用だと思う。
UNIXの方は、子プロセスを作って別の仕事をさせるって定型処理で、
「親プロセスで子プロセスの終了を待つ」ためのwait()系の関数が、
・子プロセスが正常終了した場合は子プロセスの終了ステータス
・子プロセスが割込みで中断された場合は割込みの種類
という2つの情報を1個の返り値で戻すことと関係あるのじゃないかな。
1個の整数値を上位と下位のビット群に分けて別の情報として使うために
それぞれの情報量を1バイトずつに制限した、と。
- 74 ：
- UNIX板のおじさんに聞いてみたら
- 75 ：
- auto変数で char配列を可変長で動的に確保する方法は無いかな。
アセンブラレベルならスタックポインタを操作すれば可能だと思うが。
文字列処理の内部バッファとして入力に合わせたサイズを確保したいんだが、とりあえず今は固定長バッファとそれを超える場合は malloc でやってる。
- 76 ：
- alloca
- 77 ：
- >>75
gcc使うなりalloc()使うなりすればいい
とりあえず
vla c言語
で、ぐぐれ
- 78 ：
- >>75
alloca
標準ではないけどほぼ標準扱い。（殆どの環境で使える）
ただし realloca は無いので注意。
- 79 ：
- >>76-77
ありがとう、まさにぴったり。
言語レベルでの可変長配列は C11 から（オプションだけど）入ってるんだね。
90年代からメンテされてるコードだからそっちは使えなそうだけど、alloca を検討してみる。
- 80 ：
- >>79
環境わからんからなんとも言えんが組込みとかWindowsとか意外にスタックサイズがしょぼい環境あるから気を付けてね
- 81 ：
- いやいや、C99からだよ。C11でオプションになった。答える方はそのくらい知っとけよ。
まあ入力が小さいのが予め分かってないと使いにくい機能だよ。
- 82 ：
- >>75
その入力というのがファイルからの1行入力みたいなものならば getline() 使ってしまえば
自分で考える必要がなくて楽だ。
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/getline.3.html
- 83 ：
- 発端の >>75 の意図次第だが、free()しなくても安全に蒸発して欲しいとか、
ヒープの確保と解放の処理時間を嫌っての話ならgetline()はちょいと違うね。
文字数の予測が難しい入力を扱うにはとても便利なんだけど。
それにしても「上級者専用」って看板が架かってることを意識すると
このスレッドは書き込みにくいな。気後れしちゃう。
- 84 ：
- alloca
- 85 ：
- 動的確保が無難なんだよね。最後にfreeすればいいだけだし。
最近まで知らなかったんだけどscanfで%msで動的確保してくれるの便利だな。scanf自体はなかなか難しくて使いづらいが…
- 86 ：
- >>81
あ、C99で入ったのをC11でオプショナルに格下げ(?)されたってことか。
処理系によっては厳しい実装なのかな。
やりたいことってのは文字列のエスケープを含んだ組み立てなんだけど、使用するエスケープ関数がありものでその仕様は入力文字列長に対して2倍以上の出力バッファを与えないといけないことになってる（出力サイズを指定して打ち切らせることができない）。
実際に2倍に膨らむことは稀だし、エスケープするのも文字列中の一部なので、自分の処理で最終的に出す出力結果は論理最大よりかなり小さくなる（自分の処理は指定された出力長で打ち切る）。
まず来ることが無い事態のために論理最大の配列を取っておくのもどうかと思い、いい方法があるかここで相談させてもらった。
しかし想定外のことが起きちゃった時にどうなるべきかを考えてどうするかを決めるから、もしかしたら動的配列の意義が無くなって別の方法にするかもしれない。
この処理自体は高頻度で呼ばれるから、高速で省メモリそして内部的な都合での打ち切りは極力避けた作りにしたいって感じ。
いろいろコメントありがとう
- 87 ：
- あらかじめプールしておいて使いまわす
足りない時だけ臨時で増やす
- 88 ：
- ReactOSというOSでフォントエンジンの改良を行っているが、
Google Chromeというブラウザでおかしくなる。
何故かEIPレジスタがゼロになって、初回例外が発生する。KDBという付属のデバッガでトレースしたが、
どこの関数で例外が発生しているかわからない。
たすけて。。。
- 89 ：
- これがイシュー。
https://jira.reactos.org/browse/CORE-14926
これが問題のコミット。
https://github.com/reactos/reactos/commit/35f62fc5ba0b69e7335ff41400cb3b45660f4557
- 90 ：
- 晒しあげ
- 91 ：
- スタック破壊の可能性か。。。
- 92 ：
- >>85
> 動的確保が無難なんだよね。最後にfreeすればいいだけだし。
結局の所、結論としてはそうだね。
>>86
多分素直にmallocする関数をラップして使う方がいい。
仕様の動向自体は知らんが、
> 処理系によっては厳しい実装なのかな。
技術的にはこれはない。alloca相当（ポインタ相当）にすればいいだけなので。
ただ、間接アクセスになるから速度は落ちるし、
mallocに対しての利点は『自分で』freeしなくて済むことくらいしかない。
（『自分で』ソースに書かなくてよくなるだけで、速度上のメリットはない。
reallocaが無い為、最初のバッファ（＝サイズが不明）はヒープ上に動的確保するしかなく、
自分で書いてなくてもどこかでfreeされてるだけだから。なら最初からgetlineでもいいし)
ただ、そちらの実装は(おそらくバッファオーバラン対策で)一旦固定長バッファに取り込み、
その後alloca領域に対してのコピーか？
ならまあ一応freeしなくていい速度上のメリットは残るが、
一般的にはスタックサイズ管理のコストが増える方が問題とされ、その実装はないとも思うが。
結局、allocaもイマイチなんだよ。だから標準にもなりきれない。
- 93 ：
- >>83
>>1,13読んで以下にどうぞ。
C言語なら俺に聞け
https://mevius.2ch.sc/test/read.cgi/tech/1534430162/
>>12
>>89
それがこのスレの正しい使い方かもしれんね。
ぱっと見て分かるものでもないけどさ。
- 94 ：
- allocaとか動的サイズ指定の配列はスタックだから基本的にはmallocするよりは速いよ。頑張っても同等。
繰り返して呼ぶなら差が出るかもね。
- 95 ：
- ああ、言い直しておくよ。
allocaとmallocなら、
確保：allocaの方が速い
使用：同速(ただし初回からキャッシュが当たる分allocaの方が速い）
解放：freeの必要が無い分、allocaの方が速い
（ただし実装によっては上位でfreeしてるだけであり、同速）
管理：通常、ヒープサイズ>>>>>>スタックサイズの為、サイズ管理が必要
速度差が見えるような使い方が出来るのなら、ある意味大したもんだと思うよ。
- 96 ：
- スタックって確かスレッド毎に肥大化してくよね？
で、肥大化してもスレッドが停止するまで縮小しない
あってる？
- 97 ：
- 関数から戻るとき(エピローグ)にスタックは縮小することがある。
- 98 ：
- 実際のx86 CPUでスタックポインタを表しているのが、ESPレジスタの値。スタックサイズの増減はESPの書き換えに過ぎない。
- 99 ：
- 流れのついでに聞いてみたいけど、malloc はスレッドセーフでしょ。
てことは内部で排他をかけてると思うけど、となるとマルチスレッド下で malloc や free を多発させるとパフォーマンス的に良くなかったりしないかな。
言ってなくてごめんだけど、今回の処理はマルチスレッドで動くんだ。
なのでバッファはスタック上に取れると都合がいいという事情もあるし、特別な初期化手順や終了手順も用意したくないから事前に malloc して使い回すってのもやりづらい。
ちなみに動作環境は x86 linux だから、alloca は SP をズラすだけの非常に高速な実装になってるんじゃないかと想像してるから、関心は高い。
でも、最悪でもスタック上に収まるバッファという前提にするなら最初から論理最大サイズ固定のバッファで良くね？なんて話もあるから、実際にどうするかはこれから検討。
- 100 ：
- glibcのmallocならサブarenaから獲得してくるから性能問題にはならないらしい
100〜のスレッドの続きを読む
ふらっと C#,C♯,C＃（初心者用） Part142
音声合成プログラムを作りる
ふらっと C#,C♯,C＃（初心者用） Part141
2進数や16進数を覚える意味がわからない
【普通のやつらの】 Arc Language 0 【上を行け】
【統計分析】機械学習・データマイニング26
CVS導入スレ〜 Rev.3
関数型言語一般
仮想環境コンテナ総合スレ Docker、Vagrant等
プログラミングのお題スレ Part15
--------------------
ハッピーターンの粉を作ろうと思う。
APチャンネル ガリぞう Part5
【朗報】全てのパチンカスが納得する筐体特有の脳汁演出でランキングつけてみた。
レンジローバー・イヴォーク14
【ヒゲ面】Yanni【おじ様】
【コロナ日報】スペイン、死者4,089(+655)、感染者56,188(+8578) 死亡率7.3% 26日19時
【中央時評】 国益の時間と普遍の時間〜戦争を終わらせる努力をしないドラえもんの国[08/16]
イラストAC【フリー素材で収入】
【ブラタモリ♪】林田理沙アナ 第20楽章【おはよう日本♪】
toto総合 part140
三菱電機＆関連会社への転職
今剛
今こそ牛丼！
【このはな綺譚】此花亭の経営権を握って商売替えするスレ
★闘牌王スレその２４ 狂気な奴ら
花粉、襲来 マスクはない
長野の大学職場一般 パート７
学部学科選択を間違えて後悔してる理系いるだろ？
デジモンアドベンチャーtri.ネタバレスレ4
実写ゲーム総合スレッド
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
