【初心者歓迎】C/C++室 Ver.106【環境依存OK】

1 名前：デフォルトの名無しさん mailto:sage [2020/07/13(月) 13:51:48.09 ID:WBkWHxcT.net] エスケープシーケンスやWin32APIなどの環境依存なものもOK そのような質問は必ず環境を書きましょう 半角空白やタブでのインデントはスレに貼ると無くなります コードを貼れる所 codepad.org/ https://ideone.com/ 前スレ 【初心者歓迎】C/C++室 Ver.105【環境依存OK】 https://mevius.5ch.net/test/read.cgi/tech/1556142878/ 745 名前：デフォルトの名無しさん mailto:sage [2021/06/20(日) 22:56:11.58 ID:R7oo70Ox.net] ナンチャラカンチャラの人のdefine使用意図が無意味すぎてどうもc言語エアプなんじゃないかと疑う 746 名前：デフォルトの名無しさん mailto:sage [2021/06/21(月) 16:42:57.66 ID:iJjBc6fp.net] switchのやつは最後にbreakかfall throughってコメント書いとかないと文句言うチェッカとかありそう 747 名前：デフォルトの名無しさん mailto:sage [2021/06/29(火) 11:07:55.25 ID:HA4DrIsJ.net] do { int a; : } while(a); ↓ for(int a;;) { : if(!a) break; } でいいんじゃない？ 748 名前：デフォルトの名無しさん mailto:sage [2021/07/05(月) 16:13:31.07 ID:3/iVgePD.net] 別のところで質問したのですが、初心者歓迎スレのほうがいいと思いこちらで質問し直します。 Macのclang++でコンパイルしています。 cstdlibをインクルードしなくてもrand()が使えてしまうのですが、これはなぜでしょうか？ 749 名前：デフォルトの名無しさん mailto:sage [2021/07/06(火) 01:49:57.37 ID:w3zU8vH7.net] >>724 手元のM1のでやったら普通にエラーになるけど？ printf("%d",rand()); だけ書いたやつ。 clangでもデフォはエラーだったような。Ｃ言語の方はコンパイルオプションで通せる。暗黙の関数宣言。 すまん、役に立てなくて。 750 名前：はちみつ餃子 mailto:sage [2021/07/06(火) 05:58:16.49 ID:kwaneL8R.net] >>724 ヘッダファイルが他のヘッダファイルを内部で include している場合は有りうる。 たとえば iostream を include したら自動的に ios や istream なども include されることは保証された動作。 ただ、 cstdlib を (間接的に) include すると仕様で明言している標準ヘッダはないと思うので rand がどこかで勝手に宣言されているのだとしたら処理系の固有の動作だと思う。 -M オプションで (間接的に include されているものも含めて) 依存関係があるヘッダファイルを 抽出できるからそれで確認できるよ。 751 名前：724 mailto:sage [2021/07/06(火) 08:23:42. ] [ここ壊れてます] 752 名前：24 ID:9fUGxcs8.net mailto: >>725 ありがとうございます。M1のclangではエラーが返るのですか…。コンパイラのバージョンの問題ですかね？ >>726 ありがとうございます。-M試してみました。 インクルードはiostreamだけにしていたのですが、ぞろぞろヘッダーファイル出てきまして、その中にcstdlibもstdlib.hもありました。 iostreamのインクルードを外すと当たり前でしょうが、それらのヘッダーファイルは表示されなくなりました。 つまり、iostream以下のヘッダファイルの依存関係にcstdlibがいたということですよね？ これは処理系依存なのでしょうか？ [] [ここ壊れてます] 753 名前：はちみつ餃子 mailto:sage [2021/07/06(火) 08:56:08.30 ID:kwaneL8R.net] >>727 処理系依存だと思う。 iostream が暗黙に include すると仕様に明記しているのは ios, streambuf, istream, ostream の 4 つ。 https://timsong-cpp.github.io/cppwp/n3337/iostream.objects.overview あえていうなら cstdio の機能と結び付けるのが役割であるようにほのめかされている ので普通の実装なら cstdio も include することになると考えてもいいと思うけど、 それ以上のことについてはっきりしたことは書かれてない。 rand が必要なら (たとえ実態として間接的に cstdlib が include されていても) プログラマは明示的に cstdlib を include するほうがいい。 というか、そもそも論としてはいまどき rand を使うのは避けるほうが賢明な考えだと思うけどね。 754 名前：724 mailto:sage [2021/07/07(水) 08:49:49.95 ID:O+5oUfAp.net] >>728 なるほど、そもそも論まで含めてよくわかりました！ ありがとうございました！ 755 名前：デフォルトの名無しさん mailto:sage [2021/07/09(金) 19:37:14.99 ID:We+HIKc2.net] C言語にpthreadを使ってマルチスレッドにするときの初歩的な質問をしたいのですが、 大域変数を複数のスレッドが読み書きする部分はミューテックスでロックしないとマズい、という 説明はわかった気がします。 では読むだけの部分はどうでしょうか。単にスレッドが変数の値を読みに行った瞬間の値を 知りたいだけならば、別にロックはしなくても害はないような気もしますが.... プログラム内の 別の箇所で書き込む部分はロックして、おかしなことが起こらないようにするとして。 それとも読むだけの場合もロック（書き込む場合に使うじミューテックスでロック）は必要でしょうか。 756 名前：デフォルトの名無しさん mailto:sage [2021/07/09(金) 19:46:28.14 ID:TIX9j1Dy.net] 必要ないぞ 757 名前：デフォルトの名無しさん mailto:sage [2021/07/09(金) 21:27:55.69 ID:wrMb4YqN.net] 必要だぞ 758 名前：デフォルトの名無しさん mailto:sage [2021/07/09(金) 21:31:49.00 ID:RRTM5Oms.net] >>730 スレッド実行中に書き換わる可能性があるなら必要。 変数を読むといってもCPUは一度内部のレジスタに読み込まないと処理できないので、 スレッド１でレジスタに読み込む→スレッド2で変数を書き換える→スレッド1に結果が反映されない という事態が発生する可能性がある。 759 名前：デフォルトの名無しさん mailto:sage [2021/07/09(金) 22:32:02.32 ID:eGF9BJZ0.net] >>733 それ反映する必要ないだろ 単にスレッド1が先に読んだだけだし それより読み書きがアトミックでないなら読み出し時にも排他しないと書き換え中の変な値を読んじゃうかと 760 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 01:06:02.19 ID:iVyIfxP9.net] 書き換え後に古い値を取得してもええの？ 761 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 04:35:16.68 ID:jD2ZKaD3.net] ええ場合もある 「単にスレッドが変数の値を読みに行った瞬間の値を知りたいだけ」はそれでええ場合のように聞こえるな 762 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 05:28:04.15 ID:TJHT9gxK.net] ええ場合も何も読んだ後で書き換えられたのをどうやって反映させるつもりなんだよ… 763 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 05:33:10.76 ID:Tru2G6zE.net] 関連する操作すべてを優先順付きキュー経由にし 巻き戻し必要な操作にはジャーナル機能も入れ やり直し再キューすんのよ 764 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 05:36:14.97 ID:N1Z7W ] [ここ壊れてます] 765 名前：Bqy.net mailto: 別スレッドからflgをいじって停止できるように while (flg) {...} と書いても、{...}の内部でflgをいじってないなら、 最適化で単なる無限ループに書き換えられて、flg変えても止まらない、 みたいな話なかったっけ。 [] [ここ壊れてます] 766 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 06:47:09.06 ID:TJHT9gxK.net] >>739 それはまた違う話 volatile c言語 とかでぐぐれ 767 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 07:11:18.51 ID:JKFXuD7+.net] スレッドAが 16bit長の整数を書き換える スレッドBが 同じ16bit長の整数を読み込もうとしたとき 8bit長でしかアトミックな操作が保証されてないシステムだと 初期状態 0x0000　で　スレッドA が 0xFFFF と書き換える 　A書き込み 上位FF 　 (スイッチ) B読み込み 上位FF B読み込み 下位00 　 (スイッチ) 　A書き込み 下位FF こういうことが起き得るという話でいいんかな 768 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 08:27:22.56 ID:N9R+gZBb.net] >>734 いや、先に読んだだけっていっても、例えば i f (v==1) みたいな条件式を評価した段階では1だったけど、その先で急に2に変わった、とかだったらまずいだろw 769 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 08:34:33.02 ID:EesV0O7a.net] 質問者の文言が >単にスレッドが変数の値を読みに行った瞬間の値を知りたいだけ >読みに行った瞬間の値を知りたいだけ なので必要なし 以上 770 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 08:39:13.41 ID:fOJ6OsHP.net] >>742 何もまずくないだろ… 771 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 08:48:41.36 ID:N9R+gZBb.net] >>744 ifの中ではもう一度vの値を読んだときには2になってたりするわけよ vが1の前提で書いたコードの中に2を突っ込んだらまずいよ 772 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 09:11:07.28 ID:16vz6VAu.net] >もう一度vの値を読んだとき まずいのはこっちであって>>742のifや>>733自体は問題ないんでは。 773 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 09:15:23.13 ID:nctQkkF+.net] 質問者が言ってないことに加えて勝手に仮定を追加してまずいとか言ってる>>745はもう黙ってほしい 774 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 09:51:11.89 ID:6bm+w6Lu.net] まずいのは>>745の頭だったというオチw 775 名前：はちみつ餃子 mailto:sage [2021/07/10(土) 09:56:52.21 ID:11oc3t46.net] >>730 結論から言うとロックは必要。 同一のメモリに対するアクセスの少なくとも一方が書き込みである場合には衝突すると定義されている。 https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#4 その場合にはデータ競合が発生する。 https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#21 同時に起こりうるアクセスの内でひとつでも書き込みが存在したらそれはデータ競合の可能性があるってこと。 ミューテックスはミューテックスの所有権を取り合うことで競合を阻止する仕組み。 ロックというのは「ミューテックスをロックする (ロックしている間は自分がミューテックスの所有権を持っている)」 ということであって、対象となるデータそのもののアクセスを直接的に制御してるわけじゃないので、 書き込み側でロックするだけでは意味がない。 776 名前：デフォルトの名無しさん mailto:sage [2021/07/10(土) 10:17:52.46 ID:fOJ6OsHP.net] >>749 at least one of which is not atomic の意味ぐらいは理解してからレスしなよ 777 名前：デフォルトの名無しさん mailto:sage [2021/07/12(月) 08:43:59.78 ID:Y3qBMERg.net] >>749 質問者は衝突しても問題ないケースで排他は必要かどうかを聞きたいんだろ 778 名前：デフォルトの名無しさん mailto:sage [2021/07/12(月) 12:14:53.15 ID:uJpO0uZ2.net] 「衝突しても問題ない」＆atomicも使わない＝「データ競合となっても問題ない」＝「動作が未定義でも問題ない」なら 確かにロックは不要だけど。 779 名前：730 mailto:sage [2021/07/12(月) 15:19:59.68 ID:VxiBn2TN.net] 730です、どうもお騒が� 780 名前：ｳせしております。 どうやら読み出しだけのときも基本的にはミューテックスを使うべきのようですね。 私の場合は域変数をカウンタとして使っていてその値をログ出力する、というような状況で、 なんとなくミューテックなしでもいいかと思ったのですが、ミューテックスを使わない場合は 気持ち悪い値がプリントされている感じですかね。 一般的な状況では、ミューテックスを使わなくても実害がないかを考えるよりはちゃんと ミューテックスを使った方がよさそうですね... [] [ここ壊れてます] 781 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 17:41:58.36 ID:DZW75fJj.net] 「今値を書いてるから　書き終わるまで待て」と待たす相手は 次にそこへ書き込むヤツだけじゃなく そこを読込もうとしたヤツも対象にしとけば　ちゃんと書き終わった値が読込める 中途半端に書いてる最中であっても意図的に抜き出したいのなら　書き終わるまで待たずに読む そしてみゅーてっくすの激しい握り合い 782 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 19:15:08.97 ID:Cs3wNevb.net] >>753 単純なカウンタみたいなアトミックに読み書きできるような変数なら排他は不要だよ 783 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 20:10:22.43 ID:+UxqO86S.net] >>755 なんでそんな嘘を教えようとするの？ 784 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 20:55:03.74 ID:Cs3wNevb.net] >>756 >>749のリンク先読めばわかると思うけど競合が発生して結果が未定義になるのは > at least one of which is not atomic のケースね 785 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 21:33:13.25 ID:+UxqO86S.net] >>757 そこで言ってる "atomic" の意味は std::atomic<int> ならOKで int はダメという話なんだけど、 「単純なカウンタみたいなアトミックに読み書きできるような変数」って言い換えちゃったらどっちもOKに読めちゃうでしょ。 786 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 21:39:13.87 ID:Cs3wNevb.net] >>758 intがダメなのは>>741みたいなケースね > 「単純なカウンタみたいなアトミックに読み書きできるような変数」 でだめだと言うなら実例教えて 787 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 22:40:14.76 ID:31Jksjnm.net] 単純なカウンタがアトミックに読み書きできるかは 基本型の宣言だけではわからんから アトミック化の指示ができるならやっとけ　ということでいいんでないの？ 788 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 22:49:59.37 ID:Cs3wNevb.net] >>760 そのスタンスでいいと思うよ 俺はアトミックに読み書きできるケースなのに嘘とか言ってる>>756がなんか特殊なケースを知ってるのかな？って思ってるだけ 789 名前：デフォルトの名無しさん mailto:sage [2021/07/13(火) 23:59:32.08 ID:31Jksjnm.net] 指示ができない場合にはアトミックに操作できる保証なんてないから 排他したほうがいいぜって立場 790 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 00:44:44.53 ID:pCGEFvrX.net] >>759 生の int に複数スレッドから排他なしでアクセスしてたらその時点で未定義動作＝ダメなんだってば。 未定義動作となる場合に必ず期待に反するコードが生成されるわけでもないんで、実例を出せというのも意味が無い。 （実例が無いからといって「敢えて」未定義動作に誘導するというのは意味が無いどころか有害。） ・・・スレッドサニタイザで引っかかってウザい、とか言えば「実例」として納得してくれるの？ 791 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 01:04:57.94 ID:b90ql0x3.net] 生のintへのアクセスがアトミックに行えるかって処理系が保証したりしないのけ 792 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 05:39:14.15 ID:dtsN+T48.net] https://stackoverflow.com/questions/35226128/are-c-c-fundamental-types-atomic 793 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 06:51:23.81 ID:3FmZNcD6.net] >>764 保証してる処理系なら std::atomic<int> でオーバーヘッドは生じない、つまり排他は要らんってことでしょ >>756がなんか実例知ってるかと思ってたけど単なる規格厨だったなw 794 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 12:49:26.09 ID:pCGEFvrX.net] >>766 オーバーヘッドが生じるかどうかで考えてるなら（それもおかしいんだけど）、こんな例を見れば考えを改めてくれたり 795 名前：するの？ https://godbolt.org/z/6oM5oevsY #include <atomic> int load(std::atomic<int> const& x) { return x; } int load(int const& x) { return x; } ↓ARM64 gcc 11.1 -O2 load(std::atomic<int> const&): &nbsp; ldar w0, [x0] &nbsp; ret load(int const&): &nbsp; ldr w0, [x0] &nbsp; ret [] [ここ壊れてます] 796 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 18:54:32.14 ID:VBWUb4q7.net] >>767 それメモリーバリアの話で排他の話じゃないけど、何を言いたいの？w 797 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 19:20:02.20 ID:pCGEFvrX.net] >>768 766 が「オーバーヘッドは生じない」ならば「排他は要らん」という論理らしいので 「オーバーヘッドは生じない」を否定すれば「排他は要らん」とかいう嘘を言わなくなってくれるかなと思って書いてみた。 オーバヘッドの発生と排他の要・不要とが 766 の頭の中でどう繋がってるのかは知らない。 798 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 19:25:42.08 ID:VBWUb4q7.net] >>769 まあメモリーバリアも一種のオーバーヘッドと言えなくもないがそういう話でないことぐらいはわかりそうなもんだけどねw で、排他が必要な例は見つかったの？ 799 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 20:14:07.80 ID:pCGEFvrX.net] >>770 ごめんよ。元から意味が分からなかったところ「オーバーヘッド」の意味が何か文字通りの意味じゃなかった みたいだし、もうどういう話なのかさっぱりだわ。 767 の「オーバーヘッド」が何を指すのか、それと排他の要・不要との繋がりがわかるようだったら解説よろしく。 「排他が必要な例」と言われても、こっちとしては複数スレッドで生の int を読み書きするなら 常に排他が必要という認識なんで文字通り「排他が必要な例」なら無数にあるんだよね。 そういうのを挙げても謎理論で「不要だろ」とか「コレジャナイ」って言うだけで話は進まなさそう。 ここまでの流れを読めば >>755 をうっかり信じちゃう人もいないだろうし、もう放置でいいかなという気になってる。 800 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 20:22:20.00 ID:cMMfM4oH.net] >>771 あえて指摘しなかったけどstd::atomicでは既定のメモリーオーダーがseq_cstであることを知らんのか？ 自分で「あんたの言うオーバーヘッド」かかる書き方してオーバーヘッドかかるから排他ガーとか意味不明なんですけど？w そもそもstd::atomicは必ず排他かかるわけでもないし人を嘘つき呼ばわりするならもう少し勉強した方が恥をかかなくて済むと思うよ 801 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 20:35:16.14 ID:pCGEFvrX.net] >>772 ごめんそれは知ってるよ。でもそれを知ってる知識レベルの人が >755 のような主張をしてるとは思わなかったんだ。 あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。意味不明なのには同意する。 「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。 802 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 22:17:32.53 ID:cMMfM4oH.net] >>773 > ごめんそれは知ってるよ。 えっ？ 知ってて>>767ってそれこそ意味不明なんですけどw 結局何を言いたかったの？ > あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。 ああマジで日本語の理解力がないのね （もちろん環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない って話ね 念の為に言っておくけど>>764が言うようなハード上の排他制御は別の話ね > 意味不明なのには同意する。 同意なんていらんから>>767を書いた意味を説明してよ > 「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。 嘘だと言うなら根拠を示したほうが良いと思うよ まあ示せないからグダグダ言うとか関係の無いメモリーオーダーの話とかにそらそうとしてるんだろうけど… 803 名前：デフォルトの名無しさん mailto:sage [2021/07/14(水) 23:08:12.27 ID:pCGEFvrX.net] >>774 「767を書いた意味」なら>>769で説明した。 「環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない」これは正しい。 でもそれは生の int でデータ競合を避けられる理由にはならない。 >>755 が嘘だという根拠は >>749 に挙げられた規定による。その条件 "at least one of which is not atomic" について、生の int へのアクセスは "not atomic" に該当するから排他なしのアクセスでは未定義動作となりダメだと言っている。 規格文面の "atomic" は、規格が規定する C++ 抽象機械上の概念という認識。 対して 755 は、規格文面の "atomic" は各処理系でのメモリアクセスが実際にアトミックかどうかに依ると考えてそう。 残念ながら規格の文面で明確にその解釈を否定できないんだけど (https://cplusplus.github.io/LWG/issue2506) 少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や 現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。 804 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 05:14:12.89 ID:oWQENBCT.net] >>775 > 「767を書いた意味」なら>>769で説明した。 あああのメモリーバリアと排他の区別もついてないアホ丸出しの説明ねw > 少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や > 現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。 百歩譲ってstd::atomic使えと言うのはいいけど、排他は必須じゃないだろ 805 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 06:52:54.80 ID:DRiXJTFv.net] charはatomicなの？規格にどれがatomicだってあるの？ どれがatomicかなんて、CPU毎に違って当然だと思ってたわ 806 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 07:50:32.57 ID:oWQENBCT.net] >>777 CPU毎と言うかシステム毎に違うだろ 807 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 08:52:46.15 ID:JIUDKEB4.net] >>776 うん。データ競合を回避するにあたって std::atomic を使えば排他は必須じゃなくなるよ。 ミューテックスを使うなどの排他（順序付け）でも回避できて、どっちかでもいいし両方でもいい。 >>755 が嘘だという点には異論なくなったみたいだね。よかったよかった。 808 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 09:20:51.24 ID:oWQENBCT.net] >>775 排他は要らんケースがあると言うだけの話 ちなみに>>755では生intなんて一言も書いてないけどね std::atomic<int>でも多くの環境では > 単純なカウンタみたいなアトミックに読み書きできるような変数になるしな まあ結局規格ガーって言うしかないレベルの低い規格厨が関係のないメモリーバリアーとか出してきて恥を晒しただけだったなw 809 名前：デフォルトの名無しさん mailto:sage [2021/07/15(木) 10:06:00.17 ID:ux6gJq+a.net] お前ら暇すぎやろ 810 名前：デフォルトの名無しさん mailto:sage [2021/07/30(金) 19:50:56.40 ID:VEABT8DF.net] C++ のバイナリ互換性についてお聞きしたいのですが。C++ のライブラリの中に以下のようなものが あったとします。 class A { char *p1; }; class B { /* 略 */ }; class C { A a; B b; }; で、class A に新たな要素を追加して class A { char *p1; char *p2; }; としてからライブラリを再ビルドし、以前のアプリのバイナリと混在させると、class C 内で a のサイズ が変わる結果 b へのオフセットが変わりクラッシュするようです。 そこでふと思ったのですが、class A に最初から class A { char *p1; char *p2; char *p3; char *p4; }; 等と最初からある程度要素を確保しておき、必要に応じ上の方から使っていく、みたいなやり方は アリでしょうか? （b へアクセスするときのクラッシュを防げるでしょうか?） 811 名前：デフォルトの名無しさん mailto:sage [2021/07/30(金) 19:57:58.75 ID:SwFfvD28.net] pimpl使え 812 名前：デフォルトの名無しさん mailto:sage [2021/07/30(金) 21:01:43.73 ID:y9Kee4rz.net] >>782 素直にC.aやC.bをポインタにすりゃいいだけちゃう？ 813 名前：まあ俺が言うのもなんだがw mailto:sage [2021/07/31(土) 22:17:00.01 ID:m7lSxL/B.net] >>782 クラス定義が変わったのにそれを使う一部のコードを再ビルドしないってこと？ > そこでふと思ったのですが > （中略） > アリでしょうか? （b へアクセスするときのクラッシュを防げるでしょうか?） ありかも知れんが、なんでそんな前近代的なやり方しないといけないのかを考えたほうがいいと思う 814 名前：デフォルトの名無しさん mailto:sage [2021/08/01(日) 03:13:38.20 ID:/oR3uo3Y.net] C++ポケットリファレンス読んだ方いらっしゃいますか? 独習C++ 詳説 C++ 第2版の次に読もうかと思ってるのですが 815 名前：デフォルトの名無しさん [2021/08/02(月) 10:21:16.05 ID:WSe94FPO.net] 近年の現場と言うか、 大手の製品開発や比較的規模の大きい案件とかで使われてるC++のバージョンってどの辺ですか？ 未だにC++03ってわけないですよね？ 816 名前：デフォルトの名無しさん mailto:sage [2021/08/02(月) 10:29:43.05 ID:WSe94FPO.net] >>786 C++プログラミング言語自体の研究という訳ではないのなら、 入門書以降は何か作る系の書籍のほうが良いのではないでしょうか？ 物理シミュレーションだったりゲームだったり 人工知能だったりOSだったり様々あると思うので、 興味のある分野を極めていくのが良いと思います。 作りたいものがあるが何から手を付けて良いか分からないのなら 設計理論系の書籍等も良いと思います。 OOPを極めたいという考えであるならデザインパターン等も良いと思います。 817 名前：デフォルトの名無しさん mailto:sage [2021/08/02(月) 10:37:42.71 ID:dQnVwxld.net] どの道、 class C { A* a; }; と、ポインターに変えても、 class A { char *p1; char *p2; }; と、新しいメンバーp2 には、C を再コンパイルしないとアクセスできない 818 名前：デフォルトの名無しさん mailto:sage [2021/08/02(月) 11:23:37.60 ID:lIzbW3kq.net] class A; class C { A* a; }; だけで完結してるなら　まぁ問題をおこしにくそうではあるけど そこまでして C に関わるコンパイルを止めたい理由がわからん 819 名前：デフォルトの名無しさん [2021/08/03(火) 10:56:52.82 ID:Ljn/RAt1.net] >>787 最低でも C++11 それでも古いと思う 820 名前：デフォルトの名無しさん [2021/08/09(月) 22:11:24.65 ID:PKIz3Xw3.net] C++って競プロ以外に何に向いてるの？なんで競プロに使われるの？ 821 名前：はちみつ餃子 mailto:sage [2021/08/10(火) 01:15:34.32 ID:7+xjomdk.net] >>792 実行速度が速いことが多いから速度が評価の一部である以上は有利になる。 (速ければ速いほど良いというわけではないが、上限が設定されているのが普通) 822 名前：デフォルトの名無しさん [2021/08/11(水) 12:58:25.34 ID:MU7UJMps.net] std::map<std::pair<const char *, int> > hoge; のように const char * を key とするとき hoge.insert(std::make_pair("A", 41)); hoge.insert(std::make_pair("C", 43)); hoge.insert(std::make_pair("B", 42)); と追加すると hoge["C"] で 43 が得られると期待できますが このとき make_pair したときの "C" と hoge["C"] の "C" のポインタは値が違ってても 同一 key とみなされますか？(ポインタの値ではなく文字の中身の一致を見てくれますか？) あるいは char * だとまた変わりますか？ 823 名前：デフォルトの名無しさん mailto:sage [2021/08/11(水) 13:12:29.99 ID:Z6PNV5dP.net] ポインターは先頭アドレス 2つのオブジェクトの内容が同じでも、 別々のオブジェクトなら、ポインターも異なる ポインターが同じとは、同一のオブジェクトを指している場合だけ 824 名前：デフォルトの名無しさん [2021/08/11(水) 13:28:06.66 ID:MU7UJMps.net] 追伸 一つの fuga.cpp 内で 二か所以上で "C" が使用されていたとき 同じアドレスにしてくれる機能もあるみたいですが fuga.cpp と hage.cpp みたいに別のソースで それぞれ "C" を使ってたりすると 勝手に同じアドレスにしてくれたりはないみたいで いろいろトラブルのもとになりそうです (どっちみち変数になってると手も足も出ませんし) key は std::string にしておくか あるいは std::hash<> と std::equal_to<> を定義して自分で比較する方が安全な模様 825 名前：デフォルトの名無しさん mailto:sage [2021/08/11(水) 13:42:41.83 ID:EWMgwFeS.net] >>796 「あるいは」以降ってunordered_mapの話じゃないかい mapならstd::less<>を定義する……というかデフォルトのstd::less<>が使われないようにユーザ定義比較関数をコンストラクタで渡す 俺もこういう場合はキーにstd::string使うからいいけども 826 名前：デフォルトの名無しさん [2021/08/11(水) 14:06:43.19 ID:MU7UJMps.net] 今回の問題は >一つの fuga.cpp 内で二か所以上で "C" が使用されていたとき同じアドレスにしてくれる機能もあるみたいですが >fuga.cpp と hage.cpp みたいに別のソースでそれぞれ "C" を使ってたりすると勝手に同じアドレスにしてくれたりはないみたいで これでした stringにしたら解決です ほんとうにありがとうございました 827 名前：デフォルトの名無しさん mailto:sage [2021/08/11(水) 14:27:08.48 ID:01hIEDa4.net] >>798 別のソースでも同じアドレスにしてくれることあるよ。 828 名前：はちみつ餃子 mailto:sage [2021/08/11(水) 14:56:20.07 ID:QcAq7ivU.net] 言語仕様上は内容が同じ文字列リテラルを統合するかどうかは処理系定義。 https://timsong-cpp.github.io/cppwp/n3337/lex.string#12 829 名前：デフォルトの名無しさん mailto:sage [2021/08/12(木) 23:28:31.22 ID:sg4QisCT.net] >>ってどのように言えばいい？ だいなり、だいなり ？？？ 830 名前：はちみつ餃子 mailto:sage [2021/08/13(金) 00:46:25.67 ID:BE9FMbqU.net] >>801 トークンとしての名前は無いと思う。 演算子としての名前なら右シフト演算子とか、 iostream 的な用途の場合は抽出演算子とも言う。 831 名前：デフォルトの名無しさん mailto:sage [2021/08/13(金) 15:49:32.03 ID:ZZGdeLtF.net] insertion/extraction operatorっていうのか。 stream operatorだと思ってたわ 832 名前：はちみつ餃子 mailto:sage [2021/08/13(金) 16:31:09.36 ID:BE9FMbqU.net] >>802-803 念のために仕様書を見直して見たら抽出子 (extractor) だったわ。 833 名前：デフォルトの名無しさん [2021/08/21(土) 20:09:51.28 ID:7GAoG1Iq.net] Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？ Nimの実験的特徴 著者： アンドレアス・ルンプ バージョン： 1.5.1 nim-lang.github.io/Nim/manual_experimental.html Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます 834 名前：デフォルトの名無しさん [2021/08/22(日) 10:20:28.75 ID:0Cz6ueFz.net] Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？ Nimの実験的特徴 著者： アンドレアス・ルンプ バージョン： 1.5.1 nim-lang.github.io/Nim/manual_experimental.html Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます 835 名前：デフォルトの名無しさん [2021/08/22(日) 10:29:54.67 ID:0Cz6ueFz.net] Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？ Nimの実験的特徴 バージョン1.5.1 nim-lang.github.io/Nim/manual_experimental.html 第二プログラミング言語として Rust はオススメしません Nim をやるのです https://wolfbash.hateblo.jp/entry/2017/07/30/193412 Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます 836 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 12:34:32.34 ID:m1rLE8Mc.net] 怠け者が一生懸命２回書き込んじゃうのか 837 名前：デフォルトの名無しさん [2021/08/22(日) 13:21:27.56 ID:cx6/dnxW.net] unordered_map で erase(key) を実行した場合 要素のデストラクタは呼ばれるのでしょうか？ 必ず自分で呼ばないとだめ？ あるいは勝手に呼んでくれるオプションとかある？ 838 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 13:38:27.67 ID:m4vhMo04.net] 呼ばれるよ。そうじゃないと危なすぎるでしょ。 839 名前：デフォルトの名無しさん [2021/08/22(日) 13:51:18.62 ID:cx6/dnxW.net] つまり unordered_map<hoge, fuga *> � 840 名前：ﾝたいなときって fuga *f があるとすると delete f されるっていう認識で OK? [] [ここ壊れてます] 841 名前：デフォルトの名無しさん mailto:sage [2021/08/22(日) 13:56:28.38 ID:M38WAZ3o.net] ポインタ型のデストラクタは基本的に何もしない。 デストラクタで破棄したいならunique_ptrなどスマポを使う。 842 名前：ハノン mailto:sage [2021/08/22(日) 15:55:44.42 .net] >>809 つ　https://ideone.com/zKMtPs 843 名前：ハノン mailto:sage [2021/08/22(日) 16:00:15.54 .net] >>811 つ　https://ideone.com/AIykVF 844 名前：ハノン mailto:sage [2021/08/22(日) 18:24:32.36 .net] >>813 >>809 ユーザー定義のハッシュ関数を std 名前空間に押し込むのはお行儀が悪いよね…‥ https://ideone.com/J5JYnG 845 名前：はちみつ餃子 mailto:sage [2021/08/22(日) 21:31:04.10 ID:YcQtKocs.net] >>815 文字列リテラルを char* にキャストするほうがだいぶん行儀が悪いと思うよ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef