C++相談室 part154

**デフォルトの名無しさん** · 2021/01/08(金) 17:54:00.55

※前スレ
C++相談室 part153
https://mevius.5ch.net/test/read.cgi/tech/1602339500/

テンプレここまで

**デフォルトの名無しさん** · 2021/02/08(月) 11:20:50.36

>>627,628
そういうのは無視しろ

**デフォルトの名無しさん** · 2021/02/08(月) 12:00:56.57

スルーの法則

**デフォルトの名無しさん** · 2021/02/08(月) 12:43:41.70

>>602
>>599
誰か
永続的に使用するなら shared_ptrで受け取れ。今のままだとsetSansyoを呼び出す側が所有権手放していいのかわからなくて困るだろ。
て指摘した？
今や生ポインタなんて性能優先のときに内部的に使用するもんで、インターフェイスで使用するもんじゃない。

あと、参照も関数内だけで使用する引数に使うもんで、永続的に所有する引数に使うもんじゃない。

**デフォルトの名無しさん** · 2021/02/08(月) 14:04:18.90

コンストラクタでなら参照型のメンバ変数に保存できる。ほとんどの人はやらないけど。

**デフォルトの名無しさん** · 2021/02/08(月) 18:54:29.18

>>633
できるのと実際に実装するのは別の話だわな。
所有権の無いオブジェクトの参照を保存するなんて狂気の沙汰だ。

**デフォルトの名無しさん** · 2021/02/08(月) 19:12:34.60

アイキャンユーキャン。

**デフォルトの名無しさん** · 2021/02/08(月) 20:51:28.21

>>633
クラス間に親子関係のようなものがあって、子の生存期間が常に親の生存期間内にあるような場合は、親への参照をメンバ変数とすることは普通にあると思うけど。例えば>>484とか

**デフォルトの名無しさん** · 2021/02/08(月) 21:15:43.14

shared_ptr(またはスマポ)至上主義の変なやつ以前から居るんだよな
相手にするな

**デフォルトの名無しさん** · 2021/02/08(月) 21:37:27.20

ナマポ使ったほうが良い場面なんて皆無でしょう

**デフォルトの名無しさん** · 2021/02/08(月) 21:48:31.75

出たwナマポ完全否定奴w

**デフォルトの名無しさん** · 2021/02/08(月) 21:58:57.06

参照型のメンバ変数は参照オブジェクトの生存期間を保証できないからweak_ptrで保存しておいて使う時だけshared_ptrを取得するのがC++的な解決なんじゃないの。

**デフォルトの名無しさん** · 2021/02/08(月) 22:08:09.48

スマポにしたら所有権の問題を考えなくてよい
というわけではないからスマポ使えというのは妥当ではない
逆に所有権に矛盾が無ければインスタンスは生成元が与えた参照を持って良い

ていうかスコープを抜けたら自動的に解放される系のクラスを書いたら
エラー処理上エラー通知先としての生成元オブジェクトの参照保持はほとんど不可避

**デフォルトの名無しさん** · 2021/02/08(月) 22:11:14.29

コピー禁止のshared_ptr欲しい

**デフォルトの名無しさん** · 2021/02/08(月) 22:25:23.27

すべてスマポで書くスタイルも悪くないと思うけど、メイヤーズ神もツリー構造で子が親のポインタを持つときはナマポで十分と書いている

**デフォルトの名無しさん** · 2021/02/08(月) 22:27:43.60

木のノードは子へのポインタじゃなくて子のノードIDを持て😡

**デフォルトの名無しさん** · 2021/02/08(月) 22:48:15.38

自分よりポインタの方が寿命が長いことが保証されているなら確かに生ポで問題ないが
それが成り立つ状況ってなかなかないよな。

**デフォルトの名無しさん** · 2021/02/08(月) 23:02:19.81

参照先の実体がまだ生存しているかどうか知るにはweak_ptr::expired()を使うしかないのが現状でしょ。

**デフォルトの名無しさん** · 2021/02/08(月) 23:07:56.19

Chromiumはstd::unique_ptrを全面的に使ってるけど、ポインタを使う設計そのものが古いような気がする。

**デフォルトの名無しさん** · 2021/02/08(月) 23:13:28.50

まあcコードを全く使わないってのならいいんでないの。
ただc++のポータビリティーは君が思ってるより低いけどね。

**デフォルトの名無しさん** · 2021/02/08(月) 23:23:15.47

露骨すぎるマウント取りたがりダッセーｗｗｗ

**デフォルトの名無しさん** · 2021/02/09(火) 01:58:29.04

マウントじゃなくてポインタでは？

**デフォルトの名無しさん** · 2021/02/09(火) 02:46:23.52

C++に特化したAPIなんてどこのOSでも提供されないから、結局、Cの配列と互換性のあるstd::vectorやstd::arrayを使わざるを得なくなる。

**デフォルトの名無しさん** · 2021/02/09(火) 04:01:45.22

>>644
木もコンテナで良いですよね。
所有権がハッキリしてて。

**デフォルトの名無しさん** · 2021/02/09(火) 07:34:27.86

>>651
data()を必ず使う手合いか？

**デフォルトの名無しさん** · 2021/02/09(火) 07:39:10.06

木は木全体を収める領域ごと一気に解放する場合もあるから別に

**デフォルトの名無しさん** · 2021/02/09(火) 17:49:12.66

>Cの配列と互換性のある

doubt

**デフォルトの名無しさん** · 2021/02/09(火) 17:53:30.91

ダウトとデビューって似てるよね

**デフォルトの名無しさん** · 2021/02/09(火) 18:35:55.16

親が子のポインタを所有する木は、親を消すとネストして子孫のデストラクタを呼ぶので、スタックが枯渇します。

したがって、子から順番に消さなくてはなりません。

**デフォルトの名無しさん** · 2021/02/09(火) 18:56:53.48

その様はまるで摩天楼がドミノ倒しのように連鎖倒壊するようでもあり、DOMINOというピザにもなっています・

**デフォルトの名無しさん** · 2021/02/09(火) 19:07:16.84

なんと後味の悪い話

**デフォルトの名無しさん** · 2021/02/09(火) 20:39:36.84

意味が分からない

**デフォルトの名無しさん** · 2021/02/09(火) 21:07:48.14

>>657
それで枯渇するようじゃ木の探索すらできない。

**デフォルトの名無しさん** · 2021/02/09(火) 21:13:02.23

探索はループでもできるんで、たとえば数万個の要素を持つツリーを子から消せというのは真理なのかも

**デフォルトの名無しさん** · 2021/02/09(火) 21:27:40.55

消すのは独立して実行できるので別スレッドに送れば実質コスト0

**デフォルトの名無しさん** · 2021/02/09(火) 21:38:09.75

>>662
DFAとPDAではやれることの範囲の違いがちげう

つかこの場合は安易にスマポとかコンテナを使うから破棄ごときにトラバースの手間がかかるんである

**デフォルトの名無しさん** · 2021/02/09(火) 21:44:42.72

それもそうであるな

**デフォルトの名無しさん** · 2021/02/09(火) 21:50:17.60

ちゅか垂直探索なら木をメモリに持っておく必要が無い
水平探索ならメモリ上に世代1、世代2、....と木を育てていく（らしい）が
兄弟ノードを全部見終えたのでいざ従妹ノードに移ろうとするときに
親ノードへの参照は欲しい木がするがするとshared_ptrなら即循環参照になり、
子の情報で親（子孫がいっぱいぶら下がっている）を生成できるわけもないから、
ウィークポインタの出番でもない

**デフォルトの名無しさん** · 2021/02/10(水) 01:37:49.58

子から消さなかったばかりに。
2000人を乗せた航空機が洋上で消えた。
ってなるかも？

**デフォルトの名無しさん** · 2021/02/10(水) 01:48:13.89

A380でさえ853席だが2000人なんてどうやって載せるんだろう

**デフォルトの名無しさん** · 2021/02/10(水) 01:51:41.17

く、空中で衝突するとか…

**デフォルトの名無しさん** · 2021/02/10(水) 01:53:08.99

インドでは屋根の上にも乗ります。

**デフォルトの名無しさん** · 2021/02/10(水) 01:55:11.55

https://trafficnews.jp/post/80031

証拠写真みつけてきた。

**デフォルトの名無しさん** · 2021/02/10(水) 01:55:17.84

GTA5のMOD作成者みたいな会話だな

**デフォルトの名無しさん** · 2021/02/10(水) 02:01:19.54

>>653
昔はdata()がなかった。(遠い目)

**デフォルトの名無しさん** · 2021/02/10(水) 06:40:17.61

アントノフの貨物室にすし詰めでどんくらい乗れるかな

**デフォルトの名無しさん** · 2021/02/10(水) 06:40:27.16

東京: TK
京都: KT
大阪: OSK
淡路: AWG

**デフォルトの名無しさん** · 2021/02/10(水) 07:59:22.76

航空機や原発みたいなクリティカルなシステムでは
全部固定長の配列で書いてあるんじゃないの

**デフォルトの名無しさん** · 2021/02/10(水) 08:06:21.27

釣れますか。
ヒープのほうが少し安全です。

**デフォルトの名無しさん** · 2021/02/10(水) 10:25:11.13

>>671
どこが証拠やねん!
せいぜり100人やないかヽ(`Д´)ﾉ

**デフォルトの名無しさん** · 2021/02/10(水) 14:32:04.65

すみません、std::for_each を使っていて continue したくなりましたが、サポートしてないです
よね? これって:
1. for_each は continue する必要がないような処理に限ってに使うべき。
2. ループの中で大きい if ブロックを作って空の処理にすればよい。
3. その他

**デフォルトの名無しさん** · 2021/02/10(水) 15:13:45.18

returnすれば？
for_each(begin(foo), end(foo), []{ if(bar) return; });

**デフォルトの名無しさん** · 2021/02/10(水) 16:06:00.49

return は continue ではなく break じゃないの？
質問者の2.大きなif分で実質何もしないでいいと思う

**デフォルトの名無しさん** · 2021/02/10(水) 16:20:11.24

for_eachをbreakするにはthrowかlongjmpがいるぞ

**デフォルトの名無しさん** · 2021/02/10(水) 16:35:39.62

きったねぇジャンプだ

**デフォルトの名無しさん** · 2021/02/10(水) 16:51:31.94

あ、ラムダ式になってたのか

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/10(水) 17:51:08.81

>>679
for 文で書いた方が短く書けそうだけど、
あえて for_each を使いたい理由が何かあったりするの？

**デフォルトの名無しさん** · 2021/02/10(水) 18:41:41.17

Perlなら問題無くできる（continue→next、だが
C++規格委員会がfor_eachのcontinueを許可しないのは最後の一線なのかもしれん…

**デフォルトの名無しさん** · 2021/02/10(水) 19:51:57.06

何の一線よ

**デフォルトの名無しさん** · 2021/02/10(水) 20:18:41.39

いやreturnでいいだろ…
許可しないってなんのことだよ

**デフォルトの名無しさん** · 2021/02/10(水) 21:21:18.68

vectorで一億件ほどで、飛ばしたいのが100～1000件程度なんだろう

**デフォルトの名無しさん** · 2021/02/10(水) 21:51:25.56

>>679
for_eachをrange based forに変更は出来ないの？

**デフォルトの名無しさん** · 2021/02/10(水) 21:59:01.21

>>690
おまえのスキルのためにか？

**デフォルトの名無しさん** · 2021/02/10(水) 22:17:23.69

range based forなら普通にcontinueできるぞ

**デフォルトの名無しさん** · 2021/02/10(水) 22:18:26.21

>>689
飛ばす手段があったとして、飛ばすかどうかどこでどう判断するの？

**デフォルトの名無しさん** · 2021/02/11(木) 04:16:42.30

early returnは正義

**デフォルトの名無しさん** · 2021/02/11(木) 11:22:44.35

>>685
テンプレのときとか

**デフォルトの名無しさん** · 2021/02/11(木) 17:53:02.68

679がなぜfor_eachを使うのかを無視するのは
他人の領分を侵すお節介だ

for_eachの使い方をアドバイスできんやつは
しゃしゃり出てくるな

**デフォルトの名無しさん** · 2021/02/11(木) 18:00:13.22

よくよく話を聞いてみたらまるで異なる解決策が見つかるなんてよくあることじゃん。そんな経験ないの？
何をしたかったか確認するのは重要

**デフォルトの名無しさん** · 2021/02/11(木) 18:15:41.21

流れをよく読んでみろよ
for_eachをロクに使ってないやつなのモロバレだろ
質問者が尋ねていないことを答えたいから協力しろなんてぬかすのは
回答者の資格ねえんだよ

**デフォルトの名無しさん** · 2021/02/11(木) 18:18:25.32

自分が何か尋ねているときに
質問内容に付き合ってやれる懐のねえやつは
うぜえだけだろが

**デフォルトの名無しさん** · 2021/02/11(木) 18:23:57.31

質問内容において自分より下なやつに教えを請いたいかよ

**デフォルトの名無しさん** · 2021/02/11(木) 18:34:11.92

for_eachを使う場合の答えはとっくに出てるのに何言ってんの？

**デフォルトの名無しさん** · 2021/02/11(木) 19:17:08.97

3のその他で答えただけ。

**デフォルトの名無しさん** · 2021/02/11(木) 20:01:29.92

他人の領分なんて侵してナンボ

**デフォルトの名無しさん** · 2021/02/11(木) 20:03:18.37

>>702
はあ？returnではいけない理由は？

**デフォルトの名無しさん** · 2021/02/11(木) 20:19:00.69

>>679はループしたいだけだろ
std::for_eachを何が何でも使わなければならない特殊な事情があるなら仕方ないけどそんなこと言ってないし

**デフォルトの名無しさん** · 2021/02/11(木) 20:23:31.36

>>704
returnで良いと思うよ。

**デフォルトの名無しさん** · 2021/02/11(木) 20:50:06.93

>>701
680は俺だが何言ってんの？

**デフォルトの名無しさん** · 2021/02/11(木) 21:58:36.08

Visual Studio 2010（MSVC2010）で
　template<class T>
　void foo(T x) {
　　printf("%d: %d\n", targetEntity, x);
　}
という関数テンプレートが定義されているときに、
　namespace bar { const int targetEntity = 1; }
　using bar::targetEntity;
　void baz() { foo(100); }
はコンパイルが通るのに、
　namespace bar { const int targetEntity = 1; }
　void baz() {
　　using bar::targetEntity;
　　foo(100);
　}
だと
　error C2065: 'targetEntity': 定義されていない識別子です。
と言われるorz

**デフォルトの名無しさん** · 2021/02/11(木) 22:06:56.76

>>688
for_eachを勘違いいてたわｻｰｾﾝ、
確かにfor_each<bgn, end, Function>のFunction(*it)からならreturnするで良さげ

**デフォルトの名無しさん** · 2021/02/11(木) 23:28:48.49

>>707
アンパンマンはキミだ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/12(金) 01:36:02.90

>>708
宣言の有効範囲は宣言された場所からその宣言を含むブロックの終わりまでというのが原則
(クラススコープなどの例外はあるのでその他にも関連するルールはあるかもしれんけど)
なのでどちらもエラーになるのが筋だと思うし、 gcc や clang で試したらどっちもエラーだった。

逆にどういう理屈で前者が通るのかは気になる。

**デフォルトの名無しさん** · 2021/02/12(金) 06:02:20.64

>>708
当たり前だね
最初の例ではtargetEntryをグローバル空間に導入しているからbaz()とfoo()の両方から見える
２番目の例ではtargetEntryをbaz()のブロック内に導入しているから、そこに包含されないfoo()のブロックからは見えない

ただし、これはfoo()を関数原型と関数定義に分けて関数定義をbarよりも後方に置いた場合の話だ
原文のままでは>>711が言うとおり通るわけがない

**デフォルトの名無しさん** · 2021/02/12(金) 06:03:16.30

- barよりも後方
+ usingよりも後方

**デフォルトの名無しさん** · 2021/02/12(金) 07:01:12.63

確かにideoneでもVS2019でも両方エラーになるのですだが、
1番目の例はVS2010ではビルドも通って動くもーん

ソース:
https://ideone.com/DC8fMv

実行結果（※ VS2010限定）：
1: 100
続行するには何かキーを押してください . . .

**デフォルトの名無しさん** · 2021/02/12(金) 07:04:11.00

ちな関数テンプレートfoo()の定義をusingよりも後方にしたら全てでビルドが通って動く
まそりゃーそうならないとおかしいが

**デフォルトの名無しさん** · 2021/02/12(金) 07:12:42.48

>>714
通ってねえじゃん
何が言いたいんだ？

**デフォルトの名無しさん** · 2021/02/12(金) 07:17:08.75

>>716
> >>714
> 通ってねえじゃん
> 何が言いたいんだ？
※ VS2010限定

**デフォルトの名無しさん** · 2021/02/12(金) 07:24:49.77

だから何？
ill-formedなのがわかっても自分が正しいと強弁したいのか？

**デフォルトの名無しさん** · 2021/02/12(金) 07:27:26.57

全員の主張を再検証しただけでつよ？
>原文のままでは>>711が言うとおり通るわけがない (>>712)
が覆されてご機嫌ななめ？？

**デフォルトの名無しさん** · 2021/02/12(金) 07:32:07.63

覆った？
おまえVS2010限定で逃げただろ
ill-formedはill-formed
これを覆せたら出直して来な

**デフォルトの名無しさん** · 2021/02/12(金) 07:34:53.80

俺も昔のバージョンのコンパイラは使うがバグ技は使わないし
そういうことをする厨二病とは組みたくない

**デフォルトの名無しさん** · 2021/02/12(金) 07:38:38.54

>おまえVS2010限定で逃げただろ
VS2010ではビルドが通るというのが話の発端なので…
1番目の例がill-formedであろう点は同意

**デフォルトの名無しさん** · 2021/02/12(金) 07:51:23.22

orzなんだろ
何が誰が悪いのかわかったら素直になれよ
居直る態度が気に入らねえ

**デフォルトの名無しさん** · 2021/02/12(金) 08:12:22.74

何が悪いのか、はともかく
誰が悪いのかとは一体…
つか現象（事実）の提示に対してそれを反発と解釈して勝手に炎上しないでいただきたい；；；

個人的にはVS2010のバグである可能性でほぼ確定とは思いつつ、
例1と例2で動きが違うことから、MSVC2010は、グローバルなシンボルについて
template foo()や関数baz()の中の解釈に入る前に名前空間を確定させる実装なのだと感じる
（template foo()の解釈ロジック自体にバグがあるなら例1、2とも同じ結果になるのが自然

再発防止のためには、C++規格のどこをどう読めば良いんじゃorz

**デフォルトの名無しさん** · 2021/02/12(金) 08:57:55.62

>>719は明らかに煽り口調だろうが
和解したいなら、あの態度を撤回しろ

俺は和解なんかできなくて構わんが

**デフォルトの名無しさん** · 2021/02/12(金) 10:26:37.15

匿名掲示板で誰が何を言ったのどうのとみっともないぞデフォルトの名無しさんよ

**デフォルトの名無しさん** · 2021/02/12(金) 11:29:35.12

どう見ても>>716がイミフな言いがかりつけてるだけにしか見えんが…

> 確かにideoneでもVS2019でも両方エラーになるのですだが、
> 1番目の例はVS2010ではビルドも通って動くもーん

**デフォルトの名無しさん** · 2021/02/12(金) 13:22:44.45

匿名でも江副とかQZとか片山やはちみつが糞なのは伝わってくるω

**デフォルトの名無しさん** · 2021/02/12(金) 18:24:14.30

単発IDになりやがった
どこまでも腐ってやがるな

**蟻人間** ◆T6xkBnTXz7B0 · 2021/02/12(金) 19:12:56.39

どこでも動くように標準化しましょうねって話だよね。