[過去ﾛｸﾞ] C++相談室 part157 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
153: 2021/08/21(土)00:37 ID:E2GGZp0E(2/4) AAS
>>146
forの変数スコープは回避策あったやん
98年発売なんでもうちょっとどうにか出来たのではとも思うが
154(1): 2021/08/21(土)00:45 ID:E2GGZp0E(3/4) AAS
あ、すまんラムダじゃなくて関数オブジェクトか
確かにタイプ数くらいしか思いつかんけど
テンプレートは既に使えるのでは？関数テンプレートに出来て関数オブジェクトに出来ないテンプレートの使い方あったっけ
155(1): 2021/08/21(土)10:46 ID:+K/WXdke(1) AAS
>>148
日本でも煙草を真似したデザインのチョコレート菓子があったけど
間違って煙草食った子供が死んだとか裁判になったとか聴かないな
おそらくあったんだろうな
156: 2021/08/21(土)12:15 ID:t0h3aTQf(1) AAS
>>154
実体化の制御かね。
関数テンプレートは使用されない限りエラーにならない。
SFINAEもそうじゃなかったっけ？
157: 2021/08/21(土)13:42 ID:E2GGZp0E(4/4) AAS
クラステンプレート内の普通のoperator ()だとそうだね
operator ()がテンプレートの場合ならほぼ関数テンプレートと同じ事出来るとは思うけど
文法上、明示的にテンプレート引数指定する際、関数と共通の書き方には出来ないな・・
158: 2021/08/21(土)20:47 ID:7GAoG1Iq(1) AAS
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
省6
159: 2021/08/21(土)22:35 ID:o/sUihIV(1) AAS
質問です。
std::array ary = { 1, 2 };
↑の{}で初期化すると、
要素数を自動推論できるようにするにはどう実装すればいいんでしょう？
160(1): 2021/08/21(土)22:55 ID:+FOhqLVw(1) AAS
推論補助だと思う
外部ﾘﾝｸ[html]:cpprefjp.github.io
161: 2021/08/22(日)01:17 ID:maGRuunL(1) AAS
>>155
食ったところで飲みこまずにペッペッて吐き出すだろ
162: 2021/08/22(日)04:31 ID:Roj0wExz(1) AAS
g++ -std=c++17
163: 2021/08/22(日)12:59 ID:0Cz6ueFz(1) AAS
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
外部ﾘﾝｸ[html]:nim-lang.github.io
省6
164: 2021/08/22(日)18:45 ID:gNvESTNy(1/3) AAS
std::chrono::time_point::time_since_epoch()が返すエポックタイムの原点はいつですか？
もし具体的に規定されていないとしても、
ミリ秒パートが0であることは保証されていますか？
165: 2021/08/22(日)19:20 ID:gNvESTNy(2/3) AAS
ある意味自己解決しますたorz
外部ﾘﾝｸ[html]:cpprefjp.github.io
>C++17 以前の場合、system_clock のエポックがどの時間を指しているかは未規定だが、ほとんどの処理系は UNIX 時間（1970年1月1日0時0分0秒)を指している
>C++20 以降の場合、system_clock のエポックは必ず UNIX 時間（1970年1月1日0時0分0秒)を指す
しかし（特にC++17以前において）ミリ秒パートが0が保証されているのかどうかがはっきりしませんぬ、
166: 2021/08/22(日)19:28 ID:VeL/IzCV(1) AAS
生年月日をUNIX時間で表現できないオッサンはこのスレにどのくらいいるの？
167(3): 2021/08/22(日)21:27 ID:gNvESTNy(3/3) AAS
生年月日ならミリ秒まで言える必要は無いが
ログの時刻を極力正確に（WindowsのGetLocalTime()と同じ時刻で）記録したいのでつ∀`；)
168: 2021/08/23(月)04:13 ID:F733kpwr(1) AAS
1970年以前生まれの50代以上のオッサン
169: 2021/08/23(月)16:50 ID:Rrt4HCug(1) AAS
B.C.
A.D.
B.E.
170: 2021/08/23(月)22:05 ID:xWEF4I0D(1/2) AAS
B.E.って何ですか
UCとSEとかRCとかじゃないの
171: 2021/08/23(月)22:52 ID:xWEF4I0D(2/2) AAS
ていうかsystem_clockはC++17以前からtime_tと相互変換できるのに（system_clock::from_time_t()、system_clock::to_time_t()）、
エポックがどの時間を指しているかは未規定とかおかしくね↑？
172: 2021/08/23(月)23:20 ID:AuTnTHJo(1) AAS
別におかしくない
変換時にエポックの差の分ずらせばいいだけだろ
173(1): 2021/08/23(月)23:31 ID:sPTJEjpv(1) AAS
そんなことよりなんでtime_tは符号なしなん？
64bit拡張するときに符号ありにしとけば166みたいな煽りを受けずにすんだのに
174(1): 2021/08/24(火)00:03 ID:24MephMZ(1) AAS
符号なし使うのは総じてセンスないよね
175(1): 2021/08/24(火)07:17 ID:NEyNeI43(1) AAS
符号付き整数はwrap aroundしたときの挙動が処理系依存か何かだったはず……
ハードウェア例外を生じるやつがあるらしい
176: 2021/08/24(火)07:52 ID:4Ohx7QuI(1) AAS
>>173
純粋にプログラミングスキルの話と受け取った>>167に謝れ
177: 2021/08/24(火)08:21 ID:NErefsYh(1) AAS
>>175
オーバーフローしたときにラップアラウンドさせる使い方が数値計算としては特殊だからねぇ。
178: 2021/08/24(火)15:27 ID:WZMj7UxV(1) AAS
>>167
ntp使え
179(1): 2021/08/24(火)17:48 ID:DexxKsi1(1) AAS
>>174
time_tを符号なしにしたやつはアフォだと思うが
それをもって符号なしを使うやつ全員が例外なくアフォというのは
早まった一般化という誤謬だ
180: 2021/08/24(火)22:08 ID:OPjw/0cg(1) AAS
>>160
なるほど！ありがとうございます
181: 167 2021/08/25(水)00:50 ID:MXKFEwSS(1) AAS
そういやーまだご存命の方もいらっしゃるんでしたね
>>179
符号付きにしたら2038年問題が2004年問題になってた
人類は間に合わなかった
182: 2021/08/25(水)07:34 ID:VHSVWUHA(1) AAS
３０年も猶予があったのにな
183: 2021/08/25(水)10:43 ID:M5WZn8fZ(1) AAS
ヒトラー「2036年、人類と云われる者は居なくなっている」
184: 2021/08/26(木)16:49 ID:WPRv8+9f(1) AAS
関東大震災だって100年も猶予があっても何もしない國ですし
185: 2021/08/26(木)21:09 ID:xnTAPql6(1) AAS
色々やってるぞ
庶民を助ける政策をやってないだけで
186(1): 2021/08/27(金)17:50 ID:BFKMFKNN(1) AAS
Twitterﾘﾝｸ:cpp_akira
最近はC++の発表資料を公開すると「Rustでいいじゃん」というコメントがたくさんつくのか…。
Rustへの言及とか一文字も書いてないのに。
普及活動だと思うけど、さすがに嫌がらせチックに見える。
Twitterﾘﾝｸ:moriyoshit
C++の件に限らず、旧来からある言語の長所短所を理解せずに、
表面的に新言語を推す発言を見ると、
果たして当人は新しい言語の方も理解できているのだろうか、
という疑念をもってしまう...
Twitterﾘﾝｸ:5chan_nel (5ch newer account)
187: 2021/08/27(金)19:27 ID:wbifwX7a(1) AAS
>>186
Rustはいらんけど、制約を強化してコンパイルエラーを増やしたc++--は欲しいなぁ。
スライシングはすべてコンパイルエラー、ダウンキャストはメンバー関数とフレンド関数のみ使用可能
new deleteはメンバー関数とフレンド関数のみ使用可能（global operator new/deleteは廃止）
といったメモリ周りの制約強化は欲しい。
188: 2021/08/28(土)14:03 ID:dCOU+NEa(1) AAS
Rustを使って欲しいなら、そう言えばいいのに
人のすることを小馬鹿にするような態度で来るから敵と見られるんだよ
コミュ障にも程がある
189: 2021/08/28(土)18:35 ID:iJLWqDs6(1) AAS
インテルコンパイラの-fastには-staticが含まれてるけど、なんでスタティックリンクは速いの？
190: 2021/08/28(土)18:49 ID:Ovc44+68(1) AAS
ライブラリ使うときのロードの手間がなくなるからね
191: はちみつ餃子 ◆8X2XSCHEME 2021/08/28(土)23:41 ID:V8MBAFoh(1) AAS
スタティックリンクにすると最適化の情報が増えるというのもあると思う。
C/C++ では翻訳単位ごとにコンパイルしてからリンクするという工程を踏むから、
コンパイル時には他の翻訳単位の情報を知らず、他の翻訳単位の情報を利用した
最適化が出来なかった。
今では LTO が当たり前になって、リンク時にあらためてコンパイラに戻して最適化
させる仕組みがあるんだけど、バイナリ自体が別物だとその仕組みを使えない。
192(1): 2021/08/29(日)13:13 ID:h29TClHM(1/6) AAS
std::threadってスタックサイズを指定できないってﾏｼﾞ？
仮想メモリを使えない組み込み用途だとどうすんじゃ……
193(1): 2021/08/29(日)13:20 ID:kSqJuAzn(1) AAS
native_handle()関数で環境に応じたスレッドハンドル(linuxならpthread)を取得できるから、スタックサイズを設定するところだけ環境ごとに用意して切り替えればいいよ
194: 2021/08/29(日)13:28 ID:h29TClHM(2/6) AAS
Windowsみたいにスレッドハンドルを生成したときはスタックサイズ指定済のとき、みたいな
組み込み用OSがあったらどうすんじゃ……
195: 2021/08/29(日)13:46 ID:h29TClHM(3/6) AAS
とわいえμITRONのcre_tsk()は
>cre_tsk でスタック領域を明示しない場合のタスクのスタックや割込みハンドラ/割込みサー
>ビスルーチンのスタックは、OS が用意する「スタック用メモリ」から割り当てられます。
>スタック用メモリのサイズを定義する STKMSZ の標準値は 0 で、この場合、main 関数が使って
>いる処理系のデフォルトのスタック領域(スタックセクション)を、OS のスタック用メモリとし
>ます。この場合の実際のスタックサイズは、リンカでのセクション設定とスタートアップルー
>チンでの初期スタックポインタ値で決まります。
みたいなことが書いてある
C/C++界隈はみんな頭おかしい……
196(1): 2021/08/29(日)13:55 ID:h29TClHM(4/6) AAS
ｺﾞﾒ勘違いcre_tsk()（IDがOSが自動割り当てのやつはacre_tsk()）は
第2引数に与えるT_CTSK構造体でタスクごとにスタックサイズを指定できたわ；；；
なんでstd::threadではできないんじゃ……
197(1): 2021/08/29(日)14:18 ID:vSvS+48a(1) AAS
コイツ前スレでも連レスしてたムーブ全く理解してないバカだよね？
NGしたいからトリップつけてください
198: 2021/08/29(日)14:25 ID:x8xWTwL3(1) AAS
>>192
標準じゃ無理でしょ
全てのスレッドを変えたいならリンカのオプションとかで指摘できる環境もあるけど
boost::thread使って
boost::thread::thread_attribute::set_stack_size()
で設定するがよろし
>>193
native_handle()関数でハンドル取れると言う事はスレッド開始してる
開始済みスレッドのスタックサイズを変えられる環境って聞いたことない
199: 2021/08/29(日)14:30 ID:AWkeWwKB(1) AAS
>>196
ほんと組み込み屋は馬鹿だな
200: 2021/08/29(日)16:52 ID:h29TClHM(5/6) AAS
>>197
完璧な理解をサンプルコード付きで示したやろうが；；；
論点はなんでムーブに置き換えられるケース（明示的にstd::move()したら明らかに効率的なコードになる
において最適化でムーブにならないのか？なのだが高度すぎるのか文盲か故に>>197が付いてこれていないだけ
>>197はブーメラン
201: 2021/08/29(日)16:54 ID:h29TClHM(6/6) AAS
もっとも天才の漏れは答えにたどりついたがな
ムーブコンの実装がコピコンの実装より効率的である保証が無い以上、
置き換え可能なケースであってもコピコンからムーブコンへの機械的置き換えは正当化されない
202: 2021/08/30(月)14:34 ID:jKIf8Vzq(1) AAS
天才のインフレ
203(2): 2021/09/01(水)16:43 ID:Uxp79PtR(1) AAS
Rustみたいにコンパイル時にいちいち参照のチェックするんじゃなくて
C++で最終的に完成したバイナリに対してメモリサニタイザーを一回動かす
ってのではだめな理由ある？
204: 2021/09/01(水)20:16 ID:dG55Jwur(1) AAS
>>203 動かしたフロー以外のフローについて不安が残るし、サニタイザーの精度がどれほどかという問題もありそう。
205: はちみつ餃子 ◆8X2XSCHEME 2021/09/01(水)23:35 ID:3mB0e8fG(1) AAS
>>203
ものによって賢さの程度が違うから一概には言えないけど
基本的にはサニタイザは実際に起こった問題を検出するものなので
入力値次第で問題が有ったりなかったりするようなケースを検出できなかったり、
言語仕様上で未定義なものがたまたま問題ないアクセスになってしまうようなケースも
検出できないかもしれない。
問題が起こっていて再現条件が分かっているときに検証するツール、つまりデバッグ用のツール
としてはサニタイザは有用だし、ごく基本的なテストツールとしても使えるけど、
Rust のライフタイムチェックほど網羅的ではない。
206: 2021/09/02(木)05:18 ID:90/tsZBA(1) AAS
一言でまとめると動的試験てことだな
207(3): 2021/09/03(金)09:16 ID:6YHhlfzl(1/3) AAS
MozillaのFireFoxの場合、わざとクラッカーがセキュリティーホールを見つけ出して
そこを付いてくるから、普段の実行テストでは一度も発見できなかった
メモリーバグが問題になるが、普通のアプリの場合、ユーザーがわざとバグを
付くことはないから、そのようなホールはあまり関係ないと思う。
テスト駆動開発とかアジャイル開発とかも、普段使いで問題が無いかをテスト
することで大部分のバグが無い状態で開発していこうとする考え方。
それでもほとんどのメモリーバグは無い状態になっている。
メモリーバグがあると、普段使い的なテストをしても発覚することが多いから。
昔から言われているメモリーバグの問題点は、再現性が有る場合でも、バグが
ある行とそれが発覚した時期とがずれていることがあるから。
省7
208(1): 2021/09/03(金)09:22 ID:6YHhlfzl(2/3) AAS
>>207
例えば、ダングリングポインタ(Use After Free)は、ptrがどこかでまだ使用中なのに、
free(ptr)としてしまうこと。しかし、そのfree()をした時点ではアプリはダウン
しないし、ptrに対して読み書きした段階でもまだ発覚せず、ptrが指すメモリー
アドレスを別の目的で使用してしまって、お互いに読み書きがある種の干渉を
起こしてしまって、データがめちゃくちゃになり、それによってどこかで不具合
が生じた時点で発覚する。
なので、バグの根本原因であるfree(ptr)を実行した行がどこかを探し出しにくいと
される。
しかし、このバグの場所とバグが起きた場所のずれは、デバッグビルド時に速度を
省1
209: 2021/09/03(金)09:24 ID:6YHhlfzl(3/3) AAS
>>208
チェックと言っても人間が手で書く必要は無く、コンパイラがチェックコードを
自動生成できるはず。
210: 2021/09/03(金)10:00 ID:yL2Kwy6+(1) AAS
根拠のない決めつけばかりで気持ち悪い。
211: 2021/09/03(金)10:16 ID:lmzB7IZ6(1/3) AAS
>>207
世の中にはテスターという職種の人がいてだな
212: 2021/09/03(金)10:46 ID:yJUEU9nq(1/2) AAS
>>207
任意のファイルを読むアプリはファイルのパーサーの脆弱性をついてユーザ権限でコードを実行される可能性がある
どちらかと言えばアプリよりサーバとしてアクセスを受け付けているプログラムの脆弱性をつかれて攻撃コードの実行を許してしまうことが多い
さらに上のような場合でも、アプリやサーバのプログラム自体に脆弱性があるのではなく、使用しているOSのAPI側の実装の脆弱性をつかれる可能性がある
こういうアプリやサーバやOSのコードの脆弱性にMSやGoogleは悩まされている
213: 2021/09/03(金)11:00 ID:yJUEU9nq(2/2) AAS
Valgrind と言う動的解析ツールを調べて見るといい
うちはC++のプログラムは基本これを通すことになってる
商用ならもっといいツールもあるかも知れない
そういうのを利用しても充分でないから静的解析するRustが注目されている
214: 2021/09/03(金)11:27 ID:6Xh4x7Us(1/3) AAS
商用の静的解析ツール使ってると、正直メモリ関係のバグなんてありえないと思えるくらいいろいろ見つけてくれるよ
215: 2021/09/03(金)11:44 ID:9y+1HwQb(1) AAS
コンパイル時間に糸目を付けなければ、静的解析はもっと出来る。
216: 2021/09/03(金)11:47 ID:lmzB7IZ6(2/3) AAS
> メモリ関係のバグなんてありえないと思える
lintの副作用がモロに出てるなｗ
217: 2021/09/03(金)15:20 ID:MvVz2a9W(1) AAS
言うまでもない事だが完璧なメモリチェッカーは存在し得ない
停止問題と同値だからな
218: 2021/09/03(金)15:50 ID:6Xh4x7Us(2/3) AAS
完璧無理っておまえの毛髪の量がプログラム停止に与える影響が読めないとかそういう話だろ？
限定的な範囲で正しけりゃ十分だよ
219: 2021/09/03(金)16:54 ID:lmzB7IZ6(3/3) AAS
ゴールポストは動かしちゃダメだよ
220: 2021/09/03(金)17:38 ID:6Xh4x7Us(3/3) AAS
無限遠のゴールを設定するのはアホだべ
221: 2021/09/03(金)17:51 ID:xmwLNRYX(1/2) AAS
スクリプト言語も普通にクラッシュすることあるから
222: 2021/09/03(金)17:52 ID:xmwLNRYX(2/2) AAS
OSのコアダンプ出力とリブートに救われる手のひらの孫悟空
223(2): 2021/09/03(金)18:28 ID:iCLUv6gH(1) AAS
rustでもメモリアロケーション失敗するとパニックになる、てリーナスが突っ込んでいたろ。
c++の場合はどうなんのかな。
224: 2021/09/03(金)20:13 ID:USKNPKWa(1) AAS
CoverityとVectorCASTは使ったことあるけど検知レベル最高にしても見逃すリークや二重フリー, ダングリングはそれなりにある (そもそもコードの構造が悪い場合も多いが)
検知レベル上げ過ぎると逆にFalse Positiveも増えるし
225: 2021/09/04(土)07:59 ID:kFVsNuY8(1) AAS
無限遠のゴールポストを動かすって
こいつ文系か？
226: 2021/09/04(土)08:08 ID:N/QuNfWR(1) AAS
まあ見つからないのは間違いなく書き方が悪いよな
227: 2021/09/04(土)19:04 ID:7+pvijvQ(1) AAS
∞の概念が理解できるならそいつはもう文系ではあるまい
228: 2021/09/04(土)19:11 ID:ICKB9ww0(1) AAS
ε-N論法
229: 2021/09/04(土)22:28 ID:mLTAxmCN(1) AAS
超久しぶりにC＋＋の参考書 買った。
いまってC++20までいってるんでしょ？
時代遅れもいいところだから勉強しようと思ってw
ただ読む気がおきない。
「pythonでいいか」って思いが・・・ww
230(4): ハノン ◆QZaw55cn4c 2021/09/04(土)23:52 AAS
>>223
外部ﾘﾝｸ[html]:tabesugi.net
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
省11
231: 2021/09/05(日)00:05 ID:yIsM5ONG(1/3) AAS
バカが使いこなせる言語ではないからな
232: 2021/09/05(日)00:27 ID:eMsTCIh+(1/3) AAS
linusに言われると返す言葉もないが、その後の文脈にある
『もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
ほんとに。連中は「本物のデータベース」を使っているよ。
「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
これらすべての設計上の決定のために、できてきた結果はゲロゲロで
保守不可能なカオスだ。
でもあんたはきっと git よりも気に入るだろう。保証するよ。』
な感じでC++を気に入って、夢を見ていたいんだろうね。
233: 2021/09/05(日)00:53 ID:66hkUr5p(1/2) AAS
「オレはC++を使いこなせている」と思い込む素人を生温かく見守るスレはここですね
234(1): 2021/09/05(日)01:42 ID:eMsTCIh+(2/3) AAS
>>223
外部ﾘﾝｸ:lkml.org
コレのことだと思うけど、どういうケースを想定しているの？
235: 2021/09/05(日)06:00 ID:fsFc+8nQ(1) AAS
昔、バカでも使える言語でプログラマ人口増やしましょうてなことやってたな
BASICじゃないぞ、あれは初心者用で、バカ用じゃない
計算を数式で書くのは理系だけだから
英文で書けるようにして文系でも使えるようにしようという試みがあった
で、狙いどおり本当にバカプログラマを量産できた
それでいいことあったか？
C++はアレの逆をいっているわけだ
236: 2021/09/05(日)06:45 ID:ClPlKiJv(1) AAS
Qtを使ってるから、C++一択だな。
237: 2021/09/05(日)12:24 ID:cBh+EO/A(1/7) AAS
namespaceと多態性はCだけではやりにくい
238: 2021/09/05(日)12:47 ID:0Cj96kG7(1/2) AAS
静的なディスパッチの充実がCに必要なのではないか
239(1): 2021/09/05(日)14:17 ID:cBh+EO/A(2/7) AAS
>>234
Linuxはモノリシックカーネルなので動的メモリ確保を伴うような軟弱な
モジュールもカーネルのうちに入ってしまっているからメモリ不足ぐらいで
パニくられると手の打ちようがないから困るという話なんじゃないの（適当
OSはリソース管理を放り投げて停止することは許されないから
伝統的なやり方では起動時に非常用のメモリブロックをアロケートしておいて
メモリが枯渇したら非常用のメモリブロックを使うみたいな手段がとられる（と思う
がパニックされたらそこまで行きつかない
※ 個人の感想です
240: 2021/09/05(日)14:38 ID:eMsTCIh+(3/3) AAS
>>239
具体的に何かのケースを想定して言ってるわけじゃないのか。
ぶっちゃけOSをC++で書くならカーネルでnew/malloc/mmapとか使う実装はしないだろうし、処理系が使うランタイムにも依存するけど基本その辺はカスタマイズできるようになってると思う。
rustでもそんな感じで処理系次第って話だと思う。
241(1): 2021/09/05(日)14:44 ID:LgQhIBwq(1) AAS
>>230
馬鹿除けのために C++ じゃなくてあえて C を使うのは良いね
動画ﾘﾝｸ[YouTube]
242(6): ハノン ◆QZaw55cn4c 2021/09/05(日)17:28 AAS
>>241
>>230 の類の話は昔からいわれていたもので、これも有名ですね
外部ﾘﾝｸ[html]:www.kh.rim.or.jp
インタビューア（以下「I」）： あなたがソフトウェアデザインの世界を一変させてから何年にもなる。振り返ってみて、感想は。
Stroustrup（以下「S」）： 実はあなたがここへ来る直前、当時のことを思い出していたんだ。おぼえているかな。誰もが C 言語を使っていたけど、問題はみんな結構うまくコーディングしていたことだった。
大学も C 言語を教えるのがうまくなっていたしね。驚異的な割合で有能な――「有能」という言葉は強調しておきたい――卒業生を量産していた。それが問題の原因だったんだ
。
S： ある日、オフィスにいたときに、ある策略を思いついたんだ。バランスを少し回復させる策略をね。「プログラマが余るなんてことが絶対にありえないくらい、複雑でおぼえにくい言語があったらどうなるかな」ってね。
実は、この考えの一部は X10――例の X Window の――から頂いたんだ。あれはひどいグラフィックシステムでね、Sun 3/60とかでないと動かなかった。
ばかばかしいくらい複雑な構文規則とか、わかりにくい関数とか、疑似オブジェクト指向的な構造とか、僕がほしいと思う要素は全部揃っていたんだよね。
省12
243(1): 2021/09/05(日)17:47 ID:eWmYSwWp(1) AAS
>>242
とっくに否定済みのデマを貼るな
外部ﾘﾝｸ[html]:www.stroustrup.com
244(3): 2021/09/05(日)18:05 ID:Lkm6/1Sl(1) AAS
外部ﾘﾝｸ:ideone.com
これが、シングルトンとして抜けている理由を教えて下し亜。
コードのストックにするために書いたのですが、そもそもシングルトンってなんでしたっけ？
245(1): ハノン ◆QZaw55cn4c 2021/09/05(日)18:06 AAS
>>243
誰が書いたかなどどうでもよく、その内容についてはどう思いますか？
246(2): はちみつ餃子 ◆8X2XSCHEME 2021/09/05(日)18:10 ID:vh6AiUnJ(1) AAS
>>244
関数テンプレートが結果的に引数の数が違う関数として展開される。
引数の数の違いが結果の違い。
247(2): 2021/09/05(日)18:23 ID:cBh+EO/A(3/7) AAS
>static std::shared_ptr<T> O = std::make_shared<T>(A...);
の部分って、Singleton()の初回呼び出しが複数のスレッドから同時に起こってもき
ちんと排他してくれるんでした
っけ
また排他してくれるとしても最速（そのアーキテクチャ（マルチコアかもしれない）で最も適切）
であることを気体していいんでしたっけ……
つまり生成に成功した後は排他不要なわけで、無駄にロックを取りに行きたくない……
248(1): 2021/09/05(日)18:24 ID:yIsM5ONG(2/3) AAS
>>242
おまえホント頭悪いな
249: 2021/09/05(日)18:27 ID:cBh+EO/A(4/7) AAS
みたいな配慮がシングルトンにしたとたんに必要になる
メインの処理が始まる前に普通の初期化関数呼び出しでOを生成したらそれで済むのに、、、
250(1): 2021/09/05(日)18:28 ID:0Cj96kG7(2/2) AAS
>>247
呼ばれたところで最後の奴が勝てば問題ないのでは
251(1): 2021/09/05(日)18:47 ID:cBh+EO/A(5/7) AAS
>>250
ある
>static std::shared_ptr<T> O = std::make_shared<T>(A...);
全体が排他されないとしたら、Oの生成関数（初期化式「O=」の右辺）が複数回、
それも同期的に繰り返し呼ばれるのではなく、非同期的に再入される形で呼ばれかねない
生成関数の中でリソース確保するとしたら先の呼び出しで確保したリソースの
ハンドルがdunglingにならないように配慮が必要になる
非同期的再入ということは、Oが生成→破棄→生成→破棄、にならず、
生成→生成→破棄→破棄になりかねないから、デストラクタをちゃんと書いたらリークしないとか
そういう認識で当たったらバグる
省2
252: 2021/09/05(日)18:50 ID:nyuo1Vq1(1) AAS
>>245
お前の質問なんかどうでもいいからデマを貼るな
上下前次1-新書関写板覧索設栞歴
あと 750 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.063s