C++相談室 part142

**デフォルトの名無しさん** · 2019/04/01(月) 22:17:05.84

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/
C++相談室 part141
https://mevius.5ch.net/test/read.cgi/tech/1550772463/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2019/06/10(月) 09:53:37.04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 17:43:59.55

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 18:56:35.92

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

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 19:10:51.22

マ板でやれ

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

労働厨とかいう下級国民

**デフォルトの名無しさん** · 2019/06/10(月) 19:22:32.34

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 20:00:14.92

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

**デフォルトの名無しさん** · 2019/06/10(月) 20:34:00.20

auto int i =0;

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

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

int不要とかそういう話？

**デフォルトの名無しさん** · 2019/06/10(月) 20:48:57.81

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

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 21:35:34.30

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/10(月) 22:42:42.99

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

**デフォルトの名無しさん** · 2019/06/10(月) 23:08:47.95

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/11(火) 00:25:55.32

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

**デフォルトの名無しさん** · 2019/06/11(火) 00:53:07.47

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

**デフォルトの名無しさん** · 2019/06/11(火) 01:02:03.28

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

**デフォルトの名無しさん** · 2019/06/11(火) 01:13:48.45

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

**デフォルトの名無しさん** · 2019/06/11(火) 01:26:55.77

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

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

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

**デフォルトの名無しさん** · 2019/06/11(火) 02:00:33.22

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

**デフォルトの名無しさん** · 2019/06/11(火) 02:07:42.02

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

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

**デフォルトの名無しさん** · 2019/06/11(火) 02:12:17.79

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 00:12:16.75

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

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

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 09:39:04.87

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

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 16:21:34.99

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

**デフォルトの名無しさん** · 2019/06/12(水) 16:22:16.09

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

**デフォルトの名無しさん** · 2019/06/12(水) 16:24:55.92

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

**デフォルトの名無しさん** · 2019/06/12(水) 16:31:31.49

そんなの当たり前だろ

**デフォルトの名無しさん** · 2019/06/12(水) 16:40:28.14

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

**デフォルトの名無しさん** · 2019/06/12(水) 17:19:03.04

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

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

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

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

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

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 19:12:10.36

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

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 19:17:22.52

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

◆QZaw55cn4c · 2019/06/12(水) 19:33:55.80

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

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

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

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

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

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

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

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

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

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

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

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

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 20:10:41.45

>>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は、テンプレートに慣れないと使いどころが分からないだろう。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 20:24:57.03

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);

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 20:34:03.21

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

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

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

**蟻人間** ◆T6xkBnTXz7B0 · 2019/06/12(水) 21:02:08.90

あほですみません。。。

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 21:07:19.74

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

**デフォルトの名無しさん** · 2019/06/12(水) 21:11:21.95

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

**デフォルトの名無しさん** · 2019/06/12(水) 21:17:48.45

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 21:27:52.71

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

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 22:03:44.51

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

**デフォルトの名無しさん** · 2019/06/12(水) 22:42:16.79

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

**デフォルトの名無しさん** · 2019/06/12(水) 23:19:39.59

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

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

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

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

**デフォルトの名無しさん** · 2019/06/12(水) 23:44:04.96

まさか

**デフォルトの名無しさん** · 2019/06/12(水) 23:51:54.31

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/13(木) 04:35:02.91

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

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

自分で計ればいいじゃん

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

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

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

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

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

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

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

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

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

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

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

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

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

さすがにこの流れは草

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

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

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

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

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

**デフォルトの名無しさん** · 2019/06/13(木) 16:30:01.81

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