C++相談室 part155

1 名前：デフォルトの名無しさん mailto:sage [2021/03/24(水) 12:07:15.39 ID:R+oM8cup.net] ※前スレ C++相談室 part154 https://mevius.5ch.net/test/read.cgi/tech/1610096040/ テンプレここまで 340 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 00:17:13.55 ID:ru2ShUiK.net] >>329 桁数がスゲー長くないと意味ねえってお前以外全員分かってるんだけど大丈夫？ 128ビット以内の計算にカラツバなんか使うと逆に定数倍遅くなる可能性すらあるだろ 341 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 06:53:49.94 ID:WQGVMWvQ.net] mul_mlen_mlen()自体は桁数がスゲー長いケース（任意長）に対応していることは読めばﾜｶﾙ Wrapperであるmul_u64_64()が128 ビットでそれを使っているというだけ 342 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 06:58:17.03 ID:HV6xjPl7.net] いや、カラツバなんか実装する意味ねえつってるんだがどこまで馬鹿なんだ 343 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 07:17:22.47 ID:WQGVMWvQ.net] >>335 >>333 >128ビット以内の計算にカラツバなんか使うと 344 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 07:32:14.23 ID:/jtf723l.net] だめだこりゃ 345 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 08:16:22.82 ID:wJAS8IOG.net] 桁数がスゲー長いケースならカラツバなんか使わんし 数倍長程度でも使わん もちろん速度やリソースを無視して単に動くって意味なら何でも良い好きにしろ 346 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 10:16:28.69 ID:yNSfYish.net] long longで足りんとき俺はgmp使う 347 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 11:19:45.75 ID:ZUdmCczU.net] おれはlong long long使う 348 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 11:45:41.25 ID:lbVcz3R2.net] >>340 面白くないよ 面白いことを言ったつもり？ 349 名前：デフォルトの名無しさん [2021/04/22(木) 11:45:53.93 ID:aclQQfDP.net] お前らlong long long long使えるのしらねーの？ 350 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 12:22:51.68 ID:ZUdmCczU.net] 精度、用途、環境 で色々な方法を使うのがベスト カラツバだけ知っててもほとんど役に立たない 下位レイヤーでもFFT, double-double, ... など色んな方法があるし 上位レイヤーから下位レイヤーまで全体を考えて最適化しないとダメ 351 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 12:23:45.87 ID:7u43wDLB.net] boostって使える？ あれって、単なるテンプレートで遊んでるだけだろ そのくせにやたら遅い 正直使い物にならないイメージ 352 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 12:31:27.85 ID:EICaHt7b.net] >>226でいいじゃん。 これ以上早くしたかったらどうせ環境依存になる 353 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 12:43:04.70 ID:PcdMDerm.net] >>344 https://m.youtube.com/channel/UCnQU-nS2MqJDvLkOcISWvxQ 354 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 12:44:09.02 ID:b8cAf5Rb.net] >>344 使えるかどうかは置いといて、遅いのは最適化が効いてないとかでは？ 355 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 13:00:03.48 ID:7u43wDLB.net] >>347 formatなんて激遅 356 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 13:10:24.41 ID:EICaHt7b.net] >>344 boostは標準ライブラリとして採用するための実験場的な側面があるから、C++11以降を使っているならboostに足を向けて寝ちゃだめよ 357 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:00:53.68 ID:j9DIDz/e.net] stlもコンテナ類からして設計哲学に問題あると思ってる。 それにsize_tがunsignedで、ssize_tがsignedなのも馬鹿。 伝統的なCでは、strlen()などはintでsignedだったのだから、 短く書ける方のsize_tを最初からsignedにすべきだった。 358 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:06:31.92 ID:j9DIDz/e.net] 伝統的なCでは、 int strlen( const char *str ); だったのが、なぜか、64BITにも対応した後は、 size_t strlen( const char *str ); となってしまった。size_tは、必ずunsignedであるとされる。 ならばこのプロトタイプ宣言は、伝統的なCと互換性がない事になる。 しかも、伝統的に int a = sizeof(buf); のように、sizeof() は符号付き int を返す処理系が多かった。 一方、size_t は、sizeof()演算子の結果の符合なし整数とされる。 これもいろいろな意味で矛盾している。 C++11以降のC++はめちゃくちゃ。 359 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:08:44.22 ID:yNSfYish.net] 何年前のものだか忘れてんじゃね？ まだ単一継承が宗教のような存在だった頃だぞ これから新しく作るライブラリがああなってたらアホかとも思うが 当時そんな批評できてたやつを憶えているか？ 360 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:25:59.64 ID:j9DIDz/e.net] Cの教科書で、 int a; a = strlen(ptr); 見たいなのはよく見た記憶が有るが、 size_t a; a = strlen(ptr); というのは記憶に無い。 昔はsize_tなんて型は本には書いてなかった。 ところがネットだととても昔からstrlen()の戻り値はsize_tであった と言う事になってしまっていて、全世界的に事実を改竄している。 というか俺の記憶だけが世界の記憶と食い違ってる・・・。 361 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:38:12.90 ID:j9DIDz/e.net] 「サイズは本質的に負になることは無いから、符号無しでよい」 なるほど、これには一理ある。しかし、ptr2 - ptr1 は、ptrdiff_t で符号付きとされる。これは伝統的なCがそうであったから分かる。 しかし良く考えてみると、例えば32BITマシンで、2GBを越えるデータ を扱う場合、確かにそのサイズは符合つきでは扱えないので符合なしで 良い。ところが、この場合、最後のバイトをptr2、最初のバイトをptr1 でアドレスしているとすれば、ptr2 - ptr1 は、2G を超えた値になる。 おー、となると、ptr2 - ptr1 を ptrdiff_t のような符号付きで解釈すると 負の数となる！！！ おう神よ！！ 362 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:41:40.96 ID:j9DIDz/e.net] >>354 もう少し深く考えて見ると、ptr2 - ptr1 は、どちらが若いアドレスかが わからない時でも結果を理解するためには、結果は符号付き整数である ことには合理性がある。つまり、ptr2 < ptr1 なら、負、ptr2 > ptr1 なら 正と。 ところが、32BITマシンで、2GBを越えるデータを扱うと、この解釈では 問題が出る。 結論的には、sizeof()や ptr2 - ptr1 の結果の型に対してどんな場合にでも 上手く行く定義は存在しないようだ。 363 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 17:41:51.85 ID:yNSfYish.net] K&R1にはsize_tなんか出てこない strlenの戻り型はintとすら書いておらず 省略時の解釈で暗黙にintとなっている 364 名前：デフォルトの名無しさん mailto:sage [2021/04/22(木) 22:53:20.32 ID:V05yroc1.net] std::string::size_typeは？ 365 名前：はちみつ餃子 mailto:sage [2021/04/23(金) 02:30:22.88 ID:4SxnyUW7.net] >>351 「伝統的」っていつの話だよ。 C89 が制定されて以降、 strlen の返却値や sizeof の評価結果の型は size_t だろ。 念のためにちょっと確認してみたら Turbo C 1.0 なんて 1987 年の日付 (C89 制定前) だが strlen の返却値は size_t になってるぞ。 366 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 02:54:05.85 ID:ja7Blzf3.net] >>358 当時の本でも、 int a; a = strlen(ptr); と書いてあったと記憶してるので、指導的立場の人も含めてほとんどすべての人が unsigned int の戻り値を int の変数に入れていたということだね。 367 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 03:11:41.40 ID:ja7Blzf3.net] https://stackoverflow.com/questions/32985119/strlen-to-int-c-why-cant-i-do-this ↑こんなにC++に詳しそうな人達も、なぜか、符合無しの size_t を intと比較している： std::size_t length = s.size(); for (int i = 0; i < length; ++i) どこかでC/C++の長さは、intであると刷り込まれているようだ。 しかし、35年以上前のTurbo C ですら、unsigned intであったのに。 368 名前：デフォルトの名無しさん [2021/04/23(金) 03:13:55.04 ID:ja7Blzf3.net] 質問者は、 for (int i = 0; int n = (int)strlen(s); i < n, i++) がエラーになることの理由を聞いているようだが、これは単純に for文の書き間違いで、少なくとも、 int i, n; for (i = 0, n = (int)strlen(s); i < n, i++) と書けばコンパイルは通るはずだ。 369 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 03:25:18.34 ID:ja7Blzf3.net] スマン: 誤: for (i = 0, n = (int)strlen(s); i < n, i++) 正: for (i = 0, n = (int)strlen(s); i < n; i++) 370 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 05:23:38.34 ID:wmFgppeg.net] > どこかでC/C++の長さは、intであると刷り込まれているようだ。 これは違う double a = 0; と書いたからって0がdoubleと思っているのと違うようなものだ 371 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 08:03:05.37 ID:VR54cMAF.net] >>353 > 全世界的に事実を改竄している。 世界で自分だけ正しい、あとの70億人はすべて間違っていると考える病人 372 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 09:14:12.81 ID:W3jbQ1id.net] >>364 現代のガリレオかもしれない 373 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 14:58:50.01 ID:Lj3XxxY0.net] >>365 ガリレオの時代にガリレオ以外に地動説を考えてた奴が他にいなかったと思い込む馬鹿。 374 名前：はちみつ餃子 mailto:sage [2021/04/23(金) 19:32:09.65 ID:4SxnyUW7.net] >>360 その場合に int で表現可能な範囲内の値である限り暗黙の型変換で不整合は生じない。 strlen の返却値が size_t なのは、最大でそこまで対応可能ではあるが、 扱うデータの大きさが int の範囲内にあるという「想定」をしてもすぐさま誤りではないし、 int の範囲を超えるほど長大な文字列を想定しなきゃならない機会はそう多くもないだろ。 常識的な想定と言語仕様を混同するべきではない。 375 名前： mailto:sage [2021/04/23(金) 19:56:01.09 ID:O49wgyjt.net] >>365 私も、ある意見について「世界で自分だけ正しい、あとの70億人はすべて間違っている」という実感を持っています 問題はそれを世の中に知らしめす方法ですが、今の私はリアルで打撃につぐ打撃、その上におまけの打撃まで食らう状態で、いわば瀕死の状態‥‥ さてこんなボロボロな私はどうすればいいのでしょうか？ 376 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 21:03:11.51 ID:/ReE/HFJ.net] その意見とは？ 377 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 22:13:51.83 ID:P6csa9Qs.net] >>368 氏ね 378 名前：蟻人間 mailto:sage [2021/04/23(金) 22:32:09.50 ID:/PeODZRO.net] >>368 短期目標と長期目標を立てて、目標に達成したら、自分を褒める。これを繰り返す。 379 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 23:05:33.67 ID:E6ocica9.net] >>368 ビッグバンからやり直せ 380 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 23:26:25.47 ID:Q3jU6je8.net] >>368 あんたはビョーキだから何をしても無駄 「自分は間違っている」という実感を持てたら少しは回復した証拠 381 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 23:40:13.99 ID:dmQwGyWy.net] >>368 つ 聖遷・聖戦 お大事に 382 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 01:05:08.94 ID:zTQKHVDv.net] .hファイルと.hppファイルって何が違うんスかね includeするならincludeしたがわの拡張子でコンパイル方法？が決まるわけで ヘッダの拡張子の違いとは？ 383 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 01:15:37.87 ID:h5KFlu4v.net] .hには宣言だけ書いて.hppには 384 名前：実装を書くという使い分けをしている人が多い 宣言と実装を同時に行うときも .hpp [] [ここ壊れてます] 385 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 01:20:25.68 ID:/oCjni0O.net] STLコンテナに機能を追加したい (たとえば vector の要素の順番を自分のルールで並び替えるメンバ関数を追加したい) ときってどう書くのですか？ この場合はメンバ関数じゃなくてフリー関数として実装した方が良いとしても、メンバ関数を追加する方法を知りたいです (それとも、STL コンテナの継承が忌避されるのと同じ理由で、こういうのはやらない方が良い話ですか？) 386 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 01:32:10.18 ID:UuNl8IKh.net] >>377 継承すれば追加できるよ。 387 名前：はちみつ餃子 mailto:sage [2021/04/24(土) 01:45:45.85 ID:ubeHrzBk.net] >>375 仕様上の違いはない。 習慣的にもそれほどはっきりした使い分けが確立しているわけでもなくて 確かに >>376 もひとつの例として納得はできるけども 多いっていうほど多くもないような印象。 どういう意味で使い分けているのかは人 (組織) によるので、 違いがどういう意味を持つのかを一律には言えない。 個人的には、 C のヘッダとしても使えるように配慮した場合は h にするかな。 388 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 01:50:57.50 ID:zTQKHVDv.net] >>376 >>379 なるほど そういや自分もCのヘッダを意識する場合は.hにしてるかもですね どうもです 389 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 02:37:44.86 ID:/oCjni0O.net] >>378 でも STL コンテナの継承って凄い忌避されてる印象を持ってます 罠が多いって やっぱり引数で取って引数で返す方が良いのかな、、、 390 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:09:41.49 ID:CW6Yf84b.net] >>381 STLはソース(ヘッダだけど)を見ると物凄く解読に時間が掛かる書き方になって いて、正しく現状どうなって実装されているかを理解するのがとても難しいが、 継承するとなるとちゃんと理解出来てないと危険なので継承したがらない人が 多いのだと思う。 391 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:14:32.82 ID:CW6Yf84b.net] >>382 あと、テンプレートを普通のクラスの基本クラスにすることは容易だけど、 テンプレートを継承したテンプレートを作るのは、C++をかなり深く理解して無いと 色々と危険かも知れない。 また、ややこしくしてるのは、perfect forwarding や reference collapsing、 右辺値参照、moveセマンティクスが多用されていることに加えて、 余りドキュメント化されて無い解釈の難しい独自関数を使用して書かれている ことが多いこと。 392 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:21:35.70 ID:CW6Yf84b.net] >>383 それ以外にも、template引数に「...」があったり、それを使う場所でも「...」 があったりして、それぞれの意味や展開のされ方を正しく理解するのは難しい。 コンパイラがどういう解釈をするのか途方にくれることが有った。まるで 魔法のように見えることすら。結果的な意味は何とか分かっても、コンパイラが どういう原理や順序で理解したりコンパイルしているのか深く理解できないこと が多かった。 最新のSTLのソースをちゃんと理解できるまでC++を理解するのは、C++を 本格的に勉強する必要がある。 393 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:41:23.64 ID:CW6Yf84b.net] >>384 古いC++にも「initializer list」という言葉はあったが、C++11以降は 独特の概念が追加され、それに関連したオブジェクトを関数の引数にとったり できるようになったりして、それの働きを深く理解するのがまた難しい。 また、全体的に lvalue, rvalue に加えて、xvalue, prvalue, glvalueを正確に 理解し、何がどれに属するかを徹底的に理解してなければ、 394 名前：STLのソースコードを 正確に理解することはままなら無い。 僅かでも理解してないことがある状態でSTLのコンテナを独自に継承した テンプレートを作った場合、思わぬ不具合やメモリー関連の原因が特定しにくい バグをアプリ開発で忙しい時に遭遇してしまうかも知れない。 [] [ここ壊れてます] 395 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:49:16.98 ID:CW6Yf84b.net] 間違ってるかも知れないが、 initializer_list<T> は、「list initializer」に関係したテンプレートで、 登場したのはC++11移行なはず。 一方、member initializer listや、class initializer listは、名前が同じだが 全く別の概念なはずで、コンストラクタを関数定義する時に、 : MyBase(0), m_x(x), m_y(y) のように書く部分。 initilizer list と list initializer はかなり異なった概念なハズだが、 後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。 間違っていれば指摘して欲しい。 396 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 03:49:17.13 ID:CW6Yf84b.net] 間違ってるかも知れないが、 initializer_list<T> は、「list initializer」に関係したテンプレートで、 登場したのはC++11移行なはず。 一方、member initializer listや、class initializer listは、名前が同じだが 全く別の概念なはずで、コンストラクタを関数定義する時に、 : MyBase(0), m_x(x), m_y(y) のように書く部分。 initilizer list と list initializer はかなり異なった概念なハズだが、 後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。 間違っていれば指摘して欲しい。 397 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 04:06:25.90 ID:AUtfiExa.net] クラス A の中で他のクラス B のインスタンスをメンバとして持ちたいとき、B のコンストラクタに引数を渡す方法が初期化リストくらいしかない つまり後でわかる情報を使って B のコンストラクタを呼ぶ方法がない B じゃなくて B のポインタを持てば良いって思うかもしれないが、こんなどーでも良いところでポインタの使用を強制する言語仕様ってゴミだろ もーちょい頑張んなよ、C++クン 398 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 05:28:21.58 ID:n+JXhE4b.net] >>388 バカ？w 399 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 05:36:02.19 ID:RMr7e0df.net] 疑問符はいらないね 400 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 06:48:46.10 ID:glcm53ed.net] using namespace std をヘッダファイル内で使いたいです。なんせ短くなるので でも、そうすることでリスクを負うというのもわかります どう折り合いをつけるべきでしょうか 皆さんはどうされていますか 401 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 06:59:42.53 ID:xdmXCppW.net] >>381 メンバ関数追加するだけならまぁ問題は思いつかないけど(スライシングや非仮想のデストラクタはメンバ変数追加が無ければOK ただ素のvectorからの代入やコピー、ムーブコンストラクトは出来ないので追加で書いてやらないといけない さらにそのメンバ関数を呼ぶには派生型にキャスト(コピーとか防止のために参照でキャスト)をいちいち書かないといけない まぁそんな面倒な派生クラス使うくらいならフリー関数にしといた方が楽だよね そんなこんなで安易な機能追加のための継承(まして継承される前提でないクラスを)ってのは普通避ける 402 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:00:28.36 ID:xdmXCppW.net] >>491 そんなの自分で決断すれば 403 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:00:46.76 ID:xdmXCppW.net] すまん>>391だった 404 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:13:23.58 ID:RMr7e0df.net] >>391 ARM C++のコンパイラ使ったら？ #include <iostream.h> これならstd空間が元々ないよ 405 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:14:46.51 ID:+S3huMNR.net] コンテナは継承するまでもないほど完成されていること、 コンテナを継承するくらいならコンテナをメンバ変数にもつクラスを定義したほうが機能拡張や仕様変更に対応しやすい などなどでしょ 406 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:59:47.57 ID:glcm53ed.net] >>393-394 でも例えば公開するとかなってくると当然 using namespace std; は問答無用で除くべきですよね？ あと近い話で、マクロってどこに書いたら良いんでしょうか REPマクロ等を多用するんですが、同じマクロをいろんなヘッダファイルの冒頭に書くのって変ですか？ 共通するマクロは、親に該当する utility.hpp みたいなヘッダファイルを作ってそこに書く等するべきですか？ 407 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:07:53.01 ID:RMr7e0df.net] >>397 ああ、それなら俺もやる 開発初期はusing namespace std;で色々試していて 公開がちらついてきたあたりで律儀にstd::を書くスタイルに変えていく 408 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:12:30.74 ID:fCIZIfYl.net] 同じものはまとめるのがプログラミングの鉄則 409 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:15:10.79 ID:V/Qt/+uA.net] 自分はC++17でusingディレクティブでなくusing宣言のパック展開使ってるけど、(using std::cout, std::endl, std::string; とか) これも好ましくないのかな 410 名前：デフォルトの名無しさん [2021/04/24(土) 08:17:39.39 ID:+S3huMNR.net] using std::* したいスコープを独自の名前空間で囲めば他人に迷惑かけずに済む マクロは名前空間を超えるので他人に迷惑かけやすい 411 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:30:55.95 ID:glcm53ed.net] >>401 その理屈だと、公開するプログラムにおいてはマクロはよほどユニークな名前じゃない限り使うべきじゃないってことですか？ 412 名前：デフォルトの名無しさん [2021/04/24(土) 08:35:45.72 ID:+S3huMNR.net] ヘッダーファイルでマクロを定義するなら名前衝突を警戒すべきであって理屈とかじゃなくてマナー 413 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:40:34.40 ID:xdmXCppW.net] >>397 ユーザーにincludeされるヘッダじゃなくてcppでだけusingすればいいやろどうせ実装書かないんだから (テンプレートとかでヘッダに実装書くならすでに出てる通り名前空間に隠すとか >>402 まず被らない名前ならいんじゃね それかundefするヘッダも作って使い終わった段階でそれをインクルード 414 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:45:45.71 ID:fCIZIfYl.net] Windowsのmin,maxとかAppleのcheckとか 考えなしの公開マクロ名は使う側に大迷惑だから慎重にしないといけない 415 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 09:19:30.74 ID:aNHhbYgZ.net] minとmaxが関数型マクロなのはやさしさ #include <Windows.h> #include <stdio.h> #include <algorithm> int main() { 　int a = 3, b = 4; 　//int x = std::max(a, b);　　// NG! ビルドエラー 　int x = (std::max)(a, b);　　　// OK 　printf("x=%d\n", x); } 416 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 09:57:34.16 ID:RMr7e0df.net] #include <windows.h> #undef max #undef min 417 名前：デフォルトの名無しさん [2021/04/24(土) 10:18:48.27 ID:N1eYD/7j.net] >>398 >>401-403 namespace hoge { using namespace std; プログラム本体 } って書いておけば他と干渉しないんじゃないの 418 名前： mailto:sage [2021/04/24(土) 11:03:59.20 ID:Acac14lu.net] >>307 あなたの粘着力には、ほとほとあきれかえりますね‥‥それって何年前の話？ toro.2ch.net/tech/1369350072/171 171 ◆QZaw55cn4c [sage] 投稿日2013/07/11(木) 01:45:29.07 ラプラスは練習中 けれどもどうせ資格試験用だし、むずかしいことははなからやるつもりもないのです、複素関数論なんて一生縁がないとおもう留数とかもう忘れた‥‥ なお、実は 8　年たった今でも私はラプラスは練習中だったりするのです‥‥資格試験の方は諦めていますが いま詰まっている箇所は以下の定理、証明がわからない、誰か教えて‥‥ https://ja.wikibooks.org/wiki/%E5%88%B6%E5%BE%A1%E3%81%A8%E6%8C%AF%E5%8B%95%E3%81%AE%E6%95%B0%E5%AD%A6/%E7%AC%AC%E4%B8%80%E9%A1%9E/%E9%80%A3%E7%AB%8B%E5%BE%AE%E5%88%86%E6%96%B9%E7%A8%8B%E5%BC%8F%E3%81%AE%E8%A7%A3%E6%B3%95/%E9%80%A3%E7%AB%8B%E5%BE%AE%E5%88%86%E6%96%B9%E7%A8%8B%E5%BC%8F%E3%81%AE%E8%A7%A3%E6%B3%95/%28%73%49%2D%41%29%5E-1%E3%81%AE%E5%8E%9F%E5%83%8F/%E8%A1%8C%E5%88%97%E3%81%AE%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%81%A8%E4%BD%99%E5%9B%A0%E5%AD%90 419 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 11:32:30.02 ID:plvAJ+CF.net] >>409 ×留数とかもう忘れた・・・ ◎留数なんて勉強してません高卒てすから 420 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 11:40:13.58 ID:TN7U0OWK.net] 学歴コンプレックスって醜いよね〜 ところでラプラスって何ですか？ ラプラシアンなら知ってるんですけど Lhaplusのことですか？ 421 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 11:53:07.06 ID:zTQKHVDv.net] >>409 そういうのは小さい次元,2x2あたりで計算してみて、大きい次元でも成り立ちそうだなと納得するのが早いかもですな 422 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 12:43:43.67 ID:aNHhbYgZ.net] つか人生相談は板違い、 一生虐げられ続ける弱キャラとしての宿命がC++の規格書に書かれているなら話は別だが 423 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 12:44:49.58 ID:aNHhbYgZ.net] >>407 天才か！ 424 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 12:47:38.37 ID:glcm53ed.net] ヘッダオンリーライブラリの体で自作のプログラム配布するときって、全体を namespace でくるむのがマナーなんですかね 普通な名前の関数を定義したりして衝突したら不味いから？ 425 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 12:56:34.70 ID:fCIZIfYl.net] ヘッダオンリーに限った話じゃない 426 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 13:00:31.18 ID:xdmXCppW.net] >>414 それならNOMINMAXでいいのでは 427 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 13:05:05.35 ID:aNHhbYgZ.net] >>417 もしプリコンパイルヘッダーに #define NOMINMAX #include <Windows.h> と書いてしまった暁には、マクロ版のmin()やmax()を使いたい人は どうやって生きていくんじゃ…… 428 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 13:16:46.63 ID:xdmXCppW.net] なるほど（´･ω･`） 429 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 13:33:18.27 ID:5mKZGvgg.net] boost の多次元配列ライブラリ multi_array を使ってるんだが、両辺の shape が違うときに = で代入できないのがストレスなので、引数の shape が違うときには左辺を右辺と同じようにリサイズしてから代入するように = の定義を変えたい 演算子のオーバーロードってテクを使えば良いらしいが、これは諸刃の剣で注意が必要みたいな記事を見て戦々恐々としてる、、、 代入演算子のオーバーロードで最低限気をつけるべきことってどういうものですかね 430 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 14:01:29.71 ID:F03PJ4BE.net] 気をつけるべきこと 代入演算子を一時的なストレスでオーバーロードしない 431 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 14:04:54.62 ID:xdmXCppW.net] 代入はグローバルに書けないはず メンバとして書くしかない->multi_arrayのヘッダを書き換えるしかない 432 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 14:18:13.19 ID:jLd1Bq7I.net] new して確保するわけじゃない、既存の変数のアドレスを格納するだけのポインタって別にスマートポインタじゃなくて生ポで持てば十分だよね？ 433 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 14:33:50.86 ID:RMr7e0df.net] 生ポでいい用途を自信を持って判断できず「念のため」スマポ使うやつでも見かけた？ 434 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 14:39:12.20 ID:jLd1Bq7I.net] いや自分が不安なだけ 435 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 15:34:17.33 ID:fCIZIfYl.net] 用途次第だけどnullにならない分参照の方がいいかもしれない もしくはshared_ptrと一緒に使うならweak_ptr 436 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 15:39:23.77 ID:jLd1Bq7I.net] >>426 後出しですみませんが、vector の各要素へのポインタを vector で持つ事も考えてます 参照の vector は普通には持てないので、その意味でももう生ポインタの vector で良いかって気になっていました 437 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 15:46:35.43 ID:fCIZIfYl.net] reference_wrapperなら参照vector作れるけど、そこまでしたくないってことならポインタでいいんじゃない 気をつけてな 438 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 17:56:54.49 ID:F03PJ4BE.net] 考えるべき所がズレてる 既存の変数はポインタを保持してる期間に必ず存在しているか 別スレッドから既存の変数へのアクセスが発生するか 表記方法を考えるのはその後 439 名前：はちみつ餃子 mailto:sage [2021/04/24(土) 18:25:12.58 ID:ubeHrzBk.net] >>423 こういう場面では生ポインタでいいよね？ っていう意味？ #include <memory> int main(void) { int a; std::unique_ptr<int> b(&a); } むしろ不必要に解放しようとしてワヤになるんで、生ポインタである必要がある。 デリータが何もしないようにすればスマートポインタでも大丈夫ではあるけど、 あえてそうする必要もないし。 >>427 std::vector は要素を追加するなどしたときに再配置が起こる可能性があるから 要素へのポインタ (または参照) を持つのはあまりオススメできない。 (インデックスで持ったほうがいい。) 適切に管理できるならポインタでもそれほど問題でもないんだけど、 質問の雰囲気を見る限り十分な理解があるような感じでもないので……。 440 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 18:40:32.67 ID:F03PJ4BE.net] vectorの中身なら 要素の参照やポインタ vectorの参照やポインタと要素のインデックス イテレター 色々と持ち方があるから 場面場面において適切なのを選ぶ メモリ管理をしてないのにスマポで保持は無い

---

---

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

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