C++相談室 part142 ->画像>13枚

801デフォルトの名無しさん2019/06/07(金) 10:34:36.93ID:9H5/9dgd

ようするにラムダ式をチェインさせればいいんだろ
かんたんじゃん
Lispの時代に近づいてるだけだ

802デフォルトの名無しさん2019/06/07(金) 10:35:22.44ID:aX0Y7AKm

>>798
理想的な名前付き引数が存在するなら「名前付引数に比べてデメリット」といえるんだろうけど、
C++には名前付引数ないよね？

803デフォルトの名無しさん2019/06/07(金) 11:29:19.04ID:O2O1gPjv

メソッドチェーンとかいらんわ
リファクタリングしにくいし
Kotlinのapplyがベスト

804デフォルトの名無しさん2019/06/07(金) 11:30:58.83ID:dp7q4wQg

横に長いのがいやなんだよな
多少冗長でも縦の方がいい
特になっがいメソッドチェーンで途中から返り値変わってるやつとか殺意わく

805デフォルトの名無しさん2019/06/07(金) 11:38:12.52ID:Pe4fcpYB

関数の定義は正方形に近いのがいい

806デフォルトの名無しさん2019/06/07(金) 12:23:28.70ID:CBwJTjr/

>>802
そのうち追加されるだろうから待ってなよ

807デフォルトの名無しさん2019/06/07(金) 12:25:28.59ID:CBwJTjr/

>>799
行数増えるのになんの問題があるんだ？
横に長いとか見辛いし差分も取りにくいしメリットないだろ

808デフォルトの名無しさん2019/06/07(金) 14:04:49.95ID:Pe4fcpYB

>>807
縦にも横にもスクロールしたくないだけさ
>>805 に書いた

809デフォルトの名無しさん2019/06/07(金) 14:45:14.80ID:8IyUxlC9

ところで>>776のような return *this;　だとコピーが発生しないか？
return this;; として->でメソッドチェーンにするのならわかる

810蟻人間 ◆T6xkBnTXz7B0 2019/06/07(金) 14:59:30.42ID:KffKHULn

>>809
戻り値の型に&が付いてるから参照だ。

811デフォルトの名無しさん2019/06/07(金) 15:25:18.97ID:adznp1U4

>>810
普通はメソッドチェーンとかいらんけど
GUIのライブラリとかはそっちのほうが使いやすそうな気がする

812デフォルトの名無しさん2019/06/07(金) 15:29:32.41ID:DvEE5fSZ

ちゃんとした設計になっていればどんなスタイルでもいいよ

813デフォルトの名無しさん2019/06/07(金) 15:59:52.88ID:Qcue35T9

sortの比較関数についてなんですけど
たとえばvector<int> v = {0, 1, 2, 3, 4, 5}があったら
bool compare(const int& num1, const int& num2) { return num1 > num2; }
sort(v.begin(), v.end(), compare)で降順になりますよね

なるほど、0< n < v.size()でどのv[n]とv[n+1]でもcompareがtrueを満たすように
並び替えてくれるんだな、って理解したんです
それで試しに
bool compare(const int& num1, const int& num2) { return num1 == (num2 + 1); }
って書き換えたんですけど降順になってくれないんです
どのv[n]もv[n + 1] + 1に等しい→降順になると思ったんですけど

評価関数ってどう理解したらいいんでしょう？

814デフォルトの名無しさん2019/06/07(金) 16:06:41.20ID:adznp1U4

pred内でprintfデバッグでもしてみたら？
n番目ととn+1番目の要素以外でも比較が発生しているのがわかるから。

815デフォルトの名無しさん2019/06/07(金) 16:47:23.38ID:StFsiGGy

比較関数の右辺と左辺が入れ替えて比較した結果が矛盾してると、ソートは意図しない挙動になる。当たり前ではあるけど。

816デフォルトの名無しさん2019/06/07(金) 16:52:15.04ID:RgT+kAkp

>>813 俺も理解せずに言葉だけ覚えてるんだけど、
比較関数の性質として「狭義の弱順序」を示さなくちゃいけないのだ。

「狭義の弱順序」でネット検索すれば分かると思うよ。
少なくとも俺の場合「自分には(今のところ)理解できない」ことが分かった。

…て言うか、誰か分かりやすい解説サイトなど紹介してください。

817デフォルトの名無しさん2019/06/07(金) 17:52:26.15ID:9H5/9dgd

群論のマグマやモノイドあたり

818デフォルトの名無しさん2019/06/07(金) 19:55:02.31ID:eP2De+H/

>>793
俺は好きだな。 jQuery みたいでかわいい

819デフォルトの名無しさん2019/06/07(金) 20:05:15.50ID:RHh4qcVs

関数チェイン入るんかいな。
任意のコンテナにチェイン出来るフリー関数を書きたいお年頃なオレ。

820デフォルトの名無しさん2019/06/07(金) 20:43:41.59ID:bGghseJi

C++20で構造体の指示付き初期化があるみたい。
https://ja.cppreference.com/w/cpp/language/aggregate_initialization

上の使えば
void test({.year = 2019, .manth = 12, .day =24});
は可能だな。
ただし構造体の順番通りじゃないといけないのが欠点（指示をしない場合は初期値を使用）

821デフォルトの名無しさん2019/06/07(金) 20:50:05.58ID:/Ew8uqLj

バカが好きそうなクソシンタックスばっかり入るなw

822デフォルトの名無しさん2019/06/07(金) 21:19:45.80ID:khSrdsPe

cでもあるし妥当だろ
まあ順番は面倒だが

823デフォルトの名無しさん2019/06/07(金) 21:34:52.47ID:51aJPRpO

もうずっとmanthが気になって仕方がない

824デフォルトの名無しさん2019/06/07(金) 21:57:41.25ID:PFCjrauz

質問です。

std::remove_ifは実際には要素の削除を行わない。
https://qiita.com/naka4/items/1f207b5d6acf102b0db7
「削除する要素を詰めて、サイズが縮んだコンテナの新しい終端イテレータを返す」
とのことですが

vector<shared_ptr<T>>の場合、その挙動に従わない場合があって困惑しています。
下記のコードで、erase()する前にCのデスタラクタが呼ばれているのは何故ですか。
https://ideone.com/7rp1Os

たぶんムーブの挙動の絡みのナニカだとは思うのですが…

また、この挙動はどう解釈すべきですか？
特に気にせずこのままremove_if→eraseは問題ないのか？
または規格に照らし合わせてNGだったり危険だったりするものでしょうか？

825デフォルトの名無しさん2019/06/07(金) 22:07:56.01ID:bSdf4jBS

最初はsp(10)sp(11)sp(12)sp(13)sp(14)
remove_ifするとsp(10)sp(11)sp(13)sp(14*)sp(14*) (*は共有)
sp(12)の参照カウンタがなくなったので破棄される

普通の挙動では？

826デフォルトの名無しさん2019/06/07(金) 22:10:55.22ID:bSdf4jBS

ムーブするからsp(10)sp(11)sp(13)sp(14)sp(null)か
結論は一緒だけど

827デフォルトの名無しさん2019/06/07(金) 22:12:27.62ID:khSrdsPe

swapじゃなくてmove代入されているんじゃね

828デフォルトの名無しさん2019/06/07(金) 22:21:39.08ID:RHh4qcVs

参照カウンタ増やさない方法で移動されてるのかな？？
インプレースだから、扱いが雑な気がする。

829デフォルトの名無しさん2019/06/07(金) 22:25:21.08ID:bSdf4jBS

まあremoveの外側はunspecifiedだからどうするかは実装の勝手
雑に扱われてても文句は言えない

8308242019/06/07(金) 22:34:00.62ID:PFCjrauz

各位、どうも
なんとなく分かってきました
cpprefjpでも「有効だが未規定な値」とのこと
実装依存で参照カウントが減ってゼロになるときもあるよ、そういうmoveもされ得るよ
ということですね

とりあえず返却されたイテレータが示す範囲は正常だと思うので
erase()はそのまま使う方向でいってみようと思います

831デフォルトの名無しさん2019/06/07(金) 22:56:05.74ID:khSrdsPe

雑とかそう言う話ではなく
remove_ifの実装でremove後の空きshared_ptr部分に後の要素をどうやって詰めているかだけの話
swapじゃないなら、代入にせよmove代入にせよ、その場で参照カウント減ってデストラクタが呼ばれるよ

832デフォルトの名無しさん2019/06/07(金) 23:01:56.95ID:RHh4qcVs

実装がとある一つなのだから、変数に持ち直してやるのもオーバヘッドがーという場合もある。
コンテナ上の空き領域の作り方も幾つかあって、
今回は疑似ポインタだからコピーが軽いけど、実態をいじるときは涙目になるきがす。

実装を定義してないはずだから言いようはいくつかあるけど、
インプレースでやるときは面倒だということだけ知っておけばよい気がする。

833デフォルトの名無しさん2019/06/08(土) 01:15:29.93ID:B4mMYyrz

整数の事情って結局どうするのが正しいの？
powは遅いだの何だの以前にdoubleとの間で一々キャストするのが姿勢として正しいように思えない

マクロでやってる人が多い？

834デフォルトの名無しさん2019/06/08(土) 01:33:51.17ID:f9OaJysQ

powの整数型引数のがあるんじゃない？

835デフォルトの名無しさん2019/06/08(土) 06:52:32.97ID:81RPqzS0

std::powにはないから自分で書くしかない

836デフォルトの名無しさん2019/06/08(土) 08:59:01.58ID:JxaHk6L1

>>833
整数値で指数みたいな物を扱う場合、簡単にオーバーフローが起きるので
本気でやるとしたらだいぶ恣意的なサイズ区切りを入れることになる。
そんなことやるくらいなら浮動小数からのキャストのがだいぶ楽だし実装も安定する。

837デフォルトの名無しさん2019/06/08(土) 10:35:16.88ID:uBDMoQSs

負の数が指数に与えられたら結果は少数になるけどそれでもいいなら

838デフォルトの名無しさん2019/06/08(土) 10:47:03.88ID:Yv0NxNrw

二乗だろ？
何悩んでんだよ

839デフォルトの名無しさん2019/06/08(土) 11:17:40.81ID:CfSNJA7X

>>833 整数でも問題なさそう
https://qiita.com/SaitoAtsushi/items/c729f73f7f5603910b6b

840デフォルトの名無しさん2019/06/08(土) 11:37:29.71ID:6OYPkGQi

二乗なんて直接掛け算で書き込んでもいいくらい

841デフォルトの名無しさん2019/06/08(土) 12:05:54.87ID:hw2i/19C

底が2でない3乗以上の累乗なんか整数でやろうと思ったことないな

842デフォルトの名無しさん2019/06/08(土) 18:23:48.07ID:81RPqzS0

整数の冪は速度云々よりオーバーフローが気になる
100を5乗しただけであっという間にuint32_tをぶっちぎるんだぞこえーよ

843デフォルトの名無しさん2019/06/08(土) 20:11:59.83ID:KGab8pqO

n乗してオーバーフローする整数は予め求められるんだからn乗する前に判定するだけだろ

844デフォルトの名無しさん2019/06/08(土) 20:14:05.51ID:f9OaJysQ

やっぱlog表現にすべきやな

845デフォルトの名無しさん2019/06/08(土) 20:18:41.89ID:16S9+5P1

メモリを無限に使えばええ

846デフォルトの名無しさん2019/06/08(土) 20:36:16.78ID:JxaHk6L1

>>843
判定のためにdoubleにキャストして、みたいな？

847デフォルトの名無しさん2019/06/08(土) 20:37:46.29ID:KGab8pqO

>>846
100がオーバーフローする最大値なら100と予め整数比較するだけだろ

848デフォルトの名無しさん2019/06/08(土) 20:39:53.83ID:JxaHk6L1

なるほど n=100くらいまで全て持っていればいいと。
まあそうかもな。

849デフォルトの名無しさん2019/06/09(日) 02:20:42.24ID:49FyDaAW

C++知らないことが多すぎてちょっと勉強するだけでもあーあそここれ使って書いてればよかったーってなることばっかりだわ
しばらく前に書いたコード見直したくねぇ

850デフォルトの名無しさん2019/06/09(日) 02:37:22.98ID:bDrC2N4p

そのうちこれわざわざこれ使って書く必要なかったなになるゾ

851デフォルトの名無しさん2019/06/09(日) 02:55:27.45ID:5fLgSAOM

そしてC言語が正解だったことに気づく

852デフォルトの名無しさん2019/06/09(日) 02:57:41.57ID:bDrC2N4p

それはない
コンテナはやっぱり便利
動的ポリモーフィズムは必要ねえなぁ
テンプレートで十分

853デフォルトの名無しさん2019/06/09(日) 03:16:06.77ID:/cpSAd8E

>>836
modpowは自分のライブラリとして持ってるので、それ使うことにすれば良いですかね
機能過多な感じもしますが

>>837
？
普通の挙動ですよね？

>>839
ありがとうございます。読んでみます
結果によっては素直にpowを使うことにします

>>840
今はマクロでそうしてます

854デフォルトの名無しさん2019/06/09(日) 09:31:54.10ID:/FZVYwra

テンプレートもそろそろガンだってことが普通に認識されるようになるだろうな。
標準のテンプレートだけ使ってりゃいいんだよ(それでも使いこなせないだろうが。)
バカの作るテンプレートライブラリほどひどいものはない。

855デフォルトの名無しさん2019/06/09(日) 10:15:07.88ID:Gi1Jt9cY

そりゃ堂々巡りの言い方だろ
酷い奴の作るテンプレートライブラリは酷い。そりゃそうだ
テンプレートライブラリが酷けりゃ作ったヤツは酷い。こうなるわな

856デフォルトの名無しさん2019/06/09(日) 10:55:06.08ID:jMWe1oeX

>>852
＞動的ポリモーフィズムは必要ねえなぁ
データの通りにオブジェクト作るような設計一切出来ないぞ

857デフォルトの名無しさん2019/06/09(日) 10:55:18.69ID:g07iT4nf

>>854
どこが癌なのか教えてください。

858デフォルトの名無しさん2019/06/09(日) 12:52:56.51ID:Oof3fMf0

いやテンプレート「ライブラリ」ともなれば十分な機能と性能と使いやすさを全立させるには必要スキルがダンチになる印象

そうではなくて問題に特化した形でテンプレートを使ってコードの記述量を激減させることは常人のもできる
ただし他人に理解してもらうのが困難になるからそういのうはモジュール内に囲ってテンプレートそのものを外に出さなければ宜しい

もし使いにくいとか理解しがたいだけでなく動作品質に問題があるなら、
その場合は問題のある人物が取り替えられる方向へと管理者のソーシャルスキルの発動の時間である

859デフォルトの名無しさん2019/06/09(日) 13:05:27.14ID:bDrC2N4p

>>858
それが言いたかったんだよ、うん

860デフォルトの名無しさん2019/06/09(日) 15:35:10.73ID:oBKk3YD0

正直アプリレイヤーでテンプレートを駆使したライブラリを作ることはあんまない
使う側からすれば便利な仕組みだわ

これがライブラリを提供する側になると途端に言語仕様と環境との闘いが始まる

861デフォルトの名無しさん2019/06/09(日) 15:42:19.87ID:5fLgSAOM

何回同じ話するの？
障害あるの？

862デフォルトの名無しさん2019/06/09(日) 15:46:33.89ID:S7l1hTT6

いいからお前はC言語使ってろよ

863デフォルトの名無しさん2019/06/09(日) 15:46:44.77ID:aCcbeNVM

>>859
嘘つけ

864デフォルトの名無しさん2019/06/09(日) 16:02:49.06ID:P23LzvOV

テンプレートは、コンパイラのエラーや警告が意味不明なのが玉にキズ。

865デフォルトの名無しさん2019/06/09(日) 16:08:45.43ID:5fLgSAOM

同じ話を2回する奴はガイジ死ね

866デフォルトの名無しさん2019/06/09(日) 16:17:48.67ID:Q5Gsequk

>>861 と >>865 は文面は異なれど、意図として
同一の内容を繰り返してるような気がするんだが。
「同じ話を何度も投稿する人に対する敵意」ってくくり。

これは単なる感想(自己言及的で面白い)だけどね。
発言に対しての賛同でも否定でもなく。

867デフォルトの名無しさん2019/06/09(日) 16:40:22.23ID:/FZVYwra

クソライブラリ作るやつが絶滅するまで。

868デフォルトの名無しさん2019/06/09(日) 17:20:43.24ID:g07iT4nf

そのくそライブラリを使わないといけないの？

869デフォルトの名無しさん2019/06/09(日) 19:35:59.29ID:5fLgSAOM

だったら無駄なことしてないで直接乗り込んで二度とライブラリを作れないようにしてこいやゴミ

870デフォルトの名無しさん2019/06/09(日) 20:34:56.29ID:Oof3fMf0

1. より優れたライブラリを提供すれば良い

2. 労力の関係で0スタートで新規作成は無理ということであれば
　糞ライブラリをうまくwrapしてせめて使いやすい形にして見せれば良い

3. 2の場合も中身は追って作り直すこと

871デフォルトの名無しさん2019/06/09(日) 21:12:37.07ID:Gi1Jt9cY

4. 自身の頭脳がへっぽこだと、高度すぎるライブラリは全く理解できない。
　自分が使いこなせないものはダメである。
　わたしの頭のレヴェルに合わせろ。

872デフォルトの名無しさん2019/06/09(日) 21:22:41.55ID:/FZVYwra

俺なら使いこなせるって持ってきたやつが一番使えてないパターンなんだが。。

873デフォルトの名無しさん2019/06/09(日) 21:28:31.78ID:5fLgSAOM

持ってくるｗｗｗ
2ちゃんガイジのくせに偉くなったと錯覚してて草

874デフォルトの名無しさん2019/06/10(月) 00:33:49.15ID:3V4oen/z

エモーショナルエンジン搭載。
その日の気分で結果が変わります。

875デフォルトの名無しさん2019/06/10(月) 00:36:48.31ID:jI97QXDl

それが！

PS2！?

876デフォルトの名無しさん2019/06/10(月) 08:57:25.07ID:SLwWwvWV

仕事で無駄に時間かけてテンプレート使ったライブラリ(という名のほぼ何もしないクソコード)書かれたら殺意も湧くだろうな、ネットでもそういうのはたまに見かける

熟練者が長年かけて作った、良くできたフリーのライブラリしか知らんアマチュアの人にはわからんかもしれんが

877デフォルトの名無しさん2019/06/10(月) 09:53:37.04ID:5SR5C4JK

そんなもん飼ってる上司の責任だろ
糞ができるまで放置してたのか？

878デフォルトの名無しさん2019/06/10(月) 13:21:16.85ID:SLwWwvWV

俺は仕事でそんなの見たことないけど>>854の肩を持ったまでだよ
>>854以降の流れを読んでからほざけ

879デフォルトの名無しさん2019/06/10(月) 14:24:51.11ID:MigAkPcZ

テンプレートってそんな身構えるようなものかな？
外部ツールとマクロで武装した旧黒魔術系のコードに比べたら、なんぼかましな気がするがw

880デフォルトの名無しさん2019/06/10(月) 14:45:47.43ID:SLwWwvWV

もちろん便利にはなったけど、STL以来むやみにテンプレートを持ち上げる風潮が・・・
初心者が上級者を気取りたくてテンプレート持て囃し、それだけに留まらずオブジェクト指向や昔ながらのテクニックをこき下ろしてるのを良く見かける

実行時、コンパイル時、プリプロセス時でそれぞれメリットデメリットあるんだけどなぁ

881デフォルトの名無しさん2019/06/10(月) 15:05:36.77ID:psqZaESW

プロ（仕事）の話と初心者の話が一緒になっちゃってるな

882デフォルトの名無しさん2019/06/10(月) 15:44:38.79ID:EWMjDPPL

初心者を指導せずほったらかしにしてる上司がいるらしい

883デフォルトの名無しさん2019/06/10(月) 16:11:30.07ID:psqZaESW

>>854は「普通に」って書いてるけど、
バカがテンプレートライブラリを書いてそれが仕事に害悪をもたらすなんてことが
普通にあるわけがないだろ。
仕事なら出来る奴に書かせるし、趣味なら仕事には無害。

884デフォルトの名無しさん2019/06/10(月) 17:43:59.55ID:sRT+YLgZ

できる奴が書いたテンプレートライブラリを使いこなせない奴が、グダグダ文句言っているだけだろ。

言っている奴ができる奴なら文句言う前に修正しているわ

885デフォルトの名無しさん2019/06/10(月) 18:56:35.92ID:OlE51f/u

まあマクロとかテンプレートとかみんな一度はやり過ぎるぐらい作り込んだことあるだろ
多分>>854をそれを経験した直後ぐらいなんだろ

886デフォルトの名無しさん2019/06/10(月) 19:08:07.57ID:YayWwtn2

無職がおしごとごっこでつか？ｗ
以下、職業プログラマじゃない者は書き込み禁止

887デフォルトの名無しさん2019/06/10(月) 19:10:51.22ID:ZJKeta/Q

マ板でやれ

888デフォルトの名無しさん2019/06/10(月) 19:16:09.39ID:EWMjDPPL

労働厨とかいう下級国民

889デフォルトの名無しさん2019/06/10(月) 19:22:32.34ID:5SR5C4JK

お前らautoとdecltype(auto)の違いとか言語仕様の話しで盛り上がれよ

890デフォルトの名無しさん2019/06/10(月) 19:22:55.85ID:SLwWwvWV

>>885
>>852もそれ以前の段階だろ

891デフォルトの名無しさん2019/06/10(月) 19:27:55.90ID:EWMjDPPL

イテレータを受け入れる関数もオーバーロードで書いてるんですか？

892デフォルトの名無しさん2019/06/10(月) 20:00:14.92ID:J/wxl4Rl

>>886
逆だろ
プロがこんなとこに来て語ってる方が異常だわ

893デフォルトの名無しさん2019/06/10(月) 20:34:00.20ID:0NZRWrrl

auto int i =0;

K&Rはこれでいけたんだがのう

894デフォルトの名無しさん2019/06/10(月) 20:37:49.85ID:W52LT1uh

int不要とかそういう話？

895デフォルトの名無しさん2019/06/10(月) 20:48:57.81ID:9ReisgX6

decltype(auto)はあまり使わないなぁ
長いし
面倒だからauto&&で受けちゃうし
戻り値推論もauto&とかで済ましちゃう

896デフォルトの名無しさん2019/06/10(月) 21:07:56.06ID:Ii7tq5Jr

>>884
こういうクソな思想が広まってるからクソライブラリがあとを絶たないわけだ。

897デフォルトの名無しさん2019/06/10(月) 21:35:34.30ID:9ReisgX6

クソクソ言うだけで、何がどう悪いとすら具体的に例を上げないのだからもうね

898デフォルトの名無しさん2019/06/10(月) 21:36:31.46ID:YayWwtn2

>>892
（´･∀･`）ﾍｰ
アマチュアさんはそう考えるんだね

899デフォルトの名無しさん2019/06/10(月) 21:55:37.04ID:EWMjDPPL

>>898
え？お前だけだぞこんな底辺まで来てるの
もう少し世間体とか気にしようよ

900デフォルトの名無しさん2019/06/10(月) 22:04:08.27ID:irHYgLSK

utf8の文字定数って実質ASCIIしか使えないのかコレ

901デフォルトの名無しさん2019/06/10(月) 22:42:42.99ID:J/wxl4Rl

>>898
アマチュアをからかうプロwww
エンジニアがそんなんじゃ日本の将来は暗いわ

902デフォルトの名無しさん2019/06/10(月) 23:08:47.95ID:j+S7HtNV

ていうかテンプレートが絡むととたんに問題解決できなくなるプロ

903デフォルトの名無しさん2019/06/10(月) 23:51:39.69ID:Ii7tq5Jr

テンプレートの問題なんてもう語り尽くしたわ。
それでもバカがあと立たないのもずっと見てきた。。

904デフォルトの名無しさん2019/06/11(火) 00:19:02.01ID:QaZP7mkq

テンプレートの問題について何も聞いてないし、その状態で語り尽くしたというなら何も問題はないな。

905デフォルトの名無しさん2019/06/11(火) 00:19:41.89ID:kvB4pOtR

新規参入者がいるってことだから恐悦至極なのではないか

906デフォルトの名無しさん2019/06/11(火) 00:25:55.32ID:PO+d8+1v

（果たして彼にとってはテンプレートのみが例外的に特殊な問題であって
　テンプレート以外については十分なスキルを有しているのであろうか…

907デフォルトの名無しさん2019/06/11(火) 00:53:07.47ID:7MvjruKl

コンパイル時に発見できるような問題はそもそもたいして深刻な問題ではない。

908デフォルトの名無しさん2019/06/11(火) 01:02:03.28ID:TJ/Njjhl

>>907
コンパイル時にわかる程度の問題でも、ランタイムでエラー吐かれたらデバッグ大変だよ
Pythonの型違いで嫌と言うほど思い知った

909デフォルトの名無しさん2019/06/11(火) 01:13:48.45ID:7MvjruKl

>>908
私は、ランタイムエラーを解決することの困難さに比べればコンパイルエラーなんて大したことない、という意味で言ったんだが。
あなた、読解力がないって遠まわしに指摘されること多くない？

910デフォルトの名無しさん2019/06/11(火) 01:26:55.77ID:TJ/Njjhl

そもそも文脈不明な中でそれだけ書かれてもなぁ
コンパイル時の分かるような問題かどうかではなく、エラーをコンパイル時に吐いてくれるとデバッグが捗るみたいに書けば良いのに
実際、assertやstatic_assert
SFINAE使ってのなるべく上位レイヤーでエラー発生させるのは重要でしょ

911デフォルトの名無しさん2019/06/11(火) 01:51:30.87ID:GDgSrcmQ

テンプレート駆使したライブラリ使うと最適化ありなしで速度かなり変わるの困る
デバッグビルドだとくそおっそくてデバッグがままならん
なんか良い解決法ないですかね？

912デフォルトの名無しさん2019/06/11(火) 02:00:33.22ID:TJ/Njjhl

適当なところで切る
処理の定義を別ヘッダに分けて、特定のソースファイルで定義ヘッダを読み、デバッグが必要ないところは最適化Onで明示的インスタンス化をする

913デフォルトの名無しさん2019/06/11(火) 02:07:42.02ID:7MvjruKl

>>911,912
> 処理の定義を別ヘッダに分けて、特定のソースファイルで定義ヘッダを読み

自前の切り替え処理自体が不具合の原因になりかねない。
素直にprintf()するのが一番確実でしょう。

914デフォルトの名無しさん2019/06/11(火) 02:12:17.79ID:bsFR+Nzy

C++14以降でテンプレートのデザインパターンの参考書って無い？

915デフォルトの名無しさん2019/06/11(火) 02:42:42.36ID:Pe41E3Zb

テンプレート完全ガイドの2版が出てたけど、英語

916デフォルトの名無しさん2019/06/11(火) 22:59:30.61ID:GDgSrcmQ

>>912
ソースファイルごとに最適化変えるのって簡単にできます？
VSプロジェクトかCMakeで

917デフォルトの名無しさん2019/06/12(水) 00:12:16.75ID:EuvWtF/E

VSならプロジェクトじゃなくソースのプロパティ選んで最適化変えればそこだけ反映される
まあ、それ用の構成作っておくのが安全

CMakeはわからん
makeなら簡単だけど

918デフォルトの名無しさん2019/06/12(水) 09:35:50.45ID:eCiQ25Tx

c++の場合、このコンパイラでは通るけどこっちのコンパイラでは通らないとかが
普通にある方が問題。
静的だとか動的かとかそういう問題とはまた違う。

919デフォルトの名無しさん2019/06/12(水) 09:39:04.87ID:dM+mHpC4

>>917
あ、ホントだ
ありがとうございます

920デフォルトの名無しさん2019/06/12(水) 12:59:45.38ID:pwRz5TOC

>>918
コンパイラごとに違う言語なんだから当然では？
むしろコンパイラが1つしかない言語以外でそういう問題が発生しない言語ある？

921デフォルトの名無しさん2019/06/12(水) 16:21:34.99ID:7KGE0Knu

Java、C#は「コンパイラが1つしかない言語」に含む？
どのみち比較の対象が少ないね。

922デフォルトの名無しさん2019/06/12(水) 16:22:16.09ID:7cC3bFV5

普通はコンパイラは何種類もない

923デフォルトの名無しさん2019/06/12(水) 16:24:55.92ID:EuvWtF/E

そこら辺もバージョン違いで色々あるよね

924デフォルトの名無しさん2019/06/12(水) 16:31:31.49ID:7cC3bFV5

そんなの当たり前だろ

925デフォルトの名無しさん2019/06/12(水) 16:40:28.14ID:7KGE0Knu

「コンパイラが通らない問題を解消するためにビルドツールをご用意いたしました。」
で、configureやらcmakeやらantやらといった車輪の再発明が続々生まれてくる。

926デフォルトの名無しさん2019/06/12(水) 17:19:03.04ID:79FLB/Pn

ブラウザ戦争に近いものがあるな

927デフォルトの名無しさん2019/06/12(水) 18:48:39.87ID:eqhLCWed

モダンなC++を学ぶべく右辺値参照について勉強しているのですがさっぱりわかりません
本に右辺値参照は実際は左辺値でstd::moveは実際は何もmoveしない
と書いてありましたが本当に意味がわからない
言葉遊びはいいからわかりやすく教えてくれ

928デフォルトの名無しさん2019/06/12(水) 19:07:22.06ID:iR6eT4Op

>>927
正確に言うと右辺値参照が左辺値なんじゃなくて右辺値を参照している「変数」が左辺値なのさ。
それ自体ひとつの変数なんだから当然のことだろう？

929蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 19:12:10.36ID:KzwP9Gzw

>>927
誤解を恐れずに言うと、std::moveを付けると、&&が付いた特殊な型になる。その型のことを右辺値参照という。ムーヴコンストラクターやムーヴ代入などは、その特殊な型に対して行われる。

930蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 19:17:22.52ID:KzwP9Gzw

&&が付いた引数は、中身の所有権を他の場所に譲り渡すことができる。
例えば、文字列クラスだったら、ポインタが指し示す文字列の所有権だ。所有権をコピーせずに、移動するだけなら、処理コストが低くて済む。

931 ◆QZaw55cn4c 2019/06/12(水) 19:33:55.80ID:1cw0Fvdf

>>930
所有権って何ですか？
私は一つの関数で new/malloc() した領域を、別の関数に渡し、さらに別の関数で delete/free() してますが、効率よくそういうことをする場合には所有権という架空のフレームは邪魔だと思います

932デフォルトの名無しさん2019/06/12(水) 19:36:15.70ID:qnyyQkgz

>>931
まさにそれをする為のフレームやん。

933デフォルトの名無しさん2019/06/12(水) 19:38:15.23ID:eqhLCWed

>>928
あーなるほど確かに変数に代入してる時点でそうですね
右辺値参照を保持する左辺値ということですね
納得です

>>929
std::moveに渡す型も&&ですよね
&&をもらってさらに特殊な&&を返すんでしょうか？
remove_referenceとかその辺がさっぱりです
なぜこれが必要なのか
さらにその型で所有権が移るというのもよくわからず

934デフォルトの名無しさん2019/06/12(水) 19:45:51.10ID:qnyyQkgz

右辺値というのはほっといたら消える。

どうせ消えるんだったら右辺値が確保してるメモリ、こっちでちゃんと解放するからもらうね→所有権の移動

もちろん所有権移動したので右辺値でメモリ解放しちゃダメよ。

935デフォルトの名無しさん2019/06/12(水) 19:47:37.87ID:GZDxeRSP

>>933
所有権が移るというか...
T&& x を引数に持つ関数（コンストラクタが多い）は右辺値を受け取るけど、
そこで x の所有するリソースを
分捕っていいという「慣習」「イディオム」があるというだけなんだよ。

936蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 20:10:41.45ID:0iE+TYdc

>>933
そこを厳密に理解するには、lvalue, rvalue, prvalueなどの値カテゴリを理解しないといけない。
https://ja.cppreference.com/w/cpp/language/value_category
要するにlvalueをxvalueにするために、std::moveを使う。

remove_referenceは、type traitsと呼ばれる「型に対する演算」を行っているに過ぎない。
std::moveの実装のremove_referenceは、冗長な参照を削除している。
type traitsは、テンプレートに慣れないと使いどころが分からないだろう。

937蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 20:24:57.03ID:0iE+TYdc

class STRING
{
public:
...
// ムーヴコンストラクタ(一例です)。
STRING(STRING&& s) : m_ptr(nullptr)
{
std::swap(m_ptr, s.m_ptr);
}
// ムーヴ代入(一例です)。
STRING& operator=(STRING&& s)
{
std::swap(m_ptr, s.m_ptr);
return *this;
}
protected: char *m_ptr;
};
...
STRING s("abc123");
STRING t;
t = std::move(s);

938蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 20:34:03.21ID:0iE+TYdc

右辺値参照で挫折したら、Rustに進むがいい。
C++を完全に理解した人間は1%も居ない。

939デフォルトの名無しさん2019/06/12(水) 20:39:57.61ID:W9DAWVrH

蟻人間は行列理解からだな

940蟻人間 ◆T6xkBnTXz7B0 2019/06/12(水) 21:02:08.90ID:KzwP9Gzw

あほですみません。。。

941デフォルトの名無しさん2019/06/12(水) 21:03:19.70ID:wMzR7R80

難しいというよりただ複雑
概念的にそれほど難しいわけではない

942デフォルトの名無しさん2019/06/12(水) 21:07:19.74ID:JHNh+ipy

ムーブセマンティクスは今世紀最大の発明と言われてるからね。

943デフォルトの名無しさん2019/06/12(水) 21:11:21.95ID:7TWmWXJk

最近は標準ライブラリも文法も分かりやすくなったなと思ったら
initializer_list絡みの初期化がこのやろう

944デフォルトの名無しさん2019/06/12(水) 21:17:48.45ID:hxuK959+

・仮引数が右辺値参照&&なら、そこに渡した変数はぶっ壊される（そのかわり速いかもしれない）
・ただし安全のために使い捨ての一時変数か、std::moveを付けて「壊していいよ」と明示したものしか渡せないようになってる

これだけ理解してればだいたいOK

945デフォルトの名無しさん2019/06/12(水) 21:27:52.71ID:7cC3bFV5

ややこしいとか言う奴に限ってパターンの一覧表作っていつでも参照できるようにしないよな

946デフォルトの名無しさん2019/06/12(水) 21:52:10.38ID:eqhLCWed

このスレを読んだらだんだんわかってきました

>>937
なるほど
この例で使い方は何となく理解できたかもしれないです
abc123を一切コピーすることなく引き渡しているということですね
コンストラクタに右辺値が渡された時は自動的に&&のコンストラクタがよばれ(これはコンパイラが自動で判断してくれる)
コピーでは明示的に右辺値参照にしないとダメなのでstd::moveを使うと

947デフォルトの名無しさん2019/06/12(水) 21:59:50.66ID:eCiQ25Tx

右辺値判定はコンパイラ側も困ってそう

948デフォルトの名無しさん2019/06/12(水) 22:03:44.51ID:hxuK959+

厳密に決まってるから困らないぞ

949デフォルトの名無しさん2019/06/12(水) 22:42:16.79ID:JHNh+ipy

【 constexpr の掟】
「ブッ殺す」と心の中で思ったならッ！その時スデに行動は終わっているんだッ！

950デフォルトの名無しさん2019/06/12(水) 23:19:39.59ID:zt+60oVn

>>931
所有権というのは権利を連想させるようないかにもお得な感じを醸し出しているネーミングだが
その実体はオブジェクトの開放を最後の一人だけがやる「義務」に他ならない

で、「最後の一人だけに開放させる」というのを>>931のように
>別の関数に渡し、さらに別の関数で delete/free()
というのは大悪手に他ならない
なぜなら呼び出し先で最後かどうかなど（所有権やレキシカルな手法では）管理し切れない
所有権は呼び出し元ががっちり掴んでおくもの

951デフォルトの名無しさん2019/06/12(水) 23:36:10.29ID:dKzVqNYa

moveしたあとの変数を使おうとしたらエラー出してくれるの？

952デフォルトの名無しさん2019/06/12(水) 23:44:04.96ID:vc+7745/

まさか

953デフォルトの名無しさん2019/06/12(水) 23:51:54.31ID:EuvWtF/E

元の内容について所有権を失っているだけで普通は使える様になっている
スマポならnull相当
vectorみたいなのならemptyもしくは何らかのごみが入っているのでclearか新たに代入すればおk

954デフォルトの名無しさん2019/06/13(木) 00:01:02.92ID:GxcaYm6A

>>953
>元の内容について所有権を失っているだけで普通は使える様になっている
moveしたあとの変数について述べているのなら完璧な間違いだ
藻前のプログラムはバグだらけだな

955デフォルトの名無しさん2019/06/13(木) 00:16:54.69ID:VunnpS2y

合ってるだろ
ムーブ後のオブジェクトは内容は未規定だけど有効な状態だぞ、少なくとも組み込み型と標準ライブラリはな
褒められたプログラミングスタイルかはともかく、再利用すること自体が即間違いとは言えない

956デフォルトの名無しさん2019/06/13(木) 00:26:16.00ID:/TtN03F/

>>951
ムーブコンストラクタを書いて自分で処理するんだよw

957デフォルトの名無しさん2019/06/13(木) 00:26:51.45ID:scxOg7Fk

コンパイル時に既に顧客の要求を満たしてるとかマジカッコいい

958デフォルトの名無しさん2019/06/13(木) 01:25:50.43ID:bj2tv0KH

少なくとも標準ライブラリでこれが出来ないと、メンバ変数の内容一つmoveしただけで親のオブジェクトまで使えなくなる。
メンバ変数再利用する術が無いってことだからね

959デフォルトの名無しさん2019/06/13(木) 01:41:54.12ID:/Ra8Vlso

>>957
未初期化の変数をコンパイル時に検出できるんだからmoveした後かどうかも判定できるはずでしょ

960デフォルトの名無しさん2019/06/13(木) 02:03:22.10ID:/TtN03F/

>>958
メンバ変数１つムーブって、どういうこと？
普通メンバ変数は右辺値にならないでしょ。

961デフォルトの名無しさん2019/06/13(木) 03:03:13.46ID:bj2tv0KH

2分木で子のスマポ所有しているような場合、付け替えとかで所有権の移動するときshared_ptrならコピーでokだけど、unique_ptrみたいなのだとmoveする事になるが、メンバ変数で持っていた子の内容をmoveしたあとその変数が再利用可能じゃないと困るだろ

962デフォルトの名無しさん2019/06/13(木) 03:21:55.87ID:/TtN03F/

>>961
c++11で導入されたmoveはいわゆる所有権の移動とは違うもなので、その場合はmoveは使えないと思う。

963デフォルトの名無しさん2019/06/13(木) 03:33:01.74ID:fPdkPYzy

>>962
unique_ptrのmoveが所有権の移動じゃないと言うなら一体何なら「所有権の移動」だと言うのか。

964デフォルトの名無しさん2019/06/13(木) 03:46:23.77ID:/TtN03F/

もともと右辺値参照とmoveセマンティクスの話じゃなかったっけ？

965デフォルトの名無しさん2019/06/13(木) 04:35:02.91ID:qBl/BLKs

ループの中で int a なる整数を使うとき、ループ内で毎回宣言するのとループの外で宣言して使い回すのどっちが結局速いの？

966デフォルトの名無しさん2019/06/13(木) 09:17:30.68ID:wJ3u1v7j

自分で計ればいいじゃん

967デフォルトの名無しさん2019/06/13(木) 11:30:46.72ID:eqzI8P56

ループの外に出せるものは可能な限りすべて出せ

968デフォルトの名無しさん2019/06/13(木) 12:09:07.93ID:Br82W2pC

範囲for文を使ってそんなどうでもいいことは忘れろ

969デフォルトの名無しさん2019/06/13(木) 13:18:06.43ID:XHz4etUG

>>967
逆じゃないか？
インスタンスの生成にコストがかかるときはトレードオフだが、そうでないなら可能な限りスコープを狭くなるように変数を宣言した方が良いと思う

970デフォルトの名無しさん2019/06/13(木) 13:33:35.83ID:eqzI8P56

スコープ気にするならループ関係の部分だけでスコープ区切ればいいじゃん

971デフォルトの名無しさん2019/06/13(木) 15:27:33.99ID:P5difHG2

>>970
お前は何を言ってるんだよ…

972デフォルトの名無しさん2019/06/13(木) 15:28:06.57ID:PncfQdvG

cppcheckやVisual Studioのような静的コード解析にかけると「スコープを小さくできるよ？」みたいなアドバイスが出るよね。
実際のところ、どうなんだろうね。typoしにくくなったりスタックサイズが小さくなる利点があるとは思うけど。

973デフォルトの名無しさん2019/06/13(木) 16:20:20.51ID:fzRArnQO

さすがにこの流れは草

974デフォルトの名無しさん2019/06/13(木) 16:22:08.63ID:jHLKLHUC

ちょうど今朝cppcheckかけたら
style: The scope of the variable 'c' can be reduced.
「変数 c のスコープを縮小できますよ」って出たわ。
つまり「スコープを狭くできるなら狭くすべき」っていう方針を、
(少なくともcppcheckを作ってる人は)採用してるんだろうな。

どっちが速いかについては、ちょっと最適化オプションつければ
結局同じマシン語になっちゃうんじゃないかしら。

975デフォルトの名無しさん2019/06/13(木) 16:29:14.63ID:gMp0DWLA

>>967
セオリーだからって鵜呑みにするの良くないよ
(というか文面だけ覚えても意味ない

976デフォルトの名無しさん2019/06/13(木) 16:30:01.81ID:57+ky1er

スコープ広いほうが良いなら最終的に全部グローバルにしろやになるやんけ

977デフォルトの名無しさん2019/06/13(木) 17:32:58.81ID:fC2jn4Im

オブジェクト指向って実はprivate変数のスコープをかなり広く取ってるセミグローバル指向だと思う

978デフォルトの名無しさん2019/06/13(木) 17:37:28.56ID:wJ3u1v7j

おれは思わないな

979デフォルトの名無しさん2019/06/13(木) 18:39:42.63ID:XHz4etUG

>>977
それってクラスを大きくしすぎているだけじゃないか？

980デフォルトの名無しさん2019/06/13(木) 19:54:06.23ID:fmTPRROb

この流れは関数切り出しをまともにやってない連中が多いってことだな。。

981デフォルトの名無しさん2019/06/13(木) 23:39:11.49ID:ktOVSBzy

そろそろ次スレ。わっちょい。

982デフォルトの名無しさん2019/06/15(土) 13:52:11.56ID:DKQ0QQLH

次スレ
C++相談室 part143
http://2chb.net/r/tech/1560574313/

983デフォルトの名無しさん2019/06/15(土) 18:36:57.85ID:YCpCWY7o

最近馬鹿の一つ覚えが多いな
>>982 乙乙

984デフォルトの名無しさん2019/06/15(土) 19:13:31.09ID:wEtwZJzN

覚えてるだけまし。

985デフォルトの名無しさん2019/06/15(土) 19:37:22.36ID:y49ayDRp

グローバル変数と言っているのはオブジェクト指向スレを荒らしてるバカだろ

986デフォルトの名無しさん2019/06/16(日) 15:07:40.82ID:TXhOXCMI

任意の型に対応する整数を返すメタ関数ってC++11の標準であったりします？

intなら1
stringなら2
みたいな
上記の技法をなんと呼ぶかわからないので検索ワードも思い付かず…

987デフォルトの名無しさん2019/06/16(日) 15:52:45.94ID:eI7bdJXk

なんでﾜｯﾁｮｲついてんの？
スレ立てミスだろ

988デフォルトの名無しさん2019/06/16(日) 16:00:01.99ID:gyfVRbSU

>>986
std::type_info::hash_code()が似た機能を持ってるけどメタ関数かどうかわからない。たぶんランタイム。
https://cpprefjp.github.io/reference/typeinfo/type_info/hash_code.html

989デフォルトの名無しさん2019/06/16(日) 19:19:35.33ID:PFinGY+5

質問ですがC++のクラスのメソッドは、大別すると、
コンストラクタとデストラクタとsetterとgetterと何になるの？

990デフォルトの名無しさん2019/06/16(日) 19:22:19.26ID:NJ2skO19

move? be?
ステートチェンジしていくのだから、動作になるのか？

991デフォルトの名無しさん2019/06/16(日) 19:31:47.13ID:Va3vueK+

setterとgetterって何？
Javaじゃあるまいしそんなの言語要素としては用意してないよ

992デフォルトの名無しさん2019/06/16(日) 21:57:17.90ID:PFinGY+5

>>991
setterとgetterが何かについてはｸﾞｸﾞった方が良い

Javaは詳しくは知らないが、ｸﾞｸﾞった限りにおいて
Javaでもsetter/getterを定義する専用の言語要素など用意されていない印象

993デフォルトの名無しさん2019/06/16(日) 22:03:52.19ID:PFinGY+5

で、C++/Javaどっちも
　{ setter } ∪ { getter } ⊂ { メソッド }
であることは明らかだが、では
　Q1. { メソッド } - ( { setter } ∪ { getter } )には何か専用の名前は無いのか？、
というのが>>909の質問の主旨。

ついでに言うと
　Q2. { setter } や{ getter }というのは本当に確定した集合なのか？
と、
　Q3. 「操作」と言ったときそれは{ メソッド }を指すのか　{ メソッド } - ( { setter } ∪ { getter } ) を指すのかどっちなんじゃ、
とかも知りたい

994デフォルトの名無しさん2019/06/16(日) 22:04:40.86ID:fCIbdDP9

>>989
シグナルとスロット（Qt脳）

995デフォルトの名無しさん2019/06/16(日) 22:54:20.07ID:PFinGY+5

>>994
シグナルとスロットというのはGUI操作を処理する目的のﾌﾞﾂなので、
実行時の時間コストがゼロコストに近いことを気体されているハズ、
よって { メソッド } - ( { setter } ∪ { getter } ) の全て（この中には実行時の時間コストが青天井のﾌﾞﾂも含まれる）を
包含しはしないのではないか、

まあここまで書いてｵﾓﾀが、 { setter } ∪ { getter } こそ実行時時間コスト0を期待されるから、
setterやgetterは次の定義で良いのではないかという気がしてきた…

- 属性を取得する目的の操作であり、かつ実行時時間コスト≒0の実装が今現在も保たれているのがgetter

- 属性を変更する目的の操作であり、かつ実行時時間コスト≒0の実装が今現在も保たれているのがsetter

996デフォルトの名無しさん2019/06/16(日) 22:56:35.57ID:PFinGY+5

後ろ2行訂正orz、
正：
- 属性を取得する目的で設けられた操作であり、かつ実行時時間コスト≒0の実装が今現在も保たれているのがgetter

- 属性を変更する目的で設けられた操作であり、かつ実行時時間コスト≒0の実装が今現在も保たれているのがsetter

997デフォルトの名無しさん2019/06/16(日) 23:24:38.97ID:PFinGY+5

補足すると、「属性を取得する目的」や「属性を変更する目的」というのは、
インターフェースをクラスの主要な機能とは独立に変更できることを暗に言っている

例えばクラスFooのsetBar()が真にsetterならば、
属性をsetterでセットするのをやめて（Foo::setBar()を廃止して）ファイルから
直接読み込むメソッドFoo::readFromFile()に置き換えても、
クラスの主要な機能Foo::mainFunc()は変更せずに済むハズ

getterについても同様

998デフォルトの名無しさん2019/06/16(日) 23:56:38.00ID:WOfC/Ugn

operator=がsetterでoperator()がgetterにならない？

999デフォルトの名無しさん2019/06/17(月) 00:00:50.16ID:x+yzwFNm

c++かどうかなんて関係ない、オレオレ分類しているだけだろ

1000デフォルトの名無しさん2019/06/17(月) 00:01:28.14ID:7HzfXopw

ずれてるのを承知で書くけど、直接読み込むメソッドってやつも含め setter なんてない方がいいよ